Beaglebone Black Ethernet Phy Not Detected on Boot.

Artur_Festyn · June 29, 2015, 1:08pm

both bb-kernel and dtb-rebuilder say
Already up-to-date.

after git pull

sorry, I am beginner

Artur_Festyn · June 29, 2015, 1:16pm

and just to give you something in exchange,
there is nothing about eeprom on i2c-0
src/arm/am335x-bone-common-no-capemgr.dtsi

in 4.1

RobertCNelson · June 29, 2015, 1:43pm

"you" downloaded "beaglebone-black-g-ether-load.sh" from:

https://raw.githubusercontent.com/RobertCNelson/tools/master/scripts/beaglebone-black-g-ether-load.sh

Regards,

RobertCNelson · June 29, 2015, 1:45pm

Well...

am335x-bone-common-no-capemgr.dtsi

"no-capemgr"..

It's like i set it up that way...

Regards,

Artur_Festyn · June 29, 2015, 1:48pm

O yes, thank you, so there will be no reading BBB serial number from EEPROM in this version of kernel?

RobertCNelson · June 29, 2015, 1:53pm

No, i just didn't care enough to back port those changes from:

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L82

It loads g_ether, the rest doesn't matter..

Regards,

Artur_Festyn · June 29, 2015, 1:55pm

Thank you, so I just need to wait.

Artur_Festyn · June 29, 2015, 2:02pm

Ok, so we just read serial number from different place, thanks

kevinlang.ca · February 19, 2016, 7:57pm

I am runnung Debian 8.2
Linux beaglebone 4.1.12-ti-r29

I modified /etc/network/interfaces to make eth0 to be static, but every time after reboot, the IP still changed, why?

Thanks,
Kevin

ralf.lieb.cymru · April 1, 2016, 11:04am

Hi all,

The problem seems to be influenced by the outside power supply.

I run Debian Jessie with kernel 4.1.15-ti-rt-r43 on an 1month old element14 BBB (where do I find the revision??) and have the same issues.
The BBB is getting its power from a custom carrier board which has a DC-DC on. Doing a cold start by plugging the battery in, the Ethernet is hit and miss (more miss than hit).
Pressing the reset button got it working every time so far.

The DC-DC isn’t running perfect yet, as it only got the theoretical values in and is not optimized yet.

Regards

Ralf

tpkuester · June 14, 2016, 5:06pm

Just a “me too” reply, echoing Ralf’s comment.

On my board, the Beaglebone is a “guest”. The host board runs off +24 V, and provides two SMPS (5V and 3V3) to subsystems. The host 5V is hooked up to the BBB barrel jack pins on P9. The BBB’s 3V3 supply is left unconnected, and the host board supplies 3V3 to various systems.

Without sequencing the host 3V3 to SYS_RESETn, I was getting approximately 80% failure rate for the PHY, even with bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img. (This was manually recorded with ~20 attempts.)

When I keyed the 3V3 SMPS off SYS_RESETn, the PHY behaved much better, 10/10 times.

Hoping this can help someone else!

Tim

WulfMan · June 14, 2016, 6:11pm

Anything connected to a BBB must not be powered up until the BBB is
powered up so what you have done is correct

Kevin_Fructuoso · October 11, 2016, 7:18pm

Hi Robert,

I am running some power cycle testing on a rev C board with a debian image dated to April 23rd, 2014. I am also seeing this error occur across multiple boards. Do you know if this image should have resolved the issue?

It is not preferred for us to update to a newer image if we can work around it. Is there a way we can modify the u-boot and u-boot SPL files to detect and address this issue?

Is there a way to tell if this error has occurred without checking the uboot log? Maybe like a missing device or improper value of a file?

RobertCNelson · October 11, 2016, 7:23pm

Hi Kevin,

Hi Robert,

I am running some power cycle testing on a rev C board with a debian image
dated to April 23rd, 2014. I am also seeing this error occur across multiple
boards. Do you know if this image should have resolved the issue?

It is not preferred for us to update to a newer image if we can work around
it. Is there a way we can modify the u-boot and u-boot SPL files to detect
and address this issue?

Is there a way to tell if this error has occurred without checking the uboot
log? Maybe like a missing device or improper value of a file?

What kernel version?

uname -r

The issue, the phy's reset line is connected to the am335x's reset
line, so there's no way to manually reset the phy when it get's in
this odd state..

