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

[ralf.lieb.cymru via BeagleBoard]

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
 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[tpkuester]

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

On Sunday, April 3, 2016 at 7:59:49 PM UTC-4, ralf.li...@googlemail.com 
wrote:
>
> 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
>  
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/97ab9594-8b51-4f53-9713-17221293877d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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 fffe", 
never "fffb", 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 fffe
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 4a10.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=0x4050
[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...  


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 fffe
> [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 *fffb*
> [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*
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To 

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

[damon]

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 fffe
[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 4a10.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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[chandlerjs]

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

On Monday, February 10, 2014 5:56:17 PM UTC-5, da...@mahuika.co.nz wrote:
>
> 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 fffe
> [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 4a10.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.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[cl]

Robert Nelson  wrote:
> On Thu, Mar 20, 2014 at 4:48 AM, Kees k  
> 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
·

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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








On Thursday, March 20, 2014 2:44:33 PM UTC+1, c...@isbd.net wrote:
>
> Robert Nelson > wrote: 
> > On Thu, Mar 20, 2014 at 4:48 AM, Kees k > 
>
> > 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 
> · 
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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 fffe
> [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 *fffb*
> [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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Richard-tx]

I have a BBB that sometimes fails to have a useable network interface at 
power up.   Removing power and reapplying power does resolve the issue.  Is 
there a fix for this issue?  Would an upgrrade to Rev C fix this?



> ...

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sascha Ittner]

> 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 fffe
> [2.833517] libphy: 4a101000.mdio: probed
> [2.837871] davinci_mdio 4a101000.mdio: phy[0]: device 
> 4a101000.mdio:00, driver unknown
>  
>
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 *fffb*
> [2.829512] libphy: 4a101000.mdio: probed
> [2.833875] davinci_mdio 4a101000.mdio: phy[2]: device 
> 4a101000.mdio:02, driver unknown
>
>
I've experienced the same issue and found your patch 
https://github.com/RobertCNelson/linux-dev/blob/master/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch
 
to fix it.

However it seems to be more natural to me to patch the cpsw driver to use 
the first phy that it will found. Please see my suggestion for that (it's 
based on kernel 3.12.30):

diff -Naur linux.orig/arch/arm/boot/dts/am335x-bone-common.dtsi linux/arch/
arm/boot/dts/am335x-bone-common.dtsi
--- linux.orig/arch/arm/boot/dts/am335x-bone-common.dtsi2014-10-09 15:46
:37.0 +0200
+++ linux/arch/arm/boot/dts/am335x-bone-common.dtsi2015-04-23 23:38:
14.210206750 +0200
@@ -322,7 +322,7 @@
 };
 
 &cpsw_emac0 {
-phy_id = <&davinci_mdio>, <0>;
+phy_id = <&davinci_mdio>;
 phy-mode = "mii";
 };
 
diff -Naur linux.orig/drivers/net/ethernet/ti/cpsw.c linux/drivers/net/
ethernet/ti/cpsw.c
--- linux.orig/drivers/net/ethernet/ti/cpsw.c2014-10-09 15:46:
37.0 +0200
+++ linux/drivers/net/ethernet/ti/cpsw.c2015-04-24 08:16:54.401495090 +
0200
@@ -1810,6 +1810,20 @@
 slave->port_vlan = data->dual_emac_res_vlan;
 }
 
+static int match_first_phy(struct device *dev, void *data)
+{
+const char *dn = dev_name(dev);
+const char *mn = (const char *) data;
+while (*mn) {
+if (*dn != *mn)
+return 0;
+dn++;
+mn++;
+}
+
+return 1;
+}
+
 static int cpsw_probe_dt(struct cpsw_platform_data *data,
  struct platform_device *pdev)
 {
@@ -1895,7 +1909,6 @@
 for_each_child_of_node(node, slave_node) {
 struct cpsw_slave_data *slave_data = data->slave_data + i;
 const void *mac_addr = NULL;
-u32 phyid;
 int lenp;
 const __be32 *parp;
 struct device_node *mdio_node;
@@ -1906,19 +1919,31 @@
 continue;
 
 parp = of_get_property(slave_node, "phy_id", &lenp);
-if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
+if ((parp == NULL) || (lenp < sizeof(void *))) {
 pr_err("Missing slave[%d] phy_id property\n", i);
 return -EINVAL;
 }
 mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
-phyid = be32_to_cpup(parp+1);
 mdio = of_find_device_by_node(mdio_node);
 if (!mdio) {
 pr_err("Missing mdio platform device\n");
 return -EINVAL;
 }
-snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
- PHY_ID_FMT, mdio->name, phyid);
+if (lenp >= (sizeof(void *) * 2)) {
+u32 phyid;
+phyid = be32_to_cpup(parp+1);
+snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
+ PHY_ID_FMT, mdio->name, phyid);
+} else {
+struct device *phy;
+phy = bus_find_device(
+&mdio_bus_type, NULL, (void *) mdio->name, match_first_phy
);
+if (!phy) {
+pr_err("No PHY found\n");
+return -EINVAL;
+}
+strncpy(slave_data->phy_id, dev_name(phy), sizeof(slave_data->
phy_id));
+}
 
 mac_addr = of_get_mac_address(slave_node);
 if (mac_addr)



-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[sascha . ittner]

Hi Jay,

I've run into the same problem, so thank you much for your work. However it 
seems more natural to me to patch the cpsw driver to use the first MAC 
which is found rather than modifying the DT at runtime. Please see my 
suggestion (based on 3.12.30):

diff -Naur linux.orig/arch/arm/boot/dts/am335x-bone-common.dtsi linux/arch/
arm/boot/dts/am335x-bone-common.dtsi
--- linux.orig/arch/arm/boot/dts/am335x-bone-common.dtsi2014-10-09 15:46
:37.0 +0200
+++ linux/arch/arm/boot/dts/am335x-bone-common.dtsi2015-04-23 23:38:
14.210206750 +0200
@@ -322,7 +322,7 @@
 };
 
 &cpsw_emac0 {
-phy_id = <&davinci_mdio>, <0>;
+phy_id = <&davinci_mdio>;
 phy-mode = "mii";
 };
 
diff -Naur linux.orig/drivers/net/ethernet/ti/cpsw.c linux/drivers/net/
ethernet/ti/cpsw.c
--- linux.orig/drivers/net/ethernet/ti/cpsw.c2014-10-09 15:46:
37.0 +0200
+++ linux/drivers/net/ethernet/ti/cpsw.c2015-04-24 08:16:54.401495090 +
0200
@@ -1810,6 +1810,20 @@
 slave->port_vlan = data->dual_emac_res_vlan;
 }
 
+static int match_first_phy(struct device *dev, void *data)
+{
+const char *dn = dev_name(dev);
+const char *mn = (const char *) data;
+while (*mn) {
+if (*dn != *mn)
+return 0;
+dn++;
+mn++;
+}
+
+return 1;
+}
+
 static int cpsw_probe_dt(struct cpsw_platform_data *data,
  struct platform_device *pdev)
 {
@@ -1895,7 +1909,6 @@
 for_each_child_of_node(node, slave_node) {
 struct cpsw_slave_data *slave_data = data->slave_data + i;
 const void *mac_addr = NULL;
-u32 phyid;
 int lenp;
 const __be32 *parp;
 struct device_node *mdio_node;
@@ -1906,19 +1919,31 @@
 continue;
 
 parp = of_get_property(slave_node, "phy_id", &lenp);
-if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
+if ((parp == NULL) || (lenp < sizeof(void *))) {
 pr_err("Missing slave[%d] phy_id property\n", i);
 return -EINVAL;
 }
 mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
-phyid = be32_to_cpup(parp+1);
 mdio = of_find_device_by_node(mdio_node);
 if (!mdio) {
 pr_err("Missing mdio platform device\n");
 return -EINVAL;
 }
-snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
- PHY_ID_FMT, mdio->name, phyid);
+if (lenp >= (sizeof(void *) * 2)) {
+u32 phyid;
+phyid = be32_to_cpup(parp+1);
+snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
+ PHY_ID_FMT, mdio->name, phyid);
+} else {
+struct device *phy;
+phy = bus_find_device(
+&mdio_bus_type, NULL, (void *) mdio->name, match_first_phy
);
+if (!phy) {
+pr_err("No PHY found\n");
+return -EINVAL;
+}
+strncpy(slave_data->phy_id, dev_name(phy), sizeof(slave_data->
phy_id));
+}
 
 mac_addr = of_get_mac_address(slave_node);
 if (mac_addr)





-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jay @ Control Module Industries]

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 
 #include 
 #include 
