[U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 05/18/2013 09:13 PM, Lubomir Popov wrote:

> Hi Gilles,
> 
>> On 05/16/2013 10:39 AM, Lubomir Popov wrote:
>>
>>> Hi Gilles,
>>>
>>> On 16/05/13 01:31, Gilles Chanteperdrix wrote:
>>>> On 05/15/2013 05:55 PM, Lubomir Popov wrote:
>>>>
>>>>> Prerequisites: appropriate patches to the USB EHCI and Eth
>>>>> drivers, and to the OMAP5 clock register definitions.
>>>>
>>>>
>>>> Hi Lubomir,
>>>>
>>>> I have been trying to get the USB working on omap5 uEVM yesterday. In
>>>> addition to your code, I added the changes necessary to pinmux the 79
>>>> and 80 GPIOS correctly, but it does not seem to work. I suspect there
>>>> is
>>>> something else missing than simply USB specific bits, because when the
>>>> ethernet phy is supposedly out of reset, the ethernet leds keep turned
>>>> off. I was thinking about checking the PMIC registers.
>>> PMIC wouldn't be related.
>>
>>
>> Hi,
>>
>> My idea was that if the ethernet chip does not power up, maybe it is
>> because some LDO or SMPS needs to be powered on. The board documentation
>> says for some LDOs that they are enabled on boot and does not say for
>> others, so that may be because they need to be enabled.
> Both USB devices are powered by VCC_3V3_MAIN, provided by an external SMPS
> chip (U3). With the default configuration of the uEVM, this SMPS turns on
> whenever DC wall power is present; the other option - control by the PMIC
> SYSEN1 output, has no relation to software as well (SYSEN1 is driven by
> the PMIC power-on/off sequencer, which is burnt into the PMIC EPROM. Upon
> power-on it goes high at the very beginning of the sequence). So,
> unfortunately, this could not be the cause.
> Regarding the Ethernet LEDs, as far as I remember, they didn't light up at
> all, although Ethernet worked. The smsc95xx driver in u-boot supports the
> LAN9730 in compatibility mode and probably does not setup LED operation
> properly.
>>
>>>
>>> Did you pull the current u-boot master and then apply the following
>>> patches
>>> before testing? Eager to know ;)
>>>
>>> http://patchwork.ozlabs.org/patch/232742/
>>> http://patchwork.ozlabs.org/patch/244100/
>>
>>
>> I was working with u-boot-ti master, applied all the patches, and it
>> still does not seem to work. I just tried the u-boot master branch but
>> it fails to compile for omap5_uevm.
> I think mainline u-boot master still lacks another vital patch for OMAP5
> USB, which has been applied to u-boot-ti only (this is commit
> 2bcc785a1e8ffd3783c2116837fb4b4866a70cef). So please stay with the ti
> branch for now.
> Don't know what to say; it's a pity that I don't have the hardware at hand.


It does not really matter, I can use the SD card to copy my kernels for
now. It is a bit less convenient than TFTP, but still works.

> One more thing that I would suggest to try: remove the patch from ehci-hcd.c
> that calls the HSIC device reset function for OMAP5. The essence is one
> line, a function call:
> 
> omap5_ehci_hsic_reset_device(le16_to_cpu(req->index));
> 
> Just comment it out. It is fairly possible that on ES2.0 this workaround is
> not needed anymore (although I don't recall anything on the subject in the
> Silicon Errata docs). I have tested on ES1.0 only, so it has to be
> verified that this patch doesn't have a negative impact on ES2.0.


No, it does not seem to make any difference.


-- 
                                                                Gilles.