Differences

This shows you the differences between two versions of the page.

--- wrtu54g-tm:usb [2010/02/06 02:33] – external edit 127.0.0.1
+++ wrtu54g-tm:usb [2023/11/04 22:30] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== HOWTO: Replace SIM reader with USB connector ======
+====== USB Information ======
+===== HOWTO: Replace SIM reader with USB connector =====
 <code>
 Instructions to install a USB type A connector in the WRTU54G-TM
@@ Line 11: / Line 14: @@
 </code>
 - Thanks to [[http://www.dslreports.com/forum/r23202439-Working-USB-mod-photo-attached|this post]] by ccase.
+===== Original patch =====
+Since it didn't work for me, I did not submit the code to OpenWRT. The patch I originally made can be found at http://wrt.scottn.us/adm8668_ehci.patch but is probably missing some Makefile entries.. It's the meat of it though and a good starting point if someone decides to try this. I think now the resistors probably need to stay on the board and maybe it'll work?
+===== Older findings =====
+  The power bus is 5V, but the signal levels at Low-speed/Full-speed are for 3.3V rail
+  (min = 2.8V and max = 3.6V for high level). See Table 19-2, page 518 in
+  USB Complete, 3rd Edition.
+I looked at the table and again at my connections and only thing I can think of to increase success with USB is using a powered hub. \\
+[**Edit 1oct2010**]: I tried my powered USB2 hub and it's still flaky.. After a hard long search I found a USB1.1 hub (Belkin F5U021). Disk access seems greatly improved (ie. it doesn't crash the kernel!). Maybe I should just force 1.1 in software ...? \\
+[**Edit: 10nov2010**]: Maybe only USB2 storage is at fault, and I think I traced it to a function in transport.c when using "Scatter Gather" (A SCSI feature), since our USB driver is a non-PCI device and Linksys's hack on the USB driver sets device to NULL since it's expecting a PCI device... Well, later down the road the USB-storage driver wants to access that data structure **only if** using USB2.0... Haven't pinned down a successful work-around. Seemed to work once but I haven't been able to reproduce.
+  root@OpenWrt:/mnt# time dd if=100mb.test of=100mb.test2 bs=1k
++0 records in
++0 records out
+  real	4m 6.99s
+  user	0m 1.49s
+  sys	0m 23.95s
+What's that, about 415kbyte/sec? It's reading and writing to same disk, to be more fair:
+root@OpenWrt:/mnt# time dd if=/dev/zero of=test bs=512 count=204800
++0 records in
++0 records out
+  real	1m 41.51s
+  user	0m 2.33s
+  sys	0m 21.66s