>From some earlier correspondence with Gerald @ BeagleBoard:
"Rev A6 was not changed to fix this issue. It has a reset fix, but not
for this. Whatever change I come up with will not show up for months.
I don't know what the version will be. It is not clear how the Rev A6
revision will affect this issue."
On 5 February 2014 18:42, sunvale <kevinhuang...@gmail.com> wrote:
> Does the C24 value change in revision A6A suppose to fix this problem? I
> still got this issue on my two BBB A6A. Do we need to increase C24 further,
> or have it removed completely since U16 is added?
>
>
> 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> 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.
>>> 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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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.