+#include 
 
 /*
  * This timeout definition is a worst-case ultra defensive measure against
@@ -97,6 +98,10 @@ struct davinci_mdio_data {
 unsigned longaccess_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);

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[slamontagne]

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-2-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 fffb
Oct 25 00:13:13 beaglebone kernel: [3.021255] davinci_mdio: dt: updated 
phy_id[2] from phy_mask[fffb]
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 4a10.ethernet: 
Detected MACID = 68:9e:19:98:ab:30
Oct 25 00:13:13 beaglebone kernel: [3.055733] cpsw 4a10.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 fffe
Oct 25 00:13:13 beaglebone kernel: [3.021252] davinci_mdio: dt: updated 
phy_id[0] from phy_mask[fffe]
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 4a10.ethernet: 
Detected MACID = 68:9e:19:98:ab:30
Oct 25 00:13:13 beaglebone kernel: [3.055724] cpsw 4a10.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 

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 

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 addres

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

[bigjosh]

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


On Wednesday, October 26, 2016 at 12:24:42 PM UTC-4, slamontagne wrote:
>
> 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-2-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 fffb
> Oct 25 00:13:13 beaglebone kernel: [3.021255] davinci_mdio: dt: 
> updated phy_id[2] from phy_mask[fffb]
> 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 4a10.ethernet: 
> Detected MACID = 68:9e:19:98:ab:30
> Oct 25 00:13:13 beaglebone kernel: [3.055733] cpsw 4a10.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 fffe
> Oct 25 00:13:13 beaglebone kernel: [3.021252] davinci_mdio: dt: 
> updated phy_id[0] from phy_mask[fffe]
> 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 4a10.ethernet: 
> Detected MACID = 68:9e:19:98:ab:30
> Oct 25 00:13:13 beaglebone kernel: [3.055724] cpsw 4a10.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 
> 
> 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 {newl

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

[bigjosh]

So far we have 2 workarounds that seem effective...

1) Connect a GPIO pin to the SYS_RESETN pin (P9-10). Make sure the GPIO pin 
in set to be an input only with pull-up at boot time in the DT. After boot, 
have a script or service grep dmseg for the telltail `detected phy mask 
*fffb' 
*message. If the message is found, then set the GPIO pin to output and 
drive low and the board will reboot and (eventually) win the race and have 
a functional ethernet port. 

2) Add an additional external micro-usb power supply. I've had good luck 
with the 2A ones sold for the raspberry pi. I haven't had time to look at 
all the signal, but the extra power source seems to effect the rise time of 
the reset signal RC circuit enough to practically always win the race.

-josh


On Tuesday, November 26, 2013 at 5:22:42 PM UTC-5, 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 fffe
> [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 *fffb*
> [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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6a7f3bba-7fcc-4502-ace0-f89475b15485%40googlegroups.com.
For more o

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

[Andrew Glen]

FYI: The hardware fix described earlier in this thread give 100% success,
first time, every time.

On 27 April 2017 at 15:42,  wrote:

> If you have this problem and only care about solutions, jump to
> "workarounds" below.
>
> ### RECAP
>
> For unlucky souls who come fresh upon this problem and down want to read
> though a better part of a decade's worth of conflicting reports
>
> 1. Due to a design issue, the BeagleBone Black and descendants have a
> problem where they intermittently come up with various bad state set in the
> physical network connection chip (PHY) that make the wired Ethernet port
> inaccessible and there is no way to get it to recover using only software -
> a power cycle or hardware reset is required.
>
> 2. One of the ways that the PHY can have bad state is that its address can
> be assigned a different value than expected. The latest versions of the
> kernel will scan all possible addresses and find the PHY no matter what
> address is happens to get, so this failure mode is not longer part of issue
> as long as you use one of these new kernels. (BTW, I have an elegant
> solution to reassign the PHY back to the expected address which will work
> with any kernel version if you need it. It also avoids the current kluge
> that hacks up the device tree to match the new found PHY address.)
>
> 3. There are still some bad states that the PHY chip can come up in that
> are not addressed by the new kernel. As far as I know there is no software
> only workaround for these - a power cycle or hardware reset is required.
>
> 4. In my personal experience, the bad state seems to be significantly less
> likely when the board is powered though the barrel connector (or USB om
> BeagleBone Green) than when it is powered via the pin on P9 header. I've
> also noticed that most people in this thread are powering thier boards via
> a cape or header connected power supply which makes sense since these
> people tend to seen the problem more often. Note that the non-recoverable
> bad state can still happen even on a baord powered via the barrel - it is
> just less likely.
>
> 5. In my personal experience, the bad state seems to be more likely on
> certain individual boards than others. I have a board that comes up in the
> bad state about 50% of the time, while other boards only come up int he bad
> state 1 in 100 times.
>
> 6. In my experience, the bad state seems to be significantly less like if
> *nothing* is connected to the Ethernet port at power up. I really mean not
> connected - even if there is an unpowered device connected to the other end
> of the network cable, then the bad state occurs more often. The cable much
> be unplugged at one end or the other.
>
> 7. Bit 13 in register 18 seems to be a 100% indication that you are in the
> bad state. I have never seen a board with that bit set recover, and I have
> never seen a non-recoverable board without that bit set (except for a
> couple of seconds if you manually clear it before it sets itself on again).
> This bit is "reserved" in the datasheet and so far no hints from Microchip
> as to what it might mean that might lead to a better understanding of the
> issue.
>
> 8. In the bad state, it is possible to get the PHY to link by manually
> configuring it to 10Mbs half duplex (no auto negotiation). While the link
> light comes on and the "link active" bit is set, it does not appear to be
> decoding incoming packets so this is not a useful workaround.
>
> ### WORKAROUNDS
>
> In order of effectiveness/desirability.
>
> 1. Use a different board. All the commercially available BeagleBone Black
> and descendants share this design issue, so look at maybe the Raspberry Pi
> or one of the other ARM based SBCs.
>
> 2. Spin your own version of the board. This problem could be completely
> resolved by adding a connection between the reset pin of the PHY and a gpio
> on the ARM. This way the ARM would be carefully control the required timing
> sequence for bringing up the PHY chip - and also be able to hardware reset
> the chip in case there are any problems.
>
> 3. Use a USB Ethernet adapter rather than the on-board eth0 port.
> Compatible adapters can be found for less than $10.
>
> 4. Connect a gpio pin to the reset pin on header P9. That reset pin is
> tied to the hardware reset pin of the PHY chip, so you can reset it under
> software control. gpio 60 happens to be very close physically, making for a
> very easy jumper connection. Then you need a script to test for the bad
> state, and activate the gpio to reset if it is found. Note that the reset
> pin will also reset the ARM, the the BB will reboot every-time you do this
> but should eventually come up (and satay up) with the PHY in the good
> state.
>
> 5. Unplug the the Ethernet port during power up, check for bad state after
> the board comes up, and keep power cycling it until it comes up in a good
> state, then reconnect the network cable.
>
> 6. Power the board though the barrel or USB rather th

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

[Andrew Glen]

This one:

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.

On 27 April 2017 at 15:53, Andrew Glen  wrote:

> FYI: The hardware fix described earlier in this thread give 100% success,
> first time, every time.
>
> On 27 April 2017 at 15:42,  wrote:
>
>> If you have this problem and only care about solutions, jump to
>> "workarounds" below.
>>
>> ### RECAP
>>
>> For unlucky souls who come fresh upon this problem and down want to read
>> though a better part of a decade's worth of conflicting reports
>>
>> 1. Due to a design issue, the BeagleBone Black and descendants have a
>> problem where they intermittently come up with various bad state set in the
>> physical network connection chip (PHY) that make the wired Ethernet port
>> inaccessible and there is no way to get it to recover using only software -
>> a power cycle or hardware reset is required.
>>
>> 2. One of the ways that the PHY can have bad state is that its address
>> can be assigned a different value than expected. The latest versions of the
>> kernel will scan all possible addresses and find the PHY no matter what
>> address is happens to get, so this failure mode is not longer part of issue
>> as long as you use one of these new kernels. (BTW, I have an elegant
>> solution to reassign the PHY back to the expected address which will work
>> with any kernel version if you need it. It also avoids the current kluge
>> that hacks up the device tree to match the new found PHY address.)
>>
>> 3. There are still some bad states that the PHY chip can come up in that
>> are not addressed by the new kernel. As far as I know there is no software
>> only workaround for these - a power cycle or hardware reset is required.
>>
>> 4. In my personal experience, the bad state seems to be significantly
>> less likely when the board is powered though the barrel connector (or USB
>> om BeagleBone Green) than when it is powered via the pin on P9 header. I've
>> also noticed that most people in this thread are powering thier boards via
>> a cape or header connected power supply which makes sense since these
>> people tend to seen the problem more often. Note that the non-recoverable
>> bad state can still happen even on a baord powered via the barrel - it is
>> just less likely.
>>
>> 5. In my personal experience, the bad state seems to be more likely on
>> certain individual boards than others. I have a board that comes up in the
>> bad state about 50% of the time, while other boards only come up int he bad
>> state 1 in 100 times.
>>
>> 6. In my experience, the bad state seems to be significantly less like if
>> *nothing* is connected to the Ethernet port at power up. I really mean not
>> connected - even if there is an unpowered device connected to the other end
>> of the network cable, then the bad state occurs more often. The cable much
>> be unplugged at one end or the other.
>>
>> 7. Bit 13 in register 18 seems to be a 100% indication that you are in
>> the bad state. I have never seen a board with that bit set recover, and I
>> have never seen a non-recoverable board without that bit set (except for a
>> couple of seconds if you manually clear it before it sets itself on again).
>> This bit is "reserved" in the datasheet and so far no hints from Microchip
>> as to what it might mean that might lead to a better understanding of the
>> issue.
>>
>> 8. In the bad state, it is possible to get the PHY to link by manually
>> configuring it to 10Mbs half duplex (no auto negotiation). While the link
>> light comes on and the "link active" bit is set, it does not appear to be
>> decoding incoming packets so this is not a useful workaround.
>>
>> ### WORKAROUNDS
>>
>> In order of effectiveness/desirability.
>>
>> 1. Use a different board. All the commercially available BeagleBone Black
>> and descendants share this design issue, so look at maybe the Raspberry Pi
>> or one of the other ARM based SBCs.
>>
>> 2. Spin your own version of the board. This problem could be completely
>> resolved by adding a connection between the reset pin of the PHY and a gpio
>> on the ARM. This way the ARM would be carefully control the required timing
>> sequence for bringing up the PHY chip - and also be able to hardware reset
>> the chip in case there are any problems.
>>
>> 3. Use a USB Ethernet adapter rather than the on-board eth0 port.
>> Compatible adapters can be found for less than $10.
>>
>> 4. Connect a gpio pin to the reset pin on header P9. That res

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

[bigjosh]

If you have this problem and only care about solutions, jump to 
"workarounds" below.

### RECAP 

For unlucky souls who come fresh upon this problem and down want to read 
though a better part of a decade's worth of conflicting reports

1. Due to a design issue, the BeagleBone Black and descendants have a 
problem where they intermittently come up with various bad state set in the 
physical network connection chip (PHY) that make the wired Ethernet port 
inaccessible and there is no way to get it to recover using only software - 
a power cycle or hardware reset is required. 

2. One of the ways that the PHY can have bad state is that its address can 
be assigned a different value than expected. The latest versions of the 
kernel will scan all possible addresses and find the PHY no matter what 
address is happens to get, so this failure mode is not longer part of issue 
as long as you use one of these new kernels. (BTW, I have an elegant 
solution to reassign the PHY back to the expected address which will work 
with any kernel version if you need it. It also avoids the current kluge 
that hacks up the device tree to match the new found PHY address.) 

3. There are still some bad states that the PHY chip can come up in that 
are not addressed by the new kernel. As far as I know there is no software 
only workaround for these - a power cycle or hardware reset is required. 

4. In my personal experience, the bad state seems to be significantly less 
likely when the board is powered though the barrel connector (or USB om 
BeagleBone Green) than when it is powered via the pin on P9 header. I've 
also noticed that most people in this thread are powering thier boards via 
a cape or header connected power supply which makes sense since these 
people tend to seen the problem more often. Note that the non-recoverable 
bad state can still happen even on a baord powered via the barrel - it is 
just less likely. 

5. In my personal experience, the bad state seems to be more likely on 
certain individual boards than others. I have a board that comes up in the 
bad state about 50% of the time, while other boards only come up int he bad 
state 1 in 100 times. 

6. In my experience, the bad state seems to be significantly less like if 
*nothing* is connected to the Ethernet port at power up. I really mean not 
connected - even if there is an unpowered device connected to the other end 
of the network cable, then the bad state occurs more often. The cable much 
be unplugged at one end or the other. 

7. Bit 13 in register 18 seems to be a 100% indication that you are in the 
bad state. I have never seen a board with that bit set recover, and I have 
never seen a non-recoverable board without that bit set (except for a 
couple of seconds if you manually clear it before it sets itself on again). 
This bit is "reserved" in the datasheet and so far no hints from Microchip 
as to what it might mean that might lead to a better understanding of the 
issue. 

8. In the bad state, it is possible to get the PHY to link by manually 
configuring it to 10Mbs half duplex (no auto negotiation). While the link 
light comes on and the "link active" bit is set, it does not appear to be 
decoding incoming packets so this is not a useful workaround. 

### WORKAROUNDS

In order of effectiveness/desirability. 

1. Use a different board. All the commercially available BeagleBone Black 
and descendants share this design issue, so look at maybe the Raspberry Pi 
or one of the other ARM based SBCs.

2. Spin your own version of the board. This problem could be completely 
resolved by adding a connection between the reset pin of the PHY and a gpio 
on the ARM. This way the ARM would be carefully control the required timing 
sequence for bringing up the PHY chip - and also be able to hardware reset 
the chip in case there are any problems. 

3. Use a USB Ethernet adapter rather than the on-board eth0 port. 
Compatible adapters can be found for less than $10. 

4. Connect a gpio pin to the reset pin on header P9. That reset pin is tied 
to the hardware reset pin of the PHY chip, so you can reset it under 
software control. gpio 60 happens to be very close physically, making for a 
very easy jumper connection. Then you need a script to test for the bad 
state, and activate the gpio to reset if it is found. Note that the reset 
pin will also reset the ARM, the the BB will reboot every-time you do this 
but should eventually come up (and satay up) with the PHY in the good 
state. 

5. Unplug the the Ethernet port during power up, check for bad state after 
the board comes up, and keep power cycling it until it comes up in a good 
state, then reconnect the network cable.

6. Power the board though the barrel or USB rather than though the headers.

Though a combination of 5 & 6, I was able to get my bank of boards to come 
up with a better than 80% good state rate on the first try. Yona Applegate 
(of LEDscape fame) reports being able to get his large c

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

[Geetha]

We have a few Industrial Beaglebone Black from Element 14. Rev C(PCB 
revision is B6).
The Ethernet not coming up on every boot is faced in this version too.
The OS used is QNX & hence the Software fix provided in Linux Kernel could 
not be used.
Is there a solution?
-Geetha

On Wednesday, November 27, 2013 at 3:52:42 AM UTC+5:30 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 fffe
> [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 *fffb*
> [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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ca52f021-a089-4e0f-9375-1ad45b7fadd8n%40googlegroups.com.

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

[robert.sty...@gmail.com]

Which problem do you have?

*IIRC*
QNX may still use uboot or equivalent
QNX can kill and restart a driver. Would require something to determine the 
Ethernet was not working and restart it.

It seems like there are/were two problems:

   1. Random RX characters on console/debug UART interrupting normal boot
   2. Ethernet chip not resetting, because the reset pulse is too short

There are several routes to boot or reboot which clouds the issues.

*UART Problem*

The solutions and theory are...
Connecting a FTDI USB to UART cable by holding the RX line at idle (3.3V), 
stopped the random characters which triggered the uboot command line.
The original hardware fix was to pull the RX line low through a resistor, 
but this did not fix all boards. This holds the RX active which may cause a 
"break" interrupt in the UART.
Alternate hardware fix was to pull the RX to 3.3V through a resistor (like 
using a FTDI cable). This may also allow the chip to be powered by its data 
line.

The software fix is by changing uboot to only enter command line, by a 
specific sequence of characters, not just any random character.

*Ethernet Chip Reset Problem*

The hardware fixes were:
to increase the length of the reset pulse by increasing C24
to add gate to pull down SYS_RESETn when "power good" signal is not

On Wednesday, 2 June 2021 at 10:43:08 UTC+1 Geetha wrote:

> We have a few Industrial Beaglebone Black from Element 14. Rev C(PCB 
> revision is B6).
> The Ethernet not coming up on every boot is faced in this version too.
> The OS used is QNX & hence the Software fix provided in Linux Kernel could 
> not be used.
> Is there a solution?
> -Geetha
>
> On Wednesday, November 27, 2013 at 3:52:42 AM UTC+5:30 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 fffe
>> [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 *fffb*
>> [2.829512] libphy: 4a101000.mdio: probed
>> [2.833875] davinci_mdio 4a101000.mdio: phy[2]: device 
>> 4a101000.m

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

[robert.sty...@gmail.com]

I notice from linked article that 
"QNX can kill and restart a driver. Would require something to determine 
the Ethernet was not working and restart it" is not going to work.
However, you could replicate in QNX the Linux steps, assuming the source 
code is available for the Linux tools used.

>From the article 
(https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/)
 
it seems odd that you can read the registers of a failed boot Ethernet PHY, 
but you cannot write anything to reset it.
On Wednesday, 2 June 2021 at 13:04:03 UTC+1 robert.sty...@gmail.com wrote:

> Which problem do you have?
>
> *IIRC*
> QNX may still use uboot or equivalent
> QNX can kill and restart a driver. Would require something to determine 
> the Ethernet was not working and restart it.
>
> It seems like there are/were two problems:
>
>1. Random RX characters on console/debug UART interrupting normal boot
>2. Ethernet chip not resetting, because the reset pulse is too short
>
> There are several routes to boot or reboot which clouds the issues.
>
> *UART Problem*
>
> The solutions and theory are...
> Connecting a FTDI USB to UART cable by holding the RX line at idle (3.3V), 
> stopped the random characters which triggered the uboot command line.
> The original hardware fix was to pull the RX line low through a resistor, 
> but this did not fix all boards. This holds the RX active which may cause a 
> "break" interrupt in the UART.
> Alternate hardware fix was to pull the RX to 3.3V through a resistor (like 
> using a FTDI cable). This may also allow the chip to be powered by its data 
> line.
>
> The software fix is by changing uboot to only enter command line, by a 
> specific sequence of characters, not just any random character.
>
> *Ethernet Chip Reset Problem*
>
> The hardware fixes were:
> to increase the length of the reset pulse by increasing C24
> to add gate to pull down SYS_RESETn when "power good" signal is not
>
> On Wednesday, 2 June 2021 at 10:43:08 UTC+1 Geetha wrote:
>
>> We have a few Industrial Beaglebone Black from Element 14. Rev C(PCB 
>> revision is B6).
>> The Ethernet not coming up on every boot is faced in this version too.
>> The OS used is QNX & hence the Software fix provided in Linux Kernel 
>> could not be used.
>> Is there a solution?
>> -Geetha
>>
>> On Wednesday, November 27, 2013 at 3:52:42 AM UTC+5:30 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_

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

[bigjosh]

I opened a ticket with Microchip on this more then 6 months ago and just 
got the reply below.

TLDR; "Since it took us so long to get to this issue, we assume you don’t 
care anymore that our silicon doesn’t work correctly”.

Wow.  

--

 AUTOMATED MESSAGE - SEE RESPONSE METHODS BELOW  

 

Below is a proposed resolution from Microchip Engineering Support Team for 
your Case 00223815.

 

Subject: AMDIXCTRL is *not* cleared on soft reset as specified

Reason: Silicon Issue

Product:  LAN8710A

Problem Description: 

AMDIXCTRL (bit 15 of register 27) is *not* reset to the default value of 0b 
on reset as specified in the datasheet. 

Note that the bit is NOT specified as NASR, which means that it should get 
cleared to 0 on reset as per 3.8.5.2. 

Steps to reproduce... 

1. Show value of AMDIXCTRL (bit 15, reg 27) is 1… 

phyreg 0 27 
PHY=00 REG=27 : IDLE READ ACK 1000---1010 

2. Issue a soft reset by writing 1 to bit 15 on reg 0 …. 

phyreg 0 0 1000--- 
PHY=00 REG=00 : IDLE WRITE ACK 1000--- (DATA 
1000---) 

3. Verify that the soft reset has successfully completed (can take up to 
0.5s) by checking that the reset bit is back to 0… 

phyreg 0 0 
PHY=00 REG=00 : IDLE READ ACK 0011-0001-- 

4. Confirm that the AMDIXCTRL bit is still set after reset, in violation of 
the spec… 

phyreg 0 27 
PHY=00 REG=27 : IDLE READ ACK 1000---1010 

 

*  Proposed Resolution Begin *

Thanks for contacting Microchip. We have many customers in our support 
backlog and we are working to rectify this problem. Sorry for the delay in 
engaging with you, but because this support ticket is so old, I am assuming 
that you no longer require assistance and will be closing out this ticket. 
If you still need help, please reply back and we will keep the ticket open 
and try to resolve the issue.

*  Proposed Resolution End ***

 

 

If the proposed resolution does not solve your problem, please use the *Reject 
Proposed-Resolution* button on the case details and provide further details 
in the comment section. If the proposed resolution does resolve your issue, 
please use the *Accept Resolution/Close Case* button on the case details to 
indicate that it is resolved.

 

Click the link below or copy it into your browser to open the Case details: 
 

https://microchipsupport.force.com/500o00PgBhy

 


You may also contact our support staff via telephone using the webpage 
below (Click "My Support" button on the page):

http://www.microchip.com/support/hottopics.aspx

 

You will be prompted to enter your Phone Access Number: 351342890 . Press # 
on your telephone when finished. If all our engineers are busy with other 
customers, you may be directed to voice mail. Please leave a message with 
your Case Number and the best time to reach you, and we will return your 
call.

 

This case will automatically move to a Closed status if no updates are 
received in 14 calendar days.

 

Microchip Engineering Support 

 

* AUTOMATED MESSAGE - DO NOT RESPOND *

 

DISCLAIMER

 

*

Information provided to Microchip may, without notice, be exported or 
transferred to Microchip foreign subsidiaries or certified partners to 
support your requests. If your information is prohibited from export, 
subject to ITAR, or contains encryption or cryptographic functionality 
subject to the Wassenaar Agreement Control List or U.S. Department of 
Commerce Control List Category 5 do not disclose your information until we 
have agreed upon a process for transfer.

 

*

 

This transmittal and any accompanying information is for suggestion only 
and is provided "AS IS". It shall not be deemed to modify Microchip's 
standard warranty for its products. It is your responsibility to ensure 
that this information meets your requirements.

 

MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, NOT LIMITED TO 
MERCHANTABILITY, FITNESS FOR PURPOSE, NON-INFRINGEMENT, QUALITY, OR 
CONDITION. MICROCHIP PROVIDES THIS INFORMATION CONDITIONALLY UPON YOUR 
ACCEPTANCE OF THESE TERMS.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0d475e77-62e1-4c00-813d-e6fa18daaf07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[evilwulfie]

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


On 6/14/2016 10:06 AM, tpkues...@gmail.com wrote:
> 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
>
> On Sunday, April 3, 2016 at 7:59:49 PM UTC-4,
> ralf.li...@googlemail.com wrote:
>
> 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
>  
>
> -- 
> 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+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/97ab9594-8b51-4f53-9713-17221293877d%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5d860854-b839-cb8b-665d-25310c664643%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gerald Coley]

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

Gerald



On Fri, Feb 28, 2014 at 12:33 AM,  wrote:

> 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
>
>
> On Monday, February 10, 2014 5:56:17 PM UTC-5, da...@mahuika.co.nz wrote:
>>
>> 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 fffe
>> [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 4a10.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.
>>
>  --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Gerald Coley]

Where are you looking exactly?

Gerald



On Thu, Mar 20, 2014 at 8:51 AM, Kees k  wrote:

>
>
> 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?
>
>
>
>
> 
>
>
> 
>
>
> On Thursday, March 20, 2014 2:44:33 PM UTC+1, c...@isbd.net wrote:
>>
>> Robert Nelson  wrote:
>> > On Thu, Mar 20, 2014 at 4:48 AM, Kees k 
>> > 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
>> ·
>>
>>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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


On Thursday, March 20, 2014 2:52:43 PM UTC+1, Gerald wrote:
>
> Where are you looking exactly?
>
> Gerald
>
>
>
> On Thu, Mar 20, 2014 at 8:51 AM, Kees k 
> > wrote:
>
>>
>>
>> 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?
>>
>>
>>
>>
>> 
>>
>>
>> 
>>
>>
>> On Thursday, March 20, 2014 2:44:33 PM UTC+1, c...@isbd.net wrote:
>>>
>>> Robert Nelson  wrote: 
>>> > On Thu, Mar 20, 2014 at 4:48 AM, Kees k  
>>> > 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 
>>> · 
>>>
>>>  -- 
>> 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.
>>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gerald Coley]

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

Gerald



On Thu, Mar 20, 2014 at 8:58 AM, Kees k  wrote:

> 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.
>
>
> On Thursday, March 20, 2014 2:52:43 PM UTC+1, Gerald wrote:
>
>> Where are you looking exactly?
>>
>> Gerald
>>
>>
>>
>> On Thu, Mar 20, 2014 at 8:51 AM, Kees k  wrote:
>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>>
>>> On Thursday, March 20, 2014 2:44:33 PM UTC+1, c...@isbd.net wrote:

 Robert Nelson  wrote:
 > On Thu, Mar 20, 2014 at 4:48 AM, Kees k 
 > 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
 ·

  --
>>> 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.
>>>
>>
>>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gerald Coley]

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  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 fffe
>> [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 *fffb*
>> [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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[jeff]

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?

On Thursday, March 20, 2014 11:47:12 AM UTC-4, Gerald 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 
> > 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 fffe
>>> [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 *fffb*
>>> [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.
>

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

[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:
>
> 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 
> > 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 fffe
>>> [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 *fffb*
>>> [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 t

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

[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  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 fffe
>>> [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 *fffb*
>>> [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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

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

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

[Jerin George]

Hi, 
I am using a BBB Rev C with latest Angstrom image  and i have seen this 
issue with eth not getting detected at boot up. This came at the last 
stages of my project delivery. How can this be corrected. Does moving to 
the latest debian image solves this issue ?

regards, 
Jerin George

On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote:
>
>
> They phymask comes from a hardware register read by the davinci_mdio 
> driver, which gets passed to the linux phy libraries. The problem is that 
> the cpsw driver gets the value from device tree, which is hardcoded to 
> address 0. Usually the values are the same (address 0), but sometimes the 
> phy gets registered to a different address, usually in my case address 2. 
> You calculate the address using the phymask. If you changed the phymask 
> than, you pointing back to address 0, so that wouldn't help you.
>
> I rebuilt the dtb file.
>
> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote:
>>
>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:
>>>
>>> The davinci mdio driver should report a phymask and that value is used 
>>> to update the device tree.
>>>
>>
>> Back when I had this problem I tried hard to find out where the phymask 
>> comes from, and never succeeded. At that time people who received a phymask 
>> of fffe booted successfully, those with fffb failed. Do you know 
>> where the mask is found and how to change it? 
>>
>> I also remove the second phy slave from the device tree.
>>>
>>
>> That seems like a great idea, if only to stop all the useless messages 
>> about it never being found. Can that be done in the uEnv.txt, like when you 
>> disable HDMI, or do you have to rebuild the device tree binary? Would 
>> setting the phymask to  accomplish the same thing?
>>
>> Loren 
>>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Andrew Glen]

As far as I know, and as already documented in this thread, the only
reliable fix is to remove C24 and C30.
On 4/11/2014 5:40 PM, "Jerin George"  wrote:

> Hi,
> I am using a BBB Rev C with latest Angstrom image  and i have seen this
> issue with eth not getting detected at boot up. This came at the last
> stages of my project delivery. How can this be corrected. Does moving to
> the latest debian image solves this issue ?
>
> regards,
> Jerin George
>
> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote:
>>
>>
>> They phymask comes from a hardware register read by the davinci_mdio
>> driver, which gets passed to the linux phy libraries. The problem is that
>> the cpsw driver gets the value from device tree, which is hardcoded to
>> address 0. Usually the values are the same (address 0), but sometimes the
>> phy gets registered to a different address, usually in my case address 2.
>> You calculate the address using the phymask. If you changed the phymask
>> than, you pointing back to address 0, so that wouldn't help you.
>>
>> I rebuilt the dtb file.
>>
>> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote:
>>>
>>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:

 The davinci mdio driver should report a phymask and that value is used
 to update the device tree.

>>>
>>> Back when I had this problem I tried hard to find out where the phymask
>>> comes from, and never succeeded. At that time people who received a phymask
>>> of fffe booted successfully, those with fffb failed. Do you know
>>> where the mask is found and how to change it?
>>>
>>> I also remove the second phy slave from the device tree.

>>>
>>> That seems like a great idea, if only to stop all the useless messages
>>> about it never being found. Can that be done in the uEnv.txt, like when you
>>> disable HDMI, or do you have to rebuild the device tree binary? Would
>>> setting the phymask to  accomplish the same thing?
>>>
>>> Loren
>>>
>>  --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[John Syn]

From:  Andrew Glen 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Monday, November 3, 2014 at 9:42 PM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected
on Boot.

> 
> As far as I know, and as already documented in this thread, the only reliable
> fix is to remove C24 and C30.

If you read the full thread, Gerald say that if you remove these capacitors,
the board may not start at all.

Regards,
John
> On 4/11/2014 5:40 PM, "Jerin George"  wrote:
>> Hi, 
>> I am using a BBB Rev C with latest Angstrom image  and i have seen this issue
>> with eth not getting detected at boot up. This came at the last stages of my
>> project delivery. How can this be corrected. Does moving to the latest debian
>> image solves this issue ?
>> 
>> regards, 
>> Jerin George
>> 
>> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com  wrote:
>>> 
>>> They phymask comes from a hardware register read by the davinci_mdio driver,
>>> which gets passed to the linux phy libraries. The problem is that the cpsw
>>> driver gets the value from device tree, which is hardcoded to address 0.
>>> Usually the values are the same (address 0), but sometimes the phy gets
>>> registered to a different address, usually in my case address 2. You
>>> calculate the address using the phymask. If you changed the phymask than,
>>> you pointing back to address 0, so that wouldn't help you.
>>> 
>>> I rebuilt the dtb file.
>>> 
>>> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote:
>>>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:
>>>>> The davinci mdio driver should report a phymask and that value is used to
>>>>> update the device tree.
>>>> 
>>>> Back when I had this problem I tried hard to find out where the phymask
>>>> comes from, and never succeeded. At that time people who received a phymask
>>>> of fffe booted successfully, those with fffb failed. Do you know
>>>> where the mask is found and how to change it?
>>>> 
>>>>> I also remove the second phy slave from the device tree.
>>>> 
>>>> That seems like a great idea, if only to stop all the useless messages
>>>> about it never being found. Can that be done in the uEnv.txt, like when you
>>>> disable HDMI, or do you have to rebuild the device tree binary? Would
>>>> setting the phymask to  accomplish the same thing?
>>>> 
>>>> Loren 
>> -- 
>> 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Andrew Glen]

Yes, and reading the thread even more fully you'll find my report of
running thousands of automated test restarts with these parts removed, with
a 100% success rate.

We use these boards a lot, running 24-7 in this configuration, and have had
zero hardware faults. With any luck we have nearly exhausted Murphy's law
with our software.

Andrew.
On 4/11/2014 7:26 PM, "John Syn"  wrote:

>
> From: Andrew Glen 
> Reply-To: "beagleboard@googlegroups.com" 
> Date: Monday, November 3, 2014 at 9:42 PM
> To: "beagleboard@googlegroups.com" 
> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected
> on Boot.
>
> As far as I know, and as already documented in this thread, the only
> reliable fix is to remove C24 and C30.
>
> If you read the full thread, Gerald say that if you remove these
> capacitors, the board may not start at all.
>
> Regards,
> John
>
> On 4/11/2014 5:40 PM, "Jerin George"  wrote:
>
>> Hi,
>> I am using a BBB Rev C with latest Angstrom image  and i have seen this
>> issue with eth not getting detected at boot up. This came at the last
>> stages of my project delivery. How can this be corrected. Does moving to
>> the latest debian image solves this issue ?
>>
>> regards,
>> Jerin George
>>
>> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote:
>>>
>>>
>>> They phymask comes from a hardware register read by the davinci_mdio
>>> driver, which gets passed to the linux phy libraries. The problem is that
>>> the cpsw driver gets the value from device tree, which is hardcoded to
>>> address 0. Usually the values are the same (address 0), but sometimes the
>>> phy gets registered to a different address, usually in my case address 2.
>>> You calculate the address using the phymask. If you changed the phymask
>>> than, you pointing back to address 0, so that wouldn't help you.
>>>
>>> I rebuilt the dtb file.
>>>
>>> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote:
>>>>
>>>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:
>>>>>
>>>>> The davinci mdio driver should report a phymask and that value is used
>>>>> to update the device tree.
>>>>>
>>>>
>>>> Back when I had this problem I tried hard to find out where the phymask
>>>> comes from, and never succeeded. At that time people who received a phymask
>>>> of fffe booted successfully, those with fffb failed. Do you know
>>>> where the mask is found and how to change it?
>>>>
>>>> I also remove the second phy slave from the device tree.
>>>>>
>>>>
>>>> That seems like a great idea, if only to stop all the useless messages
>>>> about it never being found. Can that be done in the uEnv.txt, like when you
>>>> disable HDMI, or do you have to rebuild the device tree binary? Would
>>>> setting the phymask to  accomplish the same thing?
>>>>
>>>> Loren
>>>>
>>> --
>> 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+unsubscr...@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+unsubscr...@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 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[John Syn]

From:  Andrew Glen 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Monday, November 3, 2014 at 11:36 PM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected
on Boot.

> 
> Yes, and reading the thread even more fully you'll find my report of running
> thousands of automated test restarts with these parts removed, with a 100%
> success rate.
> 
> We use these boards a lot, running 24-7 in this configuration, and have had
> zero hardware faults. With any luck we have nearly exhausted Murphy's law with
> our software.

Hi Andrew,

I accept that you have done these tests, but removing test two capacitors
from the reset line means the device will come out of reset before the power
supply has stabilized and without a capacitor, the reset switch will bounce
several times. That is not a good idea. Perhaps you are just lucky given
your setup, but removing C24 and C30 is a bad idea. Making these capacitors
smaller may fix your problem but I suggest that you do have something there
to delay the reset line.

Regards,
John
> Andrew.
> 
> On 4/11/2014 7:26 PM, "John Syn"  wrote:
>> 
>> From:  Andrew Glen 
>> Reply-To:  "beagleboard@googlegroups.com" 
>> Date:  Monday, November 3, 2014 at 9:42 PM
>> To:  "beagleboard@googlegroups.com" 
>> Subject:  Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on
>> Boot.
>> 
>>> 
>>> As far as I know, and as already documented in this thread, the only
>>> reliable fix is to remove C24 and C30.
>> 
>> If you read the full thread, Gerald say that if you remove these capacitors,
>> the board may not start at all.
>> 
>> Regards,
>> John
>>> On 4/11/2014 5:40 PM, "Jerin George"  wrote:
>>>> Hi, 
>>>> I am using a BBB Rev C with latest Angstrom image  and i have seen this
>>>> issue with eth not getting detected at boot up. This came at the last
>>>> stages of my project delivery. How can this be corrected. Does moving to
>>>> the latest debian image solves this issue ?
>>>> 
>>>> regards, 
>>>> Jerin George
>>>> 
>>>> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com  wrote:
>>>>> 
>>>>> They phymask comes from a hardware register read by the davinci_mdio
>>>>> driver, which gets passed to the linux phy libraries. The problem is that
>>>>> the cpsw driver gets the value from device tree, which is hardcoded to
>>>>> address 0. Usually the values are the same (address 0), but sometimes the
>>>>> phy gets registered to a different address, usually in my case address 2.
>>>>> You calculate the address using the phymask. If you changed the phymask
>>>>> than, you pointing back to address 0, so that wouldn't help you.
>>>>> 
>>>>> I rebuilt the dtb file.
>>>>> 
>>>>> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote:
>>>>>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:
>>>>>>> The davinci mdio driver should report a phymask and that value is used
>>>>>>> to update the device tree.
>>>>>> 
>>>>>> Back when I had this problem I tried hard to find out where the phymask
>>>>>> comes from, and never succeeded. At that time people who received a
>>>>>> phymask of fffe booted successfully, those with fffb failed. Do
>>>>>> you know where the mask is found and how to change it?
>>>>>> 
>>>>>>> I also remove the second phy slave from the device tree.
>>>>>> 
>>>>>> That seems like a great idea, if only to stop all the useless messages
>>>>>> about it never being found. Can that be done in the uEnv.txt, like when
>>>>>> you disable HDMI, or do you have to rebuild the device tree binary? Would
>>>>>> setting the phymask to  accomplish the same thing?
>>>>>> 
>>>>>> Loren 
>>>> -- 
>>>> 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 

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

[Jerin George]

HI Andrew & John, 

Thank you for your reply. I guess that leaves me with no choice but to 
tweak the hardware & also update the kernel to the latest version by 
Robert. 
Hopefully that will fix the issue for ever. 
I will keep you posted on the status. 

regards, 
Jerin

On Wednesday, 5 November 2014 01:23:28 UTC+5:30, john3909 wrote:
>
>
> From: Andrew Glen >
> Reply-To: "beagl...@googlegroups.com " <
> beagl...@googlegroups.com >
> Date: Monday, November 3, 2014 at 11:36 PM
> To: "beagl...@googlegroups.com "  >
> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected 
> on Boot.
>
> Yes, and reading the thread even more fully you'll find my report of 
> running thousands of automated test restarts with these parts removed, with 
> a 100% success rate.
>
> We use these boards a lot, running 24-7 in this configuration, and have 
> had zero hardware faults. With any luck we have nearly exhausted Murphy's 
> law with our software.
>
> Hi Andrew,
>
> I accept that you have done these tests, but removing test two capacitors 
> from the reset line means the device will come out of reset before the 
> power supply has stabilized and without a capacitor, the reset switch will 
> bounce several times. That is not a good idea. Perhaps you are just lucky 
> given your setup, but removing C24 and C30 is a bad idea. Making these 
> capacitors smaller may fix your problem but I suggest that you do have 
> something there to delay the reset line. 
>
> Regards,
> John
>
> Andrew.
> On 4/11/2014 7:26 PM, "John Syn" > wrote:
>
>>
>> From: Andrew Glen >
>> Reply-To: "beagl...@googlegroups.com " <
>> beagl...@googlegroups.com >
>> Date: Monday, November 3, 2014 at 9:42 PM
>> To: "beagl...@googlegroups.com " > >
>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not 
>> Detected on Boot.
>>
>> As far as I know, and as already documented in this thread, the only 
>> reliable fix is to remove C24 and C30.
>>
>> If you read the full thread, Gerald say that if you remove these 
>> capacitors, the board may not start at all.
>>
>> Regards,
>> John
>>
>> On 4/11/2014 5:40 PM, "Jerin George" > 
>> wrote:
>>
>>> Hi, 
>>> I am using a BBB Rev C with latest Angstrom image  and i have seen this 
>>> issue with eth not getting detected at boot up. This came at the last 
>>> stages of my project delivery. How can this be corrected. Does moving to 
>>> the latest debian image solves this issue ?
>>>
>>> regards, 
>>> Jerin George
>>>
>>> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote:
>>>>
>>>>
>>>> They phymask comes from a hardware register read by the davinci_mdio 
>>>> driver, which gets passed to the linux phy libraries. The problem is that 
>>>> the cpsw driver gets the value from device tree, which is hardcoded to 
>>>> address 0. Usually the values are the same (address 0), but sometimes the 
>>>> phy gets registered to a different address, usually in my case address 2. 
>>>> You calculate the address using the phymask. If you changed the phymask 
>>>> than, you pointing back to address 0, so that wouldn't help you.
>>>>
>>>> I rebuilt the dtb file.
>>>>
>>>> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote:
>>>>>
>>>>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:
>>>>>>
>>>>>> The davinci mdio driver should report a phymask and that value is 
>>>>>> used to update the device tree.
>>>>>>
>>>>>
>>>>> Back when I had this problem I tried hard to find out where the 
>>>>> phymask comes from, and never succeeded. At that time people who received 
>>>>> a 
>>>>> phymask of fffe booted successfully, those with fffb failed. Do 
>>>>> you 
>>>>> know where the mask is found and how to change it? 
>>>>>
>>>>> I also remove the second phy slave from the device tree.
>>>>>>
>>>>>
>>>>> That seems like a great idea, if only to stop all the useless messages 
>>>>> about it never being found. Can that be done in the uEnv.txt, like when 
>>>>> you 
>>>>> disable HDMI, or do you have to rebuild the device tree binary? Would 
>>>

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

[rathod . pratik12]

Hello,

I am also experiencing the same issue here of etherenet not working on some 
boot-ups.
I am using A6C board. My other problem is it is my requirement to use 
Android on beaglebone black only from internal storage i.e. eMMC. To 
support all necessary functionality of Android 4.2.2, I have to use 3.2.0 
kernel and U-Boot 2013.01.01. I think latest (3.8 or any other) kernels are 
not supported for android to boot from eMMC.

When etherenet is not working on boot, I see this logs,
U-boot:
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:not set. Validating first E-fuse MAC
PHY reset timed out
cpsw
Hit any key to stop autoboot:  0

And, in kernel logs, I find these logs,
<4>[1.307249]  davinci-mcasp.0: alias fck already exists
<6>[1.790881] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
<6>[1.797342] davinci_mdio davinci_mdio.0: detected phy mask fffb
<6>[1.804569] davinci_mdio.0: probed
<6>[1.808128] davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver 
SMSC LAN8710/LAN8720
..
<3>[   22.106395] PHY 0:00 not found
<3>[   22.109607] PHY 0:01 not found
<6>[   22.122567] ADDRCONF(NETDEV_UP): eth0: link is not ready

Is it possible to apply software fixes in kernel 3.2.0 ? Can you provide me 
what changes are required to resolve this issue?

Also, I found this on "Known_Issues"  of beaglebone black
-8<-8<-8<-8<-8<-8<-8<
Ethernet PHY Default Configuration [A3,A4,A5,A6]

The mode pin setting for mode bit 2 connects to the wrong pin on the 
LAN8710. It goes to pin 15 and should go to pin 14 instead. This should not 
cause any operational issues as the internal registers are set correctly in 
Uboot by the default SW that is provided. If you are not using UBoot or 
have a custom UBoot, you will need to set the register inside the LAN8710 
for proper operation. There is a preepmtion issue in SW that is currently 
being worked. There was a theory that this error was causing the issue. As 
long as you set the correct values in your initialzation code, this will 
not cause this issue and as the default UBoot correctly sets the register 
correctly for *all modes and auto negotiate enabled* which is what the 
default mode was intended to be.
-8<-8<-8<-8<-8<-8<-8<

Is this the same issue we are refering to?
I am using custom u-boot. What are the changes inside u-boot required to 
fix it ?


Thank you for your time.

Regards,
Pratik

On Friday, 18 July 2014 16:56:21 UTC+5:30, RobertCNelson wrote:
>
> On Fri, Jul 18, 2014 at 5:42 AM, krd > 
> wrote: 
> > 
> > 
> > On Monday, July 7, 2014 5:17:12 PM UTC+2, RobertCNelson wrote: 
> >> 
> >> On Mon, Jul 7, 2014 at 2:52 AM, Micka  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? 
> >> 
> >> Regards, 
> >> 
> >> -- 
> >> Robert Nelson 
> >> http://www.rcn-ee.com/ 
> > 
> > 
> > 
> > I am using 3.15.0-rc8-bone1 kernel and I am experiencing the same 
> problem 
> > with loosing eth occasionally. For some reasons I don't want to use 
> 3.8.* 
> > kernels. Can you recommend me some of these new kernel that do not 
> replicate 
> > the issue? I am thinking of giving a try to the latest 3.16-rc5... 
>
> Well, I added that patch in "3.15.4-bone4" so "3.15.0-rc8-bone1" 
> doesn't include it.  The latest from that branch is "3.15.6-bone5" 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.rcn-ee.com/ 
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[alexschneider250]

Hello,

This Ethernet trouble also happens with my BeagleBone Black boards, quite 
frequently on Rev C (PCB Rev B6), and very rarely on Rev A6 (PCB Rev B5). I 
tried various Linux kernels, including the latest one from here 
<https://eewiki.net/display/linuxonarm/BeagleBone+Black> (3.8.13-bone67), 
however that keeps happening anyway.

I read section 3.7 of the LAN8710A data sheet 
<http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf> (Configuration 
Straps) and I agree with Loren Amelang: the trouble may be really caused by 
incorrect strap values, which depend on voltage levels at the respective 
LAN8710A pins during reset.

That assumption is backed by the observation that, whenever the "eth0: link 
not ready" thing happens, either both LEDs of the Ethernet Connector are 
off or only the yellow one (LED2) is off (and the green one is not blinking 
in both cases). Since these LEDs reflect the transceiver mode of operation, 
which is controlled by MODE[2:0] configuration straps, their strange 
behavior may indicate some wrong bit values loaded to MODE[2:0]. They are 
loaded when nRST pin is deasserted, and the timing is critical, according 
to subsection 5.5.3 of that data sheet (Power-On nRST & Configuration Strap 
Timing).

Also, according to the subsection mentioned above, the time interval 
between when external power supplies reach 80% and nRST pin is deasserted 
must be no less than 25 ms. Without the capacitor C24 on the board, that 
time is around 20 ms, I measured that. So, removing C24 does not seem to be 
safe.

Alex



On Wednesday, November 5, 2014 7:03:21 AM UTC+1, Jerin George wrote:
>
> HI Andrew & John, 
>
> Thank you for your reply. I guess that leaves me with no choice but to 
> tweak the hardware & also update the kernel to the latest version by 
> Robert. 
> Hopefully that will fix the issue for ever. 
> I will keep you posted on the status. 
>
> regards, 
> Jerin
>
> On Wednesday, 5 November 2014 01:23:28 UTC+5:30, john3909 wrote:
>>
>>
>> From: Andrew Glen 
>> Reply-To: "beagl...@googlegroups.com" 
>> Date: Monday, November 3, 2014 at 11:36 PM
>> To: "beagl...@googlegroups.com" 
>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not 
>> Detected on Boot.
>>
>> Yes, and reading the thread even more fully you'll find my report of 
>> running thousands of automated test restarts with these parts removed, with 
>> a 100% success rate.
>>
>> We use these boards a lot, running 24-7 in this configuration, and have 
>> had zero hardware faults. With any luck we have nearly exhausted Murphy's 
>> law with our software.
>>
>> Hi Andrew,
>>
>> I accept that you have done these tests, but removing test two capacitors 
>> from the reset line means the device will come out of reset before the 
>> power supply has stabilized and without a capacitor, the reset switch will 
>> bounce several times. That is not a good idea. Perhaps you are just lucky 
>> given your setup, but removing C24 and C30 is a bad idea. Making these 
>> capacitors smaller may fix your problem but I suggest that you do have 
>> something there to delay the reset line. 
>>
>> Regards,
>> John
>>
>> Andrew.
>> On 4/11/2014 7:26 PM, "John Syn"  wrote:
>>
>>>
>>> From: Andrew Glen 
>>> Reply-To: "beagl...@googlegroups.com" 
>>> Date: Monday, November 3, 2014 at 9:42 PM
>>> To: "beagl...@googlegroups.com" 
>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not 
>>> Detected on Boot.
>>>
>>> As far as I know, and as already documented in this thread, the only 
>>> reliable fix is to remove C24 and C30.
>>>
>>> If you read the full thread, Gerald say that if you remove these 
>>> capacitors, the board may not start at all.
>>>
>>> Regards,
>>> John
>>>
>>> On 4/11/2014 5:40 PM, "Jerin George"  wrote:
>>>
>>>> Hi, 
>>>> I am using a BBB Rev C with latest Angstrom image  and i have seen this 
>>>> issue with eth not getting detected at boot up. This came at the last 
>>>> stages of my project delivery. How can this be corrected. Does moving to 
>>>> the latest debian image solves this issue ?
>>>>
>>>> regards, 
>>>> Jerin George
>>>>
>>>> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote:
>>>>>
>>>>>
>>>>> They phymask comes from a hardware register read by the davinci_mdio 
>>>>> driver, which gets 

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

[Gerald Coley]

If you have what you think are he correct trappings, let me know. They are
the same for all revisions.

Also, if you reset the board after it is up, the strappings are overridden
by the states on those pins from the processor that override the strapping
options.

Gerald


On Thu, Nov 20, 2014 at 12:39 PM,  wrote:

>
> Hello,
>
> This Ethernet trouble also happens with my BeagleBone Black boards, quite
> frequently on Rev C (PCB Rev B6), and very rarely on Rev A6 (PCB Rev B5). I
> tried various Linux kernels, including the latest one from here
> <https://eewiki.net/display/linuxonarm/BeagleBone+Black> (3.8.13-bone67),
> however that keeps happening anyway.
>
> I read section 3.7 of the LAN8710A data sheet
> <http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf>
> (Configuration Straps) and I agree with Loren Amelang: the trouble may be
> really caused by incorrect strap values, which depend on voltage levels at
> the respective LAN8710A pins during reset.
>
> That assumption is backed by the observation that, whenever the "eth0:
> link not ready" thing happens, either both LEDs of the Ethernet Connector
> are off or only the yellow one (LED2) is off (and the green one is not
> blinking in both cases). Since these LEDs reflect the transceiver mode of
> operation, which is controlled by MODE[2:0] configuration straps, their
> strange behavior may indicate some wrong bit values loaded to MODE[2:0].
> They are loaded when nRST pin is deasserted, and the timing is critical,
> according to subsection 5.5.3 of that data sheet (Power-On nRST &
> Configuration Strap Timing).
>
> Also, according to the subsection mentioned above, the time interval
> between when external power supplies reach 80% and nRST pin is deasserted
> must be no less than 25 ms. Without the capacitor C24 on the board, that
> time is around 20 ms, I measured that. So, removing C24 does not seem to be
> safe.
>
> Alex
>
>
>
>
> On Wednesday, November 5, 2014 7:03:21 AM UTC+1, Jerin George wrote:
>>
>> HI Andrew & John,
>>
>> Thank you for your reply. I guess that leaves me with no choice but to
>> tweak the hardware & also update the kernel to the latest version by
>> Robert.
>> Hopefully that will fix the issue for ever.
>> I will keep you posted on the status.
>>
>> regards,
>> Jerin
>>
>> On Wednesday, 5 November 2014 01:23:28 UTC+5:30, john3909 wrote:
>>>
>>>
>>> From: Andrew Glen 
>>> Reply-To: "beagl...@googlegroups.com" 
>>> Date: Monday, November 3, 2014 at 11:36 PM
>>> To: "beagl...@googlegroups.com" 
>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>>> Detected on Boot.
>>>
>>> Yes, and reading the thread even more fully you'll find my report of
>>> running thousands of automated test restarts with these parts removed, with
>>> a 100% success rate.
>>>
>>> We use these boards a lot, running 24-7 in this configuration, and have
>>> had zero hardware faults. With any luck we have nearly exhausted Murphy's
>>> law with our software.
>>>
>>> Hi Andrew,
>>>
>>> I accept that you have done these tests, but removing test two
>>> capacitors from the reset line means the device will come out of reset
>>> before the power supply has stabilized and without a capacitor, the reset
>>> switch will bounce several times. That is not a good idea. Perhaps you are
>>> just lucky given your setup, but removing C24 and C30 is a bad idea. Making
>>> these capacitors smaller may fix your problem but I suggest that you do
>>> have something there to delay the reset line.
>>>
>>> Regards,
>>> John
>>>
>>> Andrew.
>>> On 4/11/2014 7:26 PM, "John Syn"  wrote:
>>>
>>>>
>>>> From: Andrew Glen 
>>>> Reply-To: "beagl...@googlegroups.com" 
>>>> Date: Monday, November 3, 2014 at 9:42 PM
>>>> To: "beagl...@googlegroups.com" 
>>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>>>> Detected on Boot.
>>>>
>>>> As far as I know, and as already documented in this thread, the only
>>>> reliable fix is to remove C24 and C30.
>>>>
>>>> If you read the full thread, Gerald say that if you remove these
>>>> capacitors, the board may not start at all.
>>>>
>>>> Regards,
>>>> John
>>>>
>>>> On 4/11/2014 5:40 PM, "Jerin George"  wrote:
>>>&

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

[alexschneider250]

Hi Gerald,

I meant "strap values", not connections on the board. As far as I 
understand it, correct strappings alone cannot always ensure correct bits 
in the respective registers of the transceiver chip. The power-on and reset 
timing is also important, and this timing, unlike strappings, is different 
at least for some revisions. 

In my experiments, a reset performed with RESET button never resolved the 
"phy not found" problem. A power-on reset as well as a reset with POWER 
button helped, but not always. Cannot the transceiver sometimes enter into 
some unresponsive state, which makes it impossible for the processor to 
override the strappings?

Alex

On Thursday, November 20, 2014 9:50:56 PM UTC+1, Gerald wrote:
>
> If you have what you think are he correct trappings, let me know. They are 
> the same for all revisions.
>
> Also, if you reset the board after it is up, the strappings are overridden 
> by the states on those pins from the processor that override the strapping 
> options.
>
> Gerald
>
>
> On Thu, Nov 20, 2014 at 12:39 PM, > 
> wrote:
>
>>
>> Hello,
>>
>> This Ethernet trouble also happens with my BeagleBone Black boards, quite 
>> frequently on Rev C (PCB Rev B6), and very rarely on Rev A6 (PCB Rev B5). I 
>> tried various Linux kernels, including the latest one from here 
>> <https://eewiki.net/display/linuxonarm/BeagleBone+Black> 
>> (3.8.13-bone67), however that keeps happening anyway.
>>
>> I read section 3.7 of the LAN8710A data sheet 
>> <http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf> 
>> (Configuration Straps) and I agree with Loren Amelang: the trouble may be 
>> really caused by incorrect strap values, which depend on voltage levels at 
>> the respective LAN8710A pins during reset.
>>
>> That assumption is backed by the observation that, whenever the "eth0: 
>> link not ready" thing happens, either both LEDs of the Ethernet Connector 
>> are off or only the yellow one (LED2) is off (and the green one is not 
>> blinking in both cases). Since these LEDs reflect the transceiver mode of 
>> operation, which is controlled by MODE[2:0] configuration straps, their 
>> strange behavior may indicate some wrong bit values loaded to MODE[2:0]. 
>> They are loaded when nRST pin is deasserted, and the timing is critical, 
>> according to subsection 5.5.3 of that data sheet (Power-On nRST & 
>> Configuration Strap Timing).
>>
>> Also, according to the subsection mentioned above, the time interval 
>> between when external power supplies reach 80% and nRST pin is deasserted 
>> must be no less than 25 ms. Without the capacitor C24 on the board, that 
>> time is around 20 ms, I measured that. So, removing C24 does not seem to be 
>> safe.
>>
>> Alex
>>
>>
>>
>>
>> On Wednesday, November 5, 2014 7:03:21 AM UTC+1, Jerin George wrote:
>>>
>>> HI Andrew & John, 
>>>
>>> Thank you for your reply. I guess that leaves me with no choice but to 
>>> tweak the hardware & also update the kernel to the latest version by 
>>> Robert. 
>>> Hopefully that will fix the issue for ever. 
>>> I will keep you posted on the status. 
>>>
>>> regards, 
>>> Jerin
>>>
>>> On Wednesday, 5 November 2014 01:23:28 UTC+5:30, john3909 wrote:
>>>>
>>>>
>>>> From: Andrew Glen 
>>>> Reply-To: "beagl...@googlegroups.com" 
>>>> Date: Monday, November 3, 2014 at 11:36 PM
>>>> To: "beagl...@googlegroups.com" 
>>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not 
>>>> Detected on Boot.
>>>>
>>>> Yes, and reading the thread even more fully you'll find my report of 
>>>> running thousands of automated test restarts with these parts removed, 
>>>> with 
>>>> a 100% success rate.
>>>>
>>>> We use these boards a lot, running 24-7 in this configuration, and have 
>>>> had zero hardware faults. With any luck we have nearly exhausted Murphy's 
>>>> law with our software.
>>>>
>>>> Hi Andrew,
>>>>
>>>> I accept that you have done these tests, but removing test two 
>>>> capacitors from the reset line means the device will come out of reset 
>>>> before the power supply has stabilized and without a capacitor, the reset 
>>>> switch will bounce several times. That is not a good idea. Perhaps you are 
>>>> just lucky given your setup, but removing C24 and C

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

[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 fffe*
*[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 -01*
*[3.822046]   b302 1799280 mmcblk0p2 -02*
*[3.827617] b3101024 mmcblk0boot1  (driver?)*
*[3.833197] b3081024 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] [] (unwind_backtrace) from []
(show_stack+0xb/0xc)*
*[3.862356] [] (show_stack) from []
(panic+0x65/0x170)*
*[3.869572] [] (panic) from []
(mount_block_root+0x1af/0x21c)*
*[3.877421] [] (mount_block_root) from []
(prepare_namespace+0xe9/0x128)*
*[3.886271] [] (prepare_namespace) from []
(kernel_init_freeable+0x1ab/0x1b8)*
*[3.895574] [] (kernel_init_freeable) from []
(kernel_init+0xb/0xb4)*
*[3.904060] [] (kernel_init) from []
(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 <
cmidr...@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 
>  #include 
>  #include 
> +#include 
>
>  /*
>   * This timeout definition is a worst-case ultra defensive measure against
> @@ -97,6 +98,10 @@ struct davinci_mdio_data {
>  unsigned longaccess_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_pro

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

[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

From:  Vishnu Patekar 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Saturday, July 5, 2014 at 11:01 AM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected
on Boot.

> 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 fffe
> [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 -01
> [3.822046]   b302 1799280 mmcblk0p2 -02
> [3.827617] b3101024 mmcblk0boot1  (driver?)
> [3.833197] b3081024 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] [] (unwind_backtrace) from []
> (show_stack+0xb/0xc)
> [3.862356] [] (show_stack) from [] (panic+0x65/0x170)
> [3.869572] [] (panic) from []
> (mount_block_root+0x1af/0x21c)
> [3.877421] [] (mount_block_root) from []
> (prepare_namespace+0xe9/0x128)
> [3.886271] [] (prepare_namespace) from []
> (kernel_init_freeable+0x1ab/0x1b8)
> [3.895574] [] (kernel_init_freeable) from []
> (kernel_init+0xb/0xb4)
> [3.904060] [] (kernel_init) from []
> (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
>  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 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /*
>>   * This timeout definition is a worst-case ultra defensive measure against
>> @@ -97,6 +98,10 @@ struct davinci_mdio_data {
>>  unsigned longaccess_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

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

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




On Sat, Jul 5, 2014 at 8:19 PM, John Syn  wrote:

> 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
>
> From: Vishnu Patekar 
> Reply-To: "beagleboard@googlegroups.com" 
> Date: Saturday, July 5, 2014 at 11:01 AM
> To: "beagleboard@googlegroups.com" 
> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected
> on Boot.
>
> 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 fffe*
> *[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 -01*
> *[3.822046]   b302 1799280 mmcblk0p2 -02*
> *[3.827617] b3101024 mmcblk0boot1  (driver?)*
> *[3.833197] b3081024 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] [] (unwind_backtrace) from []
> (show_stack+0xb/0xc)*
> *[3.862356] [] (show_stack) from []
> (panic+0x65/0x170)*
> *[3.869572] [] (panic) from []
> (mount_block_root+0x1af/0x21c)*
> *[3.877421] [] (mount_block_root) from []
> (prepare_namespace+0xe9/0x128)*
> *[3.886271] [] (prepare_namespace) from []
> (kernel_init_freeable+0x1ab/0x1b8)*
> *[3.895574] [] (kernel_init_freeable) from []
> (kernel_init+0xb/0xb4)*
> *[3.904060] [] (kernel_init) from []
> (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 <
> cmidr...@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 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /*
>>   * This timeout definition is a worst-case ultra defensive measure
>> against
>> @@ -97,6 +98,10 @@ struct davinci_mdio_data {
>>  unsigned longaccess_time; /* jiffies */
>>  };
>>
>> +#if IS_ENABLED(CONFIG_OF)
>> +static void davinci_mdio_upda

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

