PYNQ: PYTHON PRODUCTIVITY

Ethernet MAC address changes everytime restart the ZCU104 board

Is it usual for ethernet mac address changing in ZCU104 every time when the board is restarted? I am connecting the board via a DHCP server, and every time I restart it allocates a new IP as the MAC address of the ethernet port is always changes whenever the board is restarted. There is a limited number of free IPs, so when the numbers went out I can’t connect anymore. Also, the network administration is not in my control. Here is the two instances of ifconfig:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 192.168.104.200  netmask 255.255.255.0  broadcast 192.168.104.255
    inet6 fde2:8acd:e9d3:0:a4cf:93ff:fe63:aea7  prefixlen 64  scopeid 0x0<global>
    inet6 fe80::a4cf:93ff:fe63:aea7  prefixlen 64  scopeid 0x20<link>
    ether a6:cf:93:63:ae:a7  txqueuelen 1000  (Ethernet)
    RX packets 24  bytes 2710 (2.7 KB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 69  bytes 10222 (10.2 KB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device interrupt 30

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    inet6 ::1  prefixlen 128  scopeid 0x10<host>
    loop  txqueuelen 1000  (Local Loopback)
    RX packets 388  bytes 31694 (31.6 KB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 388  bytes 31694 (31.6 KB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Another one:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.104.176  netmask 255.255.255.0  broadcast 192.168.104.255
        inet6 fe80::1cb3:3eff:fe8c:107b  prefixlen 64  scopeid 0x20<link>
        ether 1e:b3:3e:8c:10:7b  txqueuelen 1000  (Ethernet)
        RX packets 3  bytes 746 (746.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 65  bytes 8278 (8.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 30

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 217  bytes 21070 (21.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 217  bytes 21070 (21.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Is there any way to set up a fixed MAC address?
Thanks,
Mizan

I changed the MAC id to be static by adding a line - hwaddress ether 08:00:00:00:00:01 in the file nano /etc/network/interfaces.d/eth0 .
It might solve the problem. Waiting for the network administrator to free up the IPs.

This isn’t normal - the MAC address should be read out of an EEPROM at start-up and match what’s printed on the sticker on the board. Which PYNQ image are you using and can you supply the u-boot portion of the boot log?

Peter

I have removed the line mentioned in the previous post. And restart the board.
I am using the stock image for zcu104 (PYNQ version 2.6).
In starting the boot, it is stating it is using random MAC address. Don’t know the cause though.

U-Boot 2020.01 (Oct 19 2020 - 19:26:48 +0000)

Model: ZynqMP ZCU104 RevC
Board: Xilinx ZynqMP
DRAM:  2 GiB
PMUFW:  v1.1
EL Level:       EL2
Chip ID:        zu7
NAND:  0 MiB
MMC:   mmc@ff170000: 0
In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Bootmode: LVL_SHFT_SD_MODE1
Reset reason:   EXTERNAL
Net:
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id

Warning: ethernet@ff0e0000 (eth0) using random MAC address - ae:20:1e:de:26:57
eth0: ethernet@ff0e0000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
1636 bytes read in 13 ms (122.1 KiB/s)
## Executing script at 20000000
17540848 bytes read in 1157 ms (14.5 MiB/s)
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux Kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x100000d4
     Data Size:    17494528 Bytes = 16.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x00080000
     Entry Point:  0x00080000
     Hash algo:    sha1
     Hash value:   87284f4f203116259a0e107ad3130d533b95d131
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@1' configuration
   Trying 'fdt@0' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x110af3cc
     Data Size:    44493 Bytes = 43.5 KiB
     Architecture: AArch64
     Hash algo:    sha1
     Hash value:   8c67c4af310a0234cfd574f1a792ff13cc6b7922
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x110af3cc
   Loading Kernel Image
   Loading Device Tree to 000000000fff2000, end 000000000ffffdcc ... OK

Would you be able to send over the BOOT.BIN on your SD card? I know it should be the same as stock but I just want to check. Failing that I don’t know why it’s not finding the MAC address.

You can see if something’s gone wrong with the EEPROM by reading back the MAC address in Linux:

sudo dd if=/sys/bus/i2c/drivers/at24/2-0054/2-00540/nvmem bs=16 count=1 skip=2 | xxd

The MAC address should be there. You might need to change the PATH slightly if the i2c adapters are enumerated differently. This should match the sticker on the board.

Peter

The output command as follows:

dd: /sys/bus/i2c/drivers/at24/2-0054/2-00540/nvmem: cannot skip to specified off                     set
1+0 records in
1+0 records out
00000000: 0102 0304 0506 ffff ffff ffff ffff ffff  ................
16 bytes copied, 0.00089533 s, 17.9 kB/s

Here is the Boot file.
BOOT.BIN (1.2 MB)

For me, the problem was the MAC address changing, now it is fixed by changing the ethernet mac address masking. So far I have no problem now.
Always appreciate your support.

It looks like your board has an invalid MAC address in its EEPROM - the 010203040506 should be the MAC address. I don’t know how this would have occurred. You can change it if you like by updating offset 0x20 in that device but given you have a suitable workaround for now it’s probably not worth the effort.