So the workaround that we use in later kernel versions, we just the
mdio/phy address we find, vs the one that's wired up..

Later am335x/am43xx/am57xx development board's have a dedicated gpio
pin to reset the phy..

Regards,

Kevin_Fructuoso · October 11, 2016, 7:24pm

Hi Robert,

I am running some power cycle testing on a rev C board with a debian image dated to April 23rd, 2014. I am also seeing this error occur across multiple boards. When this error occurs, the boards cannot acquire an IP address. Do you know if this image should have resolved the issue?

Phy 0 not found

[ 8.254476] libphy: PHY 4a101000.mdio:00 not found
[ 8.259608] net eth0: phy 4a101000.mdio:00 not found on slave 0

It is not preferred for us to update to a newer image if we can work around it. Is there a way we can modify the u-boot and u-boot SPL files to detect and address this issue?

Is there a way to tell if this error has occurred without checking the uboot log? Maybe like a missing device or improper value of a file?

RobertCNelson · October 11, 2016, 7:42pm

Hi Robert,

Thank you for the quick reply! We are using kernel 3.8.13-bone47 on rev C
Beaglebones.

So this was first fixed in bone60, here's the kernel patch you'll need
to apply and rebuild 3.8.13-bone47

github.com

RobertCNelson/bb-kernel/blob/607ae2e36477357a4bb222f285fd7460d5230ab9/patches/net/0009-cpsw-search-for-phy.patch

From a2c765add061a108aafecc0f1b2451db21001a46 Mon Sep 17 00:00:00 2001
From: Jay at Control Module Industries <cmidroid@gmail.com>
Date: Tue, 1 Jul 2014 14:49:52 -0500
Subject: [PATCH 9/9] cpsw: search for phy

I have encountered the same issue(s) on A6A boards.

I couldn't find a patch,  so I wrote this patch to update the device tree
in the davinci_mdio driver in the 3.15.1 tree, it seems to correct it. I
would welcome any input on a different approach.

https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
---
 drivers/net/ethernet/ti/davinci_mdio.c | 82 ++++++++++++++++++++++++++++++++++
 1 file changed, 82 insertions(+)

diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index cca2550..f005014 100644

This file has been truncated. show original

You mention later boards have a dedicated GPIO pin for this. Is
that not the case for the rev C?

If we ever get a rev D, i wish this fix would be included.

So, only later "newly" designed boards have it..

I was hoping to maybe check dmesg | grep "..." for this specific error and
then start a reboot of the beaglebone if I detect it.

"So the workaround that we use in later kernel versions, we just the
mdio/phy address we find, vs the one that's wired up.."

I'm sorry but I'm not quite an expert on this topic. What do you mean
exactly?

Thanks in advance for your reply!

Regards,

Andrew_Glen · October 11, 2016, 8:02pm

Hi Robert,

Thanks for that update.

We’re still modifying hardware on about 10 boards/month to get around the phy reset issue, so a kernel patch for the same result is very well received.

Regards,
Andrew Glen.

RobertCNelson · October 12, 2016, 4:01pm

git clone https://github.com/RobertCNelson/yakbuild
cd yakbuild
cp recipe.sh.sample recipe.sh

Open recipe.sh

Change:
toolchain="gcc_linaro_gnueabihf_5"

to:
#toolchain="gcc_linaro_gnueabihf_5"

Enable:
toolchain="gcc_linaro_gnueabihf_4_7"

Change:
kernel_tag="4.4.19-ti-r41"

to:
kernel_tag="3.8.13-bone47"

run:

./build_kernel.sh

After the ".config - Linux/arm 3.8.13 Kernel Configuration" pop's up,
just hit ecape twice, select <yes>, hit enter, then hit CTRL-C to stop
build:

wget https://raw.githubusercontent.com/RobertCNelson/bb-kernel/607ae2e36477357a4bb222f285fd7460d5230ab9/patches/net/0009-cpsw-search-for-phy.patch

patch -p1 < 0009-cpsw-search-for-phy.patch

cd ../
./tools/rebuild.sh (this time build to completion)

Regards,

Sylvain_Lamontagne · October 26, 2016, 4:24pm

Hi,

I have read this thread as I’m currently having this problem happening to me on a BeagleBone Green.
According to this thread, recent kernel versions should not have a problem as there is code that should be able to workaround the hardware problem.
I am currently running:

U-Boot 2016.09-00002-g03e9979
Kernel 4.4.26-ti-r59
The image is a derivative of Debian Image 2016-09-04

When not working:

Oct 25 00:13:13 beaglebone kernel: [ 3.008530] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
Oct 25 00:13:13 beaglebone kernel: [ 3.014688] davinci_mdio 4a101000.mdio: detected phy mask fffffffb
Oct 25 00:13:13 beaglebone kernel: [ 3.021255] davinci_mdio: dt: updated phy_id[2] from phy_mask[fffffffb]
Oct 25 00:13:13 beaglebone kernel: [ 3.034629] libphy: 4a101000.mdio: probed
Oct 25 00:13:13 beaglebone kernel: [ 3.038771] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver SMSC LAN8710/LAN8720
Oct 25 00:13:13 beaglebone kernel: [ 3.048926] cpsw 4a100000.ethernet: Detected MACID = 68:9e:19:98:ab:30
Oct 25 00:13:13 beaglebone kernel: [ 3.055733] cpsw 4a100000.ethernet: cpts: overflow check period 2125

When working as expected:

Oct 25 00:13:13 beaglebone kernel: [ 3.008520] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
Oct 25 00:13:13 beaglebone kernel: [ 3.014681] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
Oct 25 00:13:13 beaglebone kernel: [ 3.021252] davinci_mdio: dt: updated phy_id[0] from phy_mask[fffffffe]
Oct 25 00:13:13 beaglebone kernel: [ 3.034618] libphy: 4a101000.mdio: probed
Oct 25 00:13:13 beaglebone kernel: [ 3.038762] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
Oct 25 00:13:13 beaglebone kernel: [ 3.048919] cpsw 4a100000.ethernet: Detected MACID = 68:9e:19:98:ab:30
Oct 25 00:13:13 beaglebone kernel: [ 3.055724] cpsw 4a100000.ethernet: cpts: overflow check period 2125

When it’s not working, there is no light on the ethernet port at all and we can see the following later in kern.log that would suggest it to be working:

Oct 25 00:13:16 beaglebone kernel: [ 35.124353] net eth0: initializing cpsw version 1.12 (0)
Oct 25 00:13:16 beaglebone kernel: [ 35.129740] net eth0: initialized cpsw ale version 1.4
Oct 25 00:13:16 beaglebone kernel: [ 35.134940] net eth0: ALE Table size 1024
Oct 25 00:13:16 beaglebone kernel: [ 35.309306] net eth0: phy found : id is : 0x7c0f1

Here is connmand logs when working:

Oct 24 18:46:06 beaglebone connmand[1382]: Connection Manager version 1.32
Oct 24 18:46:08 beaglebone connmand[1382]: Checking loopback interface settings
Oct 24 18:46:08 beaglebone connmand[1382]: System hostname is beaglebone
Oct 24 18:46:08 beaglebone connmand[1382]: Failed to open RFKILL control device
Oct 24 18:46:08 beaglebone connmand[1382]: lo {newlink} index 1 address 00:00:00:00:00:00 mtu 65536
Oct 24 18:46:08 beaglebone connmand[1382]: lo {newlink} index 1 operstate 0
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {create} index 2 type 1
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {update} flags 4098
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {newlink} index 2 address 68:9E:19:98:AB:30 mtu 1500
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {newlink} index 2 operstate 2
Oct 24 18:46:08 beaglebone connmand[1382]: Adding interface eth0 [ ethernet ]
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {update} flags 36931 <UP,RUNNING>
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {newlink} index 2 address 68:9E:19:98:AB:30 mtu 1500
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {newlink} index 2 operstate 0
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {update} flags 36867
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {newlink} index 2 address 68:9E:19:98:AB:30 mtu 1500
Oct 24 18:46:08 beaglebone connmand[1382]: eth0 {newlink} index 2 operstate 2
Oct 24 18:46:08 beaglebone connmand[1382]: The name net.connman.vpn was not provided by any .service files
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {add} route fe80:: gw :: scope 0
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {newlink} index 2 address 68:9E:19:98:AB:30 mtu 1500
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {newlink} index 2 operstate 6
Oct 24 18:46:11 beaglebone connmand[1382]: Skipping disconnect of carrier, network is connecting.
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {add} address 172.16.1.144/24 label eth0 family 2
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {add} route 172.16.1.0 gw 0.0.0.0 scope 253
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {add} route 172.16.1.1 gw 0.0.0.0 scope 253
Oct 24 18:46:11 beaglebone connmand[1382]: eth0 {add} route 0.0.0.0 gw 172.16.1.1 scope 0
Oct 24 18:46:12 beaglebone connmand[1382]: eth0 {add} route 82.165.8.211 gw 172.16.1.1 scope 0
Oct 24 18:46:12 beaglebone connmand[1382]: can0 {newlink} index 3 address 00:00:00:00:00:00 mtu 16
Oct 24 18:46:12 beaglebone connmand[1382]: can0 {newlink} index 3 operstate 2
Oct 24 18:46:12 beaglebone connmand[1382]: eth0 {del} route 82.165.8.211 gw 172.16.1.1 scope 0
Oct 24 18:46:12 beaglebone connmand[1382]: can0 {newlink} index 3 address 00:00:00:00:00:00 mtu 16
Oct 24 18:46:12 beaglebone connmand[1382]: can0 {newlink} index 3 operstate 0
Oct 24 18:46:12 beaglebone connmand[1382]: can0 {newlink} index 3 address 00:00:00:00:00:00 mtu 16
Oct 24 18:46:12 beaglebone connmand[1382]: can0 {newlink} index 3 operstate 0

