I have recently re-flashed my Jetson TK1 board with the R21.2.0 driver and sample file system. Everything works fine after the flashing process except that the eth0 wouldn’t come up. I noticed that the MAC address for eth0 is all zeros from a “dmesg | grep eth0” as the followings.
I have found a temporary solution for it. That is to bring down the eth0, set the MAC addr, and bring it back up. It works as described except that this needs to be done upon every reboot of the Jetson TK1. I am looking for a more permanent solution/fix to this problem. Anyone?
{Temporary solution}
sudo ip link set dev eth0 down
sudo ip link set dev eth0 address {xx:xx:xx:xx:xx:xx}
sudo ip link set dev eth0 up
FYI, this is the output from my jetson-TK1’s ‘sudo ip link ls’
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ether 32:4a:46:7e:e4:88 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: sit0: mtu 1480 qdisc noop state DOWN mode DEFAULT group default
link/sit 0.0.0.0 brd 0.0.0.0
5: ip6tnl0: mtu 1452 qdisc noop state DOWN mode DEFAULT group default
link/tunnel6 :: brd ::
6: rmnetctl: mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ipip 0.0.0.0 brd 0.0.0.0
Some Tegra devices depend upon the boot loader setting up a MAC address, and then the actual hardware is never checked (this tends to be in environments with fewer resources than Jetson). In other cases the boot environment MAC is only used if network functions are part of boot (such as NFS partitions)…and then when the Linux driver takes over it switches to using settings from the operating system and NIC queries. This latter case is how Jetson works, so it seems firmware or some part of the flash actually failed. I’d go back to the flash procedure and make sure this install did not fail because of little things like failure to unpack L4T as root or an issue with apply_binaries.sh.
Are these freshly extracted host-side flash environments? It is quite possible that if the rootfs is edited those edits might cause the problem. rootfs is intended to propagate exactly (other than some boot loader characteristics) to Jetson. At this point I have to wonder if the embedded NIC is failing.
Yes, these are the freshly extracted host-side environments. No edit is made against those rootfs; they are simple extracted from the original files {Tegra_Linux_Sample-Root-Filesystem_R21.2.0_armhf.tbz2} and {Tegra124_Linux_R21.2.0_armhf.tbz2}.
I tried what falco152 suggested, that was to enter u-boot and set the “ethaddr” according to the MAC address sticker on my jetson-tk1 board. However, it didn’t help.
I have also noticed that the “ethaddr” is reset back to empty upon every re-flash. Is this a hardware issue? Can I potentially RMA this board?
FYI, setting an address during boot loader stage is quite different than after the Linux kernel loads. As @WayneWWW mentioned, you will want to try the more recent L4T version (R21.5, which JetPack3.1 can flash), and you will want to post exactly which stage of boot your are in when looking at networking. Parts of the above conversations were looking in boot loader stage, and other parts were from after Linux is booted.