[U-Boot-Users] isp116x-hcd and usb_storage

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

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/  

[U-Boot-Users] isp116x-hcd and usb_storage

[Markus Klotzbücher]

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 at denx.de

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

--- 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

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

--- 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
 

[U-Boot-Users] isp116x-hcd and usb_storage

[Markus Klotzbücher]

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 at denx.de

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

--- 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 

[U-Boot-Users] isp116x-hcd and usb_storage

[Markus Klotzbücher]

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 at denx.de

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

--- 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 

[U-Boot-Users] isp116x-hcd and usb_storage

[Markus Klotzbücher]

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 at denx.de

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

--- 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
 

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

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

[U-Boot-Users] isp116x-hcd and usb_storage

[Markus Klotzbücher]

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 at denx.de

[U-Boot-Users] isp116x-hcd and usb_storage

[tike64]

--- 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