[SOLVED] xHCI Address Device (BSR=0) and Device Descriptor queries return completion code 4

[BenLunt]

Since there is an issue with either Bochs or OVMF and cdroms, I extracted the following files from your image:

• efi\boot\bootX64.efi
• initrd.img
• kernel.elf
• NvVars

and placed them on a hard drive image with a GPT and a FAT32 volume.
Then I booted it with Bochs and OVMF.

It made it to the EFI shell and then loaded and ran bootX64.efi.
After a few lines of status, it (I presume) loaded the initrd.img file since it read quite a bit from the drive.
Bochs then PANICed with:

Code: Select all

32209838221p[PIC   ] >>PANIC<< slave:  PIC ID = 7 not supported
32209838224p[PIC   ] >>PANIC<< master: slave PIC IRQ line not supported

and shortly later your OS crashed with the following:

Are you able to create a hard drive image with a PMBR, a GPT, and then the FAT32 volume as apposed to the .ISO image you have?
(If you are on a Windows Host, you can try this utility to make and copy the files to it.)

Is the crash related to Bochs, OVMF, or your OS--I didn't investigate. However, with the past tests, I found out that there is something wrong with Bochs and CDROMs when EFI is used. Something I will have to look into.

Also, I hope this helps you investigate why your OS doesn't run on Bochs, if you wish to further investigate.

Ben

[Octocontrabass]

NvVars

Try deleting this file. OVMF creates it when your virtual machine doesn't have NVRAM, but it might cause OVMF to misbehave if it was created using a different version of OVMF or using different (virtual) hardware.

It might also explain why you're unable to boot from the virtual CD.

[BenLunt]

NvVars

Try deleting this file. OVMF creates it when your virtual machine doesn't have NVRAM, but it might cause OVMF to misbehave if it was created using a different version of OVMF or using different (virtual) hardware.

It might also explain why you're unable to boot from the virtual CD.

Unfortunately, in this case, that doesn't fix the problem. Both still have the same results.

[alnyannn]

So, I've reduced the driver's code (https://git.alnyan.me/alnyan/yggdrasil/ ... ler.rs#L99) to just do one thing: setup the xHC and start receiving interrupts, where I just print the PORTSC bits and clear the pending WR1C ones. The issue with port 6 (USB3.1) connecting and immediately disconnecting still persists, though I've managed to rule out a few extra possible causes:

* Not PCI PM related — I've additionally enabled the PMCSR.PME_En bit, because the xHCI specs says it gates the PME# signal. Not sure that was necessary, but I enabled the bit just in case
* It is not caused by the USB2.0 companion port "taking over": when I disable PP for port 2 (USB2.0 companion to Port 6), I still get the connect-disconnect PORTSC value pair in port 6, I just stop getting a connect PORTSC event in port 2, that's it.
* Forcing the U0 (PLS=0) port state by setting the Link State Write Strobe bit and writing an U0 state into PLS manually when CSC=1, CCS=1 is received does not change anything in port behavior.
* The disconnect does not seem to be caused by a link training error: PORTPMSC.LEC stays at zero all the time.
* The issue also wasn't caused by the xhci register interface library I was using — I rewrote all the register access to use my own code instead of a library and the result is still the same.

[BenLunt]

Without being able to see myself, i.e.: run your code through my tests, I can only speculate what is happening. However, a thought came to mind. Are you setting the power bit for the USB 3.0 port and clearing the power bit for the USB 2.0 port? This bit is synonyms (I think that is the word I want to use).

i.e.: if memory serves, if you set the power bit in the USB 3.0 port, the power bit in the USB 2.0 port should show the same. If you clear the power in the USB 2.0 port, the USB 3.0 port should show it cleared too.

Ben

[alnyannn]

I have finally managed to solve this problem. There were actually two main issues about my code:

• I've overlooked the part of the specification where it says that it is the xHC who allocates the bus addresses, not the system software. I was trying to stuff some address I've allocated myself into the Slot Context, which likely led to the xHC becoming confused and starting to send data to a wrong address/not being able to communicate with the device.
  
  The correct approach is to set the address in the Slot Context to zero, let the xHC do its own thing via the Address Device TRB (BSR=0), then just read back whatever address the xHC gave to the device from the Output Device Context.

• I was clearing RW1C/RW1CS bits in PORTSC incorrectly by just doing "portsc_write(portsc_read() | bits_to_clear)", which wrote incorrect bits to positions that should be preserved. Properly masking the "reg_read()" result by preserving only the RO and RWS bits fixed the issue.

I've managed to get the Mass Storage device working on my real hardware (albeit veeery slowly), plus got a functioning HID Keyboard. Thanks everyone for your time, I'm marking this thread as solved

[BenLunt]

I'm glad that you found the error(s). It is usually the small things that you tend to not see since your instinct is to think of the big things.

If you ever get around to, and have the interest to do so, to create a bootable GPT image instead of an ISO, please let us know. I would still like to have a hands-on look at it.

Thanks,
Ben