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

[bko...@scanimetrics.com]

Does anyone happen to know if the 3.8 kernel compiled as per these instructions here http://eewiki.net/display/linuxonarm/BeagleBone+Black also contains the fix? I have a root file system already that I want to use but would like to update my kernel to fix this problem.

Thanks.

On Tuesday, March 11, 2014 5:50:48 PM UTC-6, Gerald wrote:

I know what I have seen. I know what I have replicated. And I know the SW fix takes care of it.

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

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

Gerald

On Tue, Mar 11, 2014 at 6:16 PM, Andrew Glen <andrewt...@gmail.com> wrote:

If anyone has any further information on the software fix/patch for
this issue I would be very interested in hearing about it (and
backporting into the kernel from late last year I am using) - or even
the best way to search for patches to particular files.

Regards,
Andrew.

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

> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[Robert Nelson]

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

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

Regards,

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

[David Lambert]

FWIW I have seen the "PHY problem" repeatedly using the 3.8 kernel, but
not yet with the RCN 3.13 kernel.


Regards,

Dave.

[Kees k]

I have seen this problem repeatedly by A6 revision hardware, but not with revision A5C hardware (I am running exactly the same software on both).

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

I tried the following:

-Use the kernel from the v3.8.13-bone40  image 

-Change some lines in davinci_mdio.c to hardcode the mask to 0 ("desperately scan all phys")

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

[Robert Nelson]

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

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

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

[c...@isbd.net]

Robert Nelson <robert...@gmail.com> wrote:
> On Thu, Mar 20, 2014 at 4:48 AM, Kees k <keeskwe...@gmail.com>
> wrote:
> > I have seen this problem repeatedly by A6 revision hardware, but not with
> > revision A5C hardware (I am running exactly the same software on both).
> >
> > Noteworthy is that the "PHY problem" only appears when powering the BBB via
> > the headers. Powering via USB does not give any problems.
>
> Well, if it works via USB, but not with the headers. (I didn't check
> if the Ethernet can be powered from the headers.)
>

I'm powering my BBB using P9 pins 1/2 for 0v and 5/6 for +5v, I'm
using the 'real' ethernet connection and it works fine. It has run
with no problems for at least 24 hours, staying connected (ssh) to my
desktop computer.

--
Chris Green
·

[Kees k]

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

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

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

[Gerald Coley]

Where are you looking exactly?

Gerald

[Kees k]

I measure 3.3V on P9.3. 

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

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

[Gerald Coley]

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

Gerald

[bko...@scanimetrics.com]

After upgrading to the new kernel I setup a script to constantly soft reboot a revision B beaglebone black and have not seen the ethernet lockup once after some 800 consecutive reboots. With the old kernel I did see the ethernet lockup after soft reboots on the same board.

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

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

[Kees k]

Haha, I was looking at the wrong file (BB white A6). Sorry for the trouble; it seems our cape causes this difference between A5C and A6.

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

Hello,

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

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

https://groups.google.com/forum/#!msg/beagleboard/Vp4pxwHm8BU/Iaw3p5xm0MoJ

https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI

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

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

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

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

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

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

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

Some additional observations from dmesg concerning this use:

On a good phy boot I see the following:

[    2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe

[    2.833517] libphy: 4a101000.mdio: probed
[    2.837871] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver unknown

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

On a 'bad phy' boot I see the following (differences highlighted):

[    2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    2.813213] davinci_mdio 4a101000.mdio: detected phy mask fffffffb

[    2.829512] libphy: 4a101000.mdio: probed
[    2.833875] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver unknown

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

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

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

Regards,

Andrew.

[Gerald Coley]

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

Thanks!

Gerald

[je...@longofest.net]

I know our company appreciates the cape support, so thanks for supporting it :-)

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

[Jeffrey Longo]

Not sure my original post got posted, so at risk of double-posting I'm going to post again (sorry).

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

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

Thanks so much everyone for the work so far!

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

[Charles Steinkuehler]

No Capes!

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

On 3/20/2014 10:47 AM, Gerald Coley wrote:
> A cape. I hate capes. Maybe on the next revision I will just disable all of
> them!
>
> Thanks!
>
> Gerald
>
>
>
> On Thu, Mar 20, 2014 at 10:32 AM, Kees k <keeskwe...@gmail.com> wrote:
>
>> Haha, I was looking at the wrong file (BB white A6). Sorry for the
>> trouble; it seems our cape causes this difference between A5C and A6.
>>
>> On Tuesday, November 26, 2013 11:22:42 PM UTC+1, AndrewTaneGlen wrote:
>>>
>>> Hello,
>>>
>>> I have noticed very rare cases (~1/50) of the ethernet phy on the
>>> Beaglebone Black not being detected on boot, and requiring a hard reset (as
>>> opposed to calling 'reset' from the command line) to get it to work/be
>>> detected again.
>>>
>>> This problem has been mentioned in a couple of other threads (below)
>>> concerning different topics (i.e. problems getting the BBB to boot, and the
>>> ethernet phy 'dying' some time after initially working fine), with no
>>> solution/workaround for this specific problem being suggested - so I
>>> thought I'd start a thread specifically for it.
>>> https://groups.google.com/forum/#!msg/beagleboard/
>>> Vp4pxwHm8BU/Iaw3p5xm0MoJ
>>> https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI
>>>
>>> In the first thread mlc/Mike discussed his response to the problem as
>>> follows:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

>>> *"I had issues with the network not coming up on boot, and it was

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

