EHCI controller recieves Master Abort

[madeofstaples]

Hello,

I've been working on understanding how to implement USB support. My code is running in real mode (at least for now), booting from a USB drive (so I don't even scan the PCI bus for the EHCI controller, I just use INT 0x13/AH=0x48). I've left the BAR as the BIOS has it configured.

My EHCI controller supports the Pre-OS to OS handoff synchronization capability (section 5.1 of EHCI specs), and I've successfully transfered ownership from the BIOS over the EHCI controller (the BIOS appears to issue a reset to the controller in doing this).

I've successfully reset the controller (again), initialized registers, enumerated ports with devices attached, and reset those ports.

I've arbitrarily picked an offset of 32MBs to start storing the data structures for the asynchronous schedule (each structure aligned to a MB, so I'm certain that alignment is not an issue), the isochronous schedule is turned off. I've been sure to execute wbinvd before enabling the asynchronous schedule, so that I know the structures have been committed to system memory.

I've added slightly longer delays than called for in the USB 2.0 specs, and I've even added delays of up to 5 seconds after bringing ports up and preparing the data structures, but before starting the asynchronous schedule.

When I do start the schedule, the EHCI controller does not advance the queue before it halts with a status flag to indicate

Host System Error... In a PCI system, conditions that set this bit to 1 include PCI Parity error, PCI Master Abort, and PCI Target Abort.

So I checked the value of the PCI Configuration Space's Status register, which turned out to be 0x2290, indicating that the device received a master abort. I gather that this means the EHCI controller is unable to read from system memory, though the bus mastering bit is set... so I'm a little lost, could anyone please help point me in the right direction?

Thanks

[Dex]

First let me say you have done very well to get that far, but without see the code it would be very hard to help you.
The only thing that sticks out is your addressing, you say your in real mode and are addressing upwards of 32MB.

[madeofstaples]

Sorry my code is really messy as of right now from trying all sorts of things, I'll try to fix it up and make it easier to read.

I've enabled the A20 address line, of course, and I use the a32 prefix where necessary to use 32-bit address sizes.

I've been playing around with the code more today and I've made a few discoveries:

• If I make an inactive queue head, the EHCI controller is fine.
• If I make two inactive queue heads, the EHCI controller is fine and I can see that it successfully reads the address of the second queue head from the first queue head.
• When I make the second queue head active with active control transfer descriptors, the EHCI controller encounters this PCI error without changing anything in the transfer overlay area.

I picked 32MB arbitrarily based on the fact that I know that the BIOS' Get System Memory Map reports this as available memory, and I don't have a memory allocator implemented at this level.

The only thing I can think of at this point is that I am not understanding the specs correctly on the layout of the queue heads and transfer descriptors...

First let me say you have done very well to get that far

Thanks! EHCI looked to be the most difficult from skimming over the three specifications, so I'm tackling that one first. I'd be happy to contribute to the wiki when I'm done if someone else isn't already working on it.

[madeofstaples]

Aha! the problem I was having had to do with the EHCI's 64-bit addressing capability. Mine has this capability, but I overlooked that fact knowing the machine running this code only has a 32-bit processor (intel atom). Still, an EHCI controller with 64-bit addressing capability expects the extended data structures in Appendix B.

Now, I'm still having some errors, but I think it's just some misunderstanding about how to construct qTDs and queue heads.


Edit: It seems to work now after giving a slightly longer delay between resetting the ports and populating the queue. Successfully read a device descriptor. Almost done with basic EHCI...

[jal]

Almost done with basic EHCI...

Congrats, not many dare venture into the complex realm of USB. Be sure to update the Wiki for all us mere mortals to read :).


JAL