Beaglebone Black Ethernet Phy Not Detected on Boot.

[AndrewTaneGlen]

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.

[Gerald Coley]

I am just now looking at this issue. The A6 revision was not put in place to fix this issue.

Gerald

--
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/groups/opt_out.

[dave...@gmail.com]

We are experiencing the same issue, using the A5 version. Roughly 1% to 3% of the times on boot up, the unit fails to find the PHY. On next boot up  works fine.On very very rare occasions, it will fail to find the PHY 2x in a row, but haven't seen that in a few days now since started driving SYS_Resetn as below. Before started driving the Sys_Resetn line, wold see it miss in the 10+% range.

The startup SYS_Resetn glitch from the CPU has been observed on multiple units. To counter that we drove the SYS_Resetn line low { open collector } for 400 msec with occasional improvements, but the problem has never really gone away. Using the external open collector reset, we have also added an adiditonal 4K7 pullup to 3V3. We are also trying driving the line with an active 3V3 device rather than depending on the pullup.. 

Don't think see any issues with the way 3V3 is coming up.

Dave

[Gerald Coley]

Try removing C24. See if that helps.

Gerald

[AndrewTaneGlen]

Hi All,

After removing C24 and C30 (next to the large unpopulated 20-pin header P2 on the bottom of the board) we ran 1000 power cycles and had a 100%
success rate - i.e. board booted and phy detected every time.

We used a programmable power supply and some scripts processing the uart output to count observed
instances of "libphy: PHY 4a101000.mdio:00 not found" and "net eth0:
phy found : id is : 0x7c0f1", and momentarily interrupted the power supply after seeing either.

We ran the same test on an unmodified board and had a failure rate of 54/1000


Regards,
Andrew Glen.

[Loren Amelang]

Guess this issue is solved, but this seems like the best place for my comment. 

I always see "davinci_mdio 4a101000.mdio: detected phy mask fffffffe", never "fffffffb", so that may be the critical part of your error. 

But I also always see 

-----

libphy: PHY 4a101000.mdio:01 not found

net eth0: phy 4a101000.mdio:01 not found on slave 1

-----

at the end of every boot, even when the ethernet is working. 

I just realized my system says "phy[0]" and "mdio:00" first, like yours (this is Ubuntu 12.04):

-----

davinci_mdio 4a101000.mdio: davinci mdio revision 1.6

davinci_mdio 4a101000.mdio: detected phy mask fffffffe

libphy: 4a101000.mdio: probed

davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720

Detected MACID = 90:59:af:4d:71:eb

cpsw 4a100000.ethernet: NAPI disabled

-----

While my later error message is "mdio:01 not found on slave 1". Instead of your "phy[2]" and "mdio:00, slave 0".

This came up for me now because my Wi-Fi adapter just closed itself down for no obvious reason. I was handling the board, and might have interfered with the RF signal, but I wouldn't think that would make the whole adapter disappear from ifconfig. Anyway, at the end of my reboot, I saw:

-----

[    5.444191] libphy: PHY 4a101000.mdio:01 not found

[    5.449248] net eth0: phy 4a101000.mdio:01 not found on slave 1

 * Starting Network connection manager wicd        [ OK ]

 * Starting NTP server ntpd        [ OK ]

Ubuntu 12.04.3 LTS ubuntu-armhf ttyO0

ubuntu-armhf login: [  140.524031] libphy: PHY 4a101000.mdio:01 not found  <-- dmesg dumped into terminal session

[  140.529132] net eth0: phy 4a101000.mdio:01 not found on slave 1  <-- dmesg dumped into terminal session

Ubuntu 12.04.3 LTS ubuntu-armhf ttyO0

-----

And later:

-----

ubuntu@ubuntu-armhf:~$ [  714.027888] libphy: PHY 4a101000.mdio:01 not found

[  714.033046] net eth0: phy 4a101000.mdio:01 not found on slave 1

[  719.001993] libphy: PHY 4a101000.mdio:01 not found

[  719.007119] net eth0: phy 4a101000.mdio:01 not found on slave 1

ubuntu@ubuntu-armhf:~$ 

-----

With those error messages just appearing in the middle of my logged-in terminal session. 

Looking into dmesg, I found other lines interleaved with those:

-----

[  714.027888] libphy: PHY 4a101000.mdio:01 not found

[  714.033046] net eth0: phy 4a101000.mdio:01 not found on slave 1

[  718.999092] net eth0: initializing cpsw version 1.12 (0)

[  719.001963] net eth0: phy found : id is : 0x7c0f1

[  719.001993] libphy: PHY 4a101000.mdio:01 not found

[  719.007119] net eth0: phy 4a101000.mdio:01 not found on slave 1

-----

I've seen that 0x7c0f1 phy ID before, but only long after boot, if the Wi-Fi loses signal:

