OSDev.org

Posted: **Wed Jan 13, 2021 4:29 pm**

Hello Everyone.

I decided to work once again on my XHCI driver.
The problem is that it is not working fully on real hardware.
I got two real hardware computers where I test my driver on for XHCI (I got 3 real computers, the 3rd one only has EHCI ports)

Let me explain what goes wrong on the devices:
DeviceA:
DeviceA has a working command ring (response on NOOP events)
DeviceA gets a deviceID
DeviceA gets an address
DeviceA is not responding to items when I put them on the ring which is addressed at the set-address command.

DeviceB:
DeviceB has a working command ring(response on NOOP events)
DeviceB does not create an event in the event queue when assigning a device slot

URL to code: https://github.com/AdeRegt/SanderOSUSB/ ... dev/xhci.c

Does someone have a bit of advice on where I should look at? Since I am sure it cannot be a problem with the timing since the system patiently waits until the event is added to the event ring. And how do you usually debug XHCI code?

Posted: **Thu Jan 14, 2021 3:28 am**

SanderR wrote:Hello Everyone.

I decided to work once again on my XHCI driver.
The problem is that it is not working fully on real hardware.
I got two real hardware computers where I test my driver on for XHCI (I got 3 real computers, the 3rd one only has EHCI ports)

Let me explain what goes wrong on the devices:
DeviceA:
DeviceA has a working command ring (response on NOOP events)
DeviceA gets a deviceID
DeviceA gets an address
DeviceA is not responding to items when I put them on the ring which is addressed at the set-address command.

DeviceB:
DeviceB has a working command ring(response on NOOP events)
DeviceB does not create an event in the event queue when assigning a device slot

URL to code: https://github.com/AdeRegt/SanderOSUSB/ ... dev/xhci.c

Does someone have a bit of advice on where I should look at? Since I am sure it cannot be a problem with the timing since the system patiently waits until the event is added to the event ring.

A couple of pitfalls are the following:
1. The scratch pad area. Some XHCI require this to work
2. Some XHCI use 32 byte context entries while other use 64 byte.
3. XHCI doesn't need to support 64-bit addresses

SanderR wrote: And how do you usually debug XHCI code?

Usually with my built-in kernel debugger, but having a USB analyzer definitely is a plus too. I have Beagle USB 480 from total phase. It doesn't support USB 3 though, but they have one for that too that costs a lot.

Posted: **Thu Jan 14, 2021 12:05 pm**

SanderR wrote:Does someone have a bit of advice on where I should look at? Since I am sure it cannot be a problem with the timing since the system patiently waits until the event is added to the event ring. And how do you usually debug XHCI code?

Hi guys,

First, I am with rdos on this one, a good hardware analyzer is best. I have one of Total Phase's myself. It is a wonderful tool to have, though for a hobbyist, the expense may be a little much.

Without an analyzer, do you have the Bochs source code and the capabilities to compile it? If so, set the BX_DEBUG()'s to true, and then add some of your own. Print out a whole lot of debug lines until you find where something is going wrong. Then start removing those debug lines until you find the exact cause. This is a slow process, but works quite well.

When I wrote the original UHCI and OHCI source for Bochs, this is exactly what I did, though the Beagle Analyzer[1] was a great help to see what exactly was happening on real hardware.

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

[1] Please note that I am not affiliated with TotalPhase, though they were very kind to donate a unit for the development of my book, which I used extensively. It made the research so much easier.

Posted: **Thu Jan 14, 2021 3:25 pm**

Yes, they are really expensive. I got mine from work as we needed to analyse USB problems. I wish I had it to start with as it's so much easier to work with. I also wish there were some common file format for USB that drivers can log in and then the log could be opened in a Windows program. Similar to Wireshark for networks, which is free too.

One thing that the analyser will not catch is when the USB hardware fails, and it might not catch all the errors that transfers creates either.

I think the biggest challenge with doing USB drivers is to create a common interface. Especially XHCI is quite different from UHCI, OHCI and EHCI. I've done a complete rebuild of my interface and all the drivers, and it's a bit more like XHCI now, and control transfers are treated as the special case they are.

Posted: **Thu Jan 14, 2021 4:23 pm**

Hello everyone,

Thank you very much for the answers.
I have added the scratchpad buffers in the way I read from the manual.
https://github.com/AdeRegt/SanderOSUSB/ ... ci.c#L1540

I did checked if the address and the contextsize where both 64 bits, and they where on both hardware.

For the context size problem: I do not see where I should use 32bit only.

BenLunt: you are saying I should use BOCHS to test. I will see if BOCHS gives an error like this. It would probably be a good way to see how linux for example handles a device like this.

Posted: **Thu Jan 14, 2021 8:55 pm**

I've been having similar problems on VirtualBox:

Code: Select all

[xHCI] Reset port 0 (USB2) SUCCESS
[xHCI] Attempting to initialize device
[xHCI] Failed when enabling slot: Error code 0x0 (aka timed out)

and (formerly I guess, it's working now

) VMware. Have you tried either of those? They don't offer as much debug as Bochs, but testing on multiple different systems can sometimes help identify problems.

Try looking at the way you initialize ports of different types (USB2/3). Make sure you are sending the correct port ID and routing number to the controller. That's where my problem was when I had similar results to yours.

-----------------------------

In any case, I can't get your OS to run with xHCI keyboard on QEMU SanderR. I've tried this command with both of the GRUB options:

Code: Select all

qemu-system-x86_64 -cdrom cdrom.iso -device qemu-xhci,p2=1,p3=0 -device usb-kbd

It just gets stuck after

Code: Select all

Run!
System up and running wtih USBCMD 5 and USBSTS 0
Event Ring Control: pointing at event 0

Just a tip: Have the debug output go to serial. If you haven't implemented it, it's <super simple>. It makes it WAY easier to copy and paste text, as well as scroll through the entire debug output.

Unfortunately, I don't have any real devices with xHCI & BIOS to test your or my code on right now

. I may consider getting a USB3 PCIe card soon.

-----------------------

rdos wrote:A couple of pitfalls are the following:
1. The scratch pad area. Some XHCI require this to work

Huh. I may need to look into figuring them out and implementing them. Am I correct that after they are allocated they don't need to be touched?

Posted: **Fri Jan 15, 2021 1:56 am**

SanderR wrote:Hello everyone,
I did checked if the address and the contextsize where both 64 bits, and they where on both hardware.

For the context size problem: I do not see where I should use 32bit only.

I assume you mean bytes. I have one (newer) computer that has 64 bytes context size and another a bit older that has 32 bytes, so both variants exist in real hardware.

However, I don't know if there are any real computers that have more than 4G of physical memory and an XHCI chip that doesn't support 64-bit addressing. I suspect this is rather uncommon and possibly doesn't need to be supported.

OSDev.org

XHCI: problem with real hardware

XHCI: problem with real hardware

Re: XHCI: problem with real hardware

Re: XHCI: problem with real hardware

Re: XHCI: problem with real hardware

Re: XHCI: problem with real hardware

Re: XHCI: problem with real hardware

Re: XHCI: problem with real hardware