USB host port pull-up/down status

[Dirk Behme]

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

[koen]

On 25 mei, 07:40, Dirk Behme <dirk.be...@googlemail.com> 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 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

>
> 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
> 2KDownloaden
>
>  u-boot.bin_usb_pin_mux_test.bz2
> 196KDownloaden

[koen]

On 25 mei, 07:40, Dirk Behme <dirk.be...@googlemail.com> 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?

regards,

Koen

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

[Dirk Behme]

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

[Dirk Behme]

Dirk Behme wrote:
> koen wrote:
>
>> On 25 mei, 07:40, Dirk Behme <dirk.be...@googlemail.com> 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