On Tue, Oct 11, 2016 at 5:51 PM, Kevin Fructuoso
wrote:
> Thanks for the link to the patch. I have not patched the kernel before.
>
> Could you please send a link that explains and walks me through how to patch
> the kernel? Thanks.
>
> Regards,
> Kevin F.
git clone
Hi Robert,
Thanks for that update.
We're still modifying hardware on about 10 boards/month to get around the
phy reset issue, so a kernel patch for the same result is very well
received.
Regards,
Andrew Glen.
On 12 October 2016 at 08:42, Robert Nelson wrote:
> On
On Tue, Oct 11, 2016 at 2:32 PM, Kevin Fructuoso
wrote:
> Hi Robert,
>
> Thank you for the quick reply! We are using kernel 3.8.13-bone47 on rev C
> Beaglebones.
So this was first fixed in bone60, here's the kernel patch you'll need
to apply and rebuild 3.8.13-bone47
Hi Robert,
I am running some power cycle testing on a rev C board with a debian image
dated to April 23rd, 2014. I am also seeing this error occur across
multiple boards. When this error occurs, the boards cannot acquire an IP
address. Do you know if this image should have resolved the issue?
Hi Kevin,
On Tue, Oct 11, 2016 at 2:18 PM, Kevin Fructuoso
wrote:
> Hi Robert,
>
> I am running some power cycle testing on a rev C board with a debian image
> dated to April 23rd, 2014. I am also seeing this error occur across multiple
> boards. Do you know if this
Hi Robert,
I am running some power cycle testing on a rev C board with a debian image
dated to April 23rd, 2014. I am also seeing this error occur across
multiple boards. Do you know if this image should have resolved the issue?
It is not preferred for us to update to a newer image if we can
I am runnung Debian 8.2
Linux beaglebone 4.1.12-ti-r29
I modified /etc/network/interfaces to make eth0 to be static, but every
time after reboot, the IP still changed, why?
Thanks,
Kevin
-
# The primary network interface
auto eth0
iface
Thank you, so I just need to wait.
2015-06-29 14:53 GMT+01:00 Robert Nelson robertcnel...@gmail.com:
On Mon, Jun 29, 2015 at 8:48 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
O yes, thank you, so there will be no reading BBB serial number from
EEPROM
in this
:) all I am using is your bb-kernel and dtb-rebuilder
2015-06-29 14:02 GMT+01:00 Robert Nelson robertcnel...@gmail.com:
On Mon, Jun 29, 2015 at 7:59 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
Sorry for being pain in the neck, how can I apply this fix?
ah,
O yes, thank you, so there will be no reading BBB serial number from EEPROM
in this version of kernel?
2015-06-29 14:43 GMT+01:00 Robert Nelson robertcnel...@gmail.com:
On Mon, Jun 29, 2015 at 8:08 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
both bb-kernel and
Sorry for being pain in the neck, how can I apply this fix?
2015-06-29 13:56 GMT+01:00 Robert Nelson robertcnel...@gmail.com:
On Mon, Jun 29, 2015 at 7:23 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
and another one:
ls -al /sys/bus/i2c/devices/i2c-0/0-0050/
and just to give you something in exchange,
there is nothing about eeprom on i2c-0
src/arm/am335x-bone-common-no-capemgr.dtsi
in 4.1
2015-06-29 14:08 GMT+01:00 Artur Festyn fes...@googlemail.com:
both bb-kernel and dtb-rebuilder say
Already up-to-date.
after git pull
sorry, I am beginner
On Mon, Jun 29, 2015 at 8:08 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
both bb-kernel and dtb-rebuilder say
Already up-to-date.
after git pull
sorry, I am beginner
you downloaded beaglebone-black-g-ether-load.sh from:
On Mon, Jun 29, 2015 at 8:16 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
and just to give you something in exchange,
there is nothing about eeprom on i2c-0
src/arm/am335x-bone-common-no-capemgr.dtsi
in 4.1
Well...
am335x-bone-common-no-capemgr.dtsi
no-capemgr..
On Mon, Jun 29, 2015 at 8:48 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
O yes, thank you, so there will be no reading BBB serial number from EEPROM
in this version of kernel?
No, i just didn't care enough to back port those changes from:
:) Ok, so we just read serial number from different place, thanks
2015-06-29 14:55 GMT+01:00 Artur Festyn fes...@googlemail.com:
Thank you, so I just need to wait.
2015-06-29 14:53 GMT+01:00 Robert Nelson robertcnel...@gmail.com:
On Mon, Jun 29, 2015 at 8:48 AM, 'Artur Festyn' via
On Mon, Jun 29, 2015 at 7:23 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
and another one:
ls -al /sys/bus/i2c/devices/i2c-0/0-0050/
total 0
drwxr-xr-x 4 root root0 Jun 29 12:22 .
drwxr-xr-x 8 root root0 Jun 29 12:13 ..
lrwxrwxrwx 1 root root0 Jun 29
On Mon, Jun 29, 2015 at 7:59 AM, 'Artur Festyn' via BeagleBoard
beagleboard@googlegroups.com wrote:
Sorry for being pain in the neck, how can I apply this fix?
ah, re-download it from where you got it...
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
For more options, visit
both bb-kernel and dtb-rebuilder say
Already up-to-date.
after git pull
sorry, I am beginner
2015-06-29 14:04 GMT+01:00 Artur Festyn fes...@googlemail.com:
:) all I am using is your bb-kernel and dtb-rebuilder
2015-06-29 14:02 GMT+01:00 Robert Nelson robertcnel...@gmail.com:
On Mon, Jun
Have this problem in 4.1-bone9
net eth0: initializing cpsw version 1.12 (0)
[9.014985] net eth0: phy found : id is : 0x7c0f1
[9.015081] libphy: PHY 4a101000.mdio:01 not found
[9.020112] net eth0: phy 4a101000.mdio:01 not found on slave 1
kernel was generated by up to date
:) Ok, understand, this is not a problem, thank you
what about
3.177810] omap_voltage_late_init: Voltage driver support not added
2015-06-29 13:11 GMT+01:00 Robert Nelson robertcnel...@gmail.com:
On Mon, Jun 29, 2015 at 5:24 AM, Jan Kinkazu fes...@googlemail.com
wrote:
Have this problem in
and another one:
ls -al /sys/bus/i2c/devices/i2c-0/0-0050/
total 0
drwxr-xr-x 4 root root0 Jun 29 12:22 .
drwxr-xr-x 8 root root0 Jun 29 12:13 ..
lrwxrwxrwx 1 root root0 Jun 29 12:13 driver -
../../../../../../bus/i2c/drivers/at24
-r--r--r-- 1 root root 4096 Jun 29 12:22 modalias
On Mon, Jun 29, 2015 at 5:24 AM, Jan Kinkazu fes...@googlemail.com wrote:
Have this problem in 4.1-bone9
net eth0: initializing cpsw version 1.12 (0)
[9.014985] net eth0: phy found : id is : 0x7c0f1
[9.015081] libphy: PHY 4a101000.mdio:01 not found
[9.020112] net eth0: phy
I have to say, the motivation to remove caps suddenly makes a lot more
sense to me after actually observing the power-on reset sequence on the
scope:
Horizontal scale: 5ms per grid line, 1ms per minor tick
Vertical range 0-4V, scale: 0.8V per grid line, 0.2V per minor tick
(except the yellow
Hello guys,
So my hardware people found out the problem, I forgot to mention that the
problem only happened when the beagleboard was in our custom cape, so they
run some tests and the problem was in our board there was some delay when
powering the board sometimes and this cause the problem and
On Tue, May 19, 2015 at 3:56 PM, Robert Nelson robert...@gmail.com
javascript: wrote:
We assume phy_mask to be 100% correct. Maybe we should just force
the dt value of phy_id always into phy_mask?
I really need to find a board that 'never' boots with 0xfffe..
Back when I had
On Tue, May 19, 2015 at 3:56 PM, Robert Nelson robertcnel...@gmail.com wrote:
On Tue, May 19, 2015 at 3:48 PM, Fernando Derkoski bril...@gmail.com wrote:
Hi, first thank you for the response, here is the output where the network
did not work:
root@beaglebone:~# dmesg | grep mdio
[
Hi, first thank you for the response, *here is the output where the network
did not work:*
root@beaglebone:~# dmesg | grep mdio
[1.040419] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[1.040439] davinci_mdio 4a101000.mdio: detected phy mask fffb
[1.047217] libphy:
As an aside, is this in fact the problem, it would probably be listed as
nameserver 192.168.1.1 Which seems to be the default value as shipped
On Tue, May 19, 2015 at 2:44 PM, William Hermans yyrk...@gmail.com wrote:
But the network interface seems to be working fine.
What nameserver is
name servers have nothing to do with anything when pinging with IP numbers.
On 5/19/2015 2:45 PM, William Hermans wrote:
As an aside, is this in fact the problem, it would probably be listed
as nameserver 192.168.1.1 Which seems to be the default value as
shipped
On Tue, May 19, 2015 at
On Tue, May 19, 2015 at 5:00 PM, Robert Nelson robertcnel...@gmail.com wrote:
On Tue, May 19, 2015 at 4:57 PM, Robert Nelson robertcnel...@gmail.com
wrote:
On Tue, May 19, 2015 at 3:56 PM, Robert Nelson robertcnel...@gmail.com
wrote:
On Tue, May 19, 2015 at 3:48 PM, Fernando Derkoski
On Tue, May 19, 2015 at 3:24 PM, Fernando Derkoski bril...@gmail.com wrote:
Hello,
This problem happens to me as well, I have 3 beaglebones black Rev C, with
the latest kernel, 3.8.13-bone70. Anyone knows how to resolve this problem?
unlikely... show us the output off:
dmesg | grep mdio
Hello,
This problem happens to me as well, I have 3 beaglebones black Rev C, with
the latest kernel, 3.8.13-bone70. Anyone knows how to resolve this problem?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
On Tue, May 19, 2015 at 4:57 PM, Robert Nelson robertcnel...@gmail.com wrote:
On Tue, May 19, 2015 at 3:56 PM, Robert Nelson robertcnel...@gmail.com
wrote:
On Tue, May 19, 2015 at 3:48 PM, Fernando Derkoski bril...@gmail.com wrote:
Hi, first thank you for the response, here is the output
On Tue, May 19, 2015 at 3:48 PM, Fernando Derkoski bril...@gmail.com wrote:
Hi, first thank you for the response, here is the output where the network
did not work:
root@beaglebone:~# dmesg | grep mdio
[1.040419] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[1.040439]
*r116 yeap.. time to go home. ;)*
Same here, and yeah wulf is right. My problem is: I'm already home. Maybe I
need a brewski . . .
On Tue, May 19, 2015 at 3:01 PM, Robert Nelson robertcnel...@gmail.com
wrote:
On Tue, May 19, 2015 at 5:00 PM, Robert Nelson robertcnel...@gmail.com
wrote:
You can also fix most strapping options, including the PHY address, by
writing to mdio register 0x12 (see datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf page 60).
This whole issue still sounds really weird though. The RXD3/PHYAD2 line has
internal pull-down in the PHY,
Hi Alex,
In my test, like John Zhang, I also had my BBB sending a ping after boot to
confirm that Ethernet was working. In my experience the Phy 0 not found log
message will occur even when the Ethernet seems to work normally.
Regards,
Bill
--
For more options, visit
Hi Alex,
My test is to power on the BBB for 1 minute. Right after the kernel boots
up BBB starts to ping another PC connected to the same Ethernet switch to
show whether the Ethernet interface successfully started or not.
My first software combination was u-boot v2015.10 with the 1-second
Hi Robert,
Instead of trying to port the patch to u-boot, I updated my kernel from the
BBB stock v3.8.13-bone47 to the latest v3.8.13-bone70. Then re-doing the
power on/off test right now. Currently there are about 200 times power
cycling and 8 times u-boot reported Phy 0 not found. But for
On Sat, Feb 14, 2015 at 1:04 AM, John Zhang
john.zh...@nupointsystems.com wrote:
Hi Robert,
Instead of trying to port the patch to u-boot, I updated my kernel from the
BBB stock v3.8.13-bone47 to the latest v3.8.13-bone70. Then re-doing the
power on/off test right now. Currently there are
If a changed ID is a problem, why does the network work after changing that
ID manually in U-Boot and then rebooting, as I described here
https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/PK6bxAszAkoJ?
Alex
On Friday, February 13, 2015 at 8:45:08 PM UTC+1, RobertCNelson wrote:
On Fri,
Hi Bill,
Thank you for doing that experiment.
I run two automated tests with the delayed PHY initialization, each one
with 130 power-ups over 130 minutes (one power-up per minute), where I
still saw a few Phy 0 not found messages.
In the first test, BBB periodically reset itself by means of a
Hi John,
Thank you for doing this experiment. Did you power off your board right
after checking for Phy 0 not found in U-Boot console, without booting
Linux?
Have you ever tried to let Linux boot after seeing that Phy 0 not found?
Regards,
Alex
On Friday, February 13, 2015 at 6:58:46 PM
Hi Alex,
I added this delay 1 second idea on the u-boot version v2015.01 and did the
power on / off test on BBB. I did 263 board boot up. Among them 254 times
Ethernet interface successfully started up. The other 9 times the u-boot
just could not detect Phy. Below is the u-boot log comparison
On Fri, Feb 13, 2015 at 11:58 AM, John Zhang
john.zh...@nupointsystems.com wrote:
Hi Alex,
I added this delay 1 second idea on the u-boot version v2015.01 and did the
power on / off test on BBB. I did 263 board boot up. Among them 254 times
Ethernet interface successfully started up. The
On Thursday, February 5, 2015 at 11:16:55 AM UTC-7, alexschn...@gmail.com
wrote:
After I and my colleagues had fruitlessly tried many things, our hardware
developer came up with a working solution: delaying the PHY initialization
performed by the U-Boot we use (v2014.10, git checksum
If this ends up being the solution, can you please post a guide for those
not as up to speed as you on precisely how to implement this fix? Thanks
On Thursday, February 5, 2015 at 1:16:55 PM UTC-5, alexschn...@gmail.com
wrote:
Hello everybody,
After I and my colleagues had fruitlessly tried
Hello everybody,
After I and my colleagues had fruitlessly tried many things, our hardware
developer came up with a working solution: delaying the PHY initialization
performed by the U-Boot we use (v2014.10, git checksum
c43fd23cf619856b0763a64a6a3bcf3663058c49). This ensured that U-Boot code
Based on all the comments and discussions I've seen before and after
purchasing my BBB, I'm sure someone will figure out how to fix the issue.
However, unfortunately my knowledge isn't that advanced yet, so while I can
understand what folks are saying (usually,) I'm not at the level to be able
to
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
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
--
For more
reboot multiple time and try to get the orange Led !
Le Mon Dec 22 2014 at 14:44:00, ars_n8...@windstream.net a écrit :
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
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.
On Monday, December 22, 2014, Micka mickamus...@gmail.com wrote:
reboot multiple time and try to get the orange Led !
Le Mon Dec 22 2014 at 14:44:00,
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
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,
Le Tue Dec 16 2014 at 08:44:53, Robert Kuhn rob...@ku.hn a écrit :
Hi,
thanks for the answer.
So far, the only working solution seems to be removing C24 and
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
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
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
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
This:
2014-12-16 10:09 GMT+01:00 Micka mickamus...@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
c2h2,
Could you please tell us what change you did in your design to make it
better?
Regards
Alex
--
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
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
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.
Am
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
https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ tree
with actual
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?
2014-12-12 17:10 GMT+01:00 alexschneider...@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
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
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
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
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
2014-12-12 10:20 GMT+01:00
Karl,
The topic starter there reported that a reboot via watchdog didn't work.
But the AM335x reference manual
http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf says that the watchdog can
generate a reset pulse, that causes the PRCM module to generate global
WARM reset of the device, which
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,
Le Wed Dec 10 2014 at 12:13:11, Micka mickamus...@gmail.com a écrit :
From my
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
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
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
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
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
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
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
Hi Pratik,
As I studied the latest kernel code (3.8.13-bone67), I noticed that the
patch https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ
mentioned by Jay @ Control Module Industries is already there, but
apparently it doesn't help.
After a lot of experiments with U-Boot,
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
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
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,
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
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 :)
On Saturday, November 29, 2014, alexschneider...@gmail.com wrote:
to myersco...@gmail.com
javascript:_e(%7B%7D,'cvml','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
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
On
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:
It appears that the issue is known for a long time: several
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
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
But the SW can do that only when the transceiver chip is always in a
writable state, which is unfortunately not the case.
On Saturday, November 22, 2014 1:38:54 AM UTC+1, Gerald wrote:
All the SW has to do itvwrite to the registers and not rely on the straps.
Hmm I have been saying that for
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
On Friday, November 21, 2014, alexschneider...@gmail.com wrote:
Hi Gerald,
I meant strap values, not connections on the board. As far as I
understand it, correct
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
http://debian.beagleboard.org/images/BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.img.xzand
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
On Wed, Jun 4, 2014 at 4:20 PM, Eric ericpospi...@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
On Wednesday, March 19, 2014 8:52:36 PM UTC+1, RobertCNelson wrote:
On Wed, Mar 19, 2014 at 2:47 PM, bko...@scanimetrics.com javascript:
wrote:
Does anyone happen to know if the 3.8 kernel compiled as per these
instructions here http://eewiki.net/display/linuxonarm/BeagleBone+Black
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.
On Wednesday, March 19, 2014 3:31:00 PM
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
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
1 - 100 of 118 matches
Mail list logo