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,
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
FWIW I have seen the PHY problem repeatedly using the 3.8 kernel, but
not yet with the RCN 3.13 kernel.
Regards,
Dave.
On 03/19/2014 02:52 PM, Robert Nelson wrote:
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
fwiw, I'm seeing what *appears* to be this same issue on the latest board
I've bought - occasionally there is no Ethernet connectivity on power-up, a
physical power off/on always resolves it...
This is a rev B board, running the latest Debian test image with beta 3.13
kernel, and has happened
Hi,
Gerald:
Try removing C24. See if that helps.
We saw the same problem. After removing C24 and C30 it seems to be solved!
Our board is revision B.
Robert
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google
Correct. You can also solve the issue by using the correct SW as well. The
issue is that the processors interferes with the default address settings
when the PHY reads the pins. If the SW looks for the other addresses, it
works fine.
Also, removing these caps will also create issues where the
Gerald:
Correct. You can also solve the issue by using the correct SW as well. The
issue is that the processors interferes with the default address settings
when the PHY reads the pins. If the SW looks for the other addresses, it
works fine.
Also, removing these caps will also create
My SW guy is currently out. There is a change that needs to be made. I will
get with him next week to make sure the change gets done.
Gerald
On Tue, Mar 11, 2014 at 8:26 AM, Robert Kuhn rob...@ku.hn wrote:
Gerald:
Correct. You can also solve the issue by using the correct SW as well.
The
On Tue, Mar 11, 2014 at 8:26 AM, Robert Kuhn rob...@ku.hn wrote:
Gerald:
Correct. You can also solve the issue by using the correct SW as well. The
issue is that the processors interferes with the default address settings
when the PHY reads the pins. If the SW looks for the other addresses,
Gerald said:
The issue is that the processors interferes with the default address
settings when the PHY reads the pins. If the SW looks for the other
addresses, it works fine.
Could we get a clue about which addresses are the problem?
Maybe the addresses 4a10 vs. 4a101000?
davinci_mdio
The base address of the PHY. Only one address per PHY. I believe it is 0 to
7. It is my understanding that the fix was pushed up a week ago. Robert's
image should handle this.
It is not the MAC address. PHY NOT FOUND means that at the one address of
00 the PHY did not respond because the PHY has
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 =
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.
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
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
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
Try removing C24. See if that helps.
Gerald
On Sat, Dec 7, 2013 at 7:01 AM, davem...@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,
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 andrewtaneg...@gmail.comwrote:
Hello,
I have noticed very rare cases (~1/50) of the ethernet phy on the
Beaglebone Black not being detected
101 - 118 of 118 matches
Mail list logo
