This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB works (or not) in u-boot depending on SYS_BOOT (with TPS65920)

Other Parts Discussed in Thread: TPS65920

Hi,

I'm seeing some weird behaviour with host mode USB on the OTG port in u-boot (2011.03), and just wondering if anyone else seen this.

Booting from NAND after a power cycle, host mode USB doesn't work (the 'usb reset' command times out).

However, if I change the boot order (external button) to go through USB and UART before NAND it does work (it enters host mode, and devices are discovered).

After that, USB continues to work after warm-resetting the board. It's not until after a cold reset/power cycle that it stops working again.


It seems the boot rom must be doing some initialization of the USB phy (this is with a TPS65920). Dumping the I2C regs of the USB phy in u-boot shows a lot of differences between the two boot modes.

This is on a custom board, BeagleBoard derived but with a 3730.


Any ideas?

Thanks,
Orjan

  • I forgot to add that I'm using a configuration header and not x-loader as the 1st stage bootloader.

    On a BeagleBoard xM (using x-loader), 'usb reset' works fine in u-boot coming out of a cold reset.

    I'd better check my configuration header.

     

  • Ok, so I've booted a u-boot with a configuration header on the xM board and 'usb reset' works fine after a cold boot.  Vice versa, using x-loader + u-boot on our own board, 'usb reset' does not work.

    I'm looking at the silicon erratas for the 3730 and the TPS chip and found a couple of interesting entries (for example 1.101 in sprz319c) relating to the OTG functionality.  However, they don't correlate with silicon revision differences between the xM board and our own board.

    What other stuff should I be looking into?  (The xM board uses a 65950 whereas we are using the 65920, but the errata is for all 659x0 devices.)

     

    The 3730 TRM talks about the boot ROM doing USB PHY initialization, but it doesn't list any details.

    Thanks for any suggestions,

    Orjan

  • Hi,

       Did you make any progress with this issue? I believe we are seeing the same problem although characterised somewhat differently. I haven't tried changing the sysboot pins, and our uboot doesn't have usb support. However usb seems to work as long the cable is plugged into a host while the kernel is booting. After this, I can warm reboot, unplug, replug, and everything works as expected. But if the kernel boots from a cold poweron with usb unplugged, usb will not work. My attempts to trace the problem through the MUSB code have gone nowhere as everything seems identical so far. This recently became a more serious problem for us since it turns out that lower sleep modes with PM enabled seem to put it in the same state as the cold boot.

      If the device is cold booted, and usb later plugged in, the VBUS charge pump appears to activate although the ID pin was correctly read. Once the charge pump turns on, there also appears to be no way to stop it. Maybe it detects its own vbus presence?

    Regards,

    Jon Pry

  • Hi,

    Not any progress as in actually solving or understanding. We did change a few things around on our board, and usb now works from a cold boot (which was the most important thing for us).  However, a second 'usb reset' in u-boot stopped working.  What we did was route the VBUS pin on the TPS chip to permanent 5V so that it always senses VBUS.

     

    If you're using the 659x0 USB transciever, you can turn off the VBUS charge pump by writing to the DRVVBUS bit in the OTG_CTRL register over i2c.

     

     

  • Hi , 

    Can you please share the code  OTG_CTRL register VBUS off.

    Or please point me the right driver file whic i need to make change , I have tried it from twl4030-usb.c 

    with out any success.

    Any help is greatly appreciated.

     

    Regards,

    Dibin

  • Hi,

    It's been a while, but I'm pretty sure I just used u-boot's built-in i2c command on the u-boot command line (i.e. I did not add it to any driver) since I was just messing around.  You'll need to look up the I2C slave and register address in the TPS chip documentation of course.

  • Hi Orjan.

    Thankyou very much for hint.

    I have one more doubt , if I change the register in u-boot, would it persists in the kernel too.

    I need changes in kernel.

    Regards,

    Dibin

  • I don't know, you'd have to check under Linux whether the change is persistent or not using i2cget/i2cset or similar userland tool.

    Of course, changing stuff like this could break all sorts of things; I only did it for exploration and debugging.

    Good luck,

    Orjan