Hi,
I'm in the process of implementing a simple u-boot based upgrade system, and have encountered some issues with large file transfers on certain USB sticks. I've seen the issue on both u-boot-imx v2015.04 and with u-boot-fslc v2015.10.
U-Boot 2015.10-rc4+fslc+g1fb68c8 (Oct 15 2015 - 12:45:53 -0400)
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 52C
Reset cause: WDOG
Board: MX6SX SABRE SDB
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x11
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
*** Warning - bad CRC, using default environment
PCI: pcie phy link never came up
In: serial
Out: serial
Err: serial
Net: Phy 1 not found
FEC [PRIME]
Hit any key to stop autoboot: 0
=> usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1: USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
=> load usb 0:1 ${loadaddr} rootfs-a.ext4
reading rootfs-a.ext4
EHCI timed out on TD - token=0x1e008d80
EHCI timed out on TD - token=0x9e008d80
EHCI timed out on TD - token=0x800d8d80
EHCI timed out on TD - token=0x1e008d80
Error reading cluster
** Unable to read file rootfs-a.ext4 **
The issue comes and goes with no pattern I've been able to discern, but is more reproducible with some USB drives than others. The rootfs-a file is ~400MiB, and the first "time out" errors occur within ~5 seconds of running the "load" command.
I can reproduce the issue either on the host USB port or the OTG port with the correct cable.
I've had no issues with a separate 8MiB file even on the most problematic of drives.
Does anyone have any suggestions for this? I did some fairly thorough searching and was able to find other people with the same problem, but no solutions.
Just for those who need a quick workaround: Reducing the value of USB_MAX_XFER_BLK in common/usb_storage.c should do the trick (thanks to Sergei Temerkhanov for the hint).
The U-Boot guys are currently working on a solution...
I guess that I'm experiencing the same issue and therefore started this discussion on the u-boot mailing list: [U-Boot] Issue with USB mass storage (thumb drives)
MItchell,
Please report this issue in the U-boot mailing list: u-boot@lists.denx.de
Regards,
Fabio Estevam
Hi Mitchel,
Your issue is being internally discussed with AE team. As soon as getting news, I will send you an update here.
Hope this will be useful for you.
Best regards!
/Carlos
Hi Mitchel,
What is the loadaddr? I see this command
load usb 0:1 ${loadaddr} rootfs-a.ext4
Often if the address is wrong you will get the timeout errors. Try a fatload from mmc card first to see if the address is correct. If it still fails please printenv and post the contents of the u-boot.
Best regards!
Hi Carlos,
I am able to load the same rootfs from an SD card partition just fine.
=> load mmc 2:4 ${loadaddr} rootfs-a.ext4
406847488 bytes read in 19261 ms (20.1 MiB/s)
As I had mentioned before, this seems to be an issue with varying USB sticks. Some work, some do not.
Here are the contents of an env print, as well as the output of bdinfo.
=> env print
baudrate=115200
boot_fdt=try
bootcmd=mmc dev ${mmcdev};mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if run loadimage; then run mmcboot; else run netboot; fi; fi; else run netboot; fi
bootdelay=3
bootscript=echo Running bootscript from mmc ...; source
console=ttymxc0
ethact=FEC
ethaddr=00:04:9f:03:85:a4
ethprime=FEC
fdt_addr=0x88000000
fdt_file=imx6sx-sharp-lcd.dtb
fdt_high=0xffffffff
filesize=18400000
image=zImage
initrd_high=0xffffffff
ip_dyn=yes
loadaddr=0x82000000
loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};
loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}
loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}
mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot} fbcon=rotate:1 vt.global_cursor_default=0
mmcboot=echo Booting from mmc ...; run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcdev=2
mmcpart=1
mmcroot=/dev/mmcblk3p2 rootwait rw
netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
script=boot.scr
stderr=serial
stdin=serial
stdout=serial
Environment size: 1770/8188 bytes
=> bdinfo
arch_number = 0x00000000
boot_params = 0x80000100
DRAM bank = 0x00000000
-> start = 0x80000000
-> size = 0x40000000
eth0name = FEC
ethaddr = 00:04:9f:03:85:a4
current eth = FEC
ip_addr = <NULL>
baudrate = 115200 bps
TLB addr = 0xBFFF0000
relocaddr = 0xBFF57000
reloc off = 0x38757000
irq_sp = 0xBFC54EA0
sp start = 0xBFC54E90
Hi Mitchel,
AE team mentioned that it seems that there is some lack of compatibility (maybe with geometry) of the USB flash drive(s). If you can find a particular brand or size that fails consistently, then they can create a ticket to address it.
Is there a common difference? Is the failing drive 4 GB, 32 GB, or larger? How is it formatted? FAT, VFAT, EXT3, EXT4?
Hope this will be useful for you.
Best regards!
/Carlos
Mitchell,
Can you change the loadaddr to 0x80800000 and give it a try? On my solox board, I got the same errors with the load address you're using but the errors have disappeared with 0x80800000.
EDIT: Nevermind - I had stopped usb prior to using 0x82000000 but forgotten to restart it afterwards and u-boot didn't pick that up. 0x82000000 seems fine for me now with 3 different USB sticks and 425M file.
In that case I suggest changing this macro in include/usb.h and see if the timeouts disappear:
#define USB_TIMEOUT_MS(pipe) (usb_pipebulk(pipe) ? 5000 : 1000)
I'd recommend something like 30000 : 10000 for testing for the time being.