Hi Michael,
On Fri, Sep 25, 2009 at 9:19 AM, Damien Dusha d.dusha@gmail.com wrote:
On Fri, Sep 25, 2009 at 2:04 AM, Michael Trimarchi trimarchi@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: LEXAR Rev: 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