[Micka]

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


On Mon, Jul 7, 2014 at 9:52 AM, Micka  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 .
>
>
>
>
> On Sat, Jul 5, 2014 at 8:19 PM, John Syn  wrote:
>
>> 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
>>
>> From: Vishnu Patekar 
>> Reply-To: "beagleboard@googlegroups.com" 
>> Date: Saturday, July 5, 2014 at 11:01 AM
>> To: "beagleboard@googlegroups.com" 
>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>> Detected on Boot.
>>
>> 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 fffe*
>> *[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 -01*
>> *[3.822046]   b302 1799280 mmcblk0p2 -02*
>> *[3.827617] b3101024 mmcblk0boot1  (driver?)*
>> *[3.833197] b3081024 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] [] (unwind_backtrace) from []
>> (show_stack+0xb/0xc)*
>> *[3.862356] [] (show_stack) from []
>> (panic+0x65/0x170)*
>> *[3.869572] [] (panic) from []
>> (mount_block_root+0x1af/0x21c)*
>> *[3.877421] [] (mount_block_root) from []
>> (prepare_namespace+0xe9/0x128)*
>> *[3.886271] [] (prepare_namespace) from []
>> (kernel_init_freeable+0x1ab/0x1b8)*
>> *[3.895574] [] (kernel_init_freeable) from []
>> (kernel_init+0xb/0xb4)*
>> *[3.904060] [] (kernel_init) from []
>> (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 <
>> cmidr...@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..e5a9c

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

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


On Mon, Jul 7, 2014 at 12:56 AM, Micka  wrote:

> I would like to know what this means ? Is it a electrical problems ? Can
> we monitor this ?
>
>
> On Mon, Jul 7, 2014 at 9:52 AM, Micka  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 .
>>
>>
>>
>>
>> On Sat, Jul 5, 2014 at 8:19 PM, John Syn  wrote:
>>
>>> 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
>>>
>>> From: Vishnu Patekar 
>>> Reply-To: "beagleboard@googlegroups.com" 
>>> Date: Saturday, July 5, 2014 at 11:01 AM
>>> To: "beagleboard@googlegroups.com" 
>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>>> Detected on Boot.
>>>
>>> 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 fffe*
>>> *[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 -01*
>>> *[3.822046]   b302 1799280 mmcblk0p2 -02*
>>> *[3.827617] b3101024 mmcblk0boot1  (driver?)*
>>> *[3.833197] b3081024 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] [] (unwind_backtrace) from []
>>> (show_stack+0xb/0xc)*
>>> *[3.862356] [] (show_stack) from []
>>> (panic+0x65/0x170)*
>>> *[3.869572] [] (panic) from []
>>> (mount_block_root+0x1af/0x21c)*
>>> *[3.877421] [] (mount_block_root) from []
>>> (prepare_namespace+0xe9/0x128)*
>>> *[3.886

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

[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
Le 7 juil. 2014 10:41, "William Hermans"  a écrit :

> *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 ?
>
>
> On Mon, Jul 7, 2014 at 12:56 AM, Micka  wrote:
>
>> I would like to know what this means ? Is it a electrical problems ? Can
>> we monitor this ?
>>
>>
>> On Mon, Jul 7, 2014 at 9:52 AM, Micka  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 .
>>>
>>>
>>>
>>>
>>> On Sat, Jul 5, 2014 at 8:19 PM, John Syn  wrote:
>>>
>>>> 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
>>>>
>>>> From: Vishnu Patekar 
>>>> Reply-To: "beagleboard@googlegroups.com" 
>>>> Date: Saturday, July 5, 2014 at 11:01 AM
>>>> To: "beagleboard@googlegroups.com" 
>>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>>>> Detected on Boot.
>>>>
>>>> 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 fffe*
>>>> *[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 -01*
>>>> *[3.822046]   b302 1799280 mmcblk0p2 -02*
>>>> *[3.827617] b3101024 mmcblk0boot1  (driver?)*
>>>> *[3.833197] b3081024 mmcblk0boot0  (driver?)*
>>>> *[3.838767] Kernel pani

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

[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...
Le 7 juil. 2014 10:49, "Micka"  a écrit :

> 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
> Le 7 juil. 2014 10:41, "William Hermans"  a écrit :
>
>> *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 ?
>>
>>
>> On Mon, Jul 7, 2014 at 12:56 AM, Micka  wrote:
>>
>>> I would like to know what this means ? Is it a electrical problems ? Can
>>> we monitor this ?
>>>
>>>
>>> On Mon, Jul 7, 2014 at 9:52 AM, Micka  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 .
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Jul 5, 2014 at 8:19 PM, John Syn  wrote:
>>>>
>>>>> 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
>>>>>
>>>>> From: Vishnu Patekar 
>>>>> Reply-To: "beagleboard@googlegroups.com" >>>> >
>>>>> Date: Saturday, July 5, 2014 at 11:01 AM
>>>>> To: "beagleboard@googlegroups.com" 
>>>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>>>>> Detected on Boot.
>>>>>
>>>>> 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 fffe*
>>>>> *[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

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

[Robert Nelson]

On Mon, Jul 7, 2014 at 2:52 AM, Micka  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?

Regards,

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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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



On Sat, Jul 5, 2014 at 11:49 PM, John Syn  wrote:

> 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
>
> From: Vishnu Patekar 
> Reply-To: "beagleboard@googlegroups.com" 
> Date: Saturday, July 5, 2014 at 11:01 AM
> To: "beagleboard@googlegroups.com" 
> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected
> on Boot.
>
> 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 fffe*
> *[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 -01*
> *[3.822046]   b302 1799280 mmcblk0p2 -02*
> *[3.827617] b3101024 mmcblk0boot1  (driver?)*
> *[3.833197] b3081024 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] [] (unwind_backtrace) from []
> (show_stack+0xb/0xc)*
> *[3.862356] [] (show_stack) from []
> (panic+0x65/0x170)*
> *[3.869572] [] (panic) from []
> (mount_block_root+0x1af/0x21c)*
> *[3.877421] [] (mount_block_root) from []
> (prepare_namespace+0xe9/0x128)*
> *[3.886271] [] (prepare_namespace) from []
> (kernel_init_freeable+0x1ab/0x1b8)*
> *[3.895574] [] (kernel_init_freeable) from []
> (kernel_init+0xb/0xb4)*
> *[3.904060] [] (kernel_init) from []
> (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 <
> cmidr...@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 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /*
>>   * This timeout definition is a worst-case ultra defensive measure
>> against
>> @@ -97,6 +98,10 @@ struct davinci_mdio_data {
>>  unsigned longaccess_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_tim

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

[John Syn]

From:  Vishnu Patekar 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Monday, July 7, 2014 at 9:26 AM
To:  "beagleboard@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

> 
> 
> 
> On Sat, Jul 5, 2014 at 11:49 PM, John Syn  wrote:
>> 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
>> 
>> From:  Vishnu Patekar 
>> Reply-To:  "beagleboard@googlegroups.com" 
>> Date:  Saturday, July 5, 2014 at 11:01 AM
>> To:  "beagleboard@googlegroups.com" 
>> Subject:  Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on
>> Boot.
>> 
>>> 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 fffe
>>> [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 -01
>>> [3.822046]   b302 1799280 mmcblk0p2 -02
>>> [3.827617] b3101024 mmcblk0boot1  (driver?)
>>> [3.833197] b3081024 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] [] (unwind_backtrace) from []
>>> (show_stack+0xb/0xc)
>>> [3.862356] [] (show_stack) from []
>>> (panic+0x65/0x170)
>>> [3.869572] [] (panic) from []
>>> (mount_block_root+0x1af/0x21c)
>>> [3.877421] [] (mount_block_root) from []
>>> (prepare_namespace+0xe9/0x128)
>>> [3.886271] [] (prepare_namespace) from []
>>> (kernel_init_freeable+0x1ab/0x1b8)
>>> [3.895574] [] (kernel_init_freeable) from []
>>> (kernel_init+0xb/0xb4)
>>> [3.904060] [] (kernel_init) from []
>>> (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
>>>  wrote:
>>>> I have encountered the same issue(s) on A6A boards.
>>>

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

[John Syn]

From:  Vishnu Patekar 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Monday, July 7, 2014 at 9:26 AM
To:  "beagleboard@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
> 
> 
> 
> On Sat, Jul 5, 2014 at 11:49 PM, John Syn  wrote:
>> 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
>> 
>> From:  Vishnu Patekar 
>> Reply-To:  "beagleboard@googlegroups.com" 
>> Date:  Saturday, July 5, 2014 at 11:01 AM
>> To:  "beagleboard@googlegroups.com" 
>> Subject:  Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on
>> Boot.
>> 
>>> 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 fffe
>>> [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 -01
>>> [3.822046]   b302 1799280 mmcblk0p2 -02
>>> [3.827617] b3101024 mmcblk0boot1  (driver?)
>>> [3.833197] b3081024 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] [] (unwind_backtrace) from []
>>> (show_stack+0xb/0xc)
>>> [3.862356] [] (show_stack) from []
>>> (panic+0x65/0x170)
>>> [3.869572] [] (panic) from []
>>> (mount_block_root+0x1af/0x21c)
>>> [3.877421] [] (mount_block_root) from []
>>> (prepare_namespace+0xe9/0x128)
>>> [3.886271] [] (prepare_namespace) from []
>>> (kernel_init_freeable+0x1ab/0x1b8)
>>> [3.895574] [] (kernel_init_freeable) from []
>>> (kernel_init+0xb/0xb4)
>>> [3.904060] [] (kernel_init) from []
>>> (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
>>>  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 w

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

[Micka]

For your informations :

We think that we found where this problems come from . Our power Cap takes
more time to provide the power that the Beagle need at the boot. We have to
modify our CAP : release later the RESET .

which is what you have done in the REV A6A :

3) Changed C24 to a 2.2uF capacitor. This extends the reset signal to solve
an issue where some boards would not boot on power up.

Micka,



On Mon, Jul 7, 2014 at 9:56 AM, Micka  wrote:

> I would like to know what this means ? Is it a electrical problems ? Can
> we monitor this ?
>
>
> On Mon, Jul 7, 2014 at 9:52 AM, Micka  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 .
>>
>>
>>
>>
>> On Sat, Jul 5, 2014 at 8:19 PM, John Syn  wrote:
>>
>>> 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
>>>
>>> From: Vishnu Patekar 
>>> Reply-To: "beagleboard@googlegroups.com" 
>>> Date: Saturday, July 5, 2014 at 11:01 AM
>>> To: "beagleboard@googlegroups.com" 
>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>>> Detected on Boot.
>>>
>>> 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 fffe*
>>> *[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 -01*
>>> *[3.822046]   b302 1799280 mmcblk0p2 -02*
>>> *[3.827617] b3101024 mmcblk0boot1  (driver?)*
>>> *[3.833197] b3081024 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] [] (unwind_backtrace) from []
>>> (show_stack+0xb/0xc)*
>>> *[3.862356] [] (show_stack) from []
>>> (panic+0x65/0x170)*
>>> *[3.869572] [] (panic) from []
>>> (mount_block_root+0x1af/0x21c)*
>>> *[3.877421] [] (mount_block_root) from []
>>> (prepare_namespace+0xe9/0x128)*
>>> *[3.886271] [] (prepare_namespace) from []
>>> (kernel_init_freeable+0x1ab/0x1b8)*
>>> *[3.895574] [] (kernel_init_freeable) from []
>>> (kernel_init+0xb/0xb4)*
>>> *[3.904060] [] (kernel_init) from []
>>> (ret_from_fork+0x11/0x38)*
>>> *[  

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

[Micka]

Also thx you Gerald, the bone60 deals better the problem at boot .



Micka,


On Wed, Jul 9, 2014 at 2:59 PM, Micka  wrote:

> For your informations :
>
> We think that we found where this problems come from . Our power Cap takes
> more time to provide the power that the Beagle need at the boot. We have to
> modify our CAP : release later the RESET .
>
> which is what you have done in the REV A6A :
>
> 3) Changed C24 to a 2.2uF capacitor. This extends the reset signal to
> solve an issue where some boards would not boot on power up.
>
> Micka,
>
>
>
> On Mon, Jul 7, 2014 at 9:56 AM, Micka  wrote:
>
>> I would like to know what this means ? Is it a electrical problems ? Can
>> we monitor this ?
>>
>>
>> On Mon, Jul 7, 2014 at 9:52 AM, Micka  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 .
>>>
>>>
>>>
>>>
>>> On Sat, Jul 5, 2014 at 8:19 PM, John Syn  wrote:
>>>
>>>> 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
>>>>
>>>> From: Vishnu Patekar 
>>>> Reply-To: "beagleboard@googlegroups.com" 
>>>> Date: Saturday, July 5, 2014 at 11:01 AM
>>>> To: "beagleboard@googlegroups.com" 
>>>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not
>>>> Detected on Boot.
>>>>
>>>> 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 fffe*
>>>> *[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 -01*
>>>> *[3.822046]   b302 1799280 mmcblk0p2 -02*
>>>> *[3.827617] b3101024 mmcblk0boot1  (driver?)*
>>>> *[3.833197] b3081024 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] [] (unwind_backtrace) from []
>>>> (show_stack+0xb/0xc)*
>>>> *[3.862356] [] (show_stack) from []
>>>> (panic+0x65/0

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

[krd]

On Monday, July 7, 2014 5:17:12 PM UTC+2, RobertCNelson wrote:
>
> On Mon, Jul 7, 2014 at 2:52 AM, Micka > 
> 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? 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.rcn-ee.com/ 
>


I am using 3.15.0-rc8-bone1 kernel and I am experiencing the same problem 
with loosing eth occasionally. For some reasons I don't want to use 3.8.* 
kernels. Can you recommend me some of these new kernel that do not 
replicate the issue? I am thinking of giving a try to the latest 3.16-rc5...

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Nelson]

On Fri, Jul 18, 2014 at 5:42 AM, krd  wrote:
>
>
> On Monday, July 7, 2014 5:17:12 PM UTC+2, RobertCNelson wrote:
>>
>> On Mon, Jul 7, 2014 at 2:52 AM, Micka  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?
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.rcn-ee.com/
>
>
>
> I am using 3.15.0-rc8-bone1 kernel and I am experiencing the same problem
> with loosing eth occasionally. For some reasons I don't want to use 3.8.*
> kernels. Can you recommend me some of these new kernel that do not replicate
> the issue? I am thinking of giving a try to the latest 3.16-rc5...

Well, I added that patch in "3.15.4-bone4" so "3.15.0-rc8-bone1"
doesn't include it.  The latest from that branch is "3.15.6-bone5"

Regards,

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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[krd]

On Friday, July 18, 2014 1:26:21 PM UTC+2, RobertCNelson wrote:
>
> On Fri, Jul 18, 2014 at 5:42 AM, krd > 
> wrote: 
> > 
> > 
> > On Monday, July 7, 2014 5:17:12 PM UTC+2, RobertCNelson wrote: 
> >> 
> >> On Mon, Jul 7, 2014 at 2:52 AM, Micka  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? 
> >> 
> >> Regards, 
> >> 
> >> -- 
> >> Robert Nelson 
> >> http://www.rcn-ee.com/ 
> > 
> > 
> > 
> > I am using 3.15.0-rc8-bone1 kernel and I am experiencing the same 
> problem 
> > with loosing eth occasionally. For some reasons I don't want to use 
> 3.8.* 
> > kernels. Can you recommend me some of these new kernel that do not 
> replicate 
> > the issue? I am thinking of giving a try to the latest 3.16-rc5... 
>
> Well, I added that patch in "3.15.4-bone4" so "3.15.0-rc8-bone1" 
> doesn't include it.  The latest from that branch is "3.15.6-bone5" 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.rcn-ee.com/ 
>


I updated my kernel to 3.15.6-bone5, just as you've said. But, as it seems, 
this does not fix the issue completely. What I'm observing is lack of 
ethernet connection after some boots. They characterise with initial 
hangup, I can see 'C' being put on the console until a watchdog located on 
cape connected to my BBB reboots the BBB. It happens on its own, without 
any extraordinary operation being run on this system. For example two times 
last night. I have to plug out and in the power cable to fix the issue, SW 
reboot doesn't help. Power is delivered to BBB via our cape. Another way to 
reproduce it is to plug out the sd card and wait for watchdog to reboot 
BBB. After that, 'C' are printed to the console(OS on eMMC is not 
bootable), and when I insert back the sd it instantly boots from it. No 
connection after that too. Do you have any ideas on what's going on and how 
to fix this?

Below I'm attaching the log from this:

Welcome to minicom 2.7

OPTIONS: I18n 
Compiled on Jan  1 2014, 17:13:19.
Port /dev/ttyUSB0, 14:22:11

Press CTRL-A Z for help on special keys

CCC
U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)

I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

Net:not set. Validating first E-fuse MAC
Could not get PHY for cpsw: addr 0
cpsw, usb_ether
Hit any key to stop autoboot:  0 
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
1696 bytes read in 6 ms (275.4 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc ...
using: am335x-boneblack.dtb...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
reading zImaget it. After that, 'C' are printed to the console(OS on eMMC 
is not bootable), and when i insert back the sd it instantly boots from it. 
No ethernet after that too. Below I'm attaching the log f
6224648 bytes read in 343 ms (17.3 MiB/s)
reading initrd.img
2957458 bytes read in 218 ms (12.9 MiB/s)
reading /dtbs/am335x-boneblack.dtb
31128 bytes read in 11 ms (2.7 MiB/s)
Kernel image @ 0x8200 [ 0x00 - 0x5efb08 ]
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Using Device Tree in place at 8800, end 8800a997

Starting kernel ...

[0.581100] omap_init_mbox: hwmod doesn't have valid attrs
[2.361161] ti_reset_probe: missing 'resets' child node.
[2.381165] pinctrl-single 44e10800.pinmux: pin 44e10950.0 already 
requested by 48024000.serial; cai
[2.393187] pinctrl-single 44e10800.pinmux: pin-84 (4803.spi) status 
-22
[2.400599] pinctrl-single 44e10800.pinmux: could not request pin 84 
(44e10950.0) from group pinmuxe
[2.413381] omap2_mcspi 4803.spi: Error applying setting, reverse 
things back
[2.542846] Error: Driver 'tfp410' is already registered, aborting...
[2.617805] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[2.624614] sr_init: platform driver register failed for SR
Loading, please wait...
modprobe: chdir(3.15.6-bone5): No such file or directory
modprobe: chdir(3.15.6-bone5): No such file or directory
modprob

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

[cmidroid]

When you see the repeating C's, I believe that is the ROM not finding 
u-boot. You have an issue with the mailbox drivers

I use the following mailbox values for my kernel config 

 CONFIG_MAILBOX=y # CONFIG_OMAP_MBOX is not set # CONFIG_OMAP2PLUS_MBOX 
is not set # CONFIG_OMAP_MBOX_KFIFO_SIZE is not set 
The davinci mdio driver should report a phymask and that value is used to 
update the device tree.

I load the following drivers in the following order.

libphy
smsc
davinci_cpdma
davinci_mdio
ti_cpsw

I also remove the second phy slave from the device tree.

I would verify your device tree blob has the correct values for your pin 
setup.

Regards

On Tuesday, July 22, 2014 9:34:27 AM UTC-4, krd wrote:
>
>
> On Friday, July 18, 2014 1:26:21 PM UTC+2, RobertCNelson wrote:
>>
>> On Fri, Jul 18, 2014 at 5:42 AM, krd  wrote: 
>> > 
>> > 
>> > On Monday, July 7, 2014 5:17:12 PM UTC+2, RobertCNelson wrote: 
>> >> 
>> >> On Mon, Jul 7, 2014 at 2:52 AM, Micka  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? 
>> >> 
>> >> Regards, 
>> >> 
>> >> -- 
>> >> Robert Nelson 
>> >> http://www.rcn-ee.com/ 
>> > 
>> > 
>> > 
>> > I am using 3.15.0-rc8-bone1 kernel and I am experiencing the same 
>> problem 
>> > with loosing eth occasionally. For some reasons I don't want to use 
>> 3.8.* 
>> > kernels. Can you recommend me some of these new kernel that do not 
>> replicate 
>> > the issue? I am thinking of giving a try to the latest 3.16-rc5... 
>>
>> Well, I added that patch in "3.15.4-bone4" so "3.15.0-rc8-bone1" 
>> doesn't include it.  The latest from that branch is "3.15.6-bone5" 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> http://www.rcn-ee.com/ 
>>
>
>
> I updated my kernel to 3.15.6-bone5, just as you've said. But, as it 
> seems, this does not fix the issue completely. What I'm observing is lack 
> of ethernet connection after some boots. They characterise with initial 
> hangup, I can see 'C' being put on the console until a watchdog located on 
> cape connected to my BBB reboots the BBB. It happens on its own, without 
> any extraordinary operation being run on this system. For example two times 
> last night. I have to plug out and in the power cable to fix the issue, SW 
> reboot doesn't help. Power is delivered to BBB via our cape. Another way to 
> reproduce it is to plug out the sd card and wait for watchdog to reboot 
> BBB. After that, 'C' are printed to the console(OS on eMMC is not 
> bootable), and when I insert back the sd it instantly boots from it. No 
> connection after that too. Do you have any ideas on what's going on and how 
> to fix this?
>
> Below I'm attaching the log from this:
>
> Welcome to minicom 2.7
>
> OPTIONS: I18n 
> Compiled on Jan  1 2014, 17:13:19.
> Port /dev/ttyUSB0, 14:22:11
>
> Press CTRL-A Z for help on special keys
>
> CCC
> U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
> reading args
> spl_load_image_fat_os: error reading image args, err - -1
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
>
> I2C:   ready
> DRAM:  512 MiB
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
>
> Net:not set. Validating first E-fuse MAC
> Could not get PHY for cpsw: addr 0
> cpsw, usb_ether
> Hit any key to stop autoboot:  0 
> gpio: pin 53 (gpio 53) value is 1
> mmc0 is current device
> gpio: pin 54 (gpio 54) value is 1
> SD/MMC found on device 0
> reading uEnv.txt
> 1696 bytes read in 6 ms (275.4 KiB/s)
> gpio: pin 55 (gpio 55) value is 1
> Loaded environment from uEnv.txt
> Importing environment from mmc ...
> using: am335x-boneblack.dtb...
> Checking if uenvcmd is set ...
> gpio: pin 56 (gpio 56) value is 1
> Running uenvcmd ...
> reading zImaget it. After that, 'C' are printed to the console(OS on eMMC 
> is not bootable), and when i insert back the sd it instantly boots from it. 
> No ethernet after that too. Below I'm attaching the log f
> 6224648 bytes read in 343 ms (17.3 MiB/s)
> reading initrd.img
> 2957458 bytes read in 218 ms (12.9 MiB/s)
> reading /dtbs/am335x-boneblack.dtb
> 31128 bytes read in 11 ms (2.7 MiB/s)
> Kernel image @ 0x8200 [ 0x00 - 0x5efb08 ]
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Using Device Tree in p

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

[Loren Amelang]

On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:
>
> The davinci mdio driver should report a phymask and that value is used to 
> update the device tree.
>

Back when I had this problem I tried hard to find out where the phymask 
comes from, and never succeeded. At that time people who received a phymask 
of fffe booted successfully, those with fffb failed. Do you know 
where the mask is found and how to change it? 

I also remove the second phy slave from the device tree.
>

That seems like a great idea, if only to stop all the useless messages 
about it never being found. Can that be done in the uEnv.txt, like when you 
disable HDMI, or do you have to rebuild the device tree binary? Would 
setting the phymask to  accomplish the same thing?

Loren 

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[cmidroid]

They phymask comes from a hardware register read by the davinci_mdio 
driver, which gets passed to the linux phy libraries. The problem is that 
the cpsw driver gets the value from device tree, which is hardcoded to 
address 0. Usually the values are the same (address 0), but sometimes the 
phy gets registered to a different address, usually in my case address 2. 
You calculate the address using the phymask. If you changed the phymask 
than, you pointing back to address 0, so that wouldn't help you.

I rebuilt the dtb file.

On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote:
>
> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote:
>>
>> The davinci mdio driver should report a phymask and that value is used to 
>> update the device tree.
>>
>
> Back when I had this problem I tried hard to find out where the phymask 
> comes from, and never succeeded. At that time people who received a phymask 
> of fffe booted successfully, those with fffb failed. Do you know 
> where the mask is found and how to change it? 
>
> I also remove the second phy slave from the device tree.
>>
>
> That seems like a great idea, if only to stop all the useless messages 
> about it never being found. Can that be done in the uEnv.txt, like when you 
> disable HDMI, or do you have to rebuild the device tree binary? Would 
> setting the phymask to  accomplish the same thing?
>
> Loren 
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sylvain Lamontagne]

Hi Josh,

After the investigations made by our engineers. It was proven that nothing
can be done as a software fix. The power management design of the
beaglebone black/green would need a rework for this to be fixed.

We ended up using another board that can cut the power to the BBG when the
problem is detected. It was easier for us as a workaround.

We did not investigate if the Octavio version (like the blue) had this
problem.

Sylvain Lamontagne

Le 8 avr. 2017 7:49 PM,  a écrit :

> 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 fffb" 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
>
>
> On Wednesday, October 26, 2016 at 12:24:42 PM UTC-4, slamontagne wrote:
>>
>> 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-2-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 fffb
>> Oct 25 00:13:13 beaglebone kernel: [3.021255] davinci_mdio: dt:
>> updated phy_id[2] from phy_mask[fffb]
>> 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 4a10.ethernet:
>> Detected MACID = 68:9e:19:98:ab:30
>> Oct 25 00:13:13 beaglebone kernel: [3.055733] cpsw 4a10.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 fffe
>> Oct 25 00:13:13 beaglebone kernel: [3.021252] davinci_mdio: dt:
>> updated phy_id[0] from phy_mask[fffe]
>> 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 4a10.ethernet:
>> Detected MACID = 68:9e:19:98:ab:30
>> Oct 25 00:13:13 beaglebone kernel: [3.055724] cpsw 4a10.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:0

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

[Matthijs van Duin]

On Tue, 5 Jun 2018 at 02:11,  wrote:

> I've come up with a software only workaround that can make sure a BBB will
> always come up with a working Ethernet port - although it can take a few
> minutes and require several automatic internal power cycles.
>
> You can read about it here...
>
>
> https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/
>

While neat, I should caution that going into RTC-only mode on an unmodified
BBB is rather hazardous. While most power rails shut down in this mode,
SYS_5V does not. This is a situation similar to powering the BBB via the
battery terminals, and will cause VDD_3V3B to fail to shut down (see [1]
for details). This creates a situation where the 3.3V supply of hardware
connected to the AM3358 (including various other chips on the BBB itself)
remains on, yet the 3.3V I/O supply (VDD_3V3A) of the AM3358 itself is shut
off. In this situation, if anything powered from VDD_3V3B drives a signal
high (for example the serial buffer if a serial console cable is attached),
this will result in serious violations of the Absolute Maximum Ratings (see
[2]).

My suggest would be to try using an external reset circuit that keeps
nRESET low for a while during power-up (maybe combined with increased
pull-up to make nRESET rise more cleanly when it is deasserted, despite the
obnoxiously large cap).

Matthijs

[1] https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/3vFMPydR20IJ
[2] https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/_oNSCta5WusJ

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAALWOA_NvQhBk3V8nNzn%2BHOkaHofZVYyWDzvn_Bh361UHAENgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.