1

I am writing a driver for the xHCI and I have been having a problem with the address assignment.

Here's what I am doing:

  1. Reset the controller by writing 1 to the USBCMD.HCRST and wait for USBSTATUS.CONTROLLER_NOT_READY flag to clear.
  2. Set the maximum slots enabled in the config register to 16 (which is the max supported by my xHC).
  3. Allocate the device context base address register on a 64 byte aligned memory location and write that address to the dcbaap register.
  4. allocate scratchpad buffers, write their addresses in an array, then write the address of that array in the 0th entry of the dcbaap.
  5. Allocate a command ring and write its address in CRCR.
  6. Set the R/S bit and wait for the controller not ready flag CNR to clear.
  7. Allocate event ring, and event ring segment table with one entry, and write the address of table in ERSTBA
  8. Then the software waits until a device is connected on port 12, I connect the device to port 12 and I can see the port goes to the enabled state as indicated by PP, CCS, PED being 1, and PR and PLS being 0.
  9. Submit an enable slot command and I get an event on the event ring with a success completion code and a slot ID.
  10. allocate output and input device contexts data structures and initialize them to valid values.
  11. allocate transfer ring and write its address to the input context.
  12. Submit the first address device command with BSR = 1 and I get an event on the event ring with success completion code.
  13. Here is where things go wrong: submit the second address device command with BSR = 0, and I get USB transaction error for the completion code.

In the xhci spec rev 1.2, it says the USB transaction error is the result of a USB3 DPP(Data Packet Payload) Error. I looked in the USB3.2 rev 1 and it said DPP error could happen due to any of the following:

1.CRC incorrect

2.DPP aborted

3.DPP missing

4.Data Length in the Setup DPH does not match the actual data payload length.

I've been trying on this for about 2-3 weeks now and getting nowhere. I did see a post here where someone had this issue with the EHCI and they fixed it by reducing their delays. I tried to do a similar thing but still didn't fix it.

Does anyone have an idea why am I getting this error or how do I go about fixing it?

Something I want to note is that if skip step 8, an continue to enable slot command, I still get the same results. So I still get a device slot and I still get a successful first Address Device command even though there is no device connected. Which makes me think that the usb device isn't even talking? I'm using a thumb drive, I tried different thumb drives and different ports and still the same issue. I'm using a USB 3.0 thumb drive on a SS port.

effendi
  • 103
  • 8
  • Why do you do a second Address Device Command? I don't remember the xHCI spec so well and I'm not at home curently so I'll look into the spec when at home. – user123 Nov 11 '21 at 11:44
  • I actually looked andd it is not told to do 2. Unless I'm missing something. – user123 Nov 11 '21 at 12:00
  • As told in the xHCI spec, "the BSR flag may be used by software to provide compatibility with legacy USB devices which require their Device Descriptor to be read before receiving a SET_ADDRESS request". Is your device USB 1.0? Otherwise, the second Address Device Command is certainly returning an error because there simply should not be one. Simply do one Address Device Command with BSR as 0. Otherwise, the behavior may be undefined. – user123 Nov 11 '21 at 13:58
  • My device is 3.0. I still get the USB Transaction Error with one Address Device command with BSR = 0. – effendi Nov 11 '21 at 14:58
  • Lot of things can be wrong with your driver. In particular see one of my own question here: https://stackoverflow.com/questions/68281522/how-to-determine-on-which-root-hub-port-is-connected-a-usb-device-after-an-enabl. – user123 Nov 11 '21 at 15:05
  • 1
    You seem to think that the Enable Slot Command enables a specific slot while it doesn't. It sends an enabled slot id but selects which one by itself. Also, you have twelve root ports on your xHCI? That seems suspicious. Before I had only 8 and I had the most recent motherboard with an i9 CPU. The CPU has nothing to do with this but the motherboard (and chipset) was very recent. Also, are you testing your driver on QEMU? – user123 Nov 11 '21 at 15:10
  • You made a good point on port numbers and that fixed the problem. It was an off by 1 error. The problem is that when I write the port number in the input device context, I am writing port 12 when I should be writing 13 which confirms my suspicion that the device isn't even being reached. I was taking the port number from the offset of the port register on which the "attach" happened instead of the one posted on the event ring. Thank you very much! – effendi Nov 11 '21 at 15:50
  • maybe post that as an answer. – effendi Nov 11 '21 at 15:51
  • No problem. Happy that it worked out for you. Mine is still buggy. I could actually get the device descriptors of the USB device but I'm stuck because of a weird virtual memory related bug when I tried to switch to a upper half kernel. I kind of abandoned for now but I'll go back to it when I have some time. – user123 Nov 11 '21 at 15:53
  • Yes, the port number has nothing to do with the slot id. The port number is the root hub port number that is not related to Device Slots as seen by the xHC. – user123 Nov 11 '21 at 15:54

0 Answers0