USB host port pull-up/down status

There was some discussion at IRC [1] changing the USB host port pull-up/down status on the phy, the lock-ups have been eliminated (*).

Looking at the usb_validation_uboot_patch.diff [2] this seems to be done with something like patch in attachment.

I built a uboot with this (attachment, too), anybody likes to test? Does USB host feel better with this? Note that kernel CONFIG_OMAP_MUX has to be disabled for this, as enabled CONFIG_OMAP_MUX overwrites uboot's pin mux settings.

Thanks

Dirk

(*) "but, there are still many errors in the transmissions"

[1] http://www.beagleboard.org/irclogs/index.php?date=2008-05-18#T15:21:01

[2] http://code.google.com/p/beagleboard/wiki/USBHostTestREPRODUCE

u-boot_1_1_4_usb_host_pin_mux_test.patch (2.35 KB)

u-boot.bin_usb_pin_mux_test.bz2 (145 KB)

There was some discussion at IRC [1] changing the USB host port
pull-up/down status on the phy, the lock-ups have been eliminated (*).

Looking at the usb_validation_uboot_patch.diff [2] this seems to be
done with something like patch in attachment.

I built a uboot with this (attachment, too), anybody likes to test?
Does USB host feel better with this? Note that kernel CONFIG_OMAP_MUX
has to be disabled for this, as enabled CONFIG_OMAP_MUX overwrites
uboot's pin mux settings.

EHCI doesn't work with this uboot regardless of CONFIG_OMAP_MUX being
enabled.

The output if lsusb in both cases is:

root@beagleboard:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 1 Device 1: ID 1d6b:0002
root@beagleboard:~#

Do more people see this behaviour?

regards,

Koen

I think we should address this problem step by step:

1) Does u-boot setup GPIOs and MUX settings correctly for the
beagleboard? (e.g. copy/paste errors from evm and sdp code)
2) Does linux[1] overwrite u-boot settings for GPIO and MUXes?
2b) Does linux setup GPIOs and MUX settings correctly for the
beagleboard? (e.g. copy/paste errors from evm and sdp code)
3) Is the PHY getting setup properly in linux?

Can anyone familiar with the u-boot and kernel GPIO/MUX macros give an
opinion on the above?

regards,

Koen

[1] When I say 'linux' I mean linux-omap git HEAD, not the wtbu kernel

koen wrote:

There was some discussion at IRC [1] changing the USB host port
pull-up/down status on the phy, the lock-ups have been eliminated (*).

Looking at the usb_validation_uboot_patch.diff [2] this seems to be
done with something like patch in attachment.

I think we should address this problem step by step:

1) Does u-boot setup GPIOs and MUX settings correctly for the
beagleboard? (e.g. copy/paste errors from evm and sdp code)
2) Does linux[1] overwrite u-boot settings for GPIO and MUXes?
2b) Does linux setup GPIOs and MUX settings correctly for the
beagleboard? (e.g. copy/paste errors from evm and sdp code)
3) Is the PHY getting setup properly in linux?

Can anyone familiar with the u-boot and kernel GPIO/MUX macros give an
opinion on the above?

For MUX settings hopefully this makes checking easier:

1. u-boot_1_1_4_beagle_pin_mux.txt (attachment)

2. linux_git_beagle_pin_mux.txt (attachment)

Note: Ball names not from OMAP3530 (?)

3. Beagle HW manual (schematic with pin/balls)

http://www.beagleboard.org/uploads/Beagle_HW_Reference_Manual_A_5.pdf

4. OMAP3 pin mux

SPRUF98.pdf, page 684, section 6.4.4.3 Pad Multiplexing Register Fields, Table 6-4

Dirk

u-boot_1_1_4_beagle_pin_mux.txt (41.9 KB)

linux_git_beagle_pin_mux.txt (9.25 KB)

Dirk Behme wrote:

koen wrote:

There was some discussion at IRC [1] changing the USB host port
pull-up/down status on the phy, the lock-ups have been eliminated (*).

Looking at the usb_validation_uboot_patch.diff [2] this seems to be
done with something like patch in attachment.

I think we should address this problem step by step:

1) Does u-boot setup GPIOs and MUX settings correctly for the
beagleboard? (e.g. copy/paste errors from evm and sdp code)
2) Does linux[1] overwrite u-boot settings for GPIO and MUXes?
2b) Does linux setup GPIOs and MUX settings correctly for the
beagleboard? (e.g. copy/paste errors from evm and sdp code)
3) Is the PHY getting setup properly in linux?

Can anyone familiar with the u-boot and kernel GPIO/MUX macros give an
opinion on the above?

For MUX settings hopefully this makes checking easier:

1. u-boot_1_1_4_beagle_pin_mux.txt (attachment)

...

4. OMAP3 pin mux

SPRUF98.pdf, page 684, section 6.4.4.3 Pad Multiplexing Register Fields, Table 6-4

I started (not ready yet) comparing u-boot_1_1_4_beagle_pin_mux.txt with pin mux in above OMAP3 TRM. First results:

1) Empty #define CONTROL_PADCONF_ in uboot mux config definitions.

-> Copy & paste error?

2) MUX_VAL(CP(ETK_D15), (IEN | PTU | EN | M4)) /*GPIO_29*/\

is wrong. Has to be ETK_D15_ES2 to configure GPIO_29. Beagle HW manual:

"GPIO_29 SD Write protect lead. Can be polled or set to an interrupt."

With ETK_D15 we write to non existing (?) register.

3)

CONTROL_PADCONF_ETK_D11_ES2 0x05F2
CONTROL_PADCONF_ETK_D12_ES2 0x05F4
CONTROL_PADCONF_ETK_D13_ES2 0x05F6
CONTROL_PADCONF_ETK_D14_ES2 0x05F8

are not touched by uboot pin mux. Is this correct?

4)

sys_nreswarm 0x0A08
jtag_rtck 0x0A4E
jtag_tdo 0x0A50

are not touched by uboot pin mux. Is this correct?

More to come,

Dirk