uhci: stall, scheduling

[smil3]

Hello,
i feel i read all uhci articles in this forum, but i couldn't get the proper answer to my question.
At first: sry for my english.

I try to implement a uhci driver.
I test it in QEMU.

Here are my steps:

• get pci address
  SETUP
• deactivate Interrupts
• deactivate Legacy Support
• HCReset
• GReset
• zero's USBINT, USBPORTSC1, USBPORTSC2
  CONFIGURATION
• USBSOFMOD -> 1ms
• create Framelist, each entry is invalid (T=1)
• set USBFLBASEADD = Framelist
• USBFRNUM -> 0
• set/reset FGR in USBCMD
• set CF and RS -> HC runs
• reset ports

If a device is attached, i enable the port, sleep 100ms and build a setupTD.

• setupTD.status = lowspeed+active
• setupTD.token = 8Byte MaxLen (8-1) + SetupPID + ADDR=ENDP=0
• setupTD.buffer = pointer to Standard Request

After that I build a QH, set the element to setupTD and the link to 0x1.
My TD's, QH's and Framelist are aligned.

I put the QH in the Framelist and wait 2 seconds.
At that point setupTD.status = Lowspeed + STALLED.
My setupTD links to other TD's, because I would like to make a GET_DESCRIPTOR Request.
But the fault occurs after the setupTD.

I hope you know the issue

best regards!

[montrom]

Without code present:

1. you are not waiting long enough during the port reset or doing that incorrectly.
2. you are actually receiving STALLED with a Bad CRC because you built an invalid TD.
3. your alignment is off.
4. your device is fullspeed or highspeed.
5. your buffer is not mapped correctly and is inaccessible to the device.

Really, there are too many reasons why this might have happened. Though it is difficult to determine the exact cause without seeing your code, I still tried to list some of the more obvious reasons, in order of what I think is most likely in this case. I hope it helps. Good luck.

[smil3]

thank you for fast response!
I will check it.

I also try to execute my driver with a self compiled QEMU -> I can turn the DEBUG MACRO on.
I will evaluate this debug and can report it to you tomorrow.

best regards!

[smil3]

Hello again!
I checked your advises, but i can't discover a fault.

I executed my driver with the debug-QEMU Version.
The result was:
I've written 8Byte length in the MaxLength Part of the setupTD.token as 0x7.
This equals to a length of 4, so i forgot to shift it by one.
-> 0xe

Now my GET_DESCRIPTOR Request works.

I have an other question.
What is a good approach to insert a new qh in the Framelist?
I mean: if my framenumber is 3, should i insert the new qh to framenumber 4,5 or 10?

best regards

[smil3]

Hello!

Nobody knows!?
... mhmhm. Currently I add TD's at (FRNUM+5)%1024.

Ok. I have an other question, again.
I tested my enumeration in QEMU with a virtual keyboard and all works.
But if I connect a usb-mouse it doesn't.
My setupTD, get_descriptor rqst, doesn't complete in one frame.
In common, it returns the size of the descriptor (18Byte), but with the real mouse it returns -5.
Does anybody know how to handle this?
Currently I create the hole query, i mean setupTD+3dataTD+statusTD.
Should I wait after the setupTD? If yes, how long?

best regards!

[smil3]

Hello!

Now, I add my QH to (current_framenumber+2). After that, I compare the current_framenumber with the old current_framenumber+2. If the current_framenumber is bigger than resubmit the QH.

The Problem with "real" devices:
One Transaction doesn't finish in 1ms, so at first I build all Transactions, put it in the QH and submit QH.
Then I poll over/wait for an interrupt my status_package. If this is inactive with no errors than the Transaction is completed.

best regards