Workaround for "USB disconnect" problem
Martin Guy
I've found a workaround for the "USB disconnect" problem that
prevented us from using USB devices other than keyboard and mouse
reliably.
The hack is to run the RAM in 16-bit mode instead of 32-bit, which
seems to change the RAM timing enough that the USB DMA errors do not
occur.
Of course, it also halves the amount of RAM available and slows the
system down by about 10% (as it has to fetch every 32-boit word in two
halves), but USB storage works reliably and can be used as a root
filesystem and swap space.
This is achieved by flashing a modified version of U-Boot which
initialises the RAM controller in 16-bit mode. A hacked u-boot-16bit
binary is available on the Downloads page [1], flashable by following
the instructions on the wiki/BootLoader page [2] with a longer
description of the workaround and its evil side-effects on the new
wiki/USB page [3]
I've been beating the life out of a pendrive all evening, with not a
single USB disconnect, so this seems to confirm Nuccio's theory that
it is caused by the E1 erratum, as well as explaining why the TS7250
board, which also has E1 silicon with the same erratum, doesn't suffer
from these USB disconnects (its RAM is actually connected in 16-bit
mode).
M
[1] http://code.google.com/p/sim1/downloads/list
[2] http://code.google.com/p/sim1/wiki/BootLoader
[3] http://code.google.com/p/sim1/wiki/USB
nuccio raciti
this is a very good news,
so unfortunatly Sim1 needs a new revision of its CPU in order to work fine.
N
Martin Guy
> so unfortunatly Sim1 needs a new revision of its CPU in order to work fine.
Or a reworking of the RAM circuitry to run the two chips as two 16-bit banks :(
Or some way to pad all outgoing USB packets to a multiple of 16 bytes
without adding rubbish that breaks the USB stream. I don't know much
about USB format - does it maybe have a one-byte no-op command or
something similarly harmless?
This is not a definite proof that the problem is caused by the E1
erratum but it is strong supporting evidence for that theory. Definite
proof would be provided by making up a board that is identical except
for a revision E2 CPU and finding that it works OK in 32-bit mode.
M
Marcus
I've been running Sim.One with Martins new u-boot
(u-boot-1.1.6-simone-20091201-16bit.bin ,16 bit RAM mode) without any
USB disconnects. Until today.
The same disconnect error seen previously appeared:
hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
I run 128 Mb swap on a file located on the same USB stick as the rootfs.
It seem (see [partial output]) either the swap filled up (no surprise in
that case) or somehow data r/w to swap caused the USB disconnect.
To test this further I have put the swap on another USB stick (FAT!),
and increased the swap file size to 512MB. mysql-server installed
properly, but that doesnt prove anything. Have you got any other
suggestions on how can I determine the exact cause and test this
further?
[partial output]
$> apt-get install mysql-server
...
Setting up libdbd-mysql-perl (4.007-1+lenny1) ...
Setting up mysql-client-5.0 (5.0.51a-24+lenny4) ...
Setting up mysql-server-5.0 (5.0.51a-24+lenny4) ...
Stopping MySQL database server: mysqld.
hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 1-1: USB disconnect, address 2
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
sd 0:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 00 20 15 2a 00 00 58 00
end_request: I/O error, dev sda, sector 2102570
Read-error on swap-device (8:0:2053160)
Read-error on swap-device (8:0:2053168)
...
Read-error on swap-device (8:0:2053216)
sd 0:0:0:0: [sda] Unhandled error code
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
sd 0:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 00 0c 3c fc 00 00 02 00
end_request: I/O error, dev sda, sector 802044
EXT2-fs: sda1 previous I/O error to superblock detected
EXT2-fs (sda1): error: ext2_get_inode: unable to read inode block -
inode=79430,
block=1269780
Read-error on swap-device (8:0:2046760)
...
Kernel panic - not syncing: Attempted to kill init!
...
Regards,
Marcus
Martin Guy
:(
Is this effect repeatable, or did it just happen once?
M
Marcus
> Is this effect repeatable, ...?
Yes, it seem possible to reproduce the USB disconnect. But it doesnt
reproduce well. I dont know how to make it fail every time. USB
disconnect have happened twice in my hands with the 16-bit RAM mode when
repeating the apt-get install mysql-server and "apt-get purge" the
installed files inbetween. Today, six consecutive tries did _not_ cause
USB disconnect with 128MB swap.
Regards,
Marcus
Martin Guy
> (u-boot-1.1.6-simone-20091201-16bit.bin ,16 bit RAM mode) without any
> USB disconnects. Until today.
>
> The same disconnect error seen previously appeared:
> hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
Hi again
I just got this exact same message/failure from a modern laptop x86
laptop - in that case it was when I was trying to use a USB wifi
antenna on two 5-meter USB extensions. It's probably unrelated to your
problem, but suggests power loss or signal attenuation as another
possible cause.
I assume your USB device was directly connected to the machine?
M
Marcus
Yes, it was a USB-stick directly to Sim.One (The J4 USB port) without
extension cord.
Regards,
Marcus
Federico Briata
Hi guys
It can be a voltage drop...
Is there any sense to try usb pen with 5v external power on 32 bit RAM more?
I can do it but next week.
Il giorno 01/set/2010 13:55, "Martin Guy" <marti...@gmail.com> ha scritto:On 8/19/10, Marcus <cmp...@gmail.com> wrote:
> I've been running Sim.One with Martins new u-boot
> (u-boot-1.1.6-simone-20091201-16bit.bin ,16 ...
Marcus
> Hi guys
> It can be a voltage drop...
> Is there any sense to try usb pen with 5v external power on 32 bit RAM
> more?
Hi,
Give it a try!
A long time ago I wired up a USB pen on the ADDON1 connector. I dont
remember if I took power from ADDON1 pins or if I had another source.
GND I recall taking from ADDON1 pin 39, DGND. This arrangement seemed
more sensitive to USB disconnects. My test was not very brilliant as I
had 10 cm non-shielded, non-twisted wire between ADDON1 and the USB
pen. :/
Regards,
Marcus
Federico Pietro Briata
2010/9/2 Marcus <cmp...@gmail.com>:
>> On Wed, 2010-09-01 at 14:17 +0200, Federico Briata wrote:
>> It can be a voltage drop...
>> Is there any sense to try usb pen with 5v external power on 32 bit RAM
>> more?
>
> Hi,
>
> Give it a try!
I tried by using power-supply 5V 2A, common ground with everything and
+5 from sim1 NC.
Well nothing change, still USB disconnect with 32bit RAM mode, should
I retry with 16bit or something else?
Regards,
federico
Martin Guy
> I tried by using power-supply 5V 2A, common ground with everything and
> +5 from sim1 NC.
> Well nothing change, still USB disconnect with 32bit RAM mode, should
> I retry with 16bit or something else?
Unfortunately, using the RAM in 16 bit mode is the only solution we
have to USB disconnects at the moment, caused by a timing error in the
EP93xx revision E1 silicon.
M
Federico Pietro Briata
Ok that 16 bit mode it's workaround for the bug in EP93xx E1
but I saw in list that disconnects can still happening in 16 bit mode
USB, so I will try 16bit too.
Marcus and Martin suggest EMI problem, I think too...
I also noted a strange comportment from RS232 of SIm1, when I
connected it with DCE-DTE cable to my NAS TheCUS, his Flash ROM,
containing the kernel for redboot, has become reset. Then reflashing
ROM of theCUS was enough to fix back.
federico