[U-Boot-Users] isp116x-hcd and usb_storage
Dear List,
I'm trying to set usb host up on our board (LH7A400 + ISP1160). It already works to some extend; it detects my Kingston 1GB stick. But then it (usb reset) fails with "Request Sense returned 00 00 00". Funny thing is that it starts to work if I enable debugging messages in usb_storage.c and isp116x-hcd.c. If I enable them in usb_storage.c only, it doesn't work. Here is the debug message log with debugging enabled in usb_storage.c only till the first difference I can see:
================================
USB Mass Storage device detected
Transport: Bulk/Bulk/Bulk
Endpoints In 1 Out 2 Int 0
BBB_reset
BBB_reset result 0: status 0 reset
BBB_reset result 0: status 0 clearing IN endpoint
BBB_reset result 0: status 0 clearing OUT endpoint
BBB_reset done
address 2
COMMAND phase
dir 1 lun 0 cmdlen 12 cmd c1ff9514 datalen 36 pdata c1ff9314
cmd[0] 0x12 cmd[1] 0x0 cmd[2] 0x0 cmd[3] 0x0 cmd[4] 0x24 cmd[5] 0x0 cmd[6] 0x0 cmd[7] 0x0 cmd[8] 0x0 cmd[9] 0x0 cmd[10] 0x0 cmd[11] 0x0 DATA phase
pdata[0] 0x0 pdata[1] 0x80 pdata[2] 0x0 pdata[3] 0x1 pdata[4] 0x1f pdata[5] 0x0 pdata[6] 0x0 pdata[7] 0x0 pdata[8] 0x4b pdata[9] 0x69 pdata[10] 0x6e pdata[11] 0x67 pdata[12] 0x73 pdata[13] 0x74 pdata[14] 0x6f pdata[15] 0x6e pdata[16] 0x44 pdata[17] 0x61 pdata[18] 0x74 pdata[19] 0x61 pdata[20] 0x54 pdata[21] 0x72 pdata[22] 0x61 pdata[23] 0x76 pdata[24] 0x65 pdata[25] 0x6c pdata[26] 0x65 pdata[27] 0x72 pdata[28] 0x20 pdata[29] 0x49 pdata[30] 0x49 pdata[31] 0x20 pdata[32] 0x31 pdata[33] 0x2e pdata[34] 0x31 pdata[35] 0x33
STATUS phase
ptr[0] 0x55 ptr[1] 0x53 ptr[2] 0x42 ptr[3] 0x53 ptr[4] 0x17 ptr[5] 0x0 ptr[6] 0x0 ptr[7] 0x0 ptr[8] 0x0 ptr[9] 0x0 ptr[10] 0x0 ptr[11] 0x0 ptr[12] 0x0 inquiry returns 0
================================
ptr[4] is different when I have debugging enabled in both files:
================================
- - isp116x-hcd.c: data(13): 55 53 42 53 00 00 00 00 00 00 00 00 00 ptr[0] 0x55 ptr[1] 0x53 ptr[2] 0x42 ptr[3] 0x53 ptr[4] 0x0 ptr[5] 0x0 ptr[6] 0x0 ptr[7] 0x0 ptr[8] 0x0 ptr[9] 0x0 ptr[10] 0x0 ptr[11] 0x0 ptr[12] 0x0 inquiry returns 0
================================
Could someone please help in debugging this?
--
Timo
____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
Dear Timo,
tike64 tike64@yahoo.com writes:
I'm trying to set usb host up on our board (LH7A400 + ISP1160). It already works to some extend; it detects my Kingston 1GB stick. But then it (usb reset) fails with "Request Sense returned 00 00 00". Funny
Does your stick work correctly before resetting it? Can you read a file into memory and verify it was loaded correctly?
thing is that it starts to work if I enable debugging messages in usb_storage.c and isp116x-hcd.c. If I enable them in usb_storage.c only, it doesn't work. Here is the debug message log with debugging enabled in usb_storage.c only till the first difference I can see:
U-Boots USB implementation is known to have some timing issues which havn't been fixed yet. You'll have to experiment to find out whats causing your problems. Have you tried defining ISP116X_HCD_USE_EXTRA_DELAY?
Did you miss to add some board specific initalization?
Best regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
--- Markus Klotzbücher wrote:
Dear Timo,
Does your stick work correctly before resetting it? Can you read a file into memory and verify it was loaded correctly?
What kind of reset do you mean? I think I have to do 'usb reset' first. I have not tried to read a file but 'fatls usb 0:1' gives a proper listing but ONLY when I have debugging enabled in isp116x-hcd.c.
U-Boots USB implementation is known to have some timing issues which havn't been fixed yet. You'll have to experiment to find out whats causing your problems. Have you tried defining ISP116X_HCD_USE_EXTRA_DELAY?
Yes, both ISP116X_HCD_USE_EXTRA_DELAY and ISP116X_HCD_USE_UDELAY. Without those it didn't even detect the stick.
Did you miss to add some board specific initalization?
I would think not because it at least detects the stick; it says: "1 Storage Device(s) found"
Meanwhile I learned a little more: It seems to fail at request sense command but I can't see exactly how because the problem evaporates when I enable more debugging. After that command, usb_storage.c says:
DATA phase
usb_bulk_msg error status 32
--
Timo
____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
--- tike64 wrote:
--- Markus Klotzbücher wrote:
U-Boots USB implementation is known to have some timing issues
OK, it really seems to be a timing issue. I have now a correct 'fatls' output with all debugging disabled. I added one delay into the usb_stor_BBB_transport function like this:
if (srb->datalen == 0) goto st; USB_STOR_PRINTF("DATA phase\n"); --> wait_ms(200); if (dir_in)
100 ms was too short.
Now the question is, what is the correct way to fix this?
--
Timo
____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html
tike64 tike64@yahoo.com writes:
--- tike64 wrote:
--- Markus Klotzbücher wrote:
U-Boots USB implementation is known to have some timing issues
OK, it really seems to be a timing issue. I have now a correct 'fatls' output with all debugging disabled. I added one delay into the usb_stor_BBB_transport function like this:
if (srb->datalen == 0) goto st; USB_STOR_PRINTF("DATA phase\n"); --> wait_ms(200); if (dir_in)
100 ms was too short.
Now the question is, what is the correct way to fix this?
Have you got an idea why this delay is needed? The correct way would be to figure this out and send a patch and explanation to the list.
Thanks in advance.
Best regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
--- Markus Klotzbücher wrote:
Have you got an idea why this delay is needed? The correct way would be to figure this out and send a patch and explanation to the list.
That's the problem; I have no idea. To debug this out, I will need help from someone who knows usb a lot better than me.
Clearly the delay is now at a wrong place. It most propably should be in isp116x-hcd.c. But as I don't know too much about usb or scsi protocols, I'll have hard time to follow what's going on.
We run linux on that same board and there the usb works fine.
--
Timo
____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
tike64 tike64@yahoo.com writes:
--- Markus Klotzbücher wrote:
Have you got an idea why this delay is needed? The correct way would be to figure this out and send a patch and explanation to the list.
That's the problem; I have no idea. To debug this out, I will need help from someone who knows usb a lot better than me.
Clearly the delay is now at a wrong place. It most propably should be in isp116x-hcd.c. But as I don't know too much about usb or scsi
I agree (although it wouldn't be the first first delay in usb_storage, would it). Maybe Rodolfo, who ported this driver has an idea where to start looking?
We run linux on that same board and there the usb works fine.
The problem really is that U-Boots USB is pretty old (derived somewhere from Linux 2.2) and that many bugs we are encountering these days have been fixed long ago in the kernel. So I guess what's eventually going to happen is that a new shiny Linux USB Stack will be ported to U-Boot. But until this happens we'll have to continue with and contiue fixing bugs in the old one. It's kind of messy, and I'm trying not to make things worse.
Best regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
--- Markus Klotzbücher wrote:
tike64 writes:
Clearly the delay is now at a wrong place. It most propably should be in isp116x-hcd.c. But as I don't know too much about usb or scsi
I agree (although it wouldn't be the first first delay in usb_storage, would it). Maybe Rodolfo, who ported this driver has an idea where to start looking?
Hopefully Rodolfo is reading this list...
I have made a little progress. I think the delay was needed because the stick simply needed more time. In certain occasions the stick NAKed (PTD remained active) the transactions so long that isp116x_submit_job returned an error. There was 10 retries and I increased it to 500 (in effect 500ms timeout) and now it seems to work much better.
At least one problem remains, though. I have tested it with a 165KB file and one out of about five fatloads fails. Completion codes of the first failed PTDs are 6 (PIDCheckFailure), 5 (DeviceNotResponding) and then always 0xf (propably device NAKing). After 'usb reset' it works again for a while.
Now I don't understand how transactions can fail with 6 or 5 occasionally. Are sticks known to be unreliable or should I suspect my hardware? What should be done after that kind of failure?
--
Timo
____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
Dear Timo,
tike64 tike64@yahoo.com writes:
I have made a little progress. I think the delay was needed because the stick simply needed more time. In certain occasions the stick NAKed (PTD remained active) the transactions so long that isp116x_submit_job returned an error. There was 10 retries and I increased it to 500 (in effect 500ms timeout) and now it seems to work much better.
Good job!
At least one problem remains, though. I have tested it with a 165KB file and one out of about five fatloads fails. Completion codes of the first failed PTDs are 6 (PIDCheckFailure), 5 (DeviceNotResponding) and then always 0xf (propably device NAKing). After 'usb reset' it works again for a while.
Now I don't understand how transactions can fail with 6 or 5 occasionally. Are sticks known to be unreliable or should I suspect my hardware? What should be done after that kind of failure?
Hard to say. Maybe it's a different timing issue, but could also be the stick misbehaving. Yes indeed some (usually noname) sticks have failed to work. Although you can never be sure I wouldn't suspect your hardware if the stick is working properly under Linux.
Can you test different sticks to see if that makes any difference?
Best regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
--- Markus Klotzbücher wrote:
tike64 tike64@yahoo.com writes:
At least one problem remains, though. I have tested it with a 165KB file and one out of about five fatloads fails. Completion codes of the first failed PTDs are 6 (PIDCheckFailure), 5 (DeviceNotResponding) and then always 0xf (propably device NAKing). After 'usb reset' it works again for a while.
Now I don't understand how transactions can fail with 6 or 5 occasionally. Are sticks known to be unreliable or should I suspect my hardware? What should be done after that kind of failure?
Hard to say. Maybe it's a different timing issue, but could also be the stick misbehaving. Yes indeed some (usually noname) sticks have failed to work. Although you can never be sure I wouldn't suspect
your
hardware if the stick is working properly under Linux.
Maybe Linux recovers gracefully somehow. The stick is Kingston.
Can you test different sticks to see if that makes any difference?
Good idea, must dig other sticks from somewhere.
Meanwhile, I added retries also in case of those errors. I do the retry with the remaining data of the transaction. Now it seems to pass over the original error with a couple of retries but then fails with 8 (data overrun) permanently ... to-be-continued-tomorrow
--
Timo
____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html
Markus and List,
I think I got it...
--- tike64 wrote:
--- Markus Klotzbücher wrote:
tike64 writes:
Now I don't understand how transactions can fail with 6 or 5 occasionally. Are sticks known to be unreliable or should I suspect my hardware? What should be done after that kind of failure?
It seems to me now that this is hardware problem in sticks or our HW or both. But nevertheless, failed transactions can be simply retried.
Can you test different sticks to see if that makes any difference?
They indeed are different. Some fail occasionally with wrong PID bits and some with CRC errors and so on. I saw one combination of stick and hub where I couldn't get any errors at all.
Meanwhile, I added retries also in case of those errors. I do the retry with the remaining data of the transaction. Now it seems to
pass
over the original error with a couple of retries but then fails with
8
(data overrun) permanently ... to-be-continued-tomorrow
Retries were working properly but after that program logic error led to the data overrun error. I fixed it and now it seems to work reliably.
I have tested it with several memory sticks (Kingston, Toshiba, SanDisk and no-name) by repeatedly loading 165K file and comparing it each time with an image loaded with tftpboot.
How do I proceed to upload the file (isp116x-hcd.c) for review and public consumption?
--
Timo
____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC
Hi Timo,
tike64 tike64@yahoo.com writes:
I think I got it...
Thats good news!
--- tike64 wrote:
--- Markus Klotzbücher wrote:
tike64 writes:
Now I don't understand how transactions can fail with 6 or 5 occasionally. Are sticks known to be unreliable or should I suspect my hardware? What should be done after that kind of failure?
It seems to me now that this is hardware problem in sticks or our HW or both. But nevertheless, failed transactions can be simply retried.
Ok. I think thats a good thing to do. We simply live in a world of misbehaving USB Hardware.
Can you test different sticks to see if that makes any difference?
They indeed are different. Some fail occasionally with wrong PID bits and some with CRC errors and so on. I saw one combination of stick and hub where I couldn't get any errors at all.
Retries were working properly but after that program logic error led to the data overrun error. I fixed it and now it seems to work reliably.
I have tested it with several memory sticks (Kingston, Toshiba, SanDisk and no-name) by repeatedly loading 165K file and comparing it each time with an image loaded with tftpboot.
How do I proceed to upload the file (isp116x-hcd.c) for review and public consumption?
Please post a patch to the list. See this link for detailed information on submitting patches:
http://www.denx.de/wiki/UBoot/Patches
Thanks!
Best regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
--- Markus Klotzbücher wrote:
Please post a patch to the list...
Ok, patch send - my first patch ever. Hopefully it turns out to be useful for others too...
--
Timo
____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html
participants (2)
-
Markus Klotzbücher -
tike64