I was asking specifically about function number. Whenever you find a device during the brute force scan where you go through all bus and slot numbers, there can be other related devices hidden on other function numbers with that same bus and slot number. This happens with USB, for example, where if you find a USB 2 controller on function 0 you can expect to find associated USB 1 controllers in the same place but using different function numbers, and there can be unused function numbers between used ones, so you need to check them all. (There's no need to check them if there's no device on function zero though, which is why the brute force scan only looks at 256 x 32 addresses rather than 256 x 32 x 8.) The lack of any content in the BAR fields for function 0 for your multimedia audio device means that the HDA address must be hidden somewhere else.Ethin wrote:If you mean the prog if, status, and command offsets, I have those, which may answer your question
Remember too that Spyder told you this:-
Have you looked at that address to see what's there? It should be safe to read those memory-mapped ports, so what do the first few look like? Read 256 bytes from there and paste what you find into a reply here. I'll tell you if it looks right, and if so, you can start programming your driver for it and resolve the PCI issue later.In QEMU, the HDAudio base address is 0xFEBF0000. You can simply hard-code this address for your Intel HD Audio logic, for now.