-----

[245583.292875] CNTL - All roaming failed, restore to channel 1, Total BSS[00]

[245583.293003] ==>  DMAIdle, GloCfg=0x40000050

[245583.654358] net eth0: initializing cpsw version 1.12 (0)

[245583.657826] net eth0: phy found : id is : 0x7c0f1

[245583.657867] libphy: PHY 4a101000.mdio:01 not found

[245583.663134] net eth0: phy 4a101000.mdio:01 not found on slave 1

[245583.673942] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

-----

I'm not sure what my point is here, except that I see lots of people with "phy not found" messages all over successful boots, and since I've dug this deeply already I thought I'd share. During my boot fail adventure it was very hard to tell which apparent error messages really were part of the problem and which seem to be "normal". Turned out I had a hardware failure and none of these "not found" messages were relevant. 

https://groups.google.com/forum/#!searchin/beagleboard/lorenamelang/beagleboard/VXYkdt_jvTo/iAgYvzoquK8J

Maybe these clues will help someone...  

[Andrew Glen]

From some earlier correspondence with Gerald @ BeagleBoard:

"Rev A6 was not changed to fix this issue. It has a reset fix, but not
for this. Whatever change I come up with will not show up for months.
I don't know what the version will be. It is not clear how the Rev A6
revision will affect this issue."

On 5 February 2014 18:42, sunvale <kevinh...@gmail.com> wrote:
> Does the C24 value change in revision A6A suppose to fix this problem? I
> still got this issue on my two BBB A6A. Do we need to increase C24 further,
> or have it removed completely since U16 is added?

> 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

[da...@mahuika.co.nz]

Can I add in what I'm seeing on a A5C board. 

When the board boots either with or without an ethernet cable connected I don't get any lights on the ethernet socket. Whereas my older Beaglebone (white version) lights the orange ethernet LED almost immediately after power is applied. 

I can plug in different cables and different switches into the ethernet port and no go. These cables and switches work fine with the BB white. 

Appropriate dmesg lines are always the same:

[    0.762015] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6

[    0.762046] davinci_mdio 4a101000.mdio: detected phy mask fffffffe

[    0.763087] libphy: 4a101000.mdio: probed

[    0.763120] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720

[    0.763468] cpsw 4a100000.ethernet: NAPI disabled

[    5.682733]  gadget: using random self ethernet address

[    5.888585] net eth0: initializing cpsw version 1.12 (0)

[    5.890892] net eth0: phy found : id is : 0x7c0f1

[    5.891109] libphy: PHY 4a101000.mdio:01 not found

[    5.896181] net eth0: phy 4a101000.mdio:01 not found on slave 1

[    5.960077] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Now here comes the crazy part. The *only* way I've managed to get the ethernet lights to come on is to plug in an ethernet cable directly from the BB white to this BB Black (sometimes this doesn't work first time). Then both the orange and green lights come on and stay on on the Black. Then I get:

[   17.528196] libphy: 4a101000.mdio:00 - Link is Up - 100/Full

[   17.528261] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

If I set an IPv4 address manually I can't ping between the boards tho. Even tho ifconfig is showing some packets flying around:

eth0      Link encap:Ethernet  HWaddr C4:ED:BA:7B:EB:F7  

          inet addr:192.168.5.199  Bcast:192.168.5.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:41 errors:0 dropped:0 overruns:0 frame:0

          TX packets:105 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:13493 (13.1 KiB)  TX bytes:30970 (30.2 KiB)

          Interrupt:56 

Craziness does not stop there. About 50% of the time I can then unplug the ethernet cable from the BB Black and the ethernet lights (on the now empty port) stay lit. I can then plug a cable in between the BB Black and a switch and see activity on the green LED (orange LED is still lit). But still can't actually get any packets out of it. When I do this no new dmesg's appear.

Is this faulty or some symptom similar to what else is in this post? 

I have tried computer USB power, 1A external DC power and a 2.1A USB power supply. This was observed with the original eMMC software version and I have since flashed it to 2013-09-04 version with no difference. 

regards,

Damon.

[chand...@gmail.com]

Should C24 and C30 be removed from A5A BBBs that begin experencing strange Ethernet problems?

I have two A5As that have both decided to keep their link lights on at all times (even without a cable).
Also the Ethernet switch does not recognize either of the affected BBBs (tried several known good cables and ports).

Regards,
Joe

[Gerald Coley]

That is up to you if you want to rip parts off. I am not recommending it.

Gerald

--

[Gerald Coley]

Correct. You can also solve the issue by using the correct SW as well. The issue is that the processors interferes with the default address settings when the PHY reads the pins. If the SW looks for the other addresses, it works fine.

Also, removing these caps will also create issues where the board does not boot at all. Not exactly a good trade.

Gerald

