Beaglebone Black Ethernet Phy Not Detected on Boot.

GoogleGroups
141

Hi, first thank you for the response, here is the output where the network did not work:

root@beaglebone:~# dmesg | grep mdio
[ 1.040419] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 1.040439] davinci_mdio 4a101000.mdio: detected phy mask fffffffb
[ 1.047217] libphy: 4a101000.mdio: probed
[ 1.047246] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver SMSC LAN8710/LAN8720
[ 6.101577] libphy: PHY 4a101000.mdio:03 not found
[ 6.106625] net eth0: phy 4a101000.mdio:03 not found on slave 1

root@beaglebone:~# sudo ifconfig -a
eth0 Link encap:Ethernet HWaddr 78:a5:04:e6:6a:89
inet addr:192.168.0.21 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:40

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:227 errors:0 dropped:0 overruns:0 frame:0
TX packets:227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21648 (21.1 KiB) TX bytes:21648 (21.1 KiB)

usb0 Link encap:Ethernet HWaddr 0e:d5:67:ae:38:c8
inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::cd5:67ff:feae:38c8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:182 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24685 (24.1 KiB) TX bytes:6304 (6.1 KiB)

root@beaglebone:~# ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
From 192.168.0.21 icmp_seq=1 Destination Host Unreachable
From 192.168.0.21 icmp_seq=2 Destination Host Unreachable
From 192.168.0.21 icmp_seq=3 Destination Host Unreachable
From 192.168.0.21 icmp_seq=4 Destination Host Unreachable
^C
— 192.168.0.10 ping statistics —
6 packets transmitted, 0 received, +4 errors, 100% packet loss, time 5001ms
pipe 4

And Here is the boot that the network works:

root@beaglebone:~# dmesg | grep mdio
[ 1.040170] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 1.040187] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[ 1.046996] libphy: 4a101000.mdio: probed
[ 1.047025] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 5.425524] libphy: PHY 4a101000.mdio:01 not found
[ 5.430563] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 8.501638] libphy: 4a101000.mdio:00 - Link is Up - 100/Full

root@beaglebone:~# sudo ifconfig -a
eth0 Link encap:Ethernet HWaddr 78:a5:04:e6:6a:89
inet addr:192.168.0.21 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::7aa5:4ff:fee6:6a89/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:137 errors:0 dropped:0 overruns:0 frame:0
TX packets:188 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12183 (11.8 KiB) TX bytes:17169 (16.7 KiB)
Interrupt:40

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:79 (79.0 B) TX bytes:79 (79.0 B)

usb0 Link encap:Ethernet HWaddr d6:2f:6f:eb:3c:2f
inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::d42f:6fff:feeb:3c2f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:192 errors:0 dropped:0 overruns:0 frame:0
TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:25410 (24.8 KiB) TX bytes:9669 (9.4 KiB)

root@beaglebone:~# ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
64 bytes from 192.168.0.10: icmp_req=1 ttl=128 time=1.50 ms
64 bytes from 192.168.0.10: icmp_req=2 ttl=128 time=1.44 ms
64 bytes from 192.168.0.10: icmp_req=3 ttl=128 time=1.49 ms
^C
— 192.168.0.10 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.449/1.480/1.502/0.038 ms

142

Humm, that is odd, it corrected for [phy mask fffffffb] with [4a101000.mdio:02]

But it should have been phy[4]... [4a101000.mdio:04]

The math conversion in the phy search patch is:

phy_mask = fffffffb

for (i = 0; i < PHY_MAX_ADDR; i++) {
      if ((phy_mask & (1 << i)) == 0) {
              addr = (u32) i;
              break;
       }
}

Regards,

143

But the network interface seems to be working fine.

What nameserver is listed in /etc/resolv.conf under “nameserver” ? If it is different from your network, then you should probably change it to be accurate.

Then try to ping local IPs again . . .

144

As an aside, is this in fact the problem, it would probably be listed as “nameserver 192.168.1.1” Which seems to be the default value as “shipped”

145

name servers have nothing to do with anything when pinging with IP numbers.

146

Hi, first thank you for the response, here is the output where the network
did not work:

root@beaglebone:~# dmesg | grep mdio
[ 1.040419] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 1.040439] davinci_mdio 4a101000.mdio: detected phy mask fffffffb
[ 1.047217] libphy: 4a101000.mdio: probed
[ 1.047246] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02,
driver SMSC LAN8710/LAN8720

Humm, that is odd, it corrected for [phy mask fffffffb] with [4a101000.mdio:02]

But it should have been phy[4]... [4a101000.mdio:04]

The math conversion in the phy search patch is:

phy_mask = fffffffb

for (i = 0; i < PHY_MAX_ADDR; i++) {
      if ((phy_mask & (1 << i)) == 0) {
              addr = (u32) i;
              break;
       }
}

This looks like a fun rabbit hole:

Table 14-252. MDIOALIVE Register Field Descriptions

"The alive bits are only meant to be used to give an indication of the
presence or not of a PHY with the corresponding address."

Whereas in the kernel:

/* get phy mask from the alive register */
phy_mask = __raw_readl(&data->regs->alive);
if (phy_mask) {
   /* restrict mdio bus to live phys only */
   dev_info(data->dev, "detected phy mask %x\n", ~phy_mask);
   phy_mask = ~phy_mask;
} else {
    /* desperately scan all phys */
   dev_warn(data->dev, "no live phy, scanning all\n");
   phy_mask = 0;
}
data->bus->phy_mask = phy_mask;

We "assume" phy_mask to be 100% correct. Maybe we should just force
the dt value of phy_id always into phy_mask?