>>> it can cause hard-to-trace problems with networking.*"

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

>>> "*Based on notification from TI, in random instances there could be a

>>> glitch in the SYS_RESETn signal from the processor where the SYS_RESETn
>>> signal was taken high for a momentary amount of time before it was supposed

>>> to. To prevent this, the signal was ORed with the PORZn (Power On reset).*
>>> " (http://elinux.org/Beagleboard:BeagleBoneBlack#
>>> Revision_A6_.28Production_Version.29)

>>>
>>> Is it likely that this modification will improve/resolve the issue I am
>>> seeing with the ethernt phy not resetting/powering-up correctly?, seeing as
>>> the SYS_RESETn signal also feeds into the nRST pin on the ethernet phy (The
>>> SYS_RESETn line is left untouched in my application).
>>>
>>>
>>> Some additional observations from dmesg concerning this use:
>>>
>>> On a good phy boot I see the following:
>>> [ 2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
>>> [ 2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
>>> [ 2.833517] libphy: 4a101000.mdio: probed
>>> [ 2.837871] davinci_mdio 4a101000.mdio: phy[0]: device
>>> 4a101000.mdio:00, driver unknown
>>>
>>> Followed later by:
>>> [ 21.286920] net eth0: initializing cpsw version 1.12 (0)
>>> [ 21.301166] net eth0: phy found : id is : 0x7c0f1
>>>
>>> On a 'bad phy' boot I see the following (differences highlighted):
>>> [ 2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6

>>> [ 2.813213] davinci_mdio 4a101000.mdio: detected phy mask *fffffffb*

>>> [ 2.829512] libphy: 4a101000.mdio: probed
>>> [ 2.833875] davinci_mdio 4a101000.mdio: phy[2]: device
>>> 4a101000.mdio:02, driver unknown
>>>
>>> Followed later by:
>>> [ 21.346861] net eth0: initializing cpsw version 1.12 (0)

>>> [ 21.354379] *libphy: PHY 4a101000.mdio:00 not found*
>>> [ 21.359469] *net eth0: phy 4a101000.mdio:00 not found on slave 0*

>>>
>>>
>>> So it looks like the 'davinci_mdio_reset' function see the phy in both
>>> instances, but reports differently on the bad boot. I am not sure what to
>>> make of this.
>>>
>>> I am using the Debian 7.2 Rootfs and the 'RobertCNelson' kernel
>>> '3.12.0-bone8'.
>>>
>>>
>>>
>>> Regards,
>>> Andrew.
>>>
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[David]

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

[David Lambert]

On 04/16/2014 08:46 AM, David wrote:

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

Update #2 FWIW when this occurs I cannot use the Ethernet interface even from uboot. It needs a hard reset to get out of this condition.

Dave.

[pori...@gmail.com]

 I'm using 3.14.4 kernel (latest stable) - and 'the fix' doesn't seem to have been pushed there - could you give more information about what 'the fix' is?

[Eric]

Just found this thread, adding my 2cents. 

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

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

[Robert Nelson]

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

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

[pchumc...@gmail.com]

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

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

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

[   25.166761] libphy: PHY 4a101000.mdio:00 not found

[   25.172002] net eth0: phy 4a101000.mdio:00 not found on slave 0

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

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

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

So how can I fix it? 

Regards,

Petra

[Vishnu Patekar]

Hello,

I'm using BBB board A5C, and kernel version 3.15.3-bone3.1.  I also see ethernet PHY is not detected. Log as below:

Please refer detailed attached log.

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

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

[    3.754398] libphy: 4a101000.mdio: probed

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

[    3.767567] Detected MACID = 90:59:af:5c:61:78

[    3.773165] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

[    3.779741] sr_init: No PMIC hook to init smartreflex

[    3.785201] sr_init: platform driver register failed for SR

[    3.794297] VFS: Cannot open root device "nfs" or unknown-block(0,255): error -6

[    3.802114] Please append a correct "root=" boot option; here are the available partitions:

[    3.810888] b300         1875968 mmcblk0  driver: mmcblk

[    3.816464]   b301           72261 mmcblk0p1 00000000-01

[    3.822046]   b302         1799280 mmcblk0p2 00000000-02

[    3.827617] b310            1024 mmcblk0boot1  (driver?)

[    3.833197] b308            1024 mmcblk0boot0  (driver?)

[    3.838767] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255)

[    3.847616] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.3-bone3.1 #1

[    3.854410] [<c00113f5>] (unwind_backtrace) from [<c000fa37>] (show_stack+0xb/0xc)

[    3.862356] [<c000fa37>] (show_stack) from [<c054dd05>] (panic+0x65/0x170)

[    3.869572] [<c054dd05>] (panic) from [<c08a6d0b>] (mount_block_root+0x1af/0x21c)

[    3.877421] [<c08a6d0b>] (mount_block_root) from [<c08a6eb1>] (prepare_namespace+0xe9/0x128)

[    3.886271] [<c08a6eb1>] (prepare_namespace) from [<c08a6a93>] (kernel_init_freeable+0x1ab/0x1b8)

[    3.895574] [<c08a6a93>] (kernel_init_freeable) from [<c054d37b>] (kernel_init+0xb/0xb4)

[    3.904060] [<c054d37b>] (kernel_init) from [<c000d1f9>] (ret_from_fork+0x11/0x38)

[    3.911998] drm_kms_helper: panic occurred, switching back to text console

[    3.919217] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255)

On Sat, Jun 28, 2014 at 2:22 AM, Jay @ Control Module Industries <cmid...@gmail.com> wrote:

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

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

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

[John Syn]

This is a known problem with V3.15 and NFS. We are working on finding a solution. First, you must build the SMSC driver into the kernel. Currently it is built as a kernel module which won’t work because you have to mount the rootfs to load the kernel module. That will eliminate the first issue:

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

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

Regards,

John

[Micka]

Hello,

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

Scanning for Btrfs filesystems

systemd-fsck[202]: rootfs: clean, 110431/966656 files, 771069/3864576 blocks

[    7.665617] libphy: PHY 4a101000.mdio:00 not found

[    7.670642] net eth0: phy 4a101000.mdio:00 not found on slave 0

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

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

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

[Micka]

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

[William Hermans]

Hello,

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

Scanning for Btrfs filesystems

systemd-fsck[202]: rootfs: clean, 110431/966656 files, 771069/3864576 blocks

[    7.665617] libphy: PHY 4a101000.mdio:00 not found

[    7.670642] net eth0: phy 4a101000.mdio:00 not found on slave 0

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

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

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

Hello Micka,

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

[Micka]

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

[Micka]

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

[David Lambert]

FWIW I have seen this issue on occasions with many BBBs. Quite infrequent, but seemingly random. The only way out appears to be doing a hard reset (or power cycle).

Regards,

Dave.

[Robert Nelson]

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

Hey Micka,

how about the newly pushed out bone60?

[Vishnu Patekar]

Hello John,

Thanks for info.

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

CONFIG_IP_PNP=y

CONFIG_IP_PNP_DHCP=y

CONFIG_ROOT_NFS=y

optional:

CONFIG_IP_PNP_BOOTP=y

CONFIG_IP_PNP_RARP=y

[John Syn]

From: Vishnu Patekar <vishnupa...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>

Date: Monday, July 7, 2014 at 9:26 AM

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

Hello John,

Thanks for info.

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

CONFIG_IP_PNP=y

CONFIG_IP_PNP_DHCP=y

CONFIG_ROOT_NFS=y

optional:

CONFIG_IP_PNP_BOOTP=y

CONFIG_IP_PNP_RARP=y

Hi Vishnu,

I found something similar to you. I enabled 

CONFIG_IP_PNP

CONFIG_ROOT_NFS

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

INIT: /run/initctl is not a fifo

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

Regards,

John

[John Syn]

From: Vishnu Patekar <vishnupa...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>

Date: Monday, July 7, 2014 at 9:26 AM

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

Hello John,

Thanks for info.

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

CONFIG_IP_PNP=y

CONFIG_IP_PNP_DHCP=y

CONFIG_ROOT_NFS=y

optional:

CONFIG_IP_PNP_BOOTP=y

CONFIG_IP_PNP_RARP=y

Hi Vishnu,

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

Regards,

John

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

[Micka]

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

Micka,

[krd]

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

[Robert Nelson]

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"

[krd]

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

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
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:   <ethaddr> 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 @ 0x82000000 [ 0x000000 - 0x5efb08 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Using Device Tree in place at 88000000, 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 (48030000.spi) status -22
[    2.400599] pinctrl-single 44e10800.pinmux: could not request pin 84 (44e10950.0) from group pinmuxe
[    2.413381] omap2_mcspi 48030000.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
modprobe: chdir(3.15.6-bone5): No such file or directory
systemd-fsck[211]: BBB_OS: clean, 43555/63232 files, 219629/262144 blocks
[    8.170751] libphy: PHY 4a101000.mdio:03 not found
[    8.175793] net eth0: phy 4a101000.mdio:03 not found on slave 1

The IP Address for eth0 is: 192.168.44.145
The IP Address for usb0 is: 192.168.7.2
beaglebone login: root
Linux beaglebone 3.15.6-bone5 #1 Fri Jul 18 14:35:50 CEST 2014 armv7l
root@beaglebone:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.44.250  0.0.0.0         UG    0      0        0 eth0
192.168.7.0     *               255.255.255.252 U     0      0        0 usb0
192.168.44.0    *               255.255.255.0   U     0      0        0 eth0

root@beaglebone:~# ping 192.168.44.250
PING 192.168.44.250 (192.168.44.250) 56(84) bytes of data.
From 192.168.44.145 icmp_seq=1 Destination Host Unreachable
From 192.168.44.145 icmp_seq=2 Destination Host Unreachable
From 192.168.44.145 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.44.250 ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5004ms
pipe 3
root@beaglebone:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.44.145 icmp_seq=1 Destination Host Unreachable
From 192.168.44.145 icmp_seq=2 Destination Host Unreachable
From 192.168.44.145 icmp_seq=3 Destination Host Unreachable
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4008ms

[cmid...@gmail.com]

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

[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 fffffffe booted successfully, those with fffffffb 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 ffffffff accomplish the same thing?

Loren 

[cmid...@gmail.com]

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.

[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

[Andrew Glen]

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

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[John Syn]

From: Andrew Glen <andrewt...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Monday, November 3, 2014 at 9:42 PM

To: "beagl...@googlegroups.com" <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

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.

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

[John Syn]

From: Andrew Glen <andrewt...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>

Date: Monday, November 3, 2014 at 11:36 PM

To: "beagl...@googlegroups.com" <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

[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

[rathod....@gmail.com]

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:   <ethaddr> 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 fffffffb

<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

[alexschn...@gmail.com]

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 (3.8.13-bone67), however that keeps happening anyway.

I read section 3.7 of the LAN8710A data sheet (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

[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

Gerald

 

ger...@beagleboard.org

http://beagleboard.org/

http://circuitco.com/support/

[alexschn...@gmail.com]

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

[Gerald Coley]

All the SW has to do itvwrite to the registers and not rely on the straps. Hmm I have been saying that for 3+ years now.

Gerald

[alexschn...@gmail.com]

But the SW can do that only when the transceiver chip is always in a "writable" state, which is unfortunately not the case.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jerin George]

As suggested in this discussion i moved to 3.14.1 kernel and everything went well for the first 48 hours.
After that i could see that the ETH stopped responding for close to 10 seconds.
Then it came back.

Test set up:-
I'm using BBB for Data acquisition thru ETH. For testing i have connected BBB and 2 PC in a switch. One PC is running a data acquisition software to collect data from BBB. Another PC is running the software "Total Network Monitor" and it keeps on logging the Network status by pinging to both BBB & the other PC.

After 48 Hours :-
I could see that the Total Network monitor reported that link to BBB was lost for close to 10 seconds.

Is this a known issue ? Is there any fix to this.

regards,
Jerin

[alexschn...@gmail.com]

It appears that the issue is known for a long time: several registers of the LAN8710A Ethernet transceiver sometimes get wrong values at power-up, in spite of correct pin strapping configurations. One of those wrong values is PHYAD (PHY address in the Special Modes Register), which is erroneously initialized to 2, while the processor expects it to be 0. This makes it impossible for the processor to communicate with the transceiver and override those wrong values.

Here, they suggest that this issue is inherent in the LAN8710A by Microchip, and may be caused by some interference from the clock signal. However, Microchip did not admit that.

The messages within this topic propose 3 main solutions:

1) Rebuilt the device tree to make it somehow work with a PHY address that can take on 0 or 2, or probably some other values

2) Remove C24 capacitor (this is not safe)

3) Change the file drivers/net/ethernet/ti/davinci_mdio.c and rebuild the Linux (this patch, as far as I understand, will update the device tree in such a way that other, non-zero PHY addresses, will become also acceptable)

I have tried to do another thing: to rewrite wrong register values with U-Boot, using commands like "mdio write 2 18 0xe0", and I managed to make the content of those registers looking like that of a successfully started transceiver (including the PHYAD and MODE). However, to successfully apply these changes, a reset with RESET button is required. And if I just run "reset" command in U-Boot, the transceiver doesn't work properly after reboot, even though it already has the right PHY address: 0. In this case the registers look like as if the auto-negotiation fails, and as if the link partner (i.e. the processor) doesn't have auto-negotiation ability (the Auto Negotiation Expansion Register contains 0).

If that worked, it would be possible to append all required "rewriting commands" into "bootcmd" variable, thus forcing U-Boot to rewrite wrong values automatically. But there is another obstacle on this way: the U-boot I have (2014.10-dirty) does not have "saveenv" command, for some reason. So, I cannot save any changes in environmental variables there.

If anyone solved this problem by modifying the device tree or by some U-Boot script, please share the details.

[rathod....@gmail.com]

Well, may be you can add your mdio command inside u-boot source code's default bootcmd and rebuild the u-boot.

In my case, I updated my cpsw platform data (I use 3.2 kernel, so no device tree) inside kernel dynamically to fix this problem. It seems to be working for me. 

Regards,

Pratik

[rathod....@gmail.com]

I also believe the issue mentioned here : http://e2e.ti.com/support/arm/sitara_arm/f/791/t/366351.aspx  is the same as we are facing in bbb.

Regards,

Pratik 
On Monday, 24 November 2014 21:12:50 UTC+5:30, alexschn...@gmail.com wrote:

[myersco...@gmail.com]

Ok, so this just happened to me. What I think ultimately caused it in my case is the OS hung on shutdown, so I had to hard-power-off the board with the power button. When it came back up, no network :/ Connected via the serial terminal and was seeing the same things as others had reported. I have a rev. C board, and this was the first problem I've had with it, running 24x7 since it arrived back in July :)

Linux envmon 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l

From what I gleaned from what some folks commented a few posts above, this is what I did, and so far it seems to have worked for me:

 - Logged in as root to the board via the serial terminal
 - ran the command "init 1" to take the OS into emergency maintenance mode. (I wanted to be in single-user mode because of what I was about to do.)
 - Once there, I pressed the reset button on the board once.

When the board rebooted, I had network again :)

[alexschn...@gmail.com]

Pratik,

Thank you very much for sharing you experience with this issue. Could you please provide more details on what and how you changed in cpsw platform data?

Actually, rebuilding the kernel sounds a bit dangerous to me, because it may have some side effects, in my opinion. For instance, that "dynamical fix" you mentioned results in the situation when the processor communicates to the transceiver chip using some other address, not the default 0. OK, now everything works, it's fine. But what if some piece of code unknown to you still relies on that default address 0, and it gets executed some time later, under certain conditions? Theoretically, it could cause something even worse than this current issue.

Regards,
Alex

[alexschn...@gmail.com]

to myersco...@gmail.com:

Hi,

I noticed that simply pushing RESET button actually helps sometimes, in my recent experiments. At the same time, pushing POWER button may not help sometimes. I have an impression that this issue is a bit different by different people.

Have you tried resetting the board by means of RESET button many times, without "init 1" command, to see whether RESET button alone can help?

Regards,
Alex

[rathod....@gmail.com]

Hi Alex,

What I tried to say that the fix I applied had same logic which was described by "Jay @ Control Module Industries" in this discussion. Since I can not use device tree features of latest kernels, I made the changes which can fit in kernel 3.2 which is supplied by TI Android code. In my tests (which included many resets) it seem to be working fine.

I also believe that rebuilding the kernel is not dangerous as long as we know what we are doing. :)

Regards,

Pratik

[Christopher and Christina Myers]

Hi!

I would assume that things would be fine without going into single-user mode. If it happens again, I can try as you suggested and post back :)