Here is connmand log when not working:

Oct 25 00:13:15 beaglebone connmand[1388]: Connection Manager version 1.32
Oct 25 00:13:16 beaglebone connmand[1388]: Checking loopback interface settings
Oct 25 00:13:16 beaglebone connmand[1388]: System hostname is beaglebone
Oct 25 00:13:16 beaglebone connmand[1388]: Failed to open RFKILL control device
Oct 25 00:13:16 beaglebone connmand[1388]: lo {newlink} index 1 address 00:00:00:00:00:00 mtu 65536
Oct 25 00:13:16 beaglebone connmand[1388]: lo {newlink} index 1 operstate 0
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {create} index 2 type 1
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {update} flags 4098
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {newlink} index 2 address 68:9E:19:98:AB:30 mtu 1500
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {newlink} index 2 operstate 2
Oct 25 00:13:16 beaglebone connmand[1388]: Adding interface eth0 [ ethernet ]
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {update} flags 36931 <UP,RUNNING>
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {newlink} index 2 address 68:9E:19:98:AB:30 mtu 1500
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {newlink} index 2 operstate 0
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {update} flags 36867
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {newlink} index 2 address 68:9E:19:98:AB:30 mtu 1500
Oct 25 00:13:16 beaglebone connmand[1388]: eth0 {newlink} index 2 operstate 2
Oct 25 00:13:16 beaglebone connmand[1388]: The name net.connman.vpn was not provided by any .service files
Oct 25 00:13:20 beaglebone connmand[1388]: can0 {newlink} index 3 address 00:00:00:00:00:00 mtu 16
Oct 25 00:13:20 beaglebone connmand[1388]: can0 {newlink} index 3 operstate 2
Oct 25 00:13:21 beaglebone connmand[1388]: can0 {newlink} index 3 address 00:00:00:00:00:00 mtu 16
Oct 25 00:13:21 beaglebone connmand[1388]: can0 {newlink} index 3 operstate 0
Oct 25 00:13:21 beaglebone connmand[1388]: can0 {newlink} index 3 address 00:00:00:00:00:00 mtu 16
Oct 25 00:13:21 beaglebone connmand[1388]: can0 {newlink} index 3 operstate 0

Still no lights on the eth port.

So my question, is there a patch that is not applied in the kernel that you built and that is install when using /opt/scripts/tools/update_kernel.sh that should be applied ? Or am I missing something for the workaround to actually work ?

What am I missing ?

Any help would be appreciated

Sylvain Lamontagne

bigjosh · April 8, 2017, 5:10am

Any updates on this?

I also have tried about a dozen brand new BeagleBone Greens with the latest Debian 8.7 2017-03-19 images and am still seeing the same problem - the Ethernet port occasionally does no come up on boot and requires a power cycle to fix it. The “davinci_mdio 4a101000.mdio: detected phy mask fffffffb” line always appears when the PHY doesn’t come up.

Is there any recommended work around for 100% Ethernet availability on power up? I am using these in an application they are very hard to access, so I am getting desperate and willing to do almost anything to find a solution. Happy to buy all new boards if there is a rev available somewhere that resolves this. Also will to do rework on existing boards if there is a confirmed fix,

Thanks!

-josh