[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)

[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)

[Orjan Friberg]

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

-- 
Orjan Friberg
FlatFrog Laboratories AB

[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)

[Orjan Friberg]

On 2011-07-07 11:37, Orjan Friberg wrote:
> It seems the boot rom must be doing some initialization of the USB phy
> (this is with a TPS65920).

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

On a BeagleBoard xM (with x-loader), usb reset works fine coming out of 
a cold reset.

I'd better check my configuration header.

-- 
Orjan Friberg
FlatFrog Laboratories AB

[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)

[Orjan Friberg]

On 2011-07-07 14:27, Orjan Friberg wrote:
> On 2011-07-07 11:37, Orjan Friberg wrote:
>> It seems the boot rom must be doing some initialization of the USB phy
>> (this is with a TPS65920).
>
> I forgot to add that I'm using a configuration header and not x-loader
> as the 1st stage bootloader.
>
> On a BeagleBoard xM (with x-loader), usb reset works fine 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 entries relating to the OTG functionality.  However, 
they don't correlate with silicon revision differences between the xM 
board and our own board (and they don't seem to apply here).

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

-- 
Orjan Friberg
FlatFrog Laboratories AB

[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)

[Jason Kridner]

On Tue, Aug 9, 2011 at 4:21 AM, Orjan Friberg <of@flatfrog.com> wrote:
> On 2011-07-07 14:27, Orjan Friberg wrote:
>> On 2011-07-07 11:37, Orjan Friberg wrote:
>>> It seems the boot rom must be doing some initialization of the USB phy
>>> (this is with a TPS65920).

It does.  The BeagleBoard-xM uses a TPS65950, but I don't know if that
matters.  The ROM code does send some commands across the I2C bus.
You might grab yourself an I2C bus monitor to make it easy to see
what.

>>
>> I forgot to add that I'm using a configuration header and not x-loader
>> as the 1st stage bootloader.
>>
>> On a BeagleBoard xM (with x-loader), usb reset works fine 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 entries relating to the OTG functionality. ?However,
> they don't correlate with silicon revision differences between the xM
> board and our own board (and they don't seem to apply here).
>
> 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.)

I'd carefully check that you are powering up all the critical rails
for USB to work.  You can take a look at the USB PHY initialization in
the kernel [2].  Is the OTG functionality working for you when you
boot into Linux?  Are these initialization steps part of the setup for
your board?

Might have been good to CC the x-loader and beagleboard lists.  I see
you checked on the e2e.ti.com list at [1].  That's good.

You might want to try using the latest u-boot, since you seem to
indicate you are using an old version.

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

You might be able to get details somewhere, but I suspect you'll get
the I2C bus capture first.

>
> Thanks for any suggestions,
>
> Orjan
>
> --
> Orjan Friberg
> FlatFrog Laboratories AB
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[1] http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/120937/454647.aspx

[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)

[Jason Kridner]

On Tue, Aug 9, 2011 at 2:25 PM, Jason Kridner <jkridner@beagleboard.org> wrote:
> On Tue, Aug 9, 2011 at 4:21 AM, Orjan Friberg <of@flatfrog.com> wrote:
>> On 2011-07-07 14:27, Orjan Friberg wrote:
>>> On 2011-07-07 11:37, Orjan Friberg wrote:
>>>> It seems the boot rom must be doing some initialization of the USB phy
>>>> (this is with a TPS65920).
>
> It does. ?The BeagleBoard-xM uses a TPS65950, but I don't know if that
> matters. ?The ROM code does send some commands across the I2C bus.
> You might grab yourself an I2C bus monitor to make it easy to see
> what.
>
>>>
>>> I forgot to add that I'm using a configuration header and not x-loader
>>> as the 1st stage bootloader.
>>>
>>> On a BeagleBoard xM (with x-loader), usb reset works fine 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 entries relating to the OTG functionality. ?However,
>> they don't correlate with silicon revision differences between the xM
>> board and our own board (and they don't seem to apply here).
>>
>> 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.)
>
> I'd carefully check that you are powering up all the critical rails
> for USB to work. ?You can take a look at the USB PHY initialization in
> the kernel [2]. ?Is the OTG functionality working for you when you
> boot into Linux? ?Are these initialization steps part of the setup for
> your board?

[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/usb/otg/usb/otg/twl4030-usb.c;h=14f66c35862938adc5817c123233521c9ca1f925;hb=HEAD#l531

>
> Might have been good to CC the x-loader and beagleboard lists. ?I see
> you checked on the e2e.ti.com list at [1]. ?That's good.
>
> You might want to try using the latest u-boot, since you seem to
> indicate you are using an old version.
>
>>
>> The 3730 TRM talks about the boot ROM doing USB PHY initialization, but
>> it doesn't list any details.
>
> You might be able to get details somewhere, but I suspect you'll get
> the I2C bus capture first.
>
>>
>> Thanks for any suggestions,
>>
>> Orjan
>>
>> --
>> Orjan Friberg
>> FlatFrog Laboratories AB
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
> [1] http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/120937/454647.aspx
>