Regards,

147

nm... total 5pm brain fart..

I really need to find a board that 'never' boots with 0xfffffffe..

I'm thinking yanking r117 and shorting RXD3/PHYAD2 -> vdd_3v3b

Regards,

148

"r116" yeap.. time to go home. :wink:

Regards,

149

“r116” yeap… time to go home. :wink:

Same here, and yeah wulf is right. My problem is: I’m already home. Maybe I need a brewski . . .

150

Back when I had this problem people who received a phymask of fffffffe (like when my board worked) booted successfully, those with fffffffb (like when my board failed) - failed.

The reply to my forum post back then said:

151

Hello guys,

So my hardware people found out the problem, I forgot to mention that the problem only happened when the beagleboard was in our custom cape, so they run some tests and the problem was in our board there was some delay when powering the board sometimes and this cause the problem and they were using the 3.3 pin of the beaglebone as well. I hope that this information help someone.

152

I have to say, the motivation to remove caps suddenly makes a lot more sense to me after actually observing the power-on reset sequence on the scope:

power-on reset.png

Horizontal scale: 5ms per grid line, 1ms per minor tick
Vertical range 0-4V, scale: 0.8V per grid line, 0.2V per minor tick
(except the yellow line which measures current, not well-calibrated but roughly:
Vertical range 0-640mA, scale: 128mA per grid line, 32mA per minor tick)

Blue, cyan are regulated supplies (this beagle has a unified 3V3), green is PGOOD (power-on reset release), orange is SYS_RESETn. The power-on sequencing by the PMIC (strobes 1-5) is located entirely in the first two grid blocks, with the modest bumps before 1V8 and after 3V3 are due to the first and last supplies ramped up (neither visible here).

Normally one would expect logic signals to have faster rise times than power supply ramp-ups, but instead the reset signal has such a big RC-time that you can nearly fit the complete power-up sequence in one! True, all parties that care have smith-trigger inputs, but somehow I can’t shake a feeling of discomfort looking at this graph…

I’d still be more inclined to increase the amount of pull-up than risk noise-sensitivity by removing the caps though (and/or at least leave the small cap in place).

I do see a potential issue here however: the PHY documentation says the reset edge of reset should occur no sooner than 25 ms after the power supplies are up. Even with the big RC it’s cutting things awefully close, especially since the PHY specs a minimum rising-edge voltage threshold of 0.81V.

The good part is that the phy doesn’t require reset to be low all this time, it just requires a proper reset some time after the power supplies have come up. The bad part is that thanks to being wired to SYS_RESETn, the only way to reset the phy is by performing a warm reset. SPL could of course just do exactly that if it detects the reset cause was a cold (power-on) reset. The ugly part is that the PHY requires a reset pulse of at least 100 μs, while the AM335x generates one about 10 μs if you configure RSTTIME1 (in PRM_DEVICE) to its max value, so you still need to rely on the RC-network to stretch it long enough (though it can be orders of magnitude smaller than it is now).

Please, next time connect PHY reset to a GPIO instead? (You can free up a pin by discarding the eMMC reset, it’s useless and unused anyway.)

Matthijs

153

Have this problem in 4.1-bone9

net eth0: initializing cpsw version 1.12 (0)
[ 9.014985] net eth0: phy found : id is : 0x7c0f1
[ 9.015081] libphy: PHY 4a101000.mdio:01 not found
[ 9.020112] net eth0: phy 4a101000.mdio:01 not found on slave 1

kernel was generated by up to date build_deb.sh
What should i do to get rid of it?
Cheers

154

What's your actual problem?

mdio:00 = eth0...

mdio:01 = NOT Connected..

Regards,

155

:slight_smile: Ok, understand, this is not a problem, thank you
what about
3.177810] omap_voltage_late_init: Voltage driver support not added

156

and another one:

ls -al /sys/bus/i2c/devices/i2c-0/0-0050/
total 0
drwxr-xr-x 4 root root 0 Jun 29 12:22 .
drwxr-xr-x 8 root root 0 Jun 29 12:13 …
lrwxrwxrwx 1 root root 0 Jun 29 12:13 driver → …/…/…/…/…/…/bus/i2c/drivers/at24
-r–r--r-- 1 root root 4096 Jun 29 12:22 modalias
-r–r--r-- 1 root root 4096 Jun 29 12:22 name
drwxr-xr-x 3 root root 0 Jun 29 12:13 nvmem
lrwxrwxrwx 1 root root 0 Jun 29 12:22 of_node → …/…/…/…/…/…/firmware/devicetree/base/ocp/i2c@44e0b000/baseboard_eeprom@50
drwxr-xr-x 2 root root 0 Jun 29 12:22 power
lrwxrwxrwx 1 root root 0 Jun 29 12:13 subsystem → …/…/…/…/…/…/bus/i2c
-rw-r–r-- 1 root root 4096 Jun 29 12:13 uevent

but

root@beaglebone:~# ./beaglebone-black-g-ether-load.sh
hexdump: /sys/bus/i2c/devices/0-0050/eeprom: No such file or directory
hexdump: /sys/bus/i2c/devices/0-0050/eeprom: No such file or directory
hexdump: /sys/bus/i2c/devices/0-0050/eeprom: No such file or directory
cpsw.0: 78:A5:04:BC:D2:DD
cpsw.1: 78:A5:04:BC:D2:DF

157

fixed...

Regards,

158

Sorry for being pain in the neck, how can I apply this fix?

159

ah, re-download it from where you got it...

Regards,

160

:slight_smile: all I am using is your bb-kernel and dtb-rebuilder