Skip to contentSkip to conversation

USB works (or not) depending on SYS_BOOT (with TPS65920)

U-Boot Orjan Friberg 2 participants 5 messages Jul 7, 2011 – Aug 9, 2011

lore
Share & tools
lore
#0 lore raw

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

Signature · 2 lines
Orjan Friberg
FlatFrog Laboratories AB
#1 lore raw
Quoted 2 lines · Orjan Friberg

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.

Signature · 2 lines
Orjan Friberg
FlatFrog Laboratories AB
#2 lore raw
Quoted 11 lines · Orjan Friberg
Quoted 2 lines · Orjan Friberg

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

Signature · 2 lines
Orjan Friberg
FlatFrog Laboratories AB
#3 lore raw
Quoted 4 lines · Orjan Friberg
Quoted 3 lines · Orjan Friberg
Quoted 2 lines · Orjan Friberg

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.

Quoted 13 lines
Quoted 8 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

Thanks for any suggestions,

Orjan

Quoted 8 lines

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

#4 lore raw
Quoted 29 lines · Jason Kridner
Quoted 4 lines · Orjan Friberg
Quoted 3 lines · Orjan Friberg
Quoted 2 lines · Orjan Friberg

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.

Quoted 18 lines
Quoted 8 lines

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

Quoted 8 lines
Quoted 2 lines

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

Quoted 30 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

Thanks for any suggestions,

Orjan

Quoted 8 lines

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