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: 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot