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

[Michael Trimarchi]

Damien Dusha wrote:
> 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
> .
>
>
>   
Looking at linux:

we have
phy_mode = FSL_USB2_PHY_UTMI_WIDE


portsc |= PORT_PTS_PTW;

ehci_writel(ehci, portsc, &ehci->regs->port_status[0]);

if (!strcmp(getenv("usb_phy_type"), "utmi"))
+                out_le32(&(hcor->or_portsc[0]), PORT_PTS_UTMI);
+        else
+                out_le32(&(hcor->or_portsc[0]), PORT_PTS_ULPI);

In this case you must config as a PORT_PTS_PTW so maybe add a if else

Michael






> 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
>
>