Hello,
I have a Colibri vf50 module running linux V2.5 on a custom board with two LAN ports.
The onboard and off-board ethernet ports are detected on boot by the linux kernel:
[ 15.520727] fec 400d0000.ethernet eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=400d0000.etherne:00, irq=-1)
[ 15.560467] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 15.710705] fec 400d1000.ethernet eth1: Freescale FEC PHY driver [Micrel KSZ8041] (mii_bus:phy_addr=400d1000.etherne:01, irq=-1)
[ 15.744544] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
The off-board PHY (eth0) is detected as a [Generic PHY] rather than a [Micrel KSZ8041], the same as the onboard PHY (eth1).
Do I have to specify the Micrel device in the device tree somewhere?
Also, when I plug in a network cable into the off-board ethernet port (eth0), the network connection is shown as half duplex, no flow control:
[ 197.560866] fec 400d0000.ethernet eth0: Link is Up - 100Mbps/Half - flow control off
[ 197.568786] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
whereas the same network plugged into the onboard ethernet port (eth1) is shown as full duplex, flow control rx/tx:
[ 17.710846] fec 400d1000.ethernet eth1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 17.719052] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Is this due to the Generic PHY or do I need to configure the network configuration for full/half duplex and flow control?
Any help is most appreciated.
PHY’s get detected by reading a register from the PHY. If that fails, I guess the kernel falls back to a Generic PHY. So to me it looks like a MII issue, can you check your MII configuration?
To test it, you can try using U-Boot which allows to read PHY registers manually. The identifier registers are 2h/3h (refer to the PHY datasheet for details). This is the read for the internal PHY (on address 0):
Colibri VFxx # mii read 0 2
0022
Colibri VFxx # mii read 0 3
1513
The half/full duplex issue is likely related to that communication issue since also duplex mode gets negotiated through the MII bus.
I’m assuming the external phy is address 1? If so, I see exactly the same:
Colibri VFxx # mii read 0 2
0022
Colibri VFxx # mii read 0 3
1513
Colibri VFxx # mii read 1 2
0022
Colibri VFxx # mii read 1 3
1513
I can also ping both eth0 and eth1.
I think you are reading the same PHY. MII is a I2C like protocol, and the address byte also encodes whether its a read or write using the LSB, so with the 1 you probably address device 0 too.
The effective address depends on the strapping pins of your PHY. How is your PHY’s MII bus connected?
I just realized that U-Boot does not support the second MII. On Vybrid, each (R)MII has its own MII bus, hence it could be that both PHY’s are actually using address 0. I think by default the Kernel searches the PHY on each FEC’s MII bus. If your configuration looks different, than you need to specify that in the device tree. At least you need to enable the second FEC controller in the device tree (see our dual-eth device tree).
Linux has a tool called mii-tool, which could be helpful too. It is part of the package net-tools. The output should look like this:
root@colibri-vf:~# mii-tool -v eth0
eth0: negotiated 100baseTx-FD, link ok
product info: vendor 00:08:85, model 17 rev 3
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
I’m using the same circuit as the Toradex Vybrid dual ethernet example schematic with the dual ethernet device tree customization from Toradex.
When using mii-tool on eth0 and eth1, I get:
mii-tool -v -v eth0
Using SIOCGMIIPHY=0x8947
eth0: 10 Mbit, half duplex, no link
registers for MII PHY 0:
0000 3800 0000 0001 00e0 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
product info: vendor 00:00:00, model 0 rev 1
basic mode: 10 Mbit, half duplex
basic status: no link
capabilities: 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-HD 10baseT-FD 10baseT-HD
mii-tool -v -v eth1
Using SIOCGMIIPHY=0x8947
eth1: negotiated 100baseTx-FD, link ok
registers for MII PHY 1:
3000 786d 0022 1513 01e1 cde1 000d 2001
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0001 0000 0300 0000
0000 0000 0000 0000 0008 0000 0000 9198
product info: vendor 00:08:85, model 17 rev 3
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
I am not sure if this is a hardware or a software issue. Eth0 vendor registers do not appear to be being read. However, I can ping both interfaces, which suggests that the hardware may be OK?
Found a missing pullup resistor on the Phy MDIO pin, which appears to have solved this issue.
Many thanks for your help with this.
Thanks for the update! Yeah that makes sense, since the issues you were seeing indicated MDIO issues…
Hi ashinton,
I have also faced same issue.so can you tell me.what is the value of pull-up register for MDIO pin?
Thank you in advance.
Best Regards,
Kanji Viroja.
