[U-Boot] mpc5121 - EHCI problems with some (but not all) USB hubs

[Damien Dusha]

Hi Michael,

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