filkra wrote:
Korona wrote:
Yes, the BIOS should set up PCI bridges and MTRRs. I never encountered a BIOS that does not do this correctly but I know that Linux has so code to check and/or reconfigure bridges for PCs with BIOS bugs. These bugs seem to be rare but they do exist. You could at least dump the (non-host-)bridge's setup and make sure that everything is correct.
I checked the EHCIs PCI bus and it's 0, so (if I understood this correctly) PCI bridges shouldn't be involved, should they?
That should be a correct assumption, but someone with better knowledge should probably answer that one.
filkra wrote:
Is it wrong to set the control queue head (for the control endpoint) to address=0, endpoint=0, maxPacketSize=64, linkPointer=&idleQueueHead, pipeMultiplier=0x01 (1 transaction / micro frame)and speed=0x2 (high-speed). All other queue head fields are 0x0. After this I set the idleQueueHeads linkPointer to my new queue head.
Some requests need the device to be in the addressed state, however, you are still trying to get the Device Descriptor, so address = 0 is correct. I just thought of something. You don't have more than one device attached do you? i.e.: there are not two or more devices in the default state? If so, this might cause a parity error.
filkra wrote:
In fact, how do I know which speed to set before getting the device descriptor? Currently, I know it's a high-speed device, so I hardcoded it.
Simple. If you are on a UHCI or OHCI controller, check the bit in the port register for LS or HS. If you are sending packets via the EHCI, it is a HS. This works most of the time. Rate Matching Hubs, along with a few other things can be a factor. However, if you are sending packets via the EHCI due to the fact that the EHCI set the enabled bit on one of its ports, you can (mostly) assume it is a high speed device.
Ben