EHCI didn't works at real PC and VirtualBox!

[MrLolthe1st]

Hi, Benjamin!
Sorry, i was busy at work, and had not time for OS development.
Yes, i can. Firstly, i want to say some interesting things to you: (that i've sent in e-mail a few minutes ago)

Hi, i've found some things: i've compared my and Ben async queues, and haven't found diffs. Also, i've compared my and Ben's TDs chain, and have only one difference: in Ben's realisation there isn't status packet(but why it works?), i've tryed to remove it from chain, result was: in QEMU it isn't working, in VBox it still not working. But why? I can't find any diffs! May, VBox standart debugger gives wrong data to me, but, if i set PTR_QH bit in 2nd Ben's QH from async QH list(1st is Queue Head with bit H set to 1(bit 15)), VBox completes the TDs chain, and writes data to descriptor, that he want to get.

So, detailed debug info from VBox debugger(worst debugger in the world! It can be used just for printing some info about memory and devices):
Firstly, regs:

Code: Select all

USBCMD: 80031
    EHCI_CMD_RUN
    EHCI_CMD_PERIODIC_SCHED_ENABLE
    EHCI_CMD_ASYNC_SCHED_ENABLE
    EHCI_CMD_FRAME_LIST_SIZE              0
    EHCI_CMD_ASYNC_SCHED_PARK_MODE_COUNT  0
    EHCI_CMD_INTERRUPT_THRESHOLD          8
USBSTS: e00c
    EHCI_STATUS_ASYNC_SCHED
    EHCI_STATUS_PERIOD_SCHED
    EHCI_STATUS_RECLAMATION
    EHCI_STATUS_FRAME_LIST_ROLLOVER
    EHCI_STATUS_PORT_CHANGE_DETECT
USBINTR: 0
FRINDEX: 69f0
CTRLDSSEGMENT:    0
PERIODICLISTBASE: 201000
ASYNCLISTADDR:    204000

Ok, i think all are ok. Now, print out a async queue head:

Code: Select all

%0000000000204000: 02 42 20 00 00 80 00 00-00 00 00 00 00 00 00 00  .B .............
%0000000000204010: 01 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000204020: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000204030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000204040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000204050: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

How you can see, HEAD_OF_RECLAMATION bit is set, pointer has a Typ is 1 - pointer to queue, just move to next queue in list.

Code: Select all

%0000000000204200: 02 40 20 00 00 60 40 80-00 00 00 40 00 00 00 00  .@ ..`@....@....
%0000000000204210: 00 70 20 00 00 00 00 00-00 00 00 00 00 00 00 00  .p .............
%0000000000204220: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000204230: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000204240: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000204250: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

Here we can see, that queue horizontal link points to first queue. Also, we can see characteristics. (I made them equals to your, by rewriting a small part of my code).
Ok, also we can see, that there is qTD in 0x207000.

Code: Select all

%0000000000207000: 00 71 20 00 00 71 20 00-80 0e 08 00 18 fd 00 00  .q ..q .........
%0000000000207010: 00 00 01 00 00 10 01 00-00 20 01 00 00 30 01 00  ......... ...0..
%0000000000207020: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207050: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

Now i've fixed code, and Typ, like in a specification doesn't points to queue(Typ is zero, see 3.5.1 of spec, because there aren't any Typs )
So, as you can see: there is Setup packet, and buffers are pointing to 0xfd18:

Code: Select all

%000000000000fd18: 80 06 00 01 00 00 08 00

That request just gets first eight bytes of descriptor. So, let's move to next TD in chain, to 0x207100

Code: Select all

%0000000000207100: 00 72 20 00 00 72 20 00-80 0d 08 80 94 23 11 00  .r ..r ......#..
%0000000000207110: 00 30 11 00 00 40 11 00-00 50 11 00 00 60 11 00  [email protected]...`..
%0000000000207120: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207130: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207140: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207150: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

That qTD contains pointer to next qTD, packet type is DATA_IN, and buffers are pointing to device descriptor.
Let's see last qTD in chain at 0x207200

Code: Select all

%0000000000207200: 01 00 00 00 01 00 00 00-80 0c 00 80 00 00 00 00  ................
%0000000000207210: 00 10 00 00 00 20 00 00-00 30 00 00 00 40 00 00  ..... ...0...@..
%0000000000207220: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207230: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207240: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
%0000000000207250: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

So, QH token isn't updating, TD chain isn't processing, data never comes.

So, i have no idea to do with that.

Specially thanks,
Aleksandr

[BenLunt]

Hi, Benjamin!
Sorry, i was busy at work, and had not time for OS development.

Hi. Me too.

Yes, i can. Firstly, i want to say some interesting things to you: (that i've sent in e-mail a few minutes ago)

I haven't yet received that email. Please try again.

Hi, i've found some things: i've compared my and Ben async queues, and haven't found diffs. Also, i've compared my and Ben's TDs chain, and have only one difference: in Ben's realisation there isn't status packet(but why it works?), i've tryed to remove it from chain, result was: in QEMU it isn't working, in VBox it still not working. But why? I can't find any diffs! May, VBox standart debugger gives wrong data to me, but, if i set PTR_QH bit in 2nd Ben's QH from async QH list(1st is Queue Head with bit H set to 1(bit 15)), VBox completes the TDs chain, and writes data to descriptor, that he want to get.

Remember, the Status packet is not expected until after a successful transfer of the SETUP and DATA packets. i.e.: The Status packet tells the device that you successfully received the data. In my book, I show how to send the SETUP, DATA, and STATUS packet all at once, but indicated that it is assumed that no error was found. This is so you can get the idea of what takes place. It is up to you, the reader, to parse the data packets, as well as check for errors within any of them, all before you send the STATUS packet. If there was an error in any packet before the STATUS packet is to be sent, you probably should send a CLEAR STALL or reset the device. Only after all DATA packets are completely successful do you send the STATUS packet.

Also, just a quick thought. Make sure you are handling the Short Packet Detect procedure correctly. If there is a short packet detected and the controller still executes a DATA packet, this will cause a error (possible a stall). For example, if you expect 256 bytes of data, therefore having 32 8-byte DATA packets, yet you receive a short packet detect on the second packet, the controller and device will expect the STATUS packet next. If your schedule tries to execute the third DATA packet (let alone the remaining 253 packets), this will cause an error. Note that if you don't mark those remaining packets as inactive, on the next "roll around" to that frame, it could try to execute those again. It all depends on how you create your schedule. My book explains this in some detail.

Anyway, I too have been very busy and haven't been able to frequent this forum like a want to, let alone work on my own stuff. I hope to be able to soon, though.

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