[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[Nikolay Dimitrov]

Hi Fabio,

On 05/04/2015 03:22 PM, Fabio Estevam wrote:
> Hi Nikolay,
>
> On Mon, May 4, 2015 at 1:18 AM, Nikolay Dimitrov <picmaster at mail.bg>
> wrote:
>> Hi Fabio,
>>
>> On 05/04/2015 06:30 AM, Fabio Estevam wrote:
>>>
>>> From: Fabio Estevam <fabio.estevam at freescale.com>
>>>
>>> mx6cuboxi sometimes fails to recognize the Ethernet PHY:
>>>
>>> Net:   Phy 0 not found
>>>
>>> The explanation comes from a patch from Rabeeh:
>>>
>>> "The LED_ACT pin on the carrier-one boards had a pull down that
>>> forces the phy address to 0x0; where on CuBox-i and the
>>> production HummingBoard that pin is connected directly to LED
>>> that depending on the pull down strength of the LED it might be
>>> sampled as '0' or '1' thus the phy address might appear as
>>> either address 0x0 or 0x4."
>>
>>
>> There's no such thing as "LED pull-down". The forward voltage drop
>> of a LED is between 1.65V (red low-power LEDs) to 2.1V (green
>> LEDs) to even more for blue LEDs. Even the lowest Vf doesn't
>> qualify as logic "0" for LVCMOS33, which is around 1V max (Vil).
>> The LED just can't pull-down the voltage level low enough.
>>
>> So, unless you have some control over the pin (via a programmable
>> on-chip pull-up or pull-down) which I doubt as it's a PHY pin, the
>>  actual behavior is that the pin is floating, and samples a random
>> value at boot. Which means, the hardware is just buggy.
>
> As mentioned in the commit log this explanation comes from
> Solid-run.
>
> The key point here is that the PHY can appear at 0x0 and 0x4, so this
> patch handles such case.

Yes, I saw that. Sorry for the off-topic. The reason I allowed myself to
comment is that this text will go into git log, and people can treat it
as the proper way to configure boot-strapable pins, which I don't think
it is.

Otherwise your patch is completely OK - this is the only way to fix such
behavior of the hardware.

Kind regards,
Nikolay