[Ulrich Seidel]

Is there a finished flash-image available, which fixes the sw issues?  (I wont solder on my board so there must be a sw only solution!)

So i'm still wondering, why also the last revision has still sw on hw and sw, after so long time.
Its very annoying having a nstable hw and so for this old product :( Seems i sell this board and getting a RPI for that.

[alexschn...@gmail.com]

Hi Pratik,

As I studied the latest kernel code (3.8.13-bone67), I noticed that the patch mentioned by "Jay @ Control Module Industries" is already there, but apparently it doesn't help.

After a lot of experiments with U-Boot, I'm more convinced that the problem cannot be solved with U-Boot only.

Actually, I included those "rewriting" commands I mentioned earlier in the "bootcmd" variable and rebuilt the U-Boot. But that didn't work at all, i.e. the required registers of LAN8710A transceiver weren't rewritten (maybe some delay is required before and after those commands). I also tried rewriting them "manually" in U-Boot command line, as I mentioned earlier, but this time I tried various combinations of "Soft Reset", "Power Down" and "Restart Auto-Negotiate" commands afterwards. It was all futile.

Even when transceiver settings like PHY address, mode, etc. are correct (as a result of rewriting them manually), the processor doesn't recognize the transceiver after reset command by U-Boot. And the state of some transceiver registers, containing info about its link partner, indicates that this is the problem of the link partner, i.e. the processor. And in this case, only a power-on or "button" reset can bring the processor to the state where it can detect the transceiver.

Also, I read the processor Ethernet Subsystem registers in U-Boot, both when the transceiver is detected and when it is not. And the difference seems to be in the way the processor uses the content of MDIOALIVE register (the PHY acknowledge status register), because in both cases that content is correct. For example, if the the transceiver powers up with PHY address 0 then the bit 0 of MDIOALIVE is set to 1, if the transceiver powers up with PHY address 2, the bit 2 of MDIOALIVE is set to 1, etc. So, this means that the processor gets the acknowledge from PHY with address 2 after trying to access it, according to the page 2212 of AM335x Sitara Processors Manual, and knows that a transceiver with PHY address 2 is around. But then, may be some time later, the processor fails to get the data from the transceiver, because it tries to read by a wrong PHY address, which is reflected by the state of the MDIOUSERACCESS0 register (page 2216 of AM335x manual).

When the PHY address is 0, the content of MDIOUSERACCESS0 is 0x23e01058, which means that the data 0x1058 (bits 15-0) was read from the PHY address 0 (bits 20-16), from the PHY register 31 (bits 25-21) and PHY acknowledged the read transaction (bit 29). When the PHY address is 2, the content of MDIOUSERACCESS0 is 0x0020ffff, i.e. the processor attempted to read from PHY address 0 (despite of the content of MDIOALIVE suggesting that PHY address is 2) and, of course, failed. This failure happens somewhere in U-Boot code (I guess, in drivers/net/davinci_emac.c), of course, but the same seems to happen in the kernel code (drivers/net/ethernet/ti/davinci_mdio.c) in spite of that patch, whose purpose is to update the device tree using the content of MDIOALIVE register.

Maybe all this happens because the step 4 of the MDIO module initialization procedure, mentioned on page 1972 of AM335x manual, is not present in the code? In that step, it is necessary to save the PHY address in the MDIOUSERPHYSEL0 register, to monitor the the link status of the respective PHY.

Alex

[keou...@gmail.com]

Hi Alex,

In past couple days, I went through the same path as you did. However, with my limited tests, I see improvement on 3.8.13-bone68. I have BBB Rev C from Element14 with a generic 5V 2.8A switch power supplier.

- with 3.8.13-bone47 (the original image) power cycle 50 times, there were 2 "phy not found"
- with 3.8.13-bone68 (prebuild image from http://rcn-ee.net/, power cycle 50 times, there were no "phy not found"
I also tested 3.14.22-ti-r31, power cycle 50 time, and no "phy not found".

I'll do more test to see if the issue show up. In you tests, did you see any improvement in 3.8.13-bone67 vs earlier version ?

Thanks

KeOu

[alexschn...@gmail.com]

Hi KeOu,

I guess with 3.8.13-bone67 I had "phy not found" as frequently as with the original image. On one board with 3.8.13-bone67, I had just one occurrence of "phy not found" in 50 power-on resets. On the other board with the same kernel I had 22 "phy not found" out of 50 power-on resets. Then I updated the kernel to 3.8.13-bone68, and still had that error, 12 times out of 50 power-on resets.

To perform that kernel update, I followed the instructions from the error message that showed up after I attempted to run "install-me.sh" from http://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone68/ Could you please describe in more detail what prebuilt image you tried and how exactly you installed that? Did you also install some other U-Boot?

Some time ago, I installed and tried one of the rcn-ee.net images following a procedure similar to that described here. But it didn't help.

There is one important thing to remember: "phy not found" happens before autoboot in U-Boot, and if that happens, no matter which Linux is loaded afterwards - the transceiver chip doesn't work properly. So, both 3.8.13-bone67 and 3.8.13-bone68 fail to detect the chip, if it wasn't detected by U-Boot.

Regards,
Alex

[KeOu Chao]

Alex,

I did more testing by using a remote power switch; using 3 BBBs with 3 different Kernel, no modification on U-Boot, Kernel.

- 3.8.13-bone47 - that came with the board

- 3.8.13-bone68 - upgrade via on board script /opt/scripts/tools/update_kerenl.sh

- 3.14.22-ti-r31 - download from run-ee.net

My test scripts turn power switch wait for 50 seconds, send TCP SYN request per second for 5 times, if no ACK received, declare Failure; then power off for 5 seconds, repeat.

One thing I found is that with Console port connected, there was no failure on all my tests (other then bone47). Do you have console port connect when testing ?

This is my test results, each test has 600 power cycles,

Test 1 Test 2 Test 3 Test 4
3.8.13-bone47 50 8.33% (a) 46 7.76% (a) 41 6.83% (a) 40 6.67% (b)
3.8.13-bone68 20 3.33% (a) 0 0% (b) 0 0% (b) 21 3.5% (a)
3.14.22-ti-r31 0 0% (b) 27 4.5% (a) 0 0% (c) 24 4% (a)

(a) no console connected
(b) with console connected
(c) with patch - DGGND to console GND, VDD_3V3 to Console Tx, VDD_3V3 to Console Rx.

I just start looking into this, and have not digest all the notes / manual yet; Hope the information help.

Regards

KeOu

[alexschn...@gmail.com]

KeOu,

Thank you for the data. It looks like "phy not found" does not happen very often with your boards.

I also run that "update_kernel.sh" to update the kernel to 3.8.13-bone68. And I tried 3.14.22-ti-r31 too, and had a lot of "phy not found" in this case as well. In all my experiments the console port was always connected to a PC.

Regards

Alex

[Micka]

From my experience: "Phy not found" doesn't mean that your network is not working  ... I don't know what Robert Nelson is doing at boot, but it's possible that he fix this problem by using the register PRCM.PRM_RSTTIME= 0xFFFF ?

Micka,

[Micka]

Where I can find the variable CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC ?
Did you try to increase it Robert Nelson ? Normally this should fix the problem with the phy not detected.

If not, why ?


Thx you,

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

[Karl Karpfen]

I remember a thread in TI's forum stating that this issue can't be resolved by software. There is a hardware problem with the PHY which requires either a power cycle or a reset of PHY. And for BBB the reset line isn ot connected. To solve this issue via software a connection from one GPO to this reset line would be required.

Try to find this thread after TI has changed its webboard-software, things are way more complicated there...

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Karl Karpfen]

OK, I found the thread I mentioned: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/347189

[KeOu Chao]

Alex,

This is very interesting; in your case, the debug connection did not make any difference. Assuming there is a difference on the TTL connection, can you try (c), with patch between GPIO and debug port. In my case, with this patch, I do not see any ethernet failure.

P9 1 (GND) to J1 (serial GND)

P9 3 (VDD_V3V) to J4 (serial RXD)

P9 4 (VDD_V3V) to J5 (serial TXD)

Without debug port connection, I just run ping from terminal continuously; the successful response shows Ethernet come up after power cycle.

These were discussion on the TI e2e forum, this seems to be the same issue we have here 

Phy Address Issue beaglebone U-boot - Sitara Processors Forum - Sitara™ Processors - TI E2E Community

Regards

KeOu

[KeOu Chao]

Alex,

This is very interesting; in your case, the debug connection did not make any difference. Assuming there is a difference on the TTL connection, can you try (c), with patch between GPIO and debug port. In my case, with this patch, I do not see any ethernet failure.

P9 1 (GND) to J1 (serial GND)

P9 3 (VDD_V3V) to J4 (serial RXD)

P9 4 (VDD_V3V) to J5 (serial TXD)

Without debug port connection, I just run ping from terminal continuously; the successful response shows Ethernet come up after power cycle.

These were discussion on the TI e2e forum, this seems to be the same issue we have here 

Phy Address Issue beaglebone U-boot - Sitara Processors Forum - Sitara™ Processors - TI E2E Community

Regards

KeOu

On Dec 9, 2014, at 3:40 PM, alexschn...@gmail.com wrote:

[alexschn...@gmail.com]

KeOu,

I made the connections you described and powered the board up, but still had that "phy not found", 7 times out of 10.

Also, I did another interesting experiment: in U-Boot, I manually changed the PHY address of the transceiver to 2, after it had started successfully with the address 0 ("mdio write 0 18 0xe2"). Then I restarted the CPU by the U-Boot command "reset" and noticed that the network works anyway, with PHY address 2, both in U-Boot and when Linux runs, although U-Boot shows the message "Phy not found" and fails to list MDIO buses (i.e. shows "0 - Generic PHY <--> cpsw" instead of the expected "2 - SMSC LAN8710/LAN8720 <--> cpsw" after running the command "mdio list").

So, that means that a "nonstandard" PHY address of a transceiver alone is not a problem, it is totally acceptable to the CPU, and I was wrong when I said that this patch doesn't work. There is some difference between this "non-zero address case" and the case when the network really doesn't work. In the latter case the transceiver not only has a wrong PHY address (which wouldn't be a problem alone), but also remains in some "unhealthy" state, that could be changed only by the reset signal on the nRST.

Regards

Alex

[alexschn...@gmail.com]

Micka,

Yes, you're right, the network can still work after "Phy not found" was shown, although I observed this situation very rarely (I guess, only once), when I simply powered the board up. But this situation can be created artificially, if you intentionally change PHY address to a non-zero value, as I described in my previous message (there is probably some bug in U-Boot). It's just convenient to call this problem "phy not found".

As for the PRCM.PRM_RSTTIME, I'm studying the U-Boot code and so far don't find any place where this register is written, except for some code apparently intended to be run on some other processors, not on am33xx. And I think the macro CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC is also related to some other boards or processors, because the code where it is used assumes that the PRM_RSTTIME register contains some number of 32.768 kHz clock cycles, in bits [9:0] RSTTIME1, while the same register on AM335x contains some number of 24 MHz clock cycles (CLK_M_OSC) in bits [7:0] RSTTIME1. I need to read the datasheet more to understand better what it is.

Regards

Alex

[alexschn...@gmail.com]

Karl,

Thank you for the link. So, according to that thread, we cannot start the board reliably without modifying the hardware.

But what about doing something with nRESETIN_OUT pin? The datasheet says that the pin can be used to reset external devices, although it recommends using the pin as input only (page 1149). I wonder whether a special reset signal, generated on that pin to reset the transceiver chip, will work or not.

Regards

Alex

[Karl Karpfen]

Hi Alex,

when I understand schematics of BBB correct, this input is hard-wired to the boards reset line only, so there is no chance to toggle that pin without a hard reboot of the whole board (means even a simple software reset of the CPU is not enough).

Karl

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[alexschn...@gmail.com]

Karl,

The topic starter there reported that a reboot via watchdog didn't work. But the AM335x reference manual says that the watchdog can generate a reset pulse, that "causes the PRCM module to generate global WARM reset of the device, which causes the nRESETIN_OUT pin to be driven out of the device" (page 4444). I think it's worth a try once again, and if nRESETIN_OUT is actually driven low, then it will help.

In that thread they also mention PMIC_POWER_EN signal, which can turn off the PMIC. The real-time clock of AM335x can control an external PMIC (TPS65217C on the Beaglebone Black) by means of that signal. If PWR_ENABLE_EN bit of the RTC_PMIC register is set to 1, ALARM2 event can turn the PMIC off, and ALARM event (or ext_wakeup event) can turn the PMIC on. This could probably drive the processor through a power cycle. However, as far as I understand, RTC must be powered by a battery to be able to generate that ALARM event.

Another idea: the TPS65217C data sheet describes various ways to perform the "power up sequence" (page 18), and it can be done from ACTIVE state too, by setting the SEQUP bit of the SEQ6 register to 1. I'm trying to understand now, whether this can cause a processor power cycle (and thus, drive the nRESETIN_OUT low), because some power rails are not affected by the "power up sequence".

What do you think?

Regards

Alex

[Karl Karpfen]

2014-12-12 17:10 GMT+01:00 <alexschn...@gmail.com>:

The topic starter there reported that a reboot via watchdog didn't work.

I tried the same (from within a bare-metal application) and noticed the same. Once the PHY is in this state also a watchdog-triggered reset does not help, my software was trapped in an endless loop where only toggling power did help.

And the thread I linked earlier confirms this.

Another idea: the TPS65217C data sheet describes various ways to perform the "power up sequence" (page 18), and it can be done from ACTIVE state too, by setting the SEQUP bit of the SEQ6 register to 1. I'm trying to understand now, whether this can cause a processor power cycle (and thus, drive the nRESETIN_OUT low), because some power rails are not affected by the "power up sequence".

Hm, I checked this manual some time a go and did not find such a possibility. May be I have overseen this, at least it worth's a try!

Karl

 

[Robert Kuhn]

Hi,

I have 10 boards (newest rev. C). When I use some older Ubuntu with Ubuntu and kernel Linux arm 3.13.6-bone7 eth0 is detected on one of the ten. When I use the pre-configured image with Debian and kernel Linux beaglebone 3.8.13-bone47 the eth0 is there all the time.

Strange.  

[alexschn...@gmail.com]

Hi,

I assume this happens because those older kernels cannot cope with the situation when the transceiver just gets a non-zero PHY address at reset. This is solved in recent kernels by updating the device tree with actual PHY address.

But, as I wrote above, that issue is different from what happens when PHY is not detected even with the latest kernel. You can see this when you set the PHY address to a non-zero value yourself, in U-Boot, and then run "reset" command there, and wait until the system starts. In this case everything works, even with a non-zero address. I'm pretty sure, if you repeat this experiment with those older kernels, PHY will not be detected.

It looks like something else happens, when PHY is not detected with new kernels. Not only the PHY address is wrong (i.e. different from 0, set by the strappings on the board), but the transceiver chip remains in some strange, non-working state.

So far, the only working solution seems to be removing C24 and C30 capacitors, which is not good for a variety of reasons, as was mentioned in some previous messages here.

Regards

Alex

[Robert Kuhn]

Hi,

thanks for the answer.

 

So far, the only working solution seems to be removing C24 and C30 capacitors, which is not good for a variety of reasons, as was mentioned in some previous messages here.

So they are selling Beaglebones even most(?) of them fail and have ethernet problems? Which cannot be solved in software? 

Is there a statement from TI about that?

Robert 

[alexschn...@gmail.com]

Robert,

I don't know. Someone marked this topic as complete, apparently because the problem with the wrong PHY address is solved by that patch. But I don't think it's complete, because there is another problem, which also manifests itself by "Phy not found", as I wrote above.

Could you please tell how many power-up experiments you did? I have three rev. C boards, and one of them didn't detect PHY only one time in 50 power-ups, while another board had 22 "Phy not found" in 50 power-ups (I tried that with new kernels - 3.8.13-bone67).

@Vince Caldeira: Could you please explain why you think this topic is complete?

Regards

Alex

[Micka]

TI is not responsible for this problem. It's a problem of hardware design. Which is done by Gerald Coley if I'm not wrong.

Micka,

--

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.

[alexschn...@gmail.com]

Micka,

I guess Michrochip is responsible for this problem, because their chip LAN8710A often doesn't start in a right way, in spite of correct strappings. But they don't admit that, according to the last message in this thread.

Regards

Alex

[Micka]

But Texas Instrument replied by :

This is a known issue. The problem is that the AM335X nRESET_INOUT (or warm reset) is released at approximately the moment that the PHY latches internally it's bootstrap resistors. Once in a while this happens too soon and the PHY doesn't come out of reset correctly. This can be avoided if the PHY reset is tied to a processor GPIO (it's important that the GPIO stays in low state during reset and at reset release time).

SO this can be fix by hardware modification. But I'm not an expert ... I'm just reading what Texas replied to this.

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/347189

--

[alexschn...@gmail.com]

Once in a while this happens too soon and the PHY doesn't come out of reset correctly.

 

Then, without capacitors C24 and C30, things would get only worse, because nRESET_INOUT is released even earlier without those caps. On the contrary, removing caps helps. It looks like the slope of the reset pulse matters.

Alex

[Yiling Cao]

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/335017

i have same issue, sometimes jump phy id, sometimes no detection. on my custom board with 8710A.

suspect interference with RESET pin. I have altered my design, everything is better now.

correct:
[ 1.206085] CAN bus driver for Bosch D_CAN controller 1.0
[ 1.253601] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
[ 1.260040] davinci_mdio davinci_mdio.0: detected phy mask fffffffe
[ 1.267333] davinci_mdio.0: probed
[ 1.270874] davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver SMSC LAN8710/LAN8720

wrong:
[ 1.186248] CAN bus driver for Bosch D_CAN controller 1.0
[ 1.233612] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
[ 1.240051] davinci_mdio davinci_mdio.0: detected phy mask fffffffb
[ 1.247283] davinci_mdio.0: probed
[ 1.250823] davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver SMSC LAN8710/LAN8720

--

[Karl Karpfen]

This:

2014-12-16 10:09 GMT+01:00 Micka <micka...@gmail.com>:

This is a known issue. The problem is that the AM335X nRESET_INOUT (or warm reset) is released at approximately the moment that the PHY latches internally it's bootstrap resistors. Once in a while this happens too soon and the PHY doesn't come out of reset correctly. This can be avoided if the PHY reset is tied to a processor GPIO (it's important that the GPIO stays in low state during reset and at reset release time).

is not a problem of TI since BeagleBone Black was developed by CircuitCo and not by TI.

 

[alexschn...@gmail.com]

c2h2,

Could you please tell us what change you did in your design to make it better?

Regards

Alex

[Yiling Cao]

Hi Alex,

We have also made many variation boards, including 2 PHY design, dual gigabit phy, etc.

We massively produce our own core boards www.ariaboard.com, We found out on some early revision of our boards there may exist strange "PHY not found" and "PHY 0:0x" jumping issue, the audio (TLV320AIC3106) has strange issue as well after long time uptime. 

We found that the RESET pin on both chips (8710A and TLV320AIC3106) are too close to the MCLK pins. which is a 25MHz and 24MHz clock source receptively. The RESET pins are directly connected to AM335x SYS_RESET pin. Our design was the SAME with BB and BBB.

We suspected the high frequency CLK signal generated by crystals have effect on RESET pin, therefore we used external RESET mechanism. used an RC circuit to connect to the RESET of both chips.

The phenomenon seemed went away for us so far (1k boards made, all good), we are going to produce another 2k boards very soon to verify this and 1mil boards next year.

--

[ars_...@windstream.net]

I just purchased a Beaglebone Black Revision C and I appear to be having this problem. I can't even use the ethernet port but my wireless dongle works just fine. Has any progress been made to resolve this problem? I can use WiFi for now but I prefer to use ethernet.

Thanks.
John

[Micka]

reboot multiple time and try to get the orange Led !

--
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+unsubscribe@googlegroups.com.

[Christopher and Christina Myers]

Try my solution a couple of posts up - basically, just hit the reset button on the board with the board booted and Ethernet plugged in.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[John Tucker]

Thanks for the suggestions. I reflashed the eMMC today with a very recent version of Debian (12/19). This version appears to be reasonably stable. But after rebooting and trying your suggestion, Ethernet was still not available. I even tried booting without an Ethernet cable installed and then plugged it in. Nothing. But what I do see now is the green LED flashing quite a bit. So there is something going on but I never seen any flashing from the Orange/Yellow LED.  I can connect to a static IP address but can't seem to get any bi-directional communication. I open a browser and try to go to a website but all I can see is the "Resolving host" message in the browser telling me that something is not just right. After trying to use Putty with no success, my guess is that the BBB is not getting any incoming packets at all.

I'm open to other suggestions. I want to use the BBB for ADS-B receiving with an RTL-SDR. I can use a wireless dongle if I have to.

Thanks.

John

To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.