OHCI Controller refuses my ED

[MollenOS]

Hi, after a short OS-dev break i'm back working on my Usb Drivers.

I'm having some issues thought. I can get the OHCI controller running and I do recieve interrupts from the controller. Currently I set up some queues of ED's that all have the sKip bit set and both their Head & Tail pointer is set to a dummy Td. I can see by inspecting the HcControlHeadED and HcControlCurrentED with some ms aparat that it is indeed iterating the list untill it reaches the end of the list.

Now i set up my SetAddressRequest with a list of TD's, stop the OHCI-controller, modifies the ED to Flags (0x400000) and set the Tail & Head pointer accordingly to the list of my tds, with their physical addresses of course.

But, it simply stops iterating when it reaches the ED I've modified after enabling the OHCI controller again. I can see in the HcControlCurrendED that it is simply stuck at the ED I just modified, it goes no further. The HcCommandStatus is saying that the Control List is enabled and all registers seem to be fine. The condition code of the TD's attached to the ED is still NOT-ACCESSED (0xF), so it isn't processing the Tds. I inspected the Flags of the ED after the OHCI controller stops at my ED and the flags does not change, nor does the Halted bit in Head Ptr set.

The flags of the ED should be correct, it's a high speed, address 0, endpoint 0 (setting address request), control request.

Anyone has an idea of what is wrong?

[SpyderTL]

Just a guess... You need three TDs in order to successfully send a command to a USB device and get a response:

TD 1 - Copy the command block from system memory to the USB device
TD 2 - Copy the response data from the USB device to system memory
TD 3 - A dummy TD to use as the TAIL.

TD 1 should point to TD 2, and TD 2 should point to TD 3 (in their NEXT field).

The TAIL for the endpoint should be set to TD 3, and the controller will stop sending data when the current TD matches the tail TD address.

This is my understanding of how this works, and this is the approach that I use in my OS for OCHI controllers, and it works in my OS.

[MollenOS]

I use the same procedure, but even in the scenario Mt TDs were wrong, wouldn't I get an error code or wouldn't the halted bit be set?

I always add a dummy td to the end so it doesn't skip the last td when tail == head

[SpyderTL]

wouldn't I get an error code or wouldn't the halted bit be set?

Not if the controller thinks that it's done. I think an ED only gets halted if there is a problem. Reaching the end of a TD chain does not halt the ED (I don't think). So if you have the tail set to TD 2, it will simply send TD 1 and then wait for the tail register to change for that ED.

Again, this is my understanding, and may be incorrect...

EDIT: There is another possible problem that I ran into while I was working on my OHCI code, that took me a little while to figure out. I was using the DATA0/DATA1 flag in the TD to specify the correct sequence, but this became a problem if I ever had an ODD number of TDs, because the toggle would be left in an ODD state, and I had no way of knowing which state it was in. I switched the TD flag to use the ED's toggle flag instead of the TDs flag, and that cleared things up. Just thought I'd mention it.

[MollenOS]

Thanks really much for your feedback so far! Could it still be the TDs that are wrong if the Head Ptr of the ED isn't moving but still points to the same head?

And my set address request has 3 TDs, Setup, Status and Dummy for the last.

I will look into whether or not my data toggles are correct, it might be they are not.

[SpyderTL]

Also, make sure the Halt flag is set in your ED until your TDs and Head/Tail are all setup properly, then clear the halt flag.

Also, in case it wasn't clear, the Next field on your ED needs to be zero, assuming you only have one ED. And the device address on that ED needs to be zero. It will always point to whatever device just had its port reset. Also, make sure you are resetting the port for the device before sending the Set Address command.

After you send the Set Address command, you will need to add another EP that points to whatever address you sent to the device.

[MollenOS]

I have both the sKip bit set and halted bit set in all EDs before modifing them.

I have attached how the TDs and the ED is set up, does everything look correct? This is a SetAddress packet

[SpyderTL]

I'm using TD flags 0xe0e00000 for TD1, 0xe0f00000 for TD2, and 0xe0000000 for TD3.

Try those flags and see if it helps.

Setting the halted bit on the ED shouldn't be necessary, either. Just set the skip bit.

The skip bit is 0x4000. You don't have it set in the code that you posted above.

[MollenOS]

Using your flags didn't work either. The Skip bit is set before it prints it out, it modifies the flags to what you see above and print them (we set up the TD queue and update tail/head ptr before switching off the Skip bit).

I should mention, my OHCI driver works perfectly on all emulators, Bochs, VirtualBox, Qemu etc, they all do process it. It simply get's stuck at my ED on real hardware. Again, thanks for your feedback so far!

[SpyderTL]

On real hardware, OHCI is only used if 1) there is only one USB controller, or 2) you connect a USB 1.0 device to a machine with an OHCI controller. Otherwise, EHCI is used instead.

[MollenOS]

On real hardware, OHCI is only used if 1) there is only one USB controller, or 2) you connect a USB 1.0 device to a machine with an OHCI controller. Otherwise, EHCI is used instead.

Even if I route everything to companion controllers?
It detects my Usb Flash Drive on port 1, I successfully reset the port but it won't process my EDs. Is this really because OHCI isn't used for it even though it detects a device on the port?

[SpyderTL]

I'm not sure exactly how the EHCI -> OHCI handoff works. I haven't gotten that far.

But if you figure it out, let me know. I'll need that info here shortly.

EDIT: Some other things to check... I'm assuming that you've tested this device on this machine in Windows, and it works... Also, could the BIOS be interfering in some way? If this is a USB thumb drive, are you booting from this device?

[MollenOS]

Hmm I haven't tested the thumb drive in Windows on the laptop, but I would assume that Windows would use the EHCI driver for it.

Yes I boot from the thumb drive, the BIOS is unfortunately really limited, almost just to boot priority, so I can't play around that much in it.

I'm going to verify my EHCI -> OHCI handoff code, but I'm pretty sure it works, otherwise I shouldn't be able to detect a device on the port if I'm correct

[SpyderTL]

You may be able to disable the EHCI controller in Windows, and leave the OHCI controller enabled, which should force every device to use the OHCI controller, similar to what you are trying to do in your OS.

I went through the EHCI and OCHI specs, and it looks like you are doing everything correctly at first glance, but here are some ideas that you can try:

1. Reset the EHCI controller, which should force all connections to use the OHCI controller.
2. Check the OCHI interrupt status register when the controller stalls after the first TD.
3. Dump the DoneHead and InterruptStatus registers on any interrupts from the controller. Look for ScheduleOverrun flags, and make sure that these interrupt flags are handled and acknowledged properly. I doubt a VM will ever throw a ScheduleOverrun error, so it may be something that only happens on real hardware.
4. Play around with the Frameinterval register. This is something else that would probably work fine on a VM, but may require special attention on real hardware.

I'm assuming that all USB 2.0 devices should work with the OHCI controller if the EHCI controller is disabled or the port is switched to the companion controller, but maybe someone here can verify that for sure.

EDIT: 5. In order to rule out the BIOS as a culprit, try booting from a CD instead of the USB thumb drive, and then plug the thumb drive in and see if it works with the OHCI controller.

[MollenOS]

Thanks for your response, I found an issue in my HcFmInterval, while I did save and restore it, it seems that boot firmware failed to set it up properly on my laptop, so the Max Packet size was set to 0.

I don't know yet if that was the actual issue, I'll find out tonight, but it certainly could be the issue