OSDev.org

Hi There,

It has been a while since I have posted something on this forum but I, once again, need your guys help .
Recently I decided to start working on my USB support again. It was working in general but I felt that it could be improved a lot, secondly I needed to add some new functions in order to make my mouse driver work. Re-coding UHCI and OHCI succeeded with some big struggles, but I did manage to get them both working in the end.

After applying some updates to my EHCI driver I decided to test it, and surprise surprise, it actually worked . Only on qemu and virtualbox though, real hardware somehow refused to reset and initialize the controller. I did some digging and found out that the following occurred: Every register on the EHCI controller reads as 0xFFFFFFFF (See register dump bellow).



To be honest I have no idea how this could be happening. I have faced a lot of stupid issues with USB controllers lately but those at least seamed to make sense afterwards.
The initialization code can be found here: https://github.com/Remco123/CactusOS/bl ... ci.cpp#L53
Note: Code works fine on virtual machines and register values are correct

Really hope one of you guys can help me with this!

Thanks in advance,
GhelloWorld/Remco123

Really quick, did you enable I/O in the PCI Config Register. Bit 1, if memory serves correctly.

Ben
- http://www.fysnet.net/the_universal_serial_bus.htm

Hey Ben,

Yes I tried setting both the IO and Memory space bits in the command register. This did not change anything unfortunately.
Perhaps something to note: I have tested the driver on 2 physical machines with the same result so I am pretty sure that the EHCI controller is not broken or something like that.

Since you are reading 'F's, you are reading from non-existent memory, aka, I/O space, so here are a few ideas.

1) is the BAR a 64-bit BAR and you are only using the bottom 32-bits of the address? Not really likely, since most will only use a 32-bit address, even if the BAR is marked 64-bit.
2) check the hardware specs for the device. Some devices use a device specific mechanism to enable its function. For example, there might be a bit in the PCI config space that you must set. This bit will be in a device-specific byte offset within the PCI Config Space.
3) (You already checked?) Make sure the Mem I/O Enable bit is set in the PCI Config register.
4) check your memory read code. If the register is 32-bit read only, yet your compiler is optimizing it byte reads, the hardware might return 'F's. For example:

If I was to guess, I would think that 2) above is the culprit. I have seen this on about 3 or 4 machines when I was doing my R & R (not specific only to USB either).

Ben
- http://www.fysnet.net/the_universal_serial_bus.htm

Hello Ben, Thanks for helping me out!

Lets go over each point one by one shall we?
1) The BAR reports it has a 32-bit address so I am pretty sure that I am using the right address. I Also checked it with a linux liveCD and then the linux kernel uses the same address as mine (0xFFA80800).
2) After some searching I found that the controller is a: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller. I could not really found a datasheet for the device except for this one. But that one only describes the registers and is not talking about initialization of the device.
I did however found out that linux had the SERR# bit set in the pci command register, so I decided to check if that would make any difference. It did not change anything though.
3) Yes, I am 100% sure it is enabled. I also tried setting both the IO and Memory bit but that also did not change anything.
4 ) I am pretty sure that if this is the case the code would not work on emulators, but it does. There is also no optimization performed on the kernel so the compiler should not mess with that.

I understand that this is a uncommon issue and difficult to fix but I really appreciate the help.

By the way: Really enjoying your USB book Ben, it is very useful.

Out of curiosity, what is the "EHCI regBase -> 0xC1500000" line below?

The EHCI Capability Registers start at 0xFFA80800, adding the length retrieved from the LEN field, should be something like 0xFFA80820. The value of 0xC1500000 is a bit off of that point, if in fact, that is the base of the Operational registers. Remember, you have to read the whole DWORD to get the length, then mask off the extra part(s).


Thank you for the kind words.

Ben

You forgot to add the low 12 bits of the address.

So I figured it out, thanks guys!

I always assumed that the address used by memory mapped devices was Page-aligned. When I mapped the physical address of the controller (0xFFA80800) to the virtual address (0xC1500000) I forgot to check for non-aligned addresses. So instead of reading at 0xFFA80800 I was reading registers at 0xFFA80000, which obviously, where not connected to anything.

Problems solved with following code: