(Self answered for anyone interested!)
SMSC LAN8710A/LAN8710Ai Datasheet Revision 1.4 (08-23-12)
Documents the Special Modes Register which can override the values latched at hard reset of the part.
The designed default values for the Beaglebone can be set early in the initialisation sequence to the following values:
SMR.MIIMODE := MII_MODE;
SMR.MODE := ALL;
SMR.PHYAD := 0;
Steve
Got any pointers to where this is done in u-boot or Linux?
Sorry, I found your question intriguing but didn't have time to look
through the source to answer it. I'd like to learn, though, if you
have the time to share.
Thanks,
Andrew
Andrew, Thanks for your comments.
My interest in u-boot or Linux code was to use as a reference model for another OS implementation.
I could not find the code in either source tree.
So I have gone back to first principles and researched the PHY part to derive that pseudo code.
Regards
Steve
As far as I can tell from u-boot, it probes the PHY asking for what
auto-negotiate abilities u-boot should use, then u-boot builds an
auto-negotiate "table" (of sorts) to do the auto-negotiation. u-boot
will print that info along with the result of auto-negotiation.
I don't see u-boot changing what ever the PHY was configured with.
For example, on a 100baseTX switch, I see:
Loading kernel from TFTP
cpsw Waiting for PHY auto negotiation to complete. done
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.101.20
link up on port 0, speed 100, full duplex
But, if I connect a beaglebone to a 10baseT device, u-boot will
output:
Loading kernel from TFTP
cpsw Waiting for PHY auto negotiation to complete. done
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.101.20
link up on port 0, speed 100, full duplex
I've verified that the device on the other end of the Ethernet link
ethtool says and an auto-negotiating switch I have only lights the
10baseT light with my laptop set this way if I plug to the switch.
$ sudo ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes
Might the SMSC PHY on the bone be performing auto-negotiation in
violation of its settings?
I'm not super familiar with Ethernet, but I do know that things
like wireshark won't let me see the auto-negotiation on the wire. I'm
curious to understand what's happening here as from my look though the
code I also don't see where u-boot changes the PHY settings to allow
for 10baseT auto-negotiation to work.
I'm considering hooking a scope up to an Ethernet cable and having a
look but I'm not sure how visible the auto-negotiation would be,
especially as triggering on it might be difficult.
Any thoughts?
I wonder if this has any connection to the SYS_RESETn duration being
too short for the PHY...
-Andrew