EHCI didn't works at real PC and VirtualBox!

[MrLolthe1st]

On QEMU all works, but i'm can't test hub on EHCI port, but on real hardware i'm can't connect some devices to root hub, because i'm have only one device on root hub: external hub. I'm isn't connecting external hub: i'm haven't it.

[BenLunt]

On QEMU all works, but i'm can't test hub on EHCI port, but on real hardware i'm can't connect some devices to root hub, because i'm have only one device on root hub: external hub. I'm isn't connecting external hub: i'm haven't it.

I'm sorry. That makes absolutely no sense to me.

On QEMU all works, ...

I was unaware that QEMU supported External Hubs with devices connected to this emulated external hub. However, I don't use QEMU a whole lot, so I can be a bit behind.

... but i'm can't test hub on EHCI port, but on real hardware i'm can't connect some devices to root hub, because i'm have only one device on root hub: external hub. I'm isn't connecting external hub: i'm haven't it.

Again, sorry. I don't know what you mean at all.

Ben

[MrLolthe1st]

I'm said, that hub, i've detect is connected to one of ports of EHCI.

[SpyderTL]

Just to clarify what Ben is saying, the USB "ports" that are inside your machine, connected directly to the motherboard, can be accessed by PCI memory and I/O reads and writes by the CPU. But, if you plug in an external USB hub, the "ports" on the external hub can not be controlled directly by the CPU. You must send USB commands to the external hub, and the external hub is responsible for controlling the ports on that hub.

So, the code you write to reset a device that you plug directly into your PC is completely different from the code you write to reset a device that is plugged into an external USB hub.

You do not need to create any USB descriptors to reset a device plugged directly into your PC, but you must create one or more Transfer Descriptors (TD) in order to reset a device connected to an external hub.

This is also true for all USB versions, not just EHCI.

[MrLolthe1st]

Ben, thanks at lot! Now i've working(on real PC,QEMU,BOCHS) EHCI driver with hub, mouse and keyboard drivers.
But on VirtualBox my EHCI didn't works! What it may be?

[BenLunt]

I don't use Virtual Box that much, so I cannot speak for Virtual Box. Also, with that little bit of information, I couldn't even begin to tell you why... Sorry.

Ben

[MrLolthe1st]

Hi everyone! I've written EHCI driver and driver to some USB devices(Hub, Keyboard, Mouse, Stick). On QEMU, Bochs and real hardware my driver works fine.
But on VBox my driver successfully intits the HC and trying to send control request to device. But, my queue haven't process ever. In debug mode i've see right values for HC. But it freezes.
What it may be? Code listed above.
With best regards,
Aleksandr

[MrLolthe1st]

Hey, Ben! Your OS have the same problem with VirtualBox, as me:

[BenLunt]

Hey, Ben! Your OS have the same problem with VirtualBox, as me:

Maybe its time I get out Virtual Box and see what is going on.

Is that a fairly recent HD image of my OS? (It is time to display the version in the status line I guess, just for this reason)

Thanks. I will have a look at get back with you.

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

[BenLunt]

My preliminary tests show that the controller isn't even making it to the TDs. Either the controller is stalled, the Queues are in error, or the TDs are in error. Since my code works on all other emulators and many actual machines, I am going to start to speculate that it is Virtual Box.

I will continue to investigate. Either way, a fix is in order: my code or Virtual Box.

Thanks for the heads up,
Ben

[BenLunt]

Well, I found the bug. It is actually in my code. In some instances, I was not updating the "Typ" field in the QUEUE HEAD Horizontal Link Pointer field. I was leaving it zero which tells the hardware that the pointer points to a ISO TD when it really was pointing to a QH, needing a value of 01b in that field.

Virtual Box must be more exact with these fields than other emulators and indeed some hardware. I am surprised with some of the hardware I was using didn't catch this, or it did and I didn't notice. Anyway, good job Virtual Box.

The way that I found this out is that I have a DUMP CORE routine that I can call anywhere in my schedule. This will actually dump all of the registers, then dump the Async and Periodic lists as well as the TD's that are being executed. Makes for a very long log file, but if you know what you are looking at and looking for, you can find the error.

In a few cases, my code "forgot" to update the "Typ" field and the log showed it.

Can you add something like this to your code and then see what is actually happening? Just a suggestion.

I appreciate the error catch. Thank you for catching it. I will update my HD image soon to reflect the fix.

Thanks,
Ben
- http://www.fysnet.net/the_universal_serial_bus.htm

[MrLolthe1st]

Hi, i'm cant do it.

So, i've now know, that if i wont't place my qh after async qh, status is 0xC00C, else 0xE00C. I'm checked for Typ bits - all ok.

[MrLolthe1st]

