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 <picmas...@mail.bg>
wrote:
Hi Fabio,
On 05/04/2015 06:30 AM, Fabio Estevam wrote:
From: Fabio Estevam <fabio.este...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
