Just received my long awaited Beaglebone. It's Rev. A4, S/N
0312BB000031. I can't get it to see or send traffic over ethernet. I
can login over SSH via USB ethernet. The MAC address reported for eth0
is D4:94:A1:52:1C:65.
The Angstrom OS, the BB ethernet lights and the switch/AP at the other
end of the patch cable (Netgear N600 WNDR3700v2) all see link when the
cable is plugged and no link when it's pulled. Switch and BB also
agree it's a 100Mbit/full link. Angstrom reports
PHY: 0:00 - Link is Up - 100 /Full
PHY: 0:00 - Link is Down
on cable in/out. The Netgear is usually very tolerant with various
ethernet devices and happily hands out DHCP leases to whoever asks. I
would not expect link negotiation or DHCP timing issues. The BB
ethernet status leds light up together (orange+green) soon after cable
plugged and stay on until immediately after cable pulled.
Tried with a different, older SMC box with built-in switch and DHCP
server. Same story.
The demo Angstrom image supplied was 2011.11. I've upgraded to
Angstrom-Cloud9-IDE-eglibc-ipk-v2012.01-core-beaglebone-2012.01.11
(copy paste from current info.txt) but that has not resolved the
issue.
If I issue 'ifup eth0' via the USB connection, udhcpc tries to get a
DHCP lease but gets no answer. At the same time the DHCP server (the
Netgear) sees no request, and neither does my laptop when tcpdumping
on the same segment.
If I manually assign an address on eth0 belonging to the range active
on that segment, there is still silence on both ends, no ping replies,
no traffic visible. Command issued:
ifconfig eth0 192.168.x.y netmask 255.255.255.0
ifconfig then reports a normal eth0 configuration. Adding a default gw
doesn't change anything, it's not even visible. I've also tried an
extra explicit 'ifconfig eth0 up', no difference.
Any suggestions? I guess there's something wrong with the hardware and
I need to request an RMA with the Austrian distributor?
If the Link is up, it is not likely a HW issue. I would go after a SW solution first. We have had other reports of similar operation. Everything looks fine. RX and TX packets sent and received, but issue with DHCP server giving IP address. If you do a ifconfig, what do you get back?
I tried two different builds (the newest one and an older one )
Speedtouch modem and 3com gigabit switch.
When I enable static IP on the BeagleBone and send an ping broadcast,
on my seitch is only the led blinking of my BeagleBone and not all the
ports.
If the Link is up, it is not likely a HW issue. I would go after a SW
solution first. We have had other reports of similar operation. Everything
looks fine. RX and TX packets sent and received, but issue with DHCP server
giving IP address. If you do a ifconfig, what do you get back?
See below.
... just installed tcpdump on it, and it does indeed see packets from
the other end of the cable. So you are right, the hardware works and
the software doesn't, yet. Investigating, I'll figure it out. Maybe
DHCP client or server are somehow picky, although it should have
worked with manual IP address.
Yes. I know. Give us some time to figure this one out. The boards pass our production tests, but we are seeing this issue as well. It is most likely some sort of SW issue, but we do not know what is triggering it.
We added a resistor R219 to fix the Yellow LED to be on when at 100M. Per the SMSC data sheet, it would only affect pin 18 on the PHY, one that we do not use. Evidently, it is doing something else.
If you are comfortable doing so, you can remove R219 and that should get you going. It is right under the RJ45 connector. We are also looking at a SW fix to write over which ever bit is getting messed up by this change. Once we have that working, we will be making it available.
for my Beagleboard Rev. C5 board. It is only partly
successful. To wit: with the SD card produced by
this procedure, I can boot into a nice Angstrom desktop,
but not (subsequently) from NAND.
On NAND boots, console (UART) input is almost always
ignored, and the boot process invariably ends in kernel panic:
…
[ 16.623596] regulator_init_complete: incomplete constraints, leaving VDAC on
[ 16.631378] omap_vout omap_vout: probed for an unknown device
[ 16.637512] UBIFS error (pid 1): ubifs_get_sb: cannot open “ubi0:beagleboard-rootfs”, error -19
[ 16.646331] VFS: Cannot open root device “ubi0:beagleboard-rootfs” or unknown-block(0,0)
[ 16.654510] Please append a correct “root=” boot option; here are the available partitions:
[ 16.662963] 1f00 512 mtdblock0 (driver?)
[ 16.667999] 1f01 1920 mtdblock1 (driver?)
[ 16.673004] 1f02 128 mtdblock2 (driver?)
[ 16.678039] 1f03 4096 mtdblock3 (driver?)
[ 16.683074] 1f04 517632 mtdblock4 (driver?)
[ 16.688079] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Can anyone point me at a simple, coherent and known-good
procedure for restoring NAND to factory default state? I’ve
searched the web, but I’ve come to distrust almost everything
I read on this topic.
I’m not looking for a complete bootable image. Ideally this would
be an SD card with exactly one file: an MLO specifically designed
to restore NAND and drop me back to the u-boot prompt.
Thank you, Gerald. I think it might take more than 10 seconds,
but at some point (while still holding the button down) I noticed
some serious NAND activity going on that I hadn't seen before.
We added a resistor R219 to fix the Yellow LED to be on when at 100M. Per
the SMSC data sheet, it would only affect pin 18 on the PHY, one that we do
not use. Evidently, it is doing something else.
If you are comfortable doing so, you can remove R219 and that should get
you going. It is right under the RJ45 connector. We are also looking at a
SW fix to write over which ever bit is getting messed up by this change.
Once we have that working, we will be making it available.
Gerald, thanks a lot, removed R219 and the issue goes away, the
ethernet interface now works as expected! -Bert
We added a resistor R219 to fix the Yellow LED to be on when at 100M.
Per the SMSC data sheet, it would only affect pin 18 on the PHY, one
that we do not use. Evidently, it is doing something else.
If you are comfortable doing so, you can remove R219 and that should get
you going. It is right under the RJ45 connector. We are also looking at
a SW fix to write over which ever bit is getting messed up by this
change. Once we have that working, we will be making it available.
Gerald
Hi Gerald,
Is R219 present on newer (A4) boards only? I'm unable to locate it neither on the (A3) board nor in the schematics.
On the A3 boards we have seen a couple of instances where the reset line is sitting at 1.6V. This is caused by the reset button on the board having a low resistance path of around 20K. If this is the case, it can cause the SMSC PHY to reset which will cause the link to drop,
I also have a Rev. A4 board I received yesterday and experience the
exact same problem - switch shows 100 MBit/s link but no network
connection whatsoever is possible (dchp sees no replies and neither do
pings using a statically configured IP address). I have identified the
R219 resistor under the RJ45 connector, but I am not comfortable
removing it - is that even possible without special equipment?
Well, you can just smash it if you like. It is delicate. Needle nose pliers work fine. You could probable just twist it off with some tweezers as well. It won’t violate your warranty.
Or you can wait until we figure this out.
We have noticed that after a power on boot, you can type “reboot” and then it will work. But, if you type “reboot” again, it will not work. It basically works every other time after a reboot.
We have noticed that after a power on boot, you can type "reboot" and then
it will work. But, if you type "reboot" again, it will not work. It
basically works every other time after a reboot.
Hmm, interesting, I haven't noticed this on my board – I could swear
I've rebooted a lot, but Ethernet never worked for me before I
desoldered R219.
Than again, I always reboot with "init 6" rather than "reboot" –
Gerald, could you try this (init 6 vs. reboot). If I remember
correctly, and the former doesn't trigger the works/doesn't work
cycle, then maybe analyzing the differences between these two could be
fruitful.
I've rebooted my board many times (using "reboot"), but I've never got
ethernet to work. I even tried connecting the same cable to a
different device to verify the connection is okay, but that worked.
Thanks for the info about removing R219, I'll probably do that if I
get impatient, but for now I'll just wait to see if a software
solution can be found.
Hello,
I got my rev A4 board last week and experience the same problem. I
really don't see myself removing that R219 so I'll wait for a SW
fix
By the way, even rebooting multiple times does not work.
Many thanks in advance for finding a fix, that would be great.
Kevin