(sorry for code style and comments: i'm debbuging it 3 days without a sleep) https://github.com/MrLolthe1st/butterfl ... b/ehci.cpp

[BenLunt]

(sorry for code style and comments: i'm debbuging it 3 days without a sleep) https://github.com/MrLolthe1st/butterfl ... b/ehci.cpp

I quickly looked over your code and nothing jumped out at me.

I suggest that you create a dump function wrapped around some #define's so that you can "turn on" debug mode with a simple re-build.

The following is the output of mine for the transaction to get the first 8 bytes of the device's descriptor. This dump happens for every transaction when in DEBUG mode. i.e.: For every transfer, descriptor request, Control request, Bulk request, whatever, this sequence gets printed to the log file.

Code: Select all

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
EHCI Dump Core:  0xF0405000
     EHC_CAPS_CapLength: 0x01000020
     EHC_CAPS_HCSParams: 0x0000000C
     EHC_CAPS_HCCParams: 0x00000084
 EHC_CAPS_HCSPPortRoute: 0x00000000
       EHC_OPS_USBCommand: 0x00080031
        EHC_OPS_USBStatus: 0x0000C008
     EHC_OPS_USBInterrupt: 0x00000016
       EHC_OPS_FrameIndex: 0x000007B0
    EHC_OPS_CtrlDSSegemnt: 0x00000000
 EHC_OPS_PeriodicListBase: 0x03200000
    EHC_OPS_AsyncListBase: 0x043E3000
       EHC_OPS_ConfigFlag: 0x00000001
    EHC_OPS_PortStatus[0]: 0x00001005
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Async List vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
 000: 0x043E3000
       horz_ptr = 0x043E3080, typ = 1 (QH), T = 0
       cur_qTD_ptr = 0x00000000
       next_qTD_ptr = 0x00000000, T = 1
       alt_next_qTD_ptr = 0x00000000, T = 1
 001: 0x043E3080
       horz_ptr = 0x043E5000, typ = 1 (QH), T = 0
       cur_qTD_ptr = 0x00000000
       next_qTD_ptr = 0x00000000, T = 1
       alt_next_qTD_ptr = 0x00000000, T = 1
 002: 0x043E5000
       horz_ptr = 0x043E3000, typ = 1 (QH), T = 0
       cur_qTD_ptr = 0x043E5080
       next_qTD_ptr = 0x00000000, T = 1
       alt_next_qTD_ptr = 0x00000000, T = 1
  Async List ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >>>>> Before >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 USB_CONTROL_IN:
>  Queue:  Links to:  0x043E3000 (0)
>          Control = 0, mps = 64, H = 0, eps = 2 (hs), endpt = 0x00, addr = 0
>          Mult = 1, port = 0, Hub Addr = 0
>  qTD #0 (0x043E5080)
>         Links to:  0x043E50C0 (0)
>   (alt) Links to:  0x00000000 (1)
>           toggle:  1
>            count:  0
>              ioc:  0
>            cpage:  0
>             cerr:  3
>              pid:  2 (setup)
>           status:  0x00
>           buffer:  0x047A0500
>  qTD #1 (0x043E50C0)
>         Links to:  0x00000000 (1)
>   (alt) Links to:  0x00000000 (1)
>           toggle:  0
>            count:  0
>              ioc:  0
>            cpage:  0
>             cerr:  3
>              pid:  1 (in)
>           status:  0x00
>           buffer:  0x03A3009F
<<<<< After <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 USB_CONTROL_IN:
<  Queue:  Links to:  0x043E3000 (0)
<          Control = 0, mps = 64, H = 0, eps = 2 (hs), endpt = 0x00, addr = 0
<          Mult = 1, port = 0, Hub Addr = 0
<  qTD #0 (0x043E5080)
<         Links to:  0x043E50C0 (0)
<   (alt) Links to:  0x00000000 (1)
<           toggle:  1
<            count:  0
<              ioc:  0
<            cpage:  0
<             cerr:  3
<              pid:  2 (setup)
<           status:  0x00
<           buffer:  0x047A0500
<  qTD #1 (0x043E50C0)
<         Links to:  0x00000000 (1)
<   (alt) Links to:  0x00000000 (1)
<           toggle:  0
<            count:  0
<              ioc:  0
<            cpage:  0
<             cerr:  3
<              pid:  1 (in)
<           status:  0x00
<           buffer:  0x03A3009F
 >>>>> Before >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 USB_CONTROL_IN:
>  Queue:  Links to:  0x00000000 (0)
>          Control = 0, mps = 64, H = 0, eps = 2 (hs), endpt = 0x00, addr = 0
>          Mult = 1, port = 0, Hub Addr = 0
>  qTD #0 (0x043E5080)
>         Links to:  0x00000000 (1)
>   (alt) Links to:  0x00000000 (1)
>           toggle:  1
>            count:  0
>              ioc:  0
>            cpage:  0
>             cerr:  3
>              pid:  0 (out)
>           status:  0x80
>           buffer:  0x00000000
 <<<<< After <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 USB_CONTROL_IN:
<  Queue:  Links to:  0x043E3000 (0)
<          Control = 0, mps = 64, H = 0, eps = 2 (hs), endpt = 0x00, addr = 0
<          Mult = 1, port = 0, Hub Addr = 0
<  qTD #0 (0x043E5080)
<         Links to:  0x00000000 (1)
<   (alt) Links to:  0x00000000 (1)
<           toggle:  1
<            count:  0
<              ioc:  0
<            cpage:  0
<             cerr:  3
<              pid:  0 (out)
<           status:  0x00
<           buffer:  0x00000000
First eight bytes of descriptor
 03A3009F  12 01 00 02 00 00 00 40                            .......@

The "Before" is before I send it to the controller. i.e.: Just before it is inserted into the Queue. The "After" is after the interrupt has either fired, or I receive a timeout.

This shows everything that is sent to the controller and allows me to see what gets changed, if anything, as well as if the interrupt fires, etc....

My bug was found in one of the Async listings:

Code: Select all

   ...
 xxx: 0x0xxxxxxxx
       horz_ptr = 0x0xxxxxxxx, typ = 0 (iTD), T = 0     <-------  This showed that I was indicating an iTD when it should have been a QH.
       cur_qTD_ptr = 0x00000000
       next_qTD_ptr = 0x00000000, T = 1
       alt_next_qTD_ptr = 0x00000000, T = 1
   ...

I suggest that you do something like this and I guarantee that you will find the error.

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

[BenLunt]

I suggest that you do something like this and I guarantee that you will find the error.

I'm just wondering what you found out.

Where you able to print a more detailed debug report? Did this help?

What is the status?

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