<snip>
Up until a reboot or other warm software reset (u-boot 'reset'
command, Linux 'reboot', or similar), for me. After a warm software
reset I observe the LEDs to have inverted themselves, now my 100 Mbit
network link is shown by both LEDs being off and removing the cable
turns both LEDs on. A further reboot or warm reset inverts it back
to how it was before.
Has any one else observed this?
I'm worried that no one else has seen this. I'm searching for someone
to verify my findings below. If you have an A5 or A6 bone, could you
please help me out?
The following is how to reproduce on A5 and A6 bones with current (as
of this morning) mainline U-Boot 2013.01-rc1-00071-g1cc619b and no
uEnv.txt using the 'am335x_evm_config' and USB power only (I do not
allow Linux to load):
A3: at first boot when connected to 100 Mbit Ethernet, just the orange
Ethernet LED is on and the green LED is off, then after u-boot loads the
networking components just the green LED is on and the orange LED is
off. Executing a u-boot 'reset' command does not change the LED
orientation. This is as expected, u-boot 'reset' command (a warm
software reset) should not change the LED orientation even though the
SMSC PHY's nRST line gets pulled and thus the PHY should resample its
strapping resistors.
A5: at first boot when connected to 100 Mbit Ethernet, just the orange
Ethernet LED is on and the green LED is off, then after u-boot loads the
networking components just the green LED is on and the orange LED is
off. However, executing a u-boot 'reset' command DOES change the LED
orientation. After the 'reset' command, both the orange and green LEDs
are on until u-boot loads the networking components and then both LEDs
turn off. A further u-boot 'reset' command reverts to the original LED
configuration and operation. This is NOT expected, u-boot 'reset'
command should NOT change the orientation of the Ethernet LEDs.
A6: at first boot when connected to 100 Mbit Ethernet, no Ethernet LEDs
are on, then after u-boot loads the networking components both the
orange and green LEDs are on. However, executing a u-boot 'reset'
command DOES change the LED orientation. After the 'reset' command,
both the orange and green LEDs are off until u-boot loads the
networking components and then both LEDs turn on. A further u-boot
'reset' reverts to the original LED configuration and operation. This
is NOT expected, u-boot 'reset' command should NOT change the
orientation of the Ethernet LEDs.
I'm working on patch to be submitted to mainline u-boot to either
lengthen the PRM_DEVICE.PRM_SRTTIME.RSTTIME1 register's default from
0x06 to at least 0x80 (determined from some quick testing and results
shown in previous scope plots to this thread) or to provide a software
reset to the PHY (which has not yet been tested). If lengthening the
RSTTIME1 value is performed, the nRST line still is not asserted to the
SMSC PHY for longer than the SMSC recommended minimum, which seems OK,
but isn't ideal. The ideal solution is a change to the nRST PHY
circuit to ensure that nRST is asserted for at least 100 us when ever
it's asserted.
A caveat on the A3, if I reduce the RSTTIME1 register to lower than the
default 0x06, I can make the A3 act like the A5. It seems the A3 I
have to test with is slightly less sensitive, but still exhibits the
issue with low values of RSTTIME1. Due to this, not all bones may show
this issue. Bones, in general, may be dancing on the limit of the SMSC
PHY's minimum nRST asserted duration. My theory is that with very
short nRST durations, the PHY's sampling of the strapping resistors is
being cut short and thus the LED orientation (active low vs high) gets
inverted. Why this reverses itself on a warm software reset still
boggles me.
I'm not confident in sending a patch for this unless someone else can
verify my observations above. Could a few intrepid souls who have
either A5 or A6 bones and 100 Mbit Ethernet switches please try to
reproduce this issue? It should only take you a moment and will not
harm your SD card. Just stop the boot at the u-boot prompt and observe
the LEDs, then issue a 'reset' command to u-boot and again stop the
boot and observe the LEDs.
Thanks,
Andrew