Skip to contentSkip to conversation

usb problem

U-Boot-Users Applied kow9loon 4 participants 11 messages Apr 18, 2007 – Apr 23, 2007

lore
Share & tools
lore

kow9loon

author
#0 lore raw

Hi,

We have problems reading/writing from/to a USB NAND flash having a capacity of 512 MB. What we dicovered was: up to a capacity of 128 MB, the operations looked 'koche', thereafter, the system hanged. Our hardware setup are as
follows: (1) a MPC8544E CPU; (2) a ISP 1564 PCI-USB 2.0 Host Controller; (3) a ST72681 Flash Driver Controller; and (4) a 512 MB Nand flash.

We also understand that support of the OHCI driver in U-boot is only limited to support of "Mass Storage Device" class device, and rapid reading and writing could post a potential problem. We deliberately slow down the read/write traffic in an attempt to give some breathing rooms to the the driver (and possibly to the controller). Unfortunately, our endeavors, thus far, have only limited success. We would appreciate any comments that could help us to dig our way out of this hole. Thank you.

Regards,

Kow9loon

Signature · 2 lines
View this message in context: http://www.nabble.com/usb-problem-tf3603390.html#a10066981
Sent from the Uboot - Users mailing list archive at Nabble.com.
#1 lore raw
Quoted 4 lines · kow9loon <[email protected]> writes:

We have problems reading/writing from/to a USB NAND flash having a capacity of 512 MB. What we dicovered was: up to a capacity of 128 MB, the operations looked 'koche', thereafter, the system hanged. Our hardware setup are as

Where does it hang?

Quoted 8 lines

follows: (1) a MPC8544E CPU; (2) a ISP 1564 PCI-USB 2.0 Host Controller; (3) a ST72681 Flash Driver Controller; and (4) a 512 MB Nand flash.

We also understand that support of the OHCI driver in U-boot is only limited to support of "Mass Storage Device" class device, and rapid reading and writing could post a potential problem. We deliberately slow down the read/write traffic in an attempt to give some breathing rooms to the the

Some so called "crappy" USB sticks are known to have some timing problems and require additional delays, but so far no real fix has been found. Search the archives for Rodolfos "crappy Usbkeys" patch. Does this fix solve you problem?

Regards

Markus

--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany

author
#2 lore raw

Hi Markus,

At this point, we have not yet identified the location of the driver where it gets hung. Just everything got frozen once the 128 MB mark was reached. By the way, where could I get hold of the patch from Rodolfos? I did a serach and followed the link provided by Rodolfos, but the link when NOWHERE. Did Rodolfos submitted his patches to be incorporated to the U-boot trunk? If he did, where could I get hold of his patches such that I could better understand it and try it out? Thank you in advance for your help.

Regards,

Kow9loon

Quoted 48 lines · Markus Klotzb?cher-2 wrote:
Quoted 6 lines · kow9loon <[email protected]> writes:

We have problems reading/writing from/to a USB NAND flash having a capacity
of 512 MB. What we dicovered was: up to a capacity of 128 MB, the operations
looked 'koche', thereafter, the system hanged. Our hardware setup are as

Where does it hang?

Quoted 10 lines

follows: (1) a MPC8544E CPU; (2) a ISP 1564 PCI-USB 2.0 Host Controller;
(3)
a ST72681 Flash Driver Controller; and (4) a 512 MB Nand flash.

We also understand that support of the OHCI driver in U-boot is only limited
to support of "Mass Storage Device" class device, and rapid reading and writing could post a potential problem. We deliberately slow down the read/write traffic in an attempt to give some breathing rooms to the the

Some so called "crappy" USB sticks are known to have some timing problems and require additional delays, but so far no real fix has been found. Search the archives for Rodolfos "crappy Usbkeys" patch. Does this fix solve you problem?

Regards

Markus

--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Signature · 2 lines
View this message in context: http://www.nabble.com/usb-problem-tf3603390.html#a10082723
Sent from the Uboot - Users mailing list archive at Nabble.com.
#3 lore raw
Quoted 3 lines · On Thu, Apr 19, 2007 at 10:28:55AM -0700, kow9loon wrote:

At this point, we have not yet identified the location of the driver where it gets hung. Just everything got frozen once the 128 MB mark was reached.

My problem was different one. I _never_ got my board frozen due USB activity.

Quoted 5 lines

By the way, where could I get hold of the patch from Rodolfos? I did a serach and followed the link provided by Rodolfos, but the link when NOWHERE. Did Rodolfos submitted his patches to be incorporated to the U-boot trunk? If he did, where could I get hold of his patches such that I could better understand it and try it out? Thank you in advance for your help.

Here my patches:

commit a8c7af8c768d1ac657286b97952eb1e66b2dd2e0

Author: Rodolfo Giometti <[email protected]>
Date:   Fri Mar 30 16:33:00 2007 +0200

USB: (Another) delay for crappy USB keys.

Some USB keys are slow in giving back an answer when the Root HUB enables power lines.

drivers/usb_ohci.c +3 -1
index c5e4c38..f381c40 100644
@@ -1178,7 +1178,9 @@ pkt_print(dev, pipe, buffer, transfer_len, cmd, "SUB(rh)", usb_pipein(pipe));
                                            WR_RH_PORTSTAT (RH_PS_PRS);
                                        OK (0);
                        case (RH_PORT_POWER):
