OSDev.org

I've been trying to figure out this problem for several days now, and I've been through dozens of threads where people have had similar problems, but I'm still at a complete dead-end.

The short version is that I can't seem to get my EHCI controller to actually read my async QH or TD records from memory and process them, even though everything appears to be running properly.

I've verified the following:

* The controller Run flag is active, the async list is active in the Status register, and the Frame Index register is incrementing at a normal rate.
* I've tried setting up and enabling the Periodic list to see if had any effect, but it did not.
* I am getting Frame Index Rollover and Port Change interrupts, but I am not getting Async Advance or Transfer Complete interrupts.
* When I set the Next Async List Address register to a chain of QH records, it does not change from the initial setting, and none of the QH working areas are updated.
* No error flags are ever set in the Status register.
* I've tried using the Reclaimation Head flag in my QH records, and not using them, with no effect. The Reclaim flag is never set in the Status register in either case.
* The EHCI version is 0x0100, the 64-bit memory support flag is not set in the capabilities register, and the PCI configuration extension address is 0x00 (none).
* The PCI command register is 0x07, so bus master, memory access and I/O access are all enabled.
* The PCI status register is 0x10, so no Error or Abort flags are set.
* I get the exact same behavior in both VirtualBox and VMWare, both of which work properly when running Windows XP.
* I've tried different virtual and real USB devices with the exact same results.
* The 64-bit segment register is 0x00000000, and I'm running a 32-bit CPU.

I have no idea why it isn't working. I don't think the controller is even attempting to read the async QH records from memory, but I can't figure out why.

Can anyone think of anything that I may be missing?

EDIT: Also, I'm setting the Config register to 0x01, and my port status has an Owner flag of 0x00, and a connected flag of 0x01, so port ownership does not seem to be a problem.

Do you set the interrupt-on-async-advance doorbell in the command register? The EHCI does not issue an interrupt on async advance when you don't ask it to do so. Interrupt on async advance is a garbage collection tool; it should not be used to track transaction progress.


I don't think the async list base register is supposed to be changed by hardware (but I did never read it back to verify). I assume the active bit on those TDs is set and the halt bit is clear? What transactions are you trying to perform? Is the QH set up correctly with your device, endpoint and endpoint speed?


Can you elaborate on that? I assume your QHs form a ring with the async list base pointing to the first element and the reclaim flag is set for exactly one element. Is that correct?


I assume that you also performed a proper reset and that the enabled status bit of the port is one?

Yes, my QHs for my Async List form a ring, and I have tried both setting the Reclaim Head flag on the first, and the last, and on none of the QH records, and it didn't affect anything. I don't think that the device is even attempting to read my async QH records at all, because I'm not getting any errors regardless of what I put in the QH data.

After controller initialization, before port reset:
Controller Status: 0x0000400C
Port Status: 0x00001003

After port reset, QH, TD and Next Async List Address setup:
Controller Status: 0x0000C00C
Port Status: 0x00001005

Obviously the controller has no problem reading and writing its own registers. It just seems to not want to read my async list at all. All of my addresses are physical, as everything is identity mapped at this stage. Is there some other reason why the device wouldn't have access to a particular RAM address, but would not cause any error bits to be set in the status register, or send any interrupts?

I don't think there is anything that prevents the controller from accessing system memory. Is the controller on a root PCI bus? Is it on a PCIe bus? At least on real hardware EHCI usually sets the host system error bit if you point it to RAM that does not exist. Are you sure that your QHs/TDs are set up correctly?

The OHCI and EHCI controller both are on a PCI bus, not PCIe. I'm not sure why they would need to be on the root PCI bus, but I can check.

The RAM definitely exists, as I can read back my QH and TD structures just fine.

I've been over the EHCI registers and the QH/TD structures, as well as the PCI configuration registers for 3 days straight. I'm sure that there is something wrong, somewhere, but I can't imagine where it could be. Since I've checked and double-checked everything I can think of, and since I get the exact same results on two different VMs (VirtualBox and VMWare), and since everything works if I run WinXP with the exact same configuration, I'm guessing that I'm missing something simple, like a PCI flag or something.

I may just change all of my addresses to a completely different area, just in case I'm colliding with something. I'll also check the memory map.

It does not have to be on a root bus but that would rule out misconfigured PCI-to-PCI bridges.

Do you have the option to check with qemu? Of course if the code is correct it should probably work everywhere but trying an additional emulator might help with debugging.

Hmm. QEMU is interesting. The ECHI controller appears to be running already when I start up the machine.

So, I can reset it, set everything up, enable the controller, and that works fine.

When I reset the port and setup the Async List and QH/TD structure, and then set the Async List Address register, and enable the Async schedule, nothing happens. The Async List register doesn't change. It remains at zero, and the status register also doesn't change from 0x100C. Retrying a few times yields the same results, but then after like 4 retries, it starts working, and the registers will then match VirtualBox and VMWare.

This ECHI controller does have a PCI extended register area, unlike VirtualBox and VMWare, so it may have a BIOS -> OS handoff that needs to be done, but so far it appears to work about the same as the other two VMs, except for not working the first few times.

Maybe there's a clue in there somewhere. I'll try to play around with it more tonight.

Thanks, guys.

EDIT: I just realized that whoever set up the EHCI controller in QEMU left everything in memory configured properly, so I'm going to just walk through their registers and queues and capture everything and start analyzing it

EDIT2: SONOFA~~~

I knew it was going to be something stupid...

QH has a "TD Work Area" that contains a copy of the current TD, but before that it has the address of the current TD. I was setting the current TD address to my first TD.

Instead of setting the "Next TD" inside the work area to my first TD address...

Which makes perfect sense.... now...

Thanks for the help, guys