Does the C24 value change in revision A6A suppose to fix this problem? I
still got this issue on my two BBB A6A. Do we need to increase C24 further,
or have it removed completely since U16 is added?
On Saturday, December 7, 2013 11:50:06 AM UTC-8, Gerald wrote:
>
> Try removing C24. See if that helps.
>
> Gerald
>
>
> On Sat, Dec 7, 2013 at 7:01 AM, <dave...@gmail.com <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 <andrewt...@gmail.com>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/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...@googlegroups.com <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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
