Mac 00:00:00:00:00:01

Hi everyone,

I received my Nano today and booted it with an SD image I downloaded a month, or so, ago.

For some reason the eth0 mac address shows up as 00:00:00:00:00:01?

I have checked, the eeprom does contain a MAC address, and it matches the QR code on the bottom of the board, but linux is stuck on that MAC…

errol@jetson:~$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.12 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::d0c:f50:872d:e4a6 prefixlen 64 scopeid 0x20
ether 00:00:00:00:00:01 txqueuelen 1000 (Ethernet)
RX packets 1052 bytes 914038 (914.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 573 bytes 51570 (51.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 151 base 0x5000

Any idea how I can fix this?

Thank you,
Errol

The dmesg and bootloader log shall tell us the clue.

https://elinux.org/Jetson/General_debug

Hi Wayne,

I have attached the log files. The bootloader log looks like it loads it MAC address?

[0002.140] eeprom_get_mac: EEPROM invalid MAC address (all 0xff)
[0002.145] shim_eeprom_update_mac:267: Failed to update 0 MAC address in DTB
[0002.154] eeprom_get_mac: EEPROM invalid MAC address (all 0xff)
[0002.160] shim_eeprom_update_mac:267: Failed to update 1 MAC address in DTB
[0002.168] updating /chosen/nvidia,ethernet-mac node 00:04:4b:e7:17:cc

Just to confirm, “ip addr” still gives me this:

errol@jetson:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 7e:9c:ac:3d:a9:5f brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.12/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 604588sec preferred_lft 604588sec
inet6 fe80::d0c:f50:872d:e4a6/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: l4tbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ea:26:19:a2:11:81 brd ff:ff:ff:ff:ff:ff
5: rndis0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000
link/ether ea:26:19:a2:11:81 brd ff:ff:ff:ff:ff:ff
6: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000
link/ether ea:26:19:a2:11:83 brd ff:ff:ff:ff:ff:ff

bootloader.log (19.8 KB)
dmesg.log (53.1 KB)

Thank you,
Errol

Could you use public tool i2cdump to scan the eeprom there and see if your mac addr is really the “ 00:04:4b:e7:17:cc”?

I found a script here somewhere here on the forum that reads the I2C eeprom and rebuilds the mac. It returns this:

MAC address is 00:04:4b:e7:17:cc

Running just the i2cdump command from the script gives me this:

errol@jetson:~$ i2cdump -y -r 172-177 2 0x50 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
a0: cc 17 e7 4b ???K
b0: 04 00 ?.

Instead of sdcard image, could you also try to use sdkmanager to flash your board and see if this issue is still there?

I will look into sdkmanager, but as far as I know my Nano B2 does not have embedded storage? The mtbblock device is only 4MB in size?

errol@jetson:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 16M 1 loop
mtdblock0 31:0 0 4M 0 disk
mmcblk0 179:0 0 29.7G 0 disk
├─mmcblk0p1 179:1 0 29.7G 0 part /
├─mmcblk0p2 179:2 0 128K 0 part
├─mmcblk0p3 179:3 0 448K 0 part
├─mmcblk0p4 179:4 0 576K 0 part
├─mmcblk0p5 179:5 0 64K 0 part
├─mmcblk0p6 179:6 0 192K 0 part
├─mmcblk0p7 179:7 0 384K 0 part
├─mmcblk0p8 179:8 0 64K 0 part
├─mmcblk0p9 179:9 0 448K 0 part
├─mmcblk0p10 179:10 0 448K 0 part
├─mmcblk0p11 179:11 0 768K 0 part
├─mmcblk0p12 179:12 0 64K 0 part
├─mmcblk0p13 179:13 0 80K 0 part
└─mmcblk0p14 179:14 0 128K 0 part
zram0 252:0 0 495.5M 0 disk [SWAP]
zram1 252:1 0 495.5M 0 disk [SWAP]
zram2 252:2 0 495.5M 0 disk [SWAP]
zram3 252:3 0 495.5M 0 disk [SWAP]

Hi,

Sdkmanager will also flash the it to your sdcard.

Hi, I am having the same issue. Is there any other method ? Unfortunately I don’t have a compatible device to install the SDkmanager . I flashed a new sdcard but the issue persists.
Thank you.

SDK Manager is a No Go.

Apparently Ubuntu 19.10 is not supported as a desktop PC version for running SDK Manager.

I can’t load Ubuntu 18.04 onto my Nano because my desktop is running Ubuntu 19.10?
My other desktop is running Ubuntu 20…

1 Like

Hi,

If both of you cannot use sdkmanager to flash your sdcard, there are few debug needed from your side

  1. If you have more than one jetson nano devices, please plug out the sdcard and put it into those jetson nanos and see if issue is still. If issue is still, then this issue comes from software. Otherwise, it is hardware issue.

  2. Please add some print in below kernel driver, and see why the mac address is not read from nvidia,ethernet-mac.

kernel/nvidia/drivers/net/ethernet/realtek/r8168_n.c

I installed SDKmanager on a virtual machine.

SDKmanager gets stuck flashing the board. Last command in log is:
tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml

Unfortunately, sdkmanager does not support on VM.
Please install dual boot on your host or find another ubuntu host for it.

Ok, I set up a fresh Ubuntu 18.04 PC. Got Jetson Nano flashed to SDK 4.4.

Still same issue.

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.12/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 604765sec preferred_lft 604765sec
inet6 fe80::534b:4e:7aca:ece1/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Hi,

Ok. Please check comment #12.

This issue is kind of new. We didn’t receive such error symptom before so need your help to add debug print to driver.

I’m busy trying to build the source. The instructions at https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/kernel_custom.html isn’t very clear.

I’m compiling the kernel on the Jetson Nano. I have compiled the kernel itself in the kernel-4.9 folder. But that did not compile the modules in the nvidia folder.

Also, the instructions at the above linked page then tells you how to copy the kernel when you are compiling in a host PC and want to integrate that new kernel into sdkmanager. It does not tell you how to install the kernel when you compiled on the Nano.

My suggestion is download the kernel source from here to your host.

and follow the instructions on the document to cross compile the kernel on your host.

I have figured out how to compile on the Nano. Much easier to do it this way when ssh-ing into the Nano.

This is what I have figured out so far:
In the function rtl8168_get_mac_address I have found that:
tp->mcfg = 29

And the code:

            *(u32*)&mac_addr[0] = rtl8168_eri_read(ioaddr, 0xE0, 4, ERIAR_ExGMAC);
            *(u16*)&mac_addr[4] = rtl8168_eri_read(ioaddr, 0xE4, 2, ERIAR_ExGMAC);

Does return the 00:00:00:00:00:01 mac address.

I have not yet figured out what is going wrong in rtl8168_eri_read/rtl8168_eri_read_with_oob_base_address

As a side note, if I understand the data being printed then:

(u32)&mac_addr[0] = rtl8168_eri_read(ioaddr, 0xE0, 4, ERIAR_ExGMAC);

Returns “0”

(u16)&mac_addr[4] = rtl8168_eri_read(ioaddr, 0xE4, 2, ERIAR_ExGMAC);

Returns “256”

I don’t know if this helps, but this is the contents of /proc/net/r8168/eth0/driver_var

Dump Driver Variable
Variable Value


MODULENAME r8168
driver version 8.045.08-NAPI
chipset 29
chipset_name RTL8168H/8111H
mtu 1500
NUM_RX_DESC 0x400
cur_rx 0x2372
dirty_rx 0x2372
NUM_TX_DESC 0x400
cur_tx 0x13a6
dirty_tx 0x13a6
rx_buf_sz 0x5f3
esd_flag 0x0
pci_cfg_is_read 0x1
rtl8168_rx_config 0xcf00
cp_cmd 0x20e1
intr_mask 0x115
timer_intr_mask 0x4000
wol_enabled 0x1
wol_opts 0x20
efuse_ver 0x3
eeprom_type 0x0
autoneg 0x1
duplex 0x1
speed 1000
eeprom_len 0x0
cur_page 0x0
bios_setting 0x0
features 0x2
org_pci_offset_99 0x4
org_pci_offset_180 0x10
issue_offset_99_event 0x0
org_pci_offset_80 0x42
org_pci_offset_81 0x0
use_timer_interrrupt 0x1
HwIcVerUnknown 0x0
NotWrRamCodeToMicroP 0x0
NotWrMcuPatchCode 0x0
HwHasWrRamCodeToMicroP 0x1
sw_ram_code_ver 0x18
hw_ram_code_ver 0x18
rtk_enable_diag 0x0
ShortPacketSwChecksum 0x0
UseSwPaddingShortPkt 0x0
RequireAdcBiasPatch 0x1
AdcBiasPatchIoffset 0x56a8
RequireAdjustUpsTxLinkPulseTiming 0x1
SwrCnt1msIni 0x7bd
HwSuppNowIsOobVer 0x1
HwFiberModeVer 0x0
RequiredSecLanDonglePatch 0x0
HwSuppDashVer 0x0
DASH 0x0
dash_printer_enabled 0x0
HwSuppKCPOffloadVer 0x0
speed_mode 0x3e8
duplex_mode 0x1
autoneg_mode 0x1
aspm 0x1
s5wol 0x0
s5_keep_curr_mac 0x0
eee_enable 0x0
hwoptimize 0x0
proc_init_num 0x1
s0_magic_packet 0x0
HwSuppMagicPktVer 0x2
HwSuppCheckPhyDisableModeVer 0x2
HwPkgDet 0x0
random_mac 0x0
org_mac_addr 00:00:00:00:00:01
perm_addr 00:00:00:00:00:01
dev_addr 00:00:00:00:00:01

This reminds me an old issue here. Could you check if that helps?