OSDev.org

Hello!
I'm writing a xhci driver for my OS, all of the code runs well on QEMU.
But, when I run my OS on my computer, after the ENABLE_SLOT command sent, it looks like it is stuck.
I can ensure that the interrupt handler of XHCI can work normally, and I can receive the interrupt from the event ring when I reset the port. However, after the ENABLE SLOT command is issued, the handler does not run. Then the system looks jammed.


The code which related to the problem: Line 1326.
https://github.com/fslongjin/DragonOS/b ... ci.c#L1326

And, after I ring the doorbell at Line 1565, the problem come into being:
https://github.com/fslongjin/DragonOS/b ... ci.c#L1565

I have thought for a long time and still can't solve the problem. How can I solve this?

It's hard to tell what's wrong at a glance, but have you confirmed that the command ring works with No Op TRBs?

Also, it appears you're not assigning any scratchpad pages?

Demindiro wrote:It's hard to tell what's wrong at a glance, but have you confirmed that the command ring works with No Op TRBs?

Also, it appears you're not assigning any scratchpad pages?

Yeah, the NOP trb can run properly after I ring the doorbell. And, is the scratchpad buffer necessary?

longjin wrote:And, is the scratchpad buffer necessary?

It absolutely is. Imagine what would happen to your program if it had no memory / something started randomly overwriting memory in it

Emulators such as QEMU do not need scratchpad buffers since they have access to malloc() which is faster & safer anyways.

Demindiro wrote:
It absolutely is. Imagine what would happen to your program if it had no memory / something started randomly overwriting memory in it

Emulators such as QEMU do not need scratchpad buffers since they have access to malloc() which is faster & safer anyways.

I haven't thought about this before. The problem solved with your help, thank you!!!

May I ask you another question?

After I reset the port, and try to send ADDRESS_DEVICE again, something came wrong. I received an event TRB, which has completion code=17, trb type=33. It means a Parameter Error. (It can work on QEMU but the computer)
I only want to get the device descriptor, so I only set the slot_context and control EP context in the input_context. How can I solve this?
The code: https://github.com/fslongjin/DragonOS/b ... ci.c#L1379

longjin wrote:I received an event TRB, which has completion code=17, trb type=33. It means a Parameter Error. (It can work on QEMU but the computer)

QEMU is quite lax and ignores many of the parameters it doesn't need (unlike real hardware).

Parameter Error means you didn't properly configure one or more fields in the Input Context. Looking at your code it appears you're not initializing a lot of fields, such as the maximum packet size. If you set the same fields as I do it should work fine (my code is GPLv3 but I give you permission to use it).

Demindiro wrote: Looking at your code it appears you're not initializing a lot of fields, such as the maximum packet size. If you set the same fields as I do it should work fine (my code is GPLv3 but I give you permission to use it).

Hmm, what I do is, copy the slot_context and ep_context from device_context of the port to the input context directly. I think this should contain all the information we need. The function works at the first time. But at the second time, it failed.

And, I try to directly send the ADDRESS_DEVICE command with BSR=0 to the device (just comment out Line 1356~1375), and successfully got the descriptor.

So, why I cannot request the first 8 bytes and reset the device, then set address again, and request all 18 bytes?

longjin wrote: Hmm, what I do is, copy the slot_context and ep_context from device_context of the port to the input context directly. I think this should contain all the information we need.

Unfortunately, the controller takes the same shortcut. It copies most fields from the input context as is to the output context,

longjin wrote: So, why I cannot request the first 8 bytes and reset the device, then set address again, and request all 18 bytes?

I'm almost certain that you can. On the other hand, you could also send a evaluate context cmd instead of resetting the device.

xeyes wrote: I'm almost certain that you can. On the other hand, you could also send a evaluate context cmd instead of resetting the device.

Hmm, I'll try it. Thank u!!!