Re: [beagleboard] Beaglebone Black Ethernet Phy Not Detected on Boot.

20,978 views
Skip to first unread message
Message has been deleted
Message has been deleted

bko...@scanimetrics.com

unread,
Mar 19, 2014, 3:47:21 PM3/19/14
to beagl...@googlegroups.com
Does anyone happen to know if the 3.8 kernel compiled as per these instructions here http://eewiki.net/display/linuxonarm/BeagleBone+Black also contains the fix? I have a root file system already that I want to use but would like to update my kernel to fix this problem.

Thanks.

On Tuesday, March 11, 2014 5:50:48 PM UTC-6, Gerald wrote:
I know what I have seen. I know what I have replicated. And I know the SW fix takes care of it.

I also know it does not happen on every board and doe snot happen every time. Do keep in mind that the board reset is not a HW reset. It is a SW reset.

The fix is in the latest image from Robert.  http://beagleboard.org/latest-images/

Gerald


On Tue, Mar 11, 2014 at 6:16 PM, Andrew Glen <andrewt...@gmail.com> wrote:
If anyone has any further information on the software fix/patch for
this issue I would be very interested in hearing about it (and
backporting into the kernel from late last year I am using) - or even
the best way to search for patches to particular files.

Regards,
Andrew.

On 12 March 2014 11:41, Loren Amelang <lorena...@gmail.com> wrote:
> Got it! (Chrome print to PDF, copy from the print...)
>
> -----
> 3.7.1 PHYAD[2:0]: PHY Address Configuration
>
> The PHYAD[2:0] configuration straps are driven high or low to give each PHY
> a unique address. This address is latched into an internal register at the
> end of a hardware reset (default = 000b). In a multitransceiver application
> (such as a repeater), the controller is able to manage each transceiver via
> the unique address. Each transceiver checks each management data frame for a
> matching address in the relevant bits. When a match is recognized, the
> transceiver responds to that particular frame. The PHY address is also used
> to seed the scrambler. In a multi-transceiver application, this ensures that
> the scramblers are out of synchronization and disperses the electromagnetic
> radiation across the frequency spectrum.
>
> The device's SMI address may be configured using hardware configuration to
> any value between 0 and 7. The user can configure the PHY address using
> Software Configuration if an address greater than 7 is required. The PHY
> address can be written (after SMI communication at some address is
> established) using the PHYAD bits of the Special Modes Register. The
> PHYAD[2:0] configuration straps are multiplexed with other signals as shown
> in Table 3.5.
> -----
>
>
> From my A5C Schematic, showing processor names = LAN8710A names = Microchip
> names:
>
> GMII1_RXERR/RMII1_RXERR/SPI1_D1/I2C1_SCL/MCASP1_FSX/UART5_RTSN/UART2_TXD/GPIO3_2
> = RXER/PHYAD0 = RXER/RXD4/PHYAD0
>
> GMII1_RXCLK/UART2_TXD/RGMII1_RCLK/MMC0_DAT6/MMC1_DAT1/UART1_DSRN/MCASP0_FSX/GPIO3_10
> = REFCLKO = RXCLK/PHYAD1
>
> GMII1_RXCLK/UART2_TXD/RGMII1_RCLK/MMC0_DAT6/MMC1_DAT1/UART1_DSRN/MCASP0_FSX/GPIO3_10
> = RXD3/PHYAD2 = RXD3/PHYAD2
>
>
> Obviously a lot of multiplexed uses there! Microchip says, "This address is
> latched into an internal register at the end of a hardware reset (default =
> 000b)." But their reset is "SYS_RESETn", right? The same reset caused by the
> user reset button? How is the processor supposed to control those three
> signals while it is reset?
>
> So how do three bits default to "000b"? I guess they are counting the
> address bits you can only program in software? But if those default to 000b,
> how does my chip end up as phy[0]?
>
> Maybe that's where the mask comes in? Mine works with mask fffffffe:
> [    2.482812] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
> [    2.490309] libphy: 4a101000.mdio: probed
> [    2.494577] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
> driver SMSC LAN8710/LAN8720
> [    2.504409] Detected MACID = 90:59:af:4d:71:eb
> ...
> [    5.854282] libphy: PHY 4a101000.mdio:01 not found
> [    5.859335] net eth0: phy 4a101000.mdio:01 not found on slave 1
>
> While I see reports above in this thread that
> On Tuesday, November 26, 2013 2:22:42 PM UTC-8, AndrewTaneGlen wrote:
> On a good phy boot I see the following:
> [    2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
> [    2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
> ...
> On a 'bad phy' boot I see the following (differences highlighted):
> [    2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
> [    2.813213] davinci_mdio 4a101000.mdio: detected phy mask fffffffb
>
>
> I'm betting the "fe" mask eliminates the default "000b" bits that are not
> set by hardware, allowing the good boot.
>
> Of the hardware set bits, it seems my chip must get address zero, so all
> three signals must be zero when reset ends. With mask "fe", only the
> hardware lines are checked.
>
> But... Where does the mask come from? I'm not finding it in the boot
> environment settings. It looks like it is read from the chip:
> [    2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
> But it is not mentioned that I see in the Microchip doc.
>
> Always another mystery...
>
>
>
>
> On Tuesday, March 11, 2014 12:56:43 PM UTC-7, Gerald wrote:
>>
>> Look in the LAN 8710A data sheet from SMSC. I would cut an paste it, but
>> Microchip has cut and paste blocked.
>>
>> http://www.microchip.com/wwwproducts/Devices.aspx?product=LAN8710A Section
>> 3.7.1
>>
>>
>> Gerald
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Robert Nelson

unread,
Mar 19, 2014, 3:52:36 PM3/19/14
to Beagle Board
On Wed, Mar 19, 2014 at 2:47 PM, <bko...@scanimetrics.com> wrote:
> Does anyone happen to know if the 3.8 kernel compiled as per these
> instructions here http://eewiki.net/display/linuxonarm/BeagleBone+Black also
> contains the fix? I have a root file system already that I want to use but
> would like to update my kernel to fix this problem.

Sorry, "the fix" is too generic of a term, therefore I can neither
confirm nor deny it. Either way, that 3.8 branch listed is the one
currently used in all debian/ubuntu images being shipped.

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

David Lambert

unread,
Mar 19, 2014, 4:31:00 PM3/19/14
to beagl...@googlegroups.com
FWIW I have seen the "PHY problem" repeatedly using the 3.8 kernel, but
not yet with the RCN 3.13 kernel.


Regards,

Dave.

Kees k

unread,
Mar 20, 2014, 5:48:59 AM3/20/14
to beagl...@googlegroups.com
I have seen this problem repeatedly by A6 revision hardware, but not with revision A5C hardware (I am running exactly the same software on both).

Noteworthy is that the "PHY problem" only appears when powering the BBB via the headers. Powering via USB does not give any problems.

I tried the following:
-Use the kernel from the v3.8.13-bone40  image 
-Change some lines in davinci_mdio.c to hardcode the mask to 0 ("desperately scan all phys")

Both tries weren't lucky. It seems to me that the CPU cannot find the PHY chip, because it never powers up.

Robert Nelson

unread,
Mar 20, 2014, 8:44:08 AM3/20/14
to Beagle Board
On Thu, Mar 20, 2014 at 4:48 AM, Kees k <keeskwe...@gmail.com> wrote:
> I have seen this problem repeatedly by A6 revision hardware, but not with
> revision A5C hardware (I am running exactly the same software on both).
>
> Noteworthy is that the "PHY problem" only appears when powering the BBB via
> the headers. Powering via USB does not give any problems.

Well, if it works via USB, but not with the headers. (I didn't check
if the Ethernet can be powered from the headers.)

I'd first double check your power regulation. It's probably dropping
from 5Volts when under load.

c...@isbd.net

unread,
Mar 20, 2014, 9:44:33 AM3/20/14
to beagl...@googlegroups.com
Robert Nelson <robert...@gmail.com> wrote:
> On Thu, Mar 20, 2014 at 4:48 AM, Kees k <keeskwe...@gmail.com>
> wrote:
> > I have seen this problem repeatedly by A6 revision hardware, but not with
> > revision A5C hardware (I am running exactly the same software on both).
> >
> > Noteworthy is that the "PHY problem" only appears when powering the BBB via
> > the headers. Powering via USB does not give any problems.
>
> Well, if it works via USB, but not with the headers. (I didn't check
> if the Ethernet can be powered from the headers.)
>
I'm powering my BBB using P9 pins 1/2 for 0v and 5/6 for +5v, I'm
using the 'real' ethernet connection and it works fine. It has run
with no problems for at least 24 hours, staying connected (ssh) to my
desktop computer.

--
Chris Green
·

Kees k

unread,
Mar 20, 2014, 9:51:24 AM3/20/14
to beagl...@googlegroups.com, c...@isbd.net



The 5V is fine (maybe a little spike of 0.8V after 60 ms PS).

However, the 3.3V gives a strange 2-stage powerup cycle. I compared a revision A5C to a revision A6, see plots below. 

As can be seen the A5C has a 'normal ' powerup cycle on the 3.3V, but the A6 a 2-stage powerup cycle. May this cause any problems with PHY?



Gerald Coley

unread,
Mar 20, 2014, 9:52:43 AM3/20/14
to beagl...@googlegroups.com, c...@isbd.net
Where are you looking exactly?

Gerald



Kees k

unread,
Mar 20, 2014, 9:58:30 AM3/20/14
to beagl...@googlegroups.com, c...@isbd.net
I measure 3.3V on P9.3. 

USB powering shows the 'good' powercycle, 5V via P9.5 shows a 'bad' powercycle. 

Btw, I seen that in revision A6 and A4 there is an NCP349 chip between VDD_5V and pin 10 of the TPS65217b, which I cant see in revision A5.

Gerald Coley

unread,
Mar 20, 2014, 10:17:16 AM3/20/14
to beagl...@googlegroups.com, c...@isbd.net
I did not use the NCP349 on the BBB. What board are you looking at?

Gerald

bko...@scanimetrics.com

unread,
Mar 20, 2014, 10:26:21 AM3/20/14
to beagl...@googlegroups.com
After upgrading to the new kernel I setup a script to constantly soft reboot a revision B beaglebone black and have not seen the ethernet lockup once after some 800 consecutive reboots. With the old kernel I did see the ethernet lockup after soft reboots on the same board.

I did however see the libphy: PHY 4a101000.mdio:01 not found message on rebooting many times.

When you say you see the "PHY problem repeatedly" do you mean you see the error messages on boot or have you actually seen the ethernet fail?

Kees k

unread,
Mar 20, 2014, 11:32:24 AM3/20/14
to beagl...@googlegroups.com
Haha, I was looking at the wrong file (BB white A6). Sorry for the trouble; it seems our cape causes this difference between A5C and A6.

On Tuesday, November 26, 2013 11:22:42 PM UTC+1, AndrewTaneGlen wrote:
Hello,

I have noticed very rare cases (~1/50) of the ethernet phy on the Beaglebone Black not being detected on boot, and requiring a hard reset (as opposed to calling 'reset' from the command line) to get it to work/be detected again.

This problem has been mentioned in a couple of other threads (below) concerning different topics (i.e. problems getting the BBB to boot, and the ethernet phy 'dying' some time after initially working fine), with no solution/workaround for this specific problem being suggested - so I thought I'd start a thread specifically for it.

In the first thread mlc/Mike discussed his response to the problem as follows:

"I had issues with the network not coming up on boot, and it was traced 
down to problems with the SYS_RESETn line. 

I had a level translator connected to SYS_RESETn, to drive a 5V chip. 
It was powered by a 5V rail. If the 5V rail powered up "differently" 
than the 3.3V rail (not sure of the exact relationship), I guess it 
pulled the SYS_RESETn line to weird levels that affected the network 
chip but not the main processor. I'm now using a GPIO to drive the 
external 5V chip now, instead of the SYS_RESETn line. 

Anyway, the moral is be very, very careful with SYS_RESETn, because it 
can cause hard-to-trace problems with networking.
"

I see that the A6 Revision of the Beaglebone Black has some changes to the SYS_RESETn line:

"Based on notification from TI, in random instances there could be a glitch in the SYS_RESETn signal from the processor where the SYS_RESETn signal was taken high for a momentary amount of time before it was supposed to. To prevent this, the signal was ORed with the PORZn (Power On reset).(http://elinux.org/Beagleboard:BeagleBoneBlack#Revision_A6_.28Production_Version.29)

Is it likely that this modification will improve/resolve the issue I am seeing with the ethernt phy not resetting/powering-up correctly?, seeing as the SYS_RESETn signal also feeds into the nRST pin on the ethernet phy (The SYS_RESETn line is left untouched in my application).


Some additional observations from dmesg concerning this use:

On a good phy boot I see the following:
[    2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[    2.833517] libphy: 4a101000.mdio: probed
[    2.837871] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver unknown

Followed later by:
[   21.286920] net eth0: initializing cpsw version 1.12 (0)
[   21.301166] net eth0: phy found : id is : 0x7c0f1

On a 'bad phy' boot I see the following (differences highlighted):
[    2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    2.813213] davinci_mdio 4a101000.mdio: detected phy mask fffffffb
[    2.829512] libphy: 4a101000.mdio: probed
[    2.833875] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver unknown

Followed later by:
[   21.346861] net eth0: initializing cpsw version 1.12 (0)
[   21.354379] libphy: PHY 4a101000.mdio:00 not found
[   21.359469] net eth0: phy 4a101000.mdio:00 not found on slave 0


So it looks like the 'davinci_mdio_reset' function see the phy in both instances, but reports differently on the bad boot. I am not sure what to make of this.

I am using the Debian 7.2 Rootfs and the 'RobertCNelson' kernel '3.12.0-bone8'.



Regards,
Andrew.


Gerald Coley

unread,
Mar 20, 2014, 11:47:12 AM3/20/14
to beagl...@googlegroups.com
A cape. I hate capes. Maybe on the next revision I will just disable all of them!

Thanks!

Gerald



je...@longofest.net

unread,
Mar 26, 2014, 2:40:59 PM3/26/14
to beagl...@googlegroups.com
I know our company appreciates the cape support, so thanks for supporting it :-)

Been watching this thread anxiously for a while.  So glad to see a fix was made, but we are using an Ubuntu 12.04 build for ARM (we really wanted to use Ubuntu to be consistent with our other field deployments).  Rob, can you point us to the source changes that were made for this issue so that we can patch our kernel or whatever needs to be patched so we can get a fix in?

Jeffrey Longo

unread,
Mar 26, 2014, 2:49:50 PM3/26/14
to beagl...@googlegroups.com
Not sure my original post got posted, so at risk of double-posting I'm going to post again (sorry).

Gerald, my company loves the Cape support.  Sorry, but thank you for supporting it!  It has made what we're doing with the BeagleBone Black capable!

Rob, regarding the OS patch - can you point us to where the source to the patch is?  We use Ubuntu 12.04 to be consistent with our other platforms, so we'd like to apply the patch ourselves.  We've seen this issue a concerning amount of times... in fact, the Ethernet will just drop out, and we have software to detect this and issue a reset and that's when the PHY is not detected until we completely drop and re-apply power.

Thanks so much everyone for the work so far!

On Thursday, March 20, 2014 11:47:12 AM UTC-4, Gerald wrote:

Charles Steinkuehler

unread,
Mar 26, 2014, 2:51:34 PM3/26/14
to beagl...@googlegroups.com
No Capes!

http://www.youtube.com/watch?v=Jy2YhxXn7NY

On 3/20/2014 10:47 AM, Gerald Coley wrote:
> A cape. I hate capes. Maybe on the next revision I will just disable all of
> them!
>
> Thanks!
>
> Gerald
>
>
>
> On Thu, Mar 20, 2014 at 10:32 AM, Kees k <keeskwe...@gmail.com> wrote:
>
>> Haha, I was looking at the wrong file (BB white A6). Sorry for the
>> trouble; it seems our cape causes this difference between A5C and A6.
>>
>> On Tuesday, November 26, 2013 11:22:42 PM UTC+1, AndrewTaneGlen wrote:
>>>
>>> Hello,
>>>
>>> I have noticed very rare cases (~1/50) of the ethernet phy on the
>>> Beaglebone Black not being detected on boot, and requiring a hard reset (as
>>> opposed to calling 'reset' from the command line) to get it to work/be
>>> detected again.
>>>
>>> This problem has been mentioned in a couple of other threads (below)
>>> concerning different topics (i.e. problems getting the BBB to boot, and the
>>> ethernet phy 'dying' some time after initially working fine), with no
>>> solution/workaround for this specific problem being suggested - so I
>>> thought I'd start a thread specifically for it.
>>> https://groups.google.com/forum/#!msg/beagleboard/
>>> Vp4pxwHm8BU/Iaw3p5xm0MoJ
>>> https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI
>>>
>>> In the first thread mlc/Mike discussed his response to the problem as
>>> follows:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *"I had issues with the network not coming up on boot, and it was
>>> traced down to problems with the SYS_RESETn line. I had a level translator
>>> connected to SYS_RESETn, to drive a 5V chip. It was powered by a 5V rail.
>>> If the 5V rail powered up "differently" than the 3.3V rail (not sure of the
>>> exact relationship), I guess it pulled the SYS_RESETn line to weird levels
>>> that affected the network chip but not the main processor. I'm now using a
>>> GPIO to drive the external 5V chip now, instead of the SYS_RESETn
>>> line. Anyway, the moral is be very, very careful with SYS_RESETn, because
>>> it can cause hard-to-trace problems with networking.*"
>>>
>>> I see that the A6 Revision of the Beaglebone Black has some changes to
>>> the SYS_RESETn line:
>>>
>>> "*Based on notification from TI, in random instances there could be a
>>> glitch in the SYS_RESETn signal from the processor where the SYS_RESETn
>>> signal was taken high for a momentary amount of time before it was supposed
>>> to. To prevent this, the signal was ORed with the PORZn (Power On reset).*
>>> " (http://elinux.org/Beagleboard:BeagleBoneBlack#
>>> Revision_A6_.28Production_Version.29)
>>>
>>> Is it likely that this modification will improve/resolve the issue I am
>>> seeing with the ethernt phy not resetting/powering-up correctly?, seeing as
>>> the SYS_RESETn signal also feeds into the nRST pin on the ethernet phy (The
>>> SYS_RESETn line is left untouched in my application).
>>>
>>>
>>> Some additional observations from dmesg concerning this use:
>>>
>>> On a good phy boot I see the following:
>>> [ 2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
>>> [ 2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
>>> [ 2.833517] libphy: 4a101000.mdio: probed
>>> [ 2.837871] davinci_mdio 4a101000.mdio: phy[0]: device
>>> 4a101000.mdio:00, driver unknown
>>>
>>> Followed later by:
>>> [ 21.286920] net eth0: initializing cpsw version 1.12 (0)
>>> [ 21.301166] net eth0: phy found : id is : 0x7c0f1
>>>
>>> On a 'bad phy' boot I see the following (differences highlighted):
>>> [ 2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
>>> [ 2.813213] davinci_mdio 4a101000.mdio: detected phy mask *fffffffb*
>>> [ 2.829512] libphy: 4a101000.mdio: probed
>>> [ 2.833875] davinci_mdio 4a101000.mdio: phy[2]: device
>>> 4a101000.mdio:02, driver unknown
>>>
>>> Followed later by:
>>> [ 21.346861] net eth0: initializing cpsw version 1.12 (0)
>>> [ 21.354379] *libphy: PHY 4a101000.mdio:00 not found*
>>> [ 21.359469] *net eth0: phy 4a101000.mdio:00 not found on slave 0*
>>>
>>>
>>> So it looks like the 'davinci_mdio_reset' function see the phy in both
>>> instances, but reports differently on the bad boot. I am not sure what to
>>> make of this.
>>>
>>> I am using the Debian 7.2 Rootfs and the 'RobertCNelson' kernel
>>> '3.12.0-bone8'.
>>>
>>>
>>>
>>> Regards,
>>> Andrew.
>>>
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>


--
Charles Steinkuehler
cha...@steinkuehler.net

David

unread,
Apr 16, 2014, 9:46:43 AM4/16/14
to beagl...@googlegroups.com
Update. I have now witnessed the problem on RCS's 3.13.x kernels :( 

David Lambert

unread,
Apr 16, 2014, 6:15:35 PM4/16/14
to beagl...@googlegroups.com
On 04/16/2014 08:46 AM, David wrote:
Update. I have now witnessed the problem on RCS's 3.13.x kernels :(
Update #2 FWIW when this occurs I cannot use the Ethernet interface even from uboot. It needs a hard reset to get out of this condition.

Dave.

pori...@gmail.com

unread,
May 30, 2014, 7:40:50 AM5/30/14
to beagl...@googlegroups.com
 I'm using 3.14.4 kernel (latest stable) - and 'the fix' doesn't seem to have been pushed there - could you give more information about what 'the fix' is?

Eric

unread,
Jun 4, 2014, 5:20:26 PM6/4/14
to beagl...@googlegroups.com, pori...@gmail.com
Just found this thread, adding my 2cents. 

We are using kernel 3.8.13-bone30. We have seen many cases of ethernet issues, usually that the ethernet port does not come up at all (no lights). I would say it happens one out of every 20 boots. We are using a cape, but just to extend i/o and provide power.

If anyone has any suggestions or kernel versions that work better, help would be greatly appreciated. I am currently working on a workaround to make the beaglebone detect the lack of ethernet and reboot itself, but this could lead to some really long boot times, and not having the problem at all would be much better!

Robert Nelson

unread,
Jun 5, 2014, 9:49:59 AM6/5/14
to Beagle Board
On Wed, Jun 4, 2014 at 4:20 PM, Eric <ericpo...@gmail.com> wrote:
> Just found this thread, adding my 2cents.
>
> We are using kernel 3.8.13-bone30. We have seen many cases of ethernet
> issues, usually that the ethernet port does not come up at all (no lights).
> I would say it happens one out of every 20 boots. We are using a cape, but
> just to extend i/o and provide power.
>
> If anyone has any suggestions or kernel versions that work better, help
> would be greatly appreciated. I am currently working on a workaround to make
> the beaglebone detect the lack of ethernet and reboot itself, but this could
> lead to some really long boot times, and not having the problem at all would
> be much better!

Well you should keep your 2cents if your running bone30, upgrade! ;)
There's been a lot of fixes to the v3.8.x branch since Nov 2013.

pchumc...@gmail.com

unread,
Jun 13, 2014, 6:56:51 AM6/13/14
to beagl...@googlegroups.com
Hi, I'm a newbie in a Beaglebone world, I have Beaglebone black rev. B, no capes, usb power. Yesterday I downloaded and flashed debian instead of angstrom  Debian (BeagleBone Black - 2GB eMMC) 2014-05-14  and today after power off and power on by power button on board I had this issue too... hardware reset helped, but it is not a solution...

[    1.042332] davinci_mdio 4a101000.mdio: detected phy mask fffffffb

[   25.164264] net eth0: initializing cpsw version 1.12 (0)
[   25.166761] libphy: PHY 4a101000.mdio:00 not found
[   25.172002] net eth0: phy 4a101000.mdio:00 not found on slave 0
[   25.178425] libphy: PHY 4a101000.mdio:01 not found
[   25.183605] net eth0: phy 4a101000.mdio:01 not found on slave 1
[   25.201488] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

So how can I fix it? 

Regards,
Petra

Vishnu Patekar

unread,
Jul 5, 2014, 2:01:36 PM7/5/14
to beagl...@googlegroups.com
Hello,
I'm using BBB board A5C, and kernel version 3.15.3-bone3.1.  I also see ethernet PHY is not detected. Log as below:
Please refer detailed attached log.


[    3.740457] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    3.746859] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[    3.754398] libphy: 4a101000.mdio: probed
[    3.758612] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver unknown
[    3.767567] Detected MACID = 90:59:af:5c:61:78
[    3.773165] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    3.779741] sr_init: No PMIC hook to init smartreflex
[    3.785201] sr_init: platform driver register failed for SR
[    3.794297] VFS: Cannot open root device "nfs" or unknown-block(0,255): error -6
[    3.802114] Please append a correct "root=" boot option; here are the available partitions:
[    3.810888] b300         1875968 mmcblk0  driver: mmcblk
[    3.816464]   b301           72261 mmcblk0p1 00000000-01
[    3.822046]   b302         1799280 mmcblk0p2 00000000-02
[    3.827617] b310            1024 mmcblk0boot1  (driver?)
[    3.833197] b308            1024 mmcblk0boot0  (driver?)
[    3.838767] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255)
[    3.847616] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.3-bone3.1 #1
[    3.854410] [<c00113f5>] (unwind_backtrace) from [<c000fa37>] (show_stack+0xb/0xc)
[    3.862356] [<c000fa37>] (show_stack) from [<c054dd05>] (panic+0x65/0x170)
[    3.869572] [<c054dd05>] (panic) from [<c08a6d0b>] (mount_block_root+0x1af/0x21c)
[    3.877421] [<c08a6d0b>] (mount_block_root) from [<c08a6eb1>] (prepare_namespace+0xe9/0x128)
[    3.886271] [<c08a6eb1>] (prepare_namespace) from [<c08a6a93>] (kernel_init_freeable+0x1ab/0x1b8)
[    3.895574] [<c08a6a93>] (kernel_init_freeable) from [<c054d37b>] (kernel_init+0xb/0xb4)
[    3.904060] [<c054d37b>] (kernel_init) from [<c000d1f9>] (ret_from_fork+0x11/0x38)
[    3.911998] drm_kms_helper: panic occurred, switching back to text console
[    3.919217] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255)



On Sat, Jun 28, 2014 at 2:22 AM, Jay @ Control Module Industries <cmid...@gmail.com> wrote:
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.

diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 0cca9de..e5a9cdc 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -39,6 +39,7 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/pinctrl/consumer.h>
+#include <linux/phy.h>
 
 /*
  * This timeout definition is a worst-case ultra defensive measure against
@@ -97,6 +98,10 @@ struct davinci_mdio_data {
     unsigned long    access_time; /* jiffies */
 };
 