On Tue, Mar 11, 2014 at 3:25 AM, Robert Kuhn <rob...@ku.hn> wrote:

Hi,

Gerald:

Try removing C24. See if that helps.

 We saw the same problem. After removing C24 and C30 it seems to be solved!

Our board is revision B.

Robert

--
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.

[Gerald Coley]

My SW guy is currently out. There is a change that needs to be made. I will get with him next week to make sure the change gets done.

Gerald

On Tue, Mar 11, 2014 at 8:26 AM, Robert Kuhn <rob...@ku.hn> wrote:

Gerald:

Correct. You can also solve the issue by using the correct SW as well. The issue is that the processors interferes with the default address settings when the PHY reads the pins. If the SW looks for the other addresses, it works fine.

Also, removing these caps will also create issues where the board does not boot at all. Not exactly a good trade.

I got my Ubuntu 12.04 from here:  http://www.armhf.com/index.php/download/
When I searched for "beaglebone+ubuntu" I got many results. So its hard to find the "correct" software.

So where can I find it? Do you have a link?

Thanks - Robert

[Robert Nelson]

On Tue, Mar 11, 2014 at 8:26 AM, Robert Kuhn <rob...@ku.hn> wrote:
>
>
> Gerald:

>>
>> Correct. You can also solve the issue by using the correct SW as well. The
>> issue is that the processors interferes with the default address settings
>> when the PHY reads the pins. If the SW looks for the other addresses, it
>> works fine.
>>
>> Also, removing these caps will also create issues where the board does not
>> boot at all. Not exactly a good trade.
>
>

> I got my Ubuntu 12.04 from here: http://www.armhf.com/index.php/download/
> When I searched for "beaglebone+ubuntu" I got many results. So its hard to
> find the "correct" software.
>
> So where can I find it? Do you have a link?

My "debian" image is now hosted here:

http://beagleboard.org/latest-images

For ubuntu you can find images from the same script that generates
that image ^ here:

http://elinux.org/BeagleBoardUbuntu

But honestly, due to ubuntu's current short eol cycles (9 months),
ubuntu isn't that great anymore for long run embedded applications. So
i've been losing interest in support ubuntu.

Regards,

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

[Loren Amelang]

Gerald said:

The issue is that the processors interferes with the default address settings when the PHY reads the pins. If the SW looks for the other addresses, it works fine.

Could we get a clue about which "addresses" are the problem?

Maybe the addresses 4a100000 vs. 4a101000?

davinci_mdio 4a101000.mdio: phy[0]: 

device 4a101000.mdio:00

---

cpsw 4a100000.ethernet: 

Or maybe the mask that seems to select the particular phy? 

davinci_mdio 4a101000.mdio: detected phy mask fffffffb

---

davinci_mdio 4a101000.mdio: detected phy mask fffffffe

Or the "phy id" which I haven't a clue about?

net eth0: phy found : id is : 0x7c0f1

Or maybe the default MAC addresses, two in the onboard hardware memory and more in the boot environment?

I still see lots of "phy not found" dmessages, even though all of my interfaces work properly when connected. Would be nice to understand this better...  

[Gerald Coley]

The base address of the PHY. Only one address per PHY. I believe it is 0 to 7. It is my understanding that the fix was pushed up a week ago. Robert's image should handle this.

It is not the MAC address. PHY NOT FOUND means that at the one address of 00 the PHY did not respond because the PHY has a different address. 

Gerald

[Gerald Coley]

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

[Loren Amelang]

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...  

[Andrew Glen]

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.

> --
> 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

[Gerald Coley]

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

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.

[Jon]

fwiw, I'm seeing what *appears* to be this same issue on the latest board I've bought - occasionally there is no Ethernet connectivity on power-up, a physical power off/on always resolves it...

This is a rev B board, running the latest Debian test image with beta 3.13 kernel, and has happened on both USB and DC power.

Regards,
Jon

[bko...@scanimetrics.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.

[Robert Nelson]

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.

[David Lambert]

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]

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]

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]

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]

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]

Where are you looking exactly?

Gerald

[Kees k]

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]

I did not use the NCP349 on the BBB. What board are you looking at?

Gerald

[bko...@scanimetrics.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]

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.

[Gerald Coley]

A cape. I hate capes. Maybe on the next revision I will just disable all of them!

Thanks!

Gerald

[je...@longofest.net]

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]

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]

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]

Update. I have now witnessed the problem on RCS's 3.13.x kernels :( 

[David Lambert]

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]

 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]

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]

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]

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]

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);

[John Syn]

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 isn’t 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]

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]

I would like to know what this means ? Is it a electrical problems ? Can we monitor this ?

[William Hermans]

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]

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]

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]

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]

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]

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]

From: Vishnu Patekar <vishnupa...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <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]

From: Vishnu Patekar <vishnupa...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <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