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 Sunday, 8 December 2013 08:50:06 UTC+13, Gerald wrote: > > Try removing C24. See if that helps. > > Gerald > > > On Sat, Dec 7, 2013 at 7:01 AM, <[email protected] <javascript:>> wrote: > >> We are experiencing the same issue, using the A5 version. Roughly 1% to >> 3% of the times on boot up, the unit fails to find the PHY. On next boot up >> works fine.On very very rare occasions, it will fail to find the PHY 2x in >> a row, but haven't seen that in a few days now since started driving >> SYS_Resetn as below. Before started driving the Sys_Resetn line, wold see >> it miss in the 10+% range. >> >> The startup SYS_Resetn glitch from the CPU has been observed on multiple >> units. To counter that we drove the SYS_Resetn line low { open collector } >> for 400 msec with occasional improvements, but the problem has never really >> gone away. Using the external open collector reset, we have also added an >> adiditonal 4K7 pullup to 3V3. We are also trying driving the line with an >> active 3V3 device rather than depending on the pullup.. >> >> Don't think see any issues with the way 3V3 is coming up. >> >> Dave >> >> >> On Tuesday, 26 November 2013 17:49:47 UTC-5, Gerald wrote: >> >>> I am just now looking at this issue. The A6 revision was not put in >>> place to fix this issue. >>> >>> Gerald >>> >>> >>> >>> On Tue, Nov 26, 2013 at 4:22 PM, AndrewTaneGlen <[email protected]>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 [email protected]. >>>> >>>> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