+#if IS_ENABLED(CONFIG_OF)
+static void davinci_mdio_update_dt_from_phymask(u32 phy_mask);
+#endif
+
 static void __davinci_mdio_reset(struct davinci_mdio_data *data)
 {
     u32 mdio_in, div, mdio_out_khz, access_time;
@@ -150,6 +155,11 @@ static int davinci_mdio_reset(struct mii_bus *bus)
         /* restrict mdio bus to live phys only */
         dev_info(data->dev, "detected phy mask %x\n", ~phy_mask);
         phy_mask = ~phy_mask;
+
+        #if IS_ENABLED(CONFIG_OF)
+        davinci_mdio_update_dt_from_phymask(phy_mask);
+        #endif
+
     } else {
         /* desperately scan all phys */
         dev_warn(data->dev, "no live phy, scanning all\n");
@@ -312,6 +322,79 @@ static int davinci_mdio_probe_dt(struct mdio_platform_data *data,
 }
 #endif
 
+#if IS_ENABLED(CONFIG_OF)
+static void davinci_mdio_update_dt_from_phymask(u32 phy_mask)
+{
+    int i, len;
+    u32 addr;
+    __be32 *old_phy_p, *phy_id_p;
+    struct property *phy_id_property = NULL;
+    struct device_node *node_p, *slave_p;
+   
+    addr = 0;
+
+    for (i = 0; i < PHY_MAX_ADDR; i++) {
+            if ((phy_mask & (1 << i)) == 0) {
+                    addr = (u32) i;
+            break;
+            }
+     }
+
+    for_each_compatible_node(node_p, NULL, "ti,cpsw") {
+        for_each_node_by_name(slave_p, "slave") {
+               
+            old_phy_p = (__be32 *) of_get_property(slave_p, "phy_id", &len);
+           
+            if (len != (sizeof(__be32 *) * 2))
+                goto err_out;
+           
+            if (old_phy_p) {
+
+                phy_id_property = kzalloc(sizeof(*phy_id_property), GFP_KERNEL);
+               
+                if (! phy_id_property)
+                    goto err_out;
+
+                phy_id_property->length = len;
+                phy_id_property->name = kstrdup("phy_id", GFP_KERNEL);
+                phy_id_property->value = kzalloc(len, GFP_KERNEL);
+               
+                if (! phy_id_property->name)
+                    goto err_out;
+               
+                if (! phy_id_property->value)
+                    goto err_out;
+           
+                memcpy(phy_id_property->value, old_phy_p, len);
+               
+                phy_id_p = (__be32 *) phy_id_property->value + 1;
+               
+                *phy_id_p = cpu_to_be32(addr);
+
+                of_update_property(slave_p, phy_id_property);
+               
+                ++addr;
+            }
+        }
+    }
+   
+    return;
+
+err_out:
+   
+    if (phy_id_property) {
+        if (phy_id_property->name)
+            kfree(phy_id_property->name);
+   
+        if (phy_id_property->value)
+            kfree(phy_id_property->value);
+
+        if (phy_id_property)
+            kfree(phy_id_property);
+    }
+}
+#endif
+
 static int davinci_mdio_probe(struct platform_device *pdev)
 {
     struct mdio_platform_data *pdata = dev_get_platdata(&pdev->dev);

EthernetPhyNotDetected.txt

John Syn

unread,
Jul 5, 2014, 2:19:37 PM7/5/14
to beagl...@googlegroups.com
This is a known problem with V3.15 and NFS. We are working on finding a solution. First, you must build the SMSC driver into the kernel. Currently it is built as a kernel module which won’t work because you have to mount the rootfs to load the kernel module. That will eliminate the first issue:

3.758612] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver unknown

Next we are trying to find out why the network isnt getting started. Looks like something to do with cpsw.  Using the same MLO, u-boot, uEnv.txt and rootfs, V3.8.13-bone57 works just fine. Changing the kernel to V3.15.3-bone3, I get the same problem you have. 

Regards,

John

Micka

unread,
Jul 7, 2014, 3:52:57 AM7/7/14
to beagl...@googlegroups.com
Hello,

I'm on the Kernel 3.8.13-bone56 and I've still this problem :

Scanning for Btrfs filesystems
systemd-fsck[202]: rootfs: clean, 110431/966656 files, 771069/3864576 blocks
[    7.665617] libphy: PHY 4a101000.mdio:00 not found
[    7.670642] net eth0: phy 4a101000.mdio:00 not found on slave 0
[    7.676834] libphy: PHY 4a101000.mdio:01 not found
[    7.681844] net eth0: phy 4a101000.mdio:01 not found on slave 1


I've to reboot many times to get lucky .....


Micka

unread,
Jul 7, 2014, 3:56:42 AM7/7/14
to beagl...@googlegroups.com, Robert Nelson, Gerald Coley
I would like to know what this means ? Is it a electrical problems ? Can we monitor this ?

William Hermans

unread,
Jul 7, 2014, 4:41:47 AM7/7/14
to beagl...@googlegroups.com
Hello,

I'm on the Kernel 3.8.13-bone56 and I've still this problem :

Scanning for Btrfs filesystems
systemd-fsck[202]: rootfs: clean, 110431/966656 files, 771069/3864576 blocks
[    7.665617] libphy: PHY 4a101000.mdio:00 not found
[    7.670642] net eth0: phy 4a101000.mdio:00 not found on slave 0
[    7.676834] libphy: PHY 4a101000.mdio:01 not found
[    7.681844] net eth0: phy 4a101000.mdio:01 not found on slave 1


I've to reboot many times to get lucky .....
Hello Micka,

This almost sounds like a power issue. How are you powering your board, and what other peripherals are you using ?

Micka

unread,
Jul 7, 2014, 4:49:20 AM7/7/14
to beagl...@googlegroups.com

Well, we made our own rs485 cap, and it also power the cap ( we took example of the lcd7). But I don't why it will make problem....

Micka

unread,
Jul 7, 2014, 4:50:06 AM7/7/14
to beagl...@googlegroups.com

Well, we made our own rs485 cap, and it also power the lcd7 and the beagle ( we took example of the lcd7). But I don't why it will make problem...

David Lambert

unread,
Jul 7, 2014, 8:30:12 AM7/7/14
to beagl...@googlegroups.com
FWIW I have seen this issue on occasions with many BBBs. Quite infrequent, but seemingly random. The only way out appears to be doing a hard reset (or power cycle).

Regards,

Dave.

Robert Nelson

unread,
Jul 7, 2014, 11:17:12 AM7/7/14
to Beagle Board
On Mon, Jul 7, 2014 at 2:52 AM, Micka <micka...@gmail.com> wrote:
> Hello,
>
> I'm on the Kernel 3.8.13-bone56 and I've still this problem :
>
> Scanning for Btrfs filesystems
> systemd-fsck[202]: rootfs: clean, 110431/966656 files, 771069/3864576 blocks
> [ 7.665617] libphy: PHY 4a101000.mdio:00 not found
> [ 7.670642] net eth0: phy 4a101000.mdio:00 not found on slave 0
> [ 7.676834] libphy: PHY 4a101000.mdio:01 not found
> [ 7.681844] net eth0: phy 4a101000.mdio:01 not found on slave 1
>
>
> I've to reboot many times to get lucky .....

Hey Micka,

how about the newly pushed out bone60?

Vishnu Patekar

unread,
Jul 7, 2014, 12:26:38 PM7/7/14
to beagl...@googlegroups.com
Hello John,
Thanks for info.

I found below configs are not set in 3.15 by default which were set in 3.8. If we set below configs in 3.15, it works including NFS.

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_ROOT_NFS=y

optional:
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y

John Syn

unread,
Jul 7, 2014, 5:49:55 PM7/7/14
to beagl...@googlegroups.com
Date: Monday, July 7, 2014 at 9:26 AM

To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on Boot.

Hello John,
Thanks for info.

I found below configs are not set in 3.15 by default which were set in 3.8. If we set below configs in 3.15, it works including NFS.

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_ROOT_NFS=y

optional:
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
Hi Vishnu,

I found something similar to you. I enabled 

CONFIG_IP_PNP
CONFIG_ROOT_NFS

Which gets me further and I see the login prompt, but now I get the following error:

INIT: /run/initctl is not a fifo

I did try the other config selections that you did and it didn’t make a difference for me. I’m using Robert Nelson’s Debian-v7.5-console-armhf rootfs. 

Regards,
John

John Syn

unread,
Jul 7, 2014, 10:47:48 PM7/7/14
to beagl...@googlegroups.com
Date: Monday, July 7, 2014 at 9:26 AM

To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on Boot.

Hello John,
Thanks for info.

I found below configs are not set in 3.15 by default which were set in 3.8. If we set below configs in 3.15, it works including NFS.

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_ROOT_NFS=y

optional:
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
Hi Vishnu,

I updated to V3.15.4-bone4 and now I can login successfully. I still have some issues with systemd shutting down, but that is another issue. 

Regards,
John