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:
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?
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:
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.
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
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.
Hi,
it seems I have a similar problem (with the same symptoms) on a ZCU208 using pynq v3.0.1:
Net:
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id
zynq_gem ethernet@ff0e0000: Failed to read eth PHY id, err: -2
Warning: ethernet@ff0e0000 (eth0) using random MAC address - f2:d9:c3:8b:2e:4d
eth0: ethernet@ff0e0000
Using the suggested command to read the EEPROM I get:
# dd if=/sys/bus/i2c/drivers/at24/6-0054/6-00542/nvmem bs=16 count=1 skip=2 | xxd
1+0 records in
1+0 records out
00000000: 312e 3300 0a35 07d7 fb00 0a35 07d7 fc00 1.3..5.....5....
while the MAC address according to the label on the back of the board should be: 00:0A:35:07:D7:FB. It seems to be on a different offset, and followed by another address.
The board is brand new. Can I just use the workaround proposed in this thread to have a permanent MAC address, or should I be worried about other problems that may arise in the future?
I ran into this problem too with a ZCU111. I solved it by setting the ethaddr variable during the boot process. Basically the steps are as follows:
Connect to the board using a com port
Power cycle the board, while it boots up, you should see the boot process in your com terminal. Press any key to interrupt the boot process.
Optionally print the current MAC address using printenv ethaddr
Set the MAC address using setenv -f ethaddr <mac address>
Save it to permanent storage using saveenv
Restart the boot using reset
The board should now have the same MAC address each time it powers on. You’ll have to repeat this process if you re-flash the SD card so make sure to check the MAC address and write it down before if you want to keep it consistent through PYNQ upgrades, etc.
Hi, this is a known issue for v3.0 images of the ZCU111 and ZCU208 boards. We have a fix for this that will be applied in future image builds mac addressing fix for zcu111 and zcu208 (#17) · Xilinx/RFSoC-PYNQ@9396d96 · GitHub. If you don’t want to build a new image from that branch then Jenny’s method is likely the easiest solution in the interim.