-                                       WR_RH_PORTSTAT (RH_PS_PPS ); OK (0);
+                                       WR_RH_PORTSTAT (RH_PS_PPS );
+                                       wait_ms(100);
+                                       OK (0);
                        case (RH_PORT_ENABLE): /* BUG IN HUP CODE *********/
                                        if (RD_RH_PORTSTAT & RH_PS_CCS)
                                            WR_RH_PORTSTAT (RH_PS_PES );

---

commit 22bd6ed0e4b31a0d1060436893d7d03c6eb203fc

Author: Rodolfo Giometti <[email protected]>
Date:   Tue Mar 6 11:32:04 2007 +0100

USB: Delay for crappy USB keys.

common/usb.c +1 -1
index 0857494..087a65f 100644
@@ -61,7 +61,7 @@
 #ifdef USB_DEBUG
 #define        USB_PRINTF(fmt,args...) printf (fmt ,##args)
 #else
-#define USB_PRINTF(fmt,args...)
+#define USB_PRINTF(fmt,args...)        wait_ms(1) /* for crappy USB keys... */
 #endif
 
 #define USB_BUFSIZ     512

---

Ciao,

Rodolfo

Signature · 4 lines
GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127
#4 lore raw
Quoted 2 lines · In message <[email protected]> you wrote:

Here my patches:

Thanks a lot.

Markus, I guess you will take care of that?

common/usb.c line 65

Quoted 11 lines
common/usb.c +1 -1
index 0857494..087a65f 100644
@@ -61,7 +61,7 @@
 #ifdef USB_DEBUG
 #define        USB_PRINTF(fmt,args...) printf (fmt ,##args)
 #else
-#define USB_PRINTF(fmt,args...)
+#define USB_PRINTF(fmt,args...)        wait_ms(1) /* for crappy USB keys... */
 #endif

Arghhh. But this one is definitely not ripe for mainstream yet.

Please clean this up.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I haven't lost my mind -- it's backed up on tape somewhere.
#5 lore raw
Quoted 5 lines · Wolfgang Denk
Quoted 5 lines
common/usb.c +0 -0
index 0857494..087a65f 100644
@@ -61,7 +61,7 @@
Quoted 8 lines

common/usb.c line 65

Quoted 6 lines
common/usb.c +1 -1
 #ifdef USB_DEBUG
 #define        USB_PRINTF(fmt,args...) printf (fmt ,##args)
 #else
-#define USB_PRINTF(fmt,args...)
+#define USB_PRINTF(fmt,args...)        wait_ms(1) /* for crappy USB keys... */
 #endif

Arghhh. But this one is definitely not ripe for mainstream yet.

Eheheheh, you already told me about this dirty trick! :P

Quoted 1 line

Please clean this up.

I see, but currently I'm very busy for that! Please keep this ?work around? in some TODO list until I (or someone else) can find some time to definitely resolve it.

Ciao,

Rodolfo

Signature · 4 lines
GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127
#8 lore raw
In reply to Rodolfo Giometti

Hi Rodolfo,

Quoted 7 lines · Rodolfo Giometti
Quoted 3 lines · On Thu, Apr 19, 2007 at 10:28:55AM -0700, kow9loon wrote:

At this point, we have not yet identified the location of the driver where it gets hung. Just everything got frozen once the 128 MB mark was reached.

My problem was different one. I _never_ got my board frozen due USB activity.

Yes, I know. But I figured it could be worth trying nevertheless.

Regards

Markus Klotzbuecher

--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany

#6 lore raw
In reply to Rodolfo Giometti

Hi Rodolfo,

Quoted 7 lines · Rodolfo Giometti
Quoted 1 line · Wolfgang Denk

Please clean this up.

I see, but currently I'm very busy for that! Please keep this ?work around? in some TODO list until I (or someone else) can find some time to definitely resolve it.

Yes, I understood these patches as work in progress. I can apply your first patch if you want, but does it make sense without the second?

Regards

Markus Klotzbuecher

--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany

#9 lore raw
In reply to Markus Klotzbücher
Quoted 2 lines · Markus Klotzb?cher

Yes, I know. But I figured it could be worth trying nevertheless.

I see and I agree with you.

Ciao,

Rodolfo

Signature · 4 lines
GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127
#7 lore raw
In reply to Markus Klotzbücher
Quoted 3 lines · Markus Klotzb?cher

Yes, I understood these patches as work in progress. I can apply your first patch if you want, but does it make sense without the second?

Yes, since they resolve two different problems. It could happen that a key is recognized by the USB host as USB device but not as mass storage and it could happen that a key is not recognized as USB device at all.

Ciao,

Rodolfo

Signature · 4 lines
GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127
#10 lore raw
In reply to Rodolfo Giometti
Quoted 6 lines · Rodolfo Giometti

Here my patches:

commit a8c7af8c768d1ac657286b97952eb1e66b2dd2e0

Author: Rodolfo Giometti <[email protected]>
Date:   Fri Mar 30 16:33:00 2007 +0200
Quoted 6 lines

USB: (Another) delay for crappy USB keys.

Some USB keys are slow in giving back an answer when the Root HUB enables power lines.

Applied to custodian USB tree, thanks!

Regards

Markus Klotzbuecher

--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany