This is the source code in a zip file of my OS, which only prints the contents of the sbrn register of the xhci controller:
section 5.2.3 of the xhci spec it says that the SBRN register must return 0x30, 0x31 or 0x32, but it returns 0x20 in my code and I would like to know why. Am I doing something wrong? If so, what is it? I am a little bit desperate to have this working because I've been trying for a long time to have a 'hello world' code working, and I tried to make an example showing how the Event Ring is supposed to work, but when I saw the source code of other osdevers I realized that this register is returning the wrong value and I'd like to fix that before going any further, especially since BenLunt confirmed that it returns 0x30.
By the way, the version of VirtualBox I have installed is 6.1.12 r139181 (Qt5.12.8)
EDIT: Removed broken github link with zip file with source code.
In the xhci: sbrn register reporting 0x20
xhci: sbrn register reporting 0x20
Last edited by slammar on Wed Dec 23, 2020 12:30 pm, edited 2 times in total.
Re: xhci: sbrn register reporting 0x20
I know I might look like if I were being lazy asking this, but could you please provide an example OS showing how the Event Ring of the xhci works? One that sends a noop TRB to the command ring and then reads the content of the event TRB that is supposed to be generated, please?.
And by this I mean the simplest possible OS showing only this with minimum code.
I know there are many OS out there but most of them are too complex to analyze.
Thanks in advance.
And by this I mean the simplest possible OS showing only this with minimum code.
I know there are many OS out there but most of them are too complex to analyze.
Thanks in advance.
Re: xhci: sbrn register reporting 0x20
Hi,
Unfortunately, it isn't just a simple task to do. You have to have all of the parts correctly initialized. The code I linked to above is pretty much as simple as it can get. It uses FreeDOS on a DOS only machine. It still uses 1,230 lines of code not counting the common items for all controllers. USB is not simple...
As for your result of 0x20 for the SBRN, this tells me you are getting the EHCI controller and not the xHCI controller. If you are running this in VirtualBox, you do need to make sure the xHCI part of the interface is selected, though I am sure you have done this already.
Second, since I don't use VirtualBox very much, there is a chance that the emulator is passing all function to the actual hardware on your machine. If this is the case, there are some controllers that start off in EHCI mode (for backward compatibility) and you must tell the controller that you are xHCI aware. This takes specific code that is specific to the hardware. This usually can be "changed" in the BIOS settings. At boot, hit the "SETUP" key (maybe F2) and see if there is a setting that tells the USB hardware to be EHCI or xHCI.
Ben
Currently, the relative code is missing from the github.slammar wrote:This is the url to the source code of my OS, which only prints the contents of the sbrn register of the xhci controller:
https://github.com/adriancuadrado/osdev_xhci
I am sure that is just a typo, but it should be 0x30, 0x31, or 0x32.slammar wrote:In section 5.2.3 of the xhci spec it says that the SBRN register must return 0x13, 0x31 or 0x32, but it returns 0x20 in my code and I would like to know why.
The source code to my book shows how to get the device's Device Descriptor.slammar wrote:I know I might look like if I were being lazy asking this, but could you please provide an example OS showing how the Event Ring of the xhci works? One that sends a noop TRB to the command ring and then reads the content of the event TRB that is supposed to be generated, please?.
And by this I mean the simplest possible OS showing only this with minimum code.
I know there are many OS out there but most of them are too complex to analyze.
Unfortunately, it isn't just a simple task to do. You have to have all of the parts correctly initialized. The code I linked to above is pretty much as simple as it can get. It uses FreeDOS on a DOS only machine. It still uses 1,230 lines of code not counting the common items for all controllers. USB is not simple...
As for your result of 0x20 for the SBRN, this tells me you are getting the EHCI controller and not the xHCI controller. If you are running this in VirtualBox, you do need to make sure the xHCI part of the interface is selected, though I am sure you have done this already.
Second, since I don't use VirtualBox very much, there is a chance that the emulator is passing all function to the actual hardware on your machine. If this is the case, there are some controllers that start off in EHCI mode (for backward compatibility) and you must tell the controller that you are xHCI aware. This takes specific code that is specific to the hardware. This usually can be "changed" in the BIOS settings. At boot, hit the "SETUP" key (maybe F2) and see if there is a setting that tells the USB hardware to be EHCI or xHCI.
Ben
Re: xhci: sbrn register reporting 0x20
Weird, I checked it out and I can see my code even logged out of github.BenLunt wrote:Hi,Currently, the relative code is missing from the github.slammar wrote:This is the url to the source code of my OS, which only prints the contents of the sbrn register of the xhci controller:
https://github.com/adriancuadrado/osdev_xhci
Fortunately, I attached the source code, so you should be able to see it if you download and extract the contents of the zip file.
Yes, it was a typo. It's fixed now.BenLunt wrote:I am sure that is just a typo, but it should be 0x30, 0x31, or 0x32.slammar wrote:In section 5.2.3 of the xhci spec it says that the SBRN register must return 0x13, 0x31 or 0x32, but it returns 0x20 in my code and I would like to know why.
I am not 100% sure what you mean by this, but when I read the Class, Subclass and Prog IF pci registers I make sure their values are 0x0C (Class = Serial Bus Controller), 0x03 (Subclass = USB Controller) and 0x30 (Prog IF = XHCI (USB3) Controller). Is this what you are talking about?BenLunt wrote: As for your result of 0x20 for the SBRN, this tells me you are getting the EHCI controller and not the xHCI controller. If you are running this in VirtualBox, you do need to make sure the xHCI part of the interface is selected, though I am sure you have done this already.
I only saw a single option in my entire BIOS configuration regarding that, which was something like USB legacy support and it was turned on. I turned it off, but the result stay the sameBenLunt wrote: Second, since I don't use VirtualBox very much, there is a chance that the emulator is passing all function to the actual hardware on your machine. If this is the case, there are some controllers that start off in EHCI mode (for backward compatibility) and you must tell the controller that you are xHCI aware. This takes specific code that is specific to the hardware. This usually can be "changed" in the BIOS settings. At boot, hit the "SETUP" key (maybe F2) and see if there is a setting that tells the USB hardware to be EHCI or xHCI.
Re: xhci: sbrn register reporting 0x20
Sorry, my mistake. This whole time I was thinking of the Programming Interface value, and that is the value I verified in the post you reference. There really is no need to verify the SBRN, so I just took it for granted that you meant the Programming Interface value. Again, my mistake.slammar wrote:I am not 100% sure what you mean by this, but when I read the Class, Subclass and Prog IF pci registers I make sure their values are 0x0C (Class = Serial Bus Controller), 0x03 (Subclass = USB Controller) and 0x30 (Prog IF = XHCI (USB3) Controller). Is this what you are talking about?BenLunt wrote: As for your result of 0x20 for the SBRN, this tells me you are getting the EHCI controller and not the xHCI controller. If you are running this in VirtualBox, you do need to make sure the xHCI part of the interface is selected, though I am sure you have done this already.
The SBRN, Serial Bus Release Number, should be 0x30. I have not verified that it is 0x30 in VirtualBox. If it is still 0x20, then my guess is that it is an artifact from the EHCI code copied over when the first implementation of the xHCI code was written, and then never checked or updated.
As I mentioned before, the SBRN is not necessarily important. i.e.: There really isn't any need to check it. You have the correct values for the Class, Sub-class, and Programming Interface values, so therefore, it is an xHCI--Enough of a check as far as the PCI(e) is concerned.
Ben