Re: [U-Boot] u-boot USB status
Hi Marcel, What I want to do is upgrade my kernel and rootfs via USB. I'm using an Atmel SAM9. You might be able to find some inspiration in ./boards/mcc200/auto_update.c and ./boards/mcc200/mcc200.c which uses the U-Boot USB stack for this purpose. This assumes there is USB host support for the SAM9 (which I have no idea whether there is or not). -- Damien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the MPC5121e USB Host controller.
Hi Einar, I'm using 2 usb sticks for testing: Corsair (32BG) and Doulos (128MB) both formatted with vfat. My board contains NXP ISP1520 USB Hub. Neither of these sticks are being detected correctly, in fact the Corsair is not detected at all. I have tested successfully the Doulos stick on another board with mpc5200 which don't have any USB Hub, just using the 2 on-chip ports. The Corsair stick is not working, halts the cpu. If you have spare hardware, are you able to remove and bypass the hub to determine if you still see the same u-boot issues? Conversely, are you able to connect this hub (for example a dev kit or a commerical hub with this chipset) to the MPC5200 to see if you still have issues? I'm trying to determine the hub's role, if at all possible. Other than that, I'm a little short of ideas. Potentially some timing since (IIRC) the mpc5200 is full-speed not high speed? I'm kind of clutching at straws here. Maybe someone with a bit more knowledge about USB can make a more informed comment. -- Damien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the MPC5121e USB Host controller.
Hi Elinar, The root hub is detected and also it detects a device connected to the controller. However, by testing with a usbstick (mass storage) it fails to detect the device as a storage device. I have here a debug printout which is being printed (with debug enabled) during execution of the command 'usb start': Unfortunately, our experience also shows some USB Mass Storage Devices work better than others. For example, we are able to reproduce some of the issues we have on the SheevaPlug (Marvel Kirkwood ARM) with the same combinations of hubs and USB sticks. Do you have another USB Host board available to try to see if your issue is reproducible across platforms? Are you able to list the hub and the USB Stick that you are using below? Is it reproducible across different hubs and sticks? For example, SMSC hubs tend to exhibit the problems far more than Genesys Logic hubs. I have no experience with Cypress hubs as to whether they perform any better or not. If you search the mailing list, I asked about the same issue some time ago. -- Damien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for the MPC5121e USB Host controller.
Add support for the USB Host controller of the MPC5121e, based on the original
patch by Francesco Rendine [1].
The patch configures the USB Host controller and the on-board UTMI phy,
including the Freescale-specific registers as per the Linux kernel driver.
Tested on the MPC5121ADS platform with various USB mass storage devices.
[1] http://lists.denx.de/pipermail/u-boot/2009-June/055022.html
Signed-off-by: Damien Dusha d.du...@gmail.com
---
arch/powerpc/include/asm/immap_512x.h |4 +
board/freescale/mpc5121ads/mpc5121ads.c |4 +-
drivers/usb/host/ehci-fsl.c | 137 -
drivers/usb/host/ehci.h |5 +
include/configs/mpc5121ads.h| 22 +-
include/usb/ehci-fsl.h | 149 +--
6 files changed, 292 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_512x.h
b/arch/powerpc/include/asm/immap_512x.h
index 7f9db8b..4923a17 100644
--- a/arch/powerpc/include/asm/immap_512x.h
+++ b/arch/powerpc/include/asm/immap_512x.h
@@ -1246,4 +1246,8 @@ static inline u32 get_pata_base (void)
}
#endif /* __ASSEMBLY__ */
+#define CONFIG_SYS_MPC512x_USB_OFFSET 0x4000
+#define CONFIG_SYS_MPC512x_USB_ADDR \
+ (CONFIG_SYS_IMMR + CONFIG_SYS_MPC512x_USB_OFFSET)
+
#endif /* __IMMAP_512x__ */
diff --git a/board/freescale/mpc5121ads/mpc5121ads.c
b/board/freescale/mpc5121ads/mpc5121ads.c
index 2e13ea8..4c0caa7 100644
--- a/board/freescale/mpc5121ads/mpc5121ads.c
+++ b/board/freescale/mpc5121ads/mpc5121ads.c
@@ -53,7 +53,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define SCCR2_CLOCKS_EN(CLOCK_SCCR2_DIU_EN | \
CLOCK_SCCR2_I2C_EN | \
CLOCK_SCCR2_MEM_EN | \
-CLOCK_SCCR2_SPDIF_EN)
+CLOCK_SCCR2_SPDIF_EN | \
+CLOCK_SCCR2_USB1_EN | \
+CLOCK_SCCR2_USB2_EN)
void __mpc5121_nfc_select_chip(struct mtd_info *mtd, int chip);
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index c674929..d7b07ca 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -1,4 +1,9 @@
/*
+ * (C) Copyright 2010, Damien Dusha, d.du...@gmail.com
+ *
+ * (C) Copyright 2009, Value Team S.p.A.
+ * Francesco Rendine, francesco.rend...@...
+ *
* (C) Copyright 2009 Freescale Semiconductor, Inc.
*
* (C) Copyright 2008, Excito Elektronik i Sk=E5ne AB
@@ -30,6 +35,7 @@
#include ehci.h
#include ehci-core.h
+#ifndef CONFIG_MPC512X
/*
* Create the appropriate control structures to manage
* a new EHCI host controller.
@@ -40,7 +46,7 @@ int ehci_hcd_init(void)
{
struct usb_ehci *ehci;
- ehci = (struct usb_ehci *)CONFIG_SYS_MPC8xxx_USB_ADDR;
+ ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
hccr = (struct ehci_hccr *)((uint32_t)ehci-caplength);
hcor = (struct ehci_hcor *)((uint32_t) hccr +
HC_LENGTH(ehci_readl(hccr-cr_capbase)));
@@ -77,3 +83,132 @@ int ehci_hcd_stop(void)
{
return 0;
}
+
+#else
+
+static void fsl_setup_phy(volatile struct ehci_hcor *);
+static void fsl_platform_set_host_mode(volatile struct usb_ehci *ehci);
+static int reset_usb_controller(volatile struct usb_ehci *ehci);
+static void usb_platform_dr_init(volatile struct usb_ehci *ehci);
+
+/*
+ * Initialise SOC FSL EHCI Controller
+ *
+ * This code is derived from EHCI FSL USB Linux driver for MPC5121
+ *
+ */
+int ehci_hcd_init(void)
+{
+ volatile struct usb_ehci *ehci;
+
+ /* Hook the memory mapped registers for EHCI-Controller */
+ ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
+ hccr = (struct ehci_hccr *)((uint32_t)(ehci-caplength));
+ hcor = (struct ehci_hcor *)((uint32_t) hccr +
+ HC_LENGTH(ehci_readl(hccr-cr_capbase)));
+
+ /* configure interface for UTMI_WIDE */
+ usb_platform_dr_init(ehci);
+
+ /* Init Phy USB0 to UTMI+ */
+ fsl_setup_phy(hcor);
+
+ /* Set to host mode */
+ fsl_platform_set_host_mode(ehci);
+
+ /*
+* Setting the burst size seems to be required to prevent the
+* USB from hanging when communicating with certain USB Mass
+* storage devices. This was determined by analysing the
+* EHCI registers under Linux vs U-Boot and burstsize was the
+* major non-interrupt related difference between the two
+* implementations.
+*
+* Some USB sticks behave better than others. In particular,
+* the following USB stick is especially problematic:
+* 0930:6545 Toshiba Corp
+*
+* The burstsize is set here to match the Linux implementation.
+*/
+ out_be32(ehci-burstsize, FSL_EHCI_TXPBURST(8) | FSL_EHCI_RXPBURST(8));
+
+ return 0;
+}
+
+/*
+ * Destroy the appropriate control structures corresponding
+ * the the EHCI host
Re: [U-Boot] [u-Boot] USB EHCI for mpc512x crashes Uboot
Hi Elinar, I have a board with mpc5121e cpu on it and I'm been patching my Uboot (U-Boot v2009.11) with the patch given initially by Francesco Rendine: I've cleaned up this patch and made it work better (there are some issues with it that needed fixing), but needs (mostly style) work before being submitted as a patch for mainline. Please email me off-list if you want to test the patch for yourself. If it works for you, I should make the effort to clean it up and contribute it back... -- Damien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC5121 EHCI - USB Mass Storage Devices sometimes fail
Dear all,
I am attempting to integrate USB support for Freescale's MPC5121e
processor. It's based on Francesco Rendine's EHCI patch which was submitted
to the mailing list some time ago [1], though I have done some small
modifications to it, in-line with Wolfgang's review comments some time ago.
Our hardware is a board loosely based on the ADS5121 (we have a ADS5121
available somewhere in the back of a cupboard if a reference platform is
preferred).
USB mass storage devices work flawlessly under Linux on our board, but
u-boot often has problems with some USB sticks. Some sticks, such as a 4GB
Lexar (05dc:a768 Lexar Media, Inc.) work in U-Boot all of the time, whereas
a Toshiba (0930:6545 Toshiba Corp. Kingston DataTraveler 2.0 Stick (4GB) /
PNY Attache 4GB Stick), works roughly 50% of the time - about half the time
it will be started correctly and the other half will fail. This result is
repeatable over multiple (more than a half a dozen) sticks of each type.
However, when testing with a Sheeva Plug on the latest Denx Git tree, the
USB sticks work flawlessly - including the problematic Toshiba sticks. Our
port of U-Boot is a little older (August 2009), but we've backported all USB
changes from the latest Git tree, so effectively they're using the same USB
code (with the exception of ehci-fsl vs ehci-kirkwood, of course)
The offending USB sticks have problems is in usb_storage.c. In particular,
they repeatably fail at the following location (forgive the somewhat
intrusive instrumentation):
int usb_stor_get_info(struct usb_device *dev, struct us_data *ss,
block_dev_desc_t *dev_desc)
{
snip
//***
// NOTE: usb_inquiry returns OK, but the next USB transaction fails
//***
if (usb_inquiry(pccb, ss))
return -1;
perq = usb_stor_buf[0];
modi = usb_stor_buf[1];
if ((perq 0x1f) == 0x1f) {
/* skip unknown devices */
return 0;
}
if ((modi0x80) == 0x80) {
/* drive is removable */
dev_desc-removable = 1;
}
memcpy(dev_desc-vendor[0], usb_stor_buf[8], 8);
memcpy(dev_desc-product[0], usb_stor_buf[16], 16);
memcpy(dev_desc-revision[0], usb_stor_buf[32], 4);
dev_desc-vendor[8] = 0;
dev_desc-product[16] = 0;
dev_desc-revision[4] = 0;
#ifdef CONFIG_USB_BIN_FIXUP
usb_bin_fixup(dev-descriptor, (uchar *)dev_desc-vendor,
(uchar *)dev_desc-product);
#endif /* CONFIG_USB_BIN_FIXUP */
printf(ISO Vers %X, Response Data %X\n, usb_stor_buf[2],
usb_stor_buf[3]);
printf([usb_stor_get_info] about to - usb_test_unit_ready\n, dev);
if (usb_test_unit_ready(pccb, ss)) {
printf(Device NOT ready\n
Request Sense returned %02X %02X %02X\n,
pccb-sense_buf[2], pccb-sense_buf[12],
pccb-sense_buf[13]);
if (dev_desc-removable == 1) {
dev_desc-type = perq;
return 1;
}
return 0;
}
snip
In this instance, the Toshiba sticks are of the BBB type, but other BBB
sticks behave fine.
Are there any suggestions as to what the problem might be? What other
information can I provide that would be of use to debug the problem?
Best regards,
Damien Dusha.
[1] http://lists.denx.de/pipermail/u-boot/2009-June/055021.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Any good __LOW COST__ MIPS SBC suggestion please
It will be nice, if its an SBC, and it has atleast 64/128 MB SDRAM, and 16/32 MB flash, USB support, (i can;t expect a super fast processor, but a decent one like 166/200 Mhz should be ok) Pure speculation, mainly because I was thinking about getting one myself, but perhaps the Netgear WNR3500L, which also has a specific Linux port. The specifications are available at [1] and it appears to meet your criteria. Has anyone used one before? If so, what was your experience? -- Damien [1] http://www.myopenrouter.com/article/13378/Features-and-Specifications-NETGEAR-WNR3500L-Open-Source-Wireless-N-Gigabit-Router/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc5121 - EHCI problems with some (but not all) USB hubs
Dear all,
I am following up on a post I made earlier in the week on U-Boot
hanging (infinite looping) in a particular part of
drivers/usb/host/ehci-hcd.c . I also reported that it works for some
hubs and not for others.
I have been attempting to debug this problem and I have found
something of interest. In one instance, one of the hubs that work
has the _same_ chipset of another hub that doesn't work - it has the
same product ID and vendor ID. However, there are what looks to be
some configuration differences between the devices.
I have attached below what Linux reports for lsusb for both hubs and I
have highlighted the differences. Are these differences likely to
have any bearing on the operation of the hub? Is there any other
testing for information that I can supply that may assist in helping
to solve the issue?
Best regards
Damien Dusha.
For the broken hub (with highlighted differences):
Bus 003 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
- bDeviceProtocol 0 Full speed (or root)
hub- DIFFERENT
bMaxPacketSize064
idVendor 0x05e3 Genesys Logic, Inc.
idProduct 0x0608 USB-2.0 4-Port HUB
bcdDevice7.02
iManufacturer 0
iProduct1 USB2.0 Hub
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
--- bInterval 255
--- DIFFERENT
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 4
-- wHubCharacteristic 0x00e9 --- DIFFERENT
Per-port power switching
--- Per-port overcurrent protection
--- Port indicators
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent100 milli Ampere
DeviceRemovable0x00
PortPwrCtrlMask0xff
Hub Port Status:
Port 1: .0100 power
Port 2: .0100 power
Port 3: .0100 power
Port 4: .0100 power
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
DIFFERENT
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Whereas on the working version of a hub with the same product and vendor ID:
Bus 001 Device 015: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT -- DIFFERENT
bMaxPacketSize064
snip
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 4
wHubCharacteristic 0x00e0 - DIFFERENT
Ganged power switching
Ganged overcurrent protection
TT think time 32 FS bits
Port indicators
snip
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub DIFFERENT
bMaxPacketSize064
bNumConfigurations 1
On Tue, Sep 22, 2009 at 4:32 PM, Damien Dusha d.du...@gmail.com wrote:
Dear All,
I am attempting to integrate the USB on the Freescale mpc5121
processor on the mpc5121ads board from Silicon Turnkey for upgrades of
kernel, u-boot etc.
I have succeeded in integrating Francesco Rendine 's EHCI patch for
the MPC5121 (see
http://lists.denx.de/pipermail/u-boot/2009-June/055021.html ) and I
have the general functionality of upgrading from a USB stick working
straight from the USB
Re: [U-Boot] mpc5121 - EHCI problems with some (but not all) USB hubs
On Fri, Sep 25, 2009 at 2:04 AM, Michael Trimarchi
trimar...@gandalf.sssup.it wrote:
Damien Dusha wrote:
Dear All,
I am attempting to integrate the USB on the Freescale mpc5121
processor on the mpc5121ads board from Silicon Turnkey for upgrades of
kernel, u-boot etc.
I have succeeded in integrating Francesco Rendine 's EHCI patch for
the MPC5121 (see
http://lists.denx.de/pipermail/u-boot/2009-June/055021.html ) and I
have the general functionality of upgrading from a USB stick working
straight from the USB, or through some (but not all) USB hubs.
However, I am having problem using the driver with some (but not all)
USB hubs. I have some USB hubs that work out of the box, but I
have other hubs that cause booting u-boot to hang after attempting to
initialise the USB. The ones that do work, and the ones that fail all
fail in the same place the great majority of the time (they succeed
very occasionally).
I have traced the hang to the following lines in
drivers/usb/host/ehci-hcd.c:
/* Wait for TDs to be processed. */
ts = get_timer(0);
vtd = td;
do {
/* Invalidate dcache */
ehci_invalidate_dcache(qh_list);
token = hc32_to_cpu(vtd-qt_token);
if (!(token 0x80))
break;
/* This was my own line I added to check. The
get_timer(ts) always returns 0 and never exits the loop */
debug(get_timer: %d, CONFIG_SYS_HZ: %d\n,
get_timer(ts), CONFIG_SYS_HZ);
} while (get_timer(ts) CONFIG_SYS_HZ);
I think that the git_timer is not proprer implemented here and so
what happen if you go out the busy loop and return an error to the
message?
Can you try on another hardware with u-boot?
Yesterday, we tried the following:
/* Add long delay before entering the loop */
udelay(1);
/* Wait for TDs to be processed. */
/* Remove the loop and exit immediately. Do not wait for timer */
// ts = get_timer(0);
//vtd = td;
//do {
/* Invalidate dcache */
ehci_invalidate_dcache(qh_list);
token = hc32_to_cpu(vtd-qt_token);
// if (!(token 0x80))
// break;
// debug(get_timer: %d, CONFIG_SYS_HZ: %d\n, get_timer(ts),
CONFIG_SYS_HZ);
//} while (get_timer(ts) CONFIG_SYS_HZ);
With the following result:
* If only working hubs and a USB stick is attached, it will do our
auto upgrade sequence as normal.
* If a broken hub is present, U-Boot will report that the devices
are found, but will not actually read a USB stick attached to the hub.
It will not read a stick, even if the stick is attached to a
working hub, and the broken hub is cascaded off the working hub.
Unfortunately, I have no other EHCI hardware available - only a
5200LITE and a AVR32 dev board in the back of the cupboard somewhere.
-- Damien.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mpc5121 - EHCI problems with some (but not all) USB hubs
Hi Michael,
On Fri, Sep 25, 2009 at 9:19 AM, Damien Dusha d.du...@gmail.com wrote:
On Fri, Sep 25, 2009 at 2:04 AM, Michael Trimarchi
trimar...@gandalf.sssup.it wrote:
Damien Dusha wrote:
Dear All,
I am attempting to integrate the USB on the Freescale mpc5121
processor on the mpc5121ads board from Silicon Turnkey for upgrades of
kernel, u-boot etc.
I have succeeded in integrating Francesco Rendine 's EHCI patch for
the MPC5121 (see
http://lists.denx.de/pipermail/u-boot/2009-June/055021.html ) and I
have the general functionality of upgrading from a USB stick working
straight from the USB, or through some (but not all) USB hubs.
However, I am having problem using the driver with some (but not all)
USB hubs. I have some USB hubs that work out of the box, but I
have other hubs that cause booting u-boot to hang after attempting to
initialise the USB. The ones that do work, and the ones that fail all
fail in the same place the great majority of the time (they succeed
very occasionally).
I have traced the hang to the following lines in
drivers/usb/host/ehci-hcd.c:
/* Wait for TDs to be processed. */
ts = get_timer(0);
vtd = td;
do {
/* Invalidate dcache */
ehci_invalidate_dcache(qh_list);
token = hc32_to_cpu(vtd-qt_token);
if (!(token 0x80))
break;
/* This was my own line I added to check. The
get_timer(ts) always returns 0 and never exits the loop */
debug(get_timer: %d, CONFIG_SYS_HZ: %d\n,
get_timer(ts), CONFIG_SYS_HZ);
} while (get_timer(ts) CONFIG_SYS_HZ);
I think that the git_timer is not proprer implemented here and so
what happen if you go out the busy loop and return an error to the
message?
Can you try on another hardware with u-boot?
Today we've done a little more testing and indeed, the timer wasn't
ticking as expected. In this case, the fix was quite simple - I was
doing my auto-update routunes (which initialises the USB) in the
board-specific misc_init_r(void) function (which a couple of others
boards did), which, after studying lib_ppc/board.c is called _before_
interrupt_init(). Hence, interrupts were not enabled and therefore
the timer never ticked.
As a result, I've moved the auto-update routines to a
last_stage_init(void) function, which does it as the last thing before
getting into the main loop. It's interesting that configuring USB
doesn't bring it up somewhere in that init sequence of board_init_r,
but that's another question for another day.
While this solves the hanging issue previously reported, it does not
yet solve the hub bring-up problem. that I have previously reported
although I now have some new information from testing.
* If I cascade the working hubs, it will recognise the USB drive
and update as expected.\
* If I connect one of the USB 1.1 hubs (which are 4-port USB-Serial
devices) through a working hub, it will sometimes recognise the USB
stick, sometimes not, and sometimes appear to hang (or at least until
my patience runs out and I reset the board), and seems to be order
dependant (i.e. which ports on the working hub they are connected
to), though I am still gathering evidence on that point.
* If I connect more than one of the 4-port USB-Serial converters
(USB 1.1 hubs), through a working hub, I have only seen a hang
and/or failed recognitions.
* If I connect the broken USB high-speed hub anywhere in the
system, I get the following error messages:
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices...
USB device not accepting new address (error=20)
4 USB Device(s) found
or
Entering do_auto_update
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 3 USB Device(s) found
0 Storage Device(s) found
or, in one instance, it actually performs an upgrade:
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
1 Storage Device(s) found
Interface: USB
Device 0: Vendor: LEXARRev: 1100 Prod: JD FIREFLY
Type: Removable Hard Disk
Capacity: 960.0 MB = 0.9 GB (1966080 x 512)
Partition 1: Filesystem: FAT16 NO NAME
reading pre.img
.
In short, it's not at all reliable and I have some anecdotal evidence
it has to do with the ordering of the ports, though I will try to
gather more evidence to effect over the next little while.
I hope this information can help.
-- Damien
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
