Orange Pi 5 | MAC address changes on reboot

[thuehlinger]

Required Information

• DietPi version |

G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=22
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | bullseye
• Kernel version | Linux orange 5.10.160-legacy-rk35xx #1 SMP Mon Aug 28 01:21:24 UTC 2023 aarch64 GNU/Linux
• SBC model | Orange Pi 5 (aarch64)
• Power supply used | 5V 3A
• SD card used | none (booting from NVMe)

Steps to reproduce

1. Update uBoot bootloader boot on SPI Flash and on NVMe to latest version included in DietPi 8.22.3 using dietpi-config
2. Reboot, check MAC address assigned (or check kernel output using sudo dmesg | grep random-> [ 4.414068] rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: generate random eth mac address: 02:63:3b:54:c3:54
3. Reboot again, check MAC address: it will have changed

Expected behaviour

The MAC address should be the same, as it was the case when originally installing DietPi (older version), using the uBoot loader contained in the supplier-provided custom Ubuntu image (by OrangePi). Without the MAC address being the same on every reboot, I cannot assign a static IP address using DHCP on my home network router.

Actual behaviour

The MAC address gets randomly assigned on every reboot.

Extra details

This might be the same issue a reported here: https://github.com/Joshua-Riek/ubuntu-rockchip/issues/274, with the solution being to revert this change https://github.com/orangepi-xunlong/u-boot-orangepi/commit/1f70ac3a968d121d86350092a7eff0dbd56114b7.

[MichaIng]

Does it help to add ethaddr=02:63:3b:54:c3:54 to /boot/dietpiEnv.txt, to have this MAC address persistent?

[Joulinar]

@MichaIng adding the value doesn't change anything on my Opi5 demo system

root@DietPiOPi5:~# cat /boot/dietpiEnv.txt | grep ethaddr
ethaddr=8a:33:ce:b3:b0:b9
root@DietPiOPi5:~#

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f2:fc:39:46:ef:1d brd ff:ff:ff:ff:ff:ff

root@DietPiOPi5:~# journalctl | grep rk_gmac-dwmac
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: IRQ eth_lpi not found
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: Looking up phy-supply from device tree
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: Looking up phy-supply property in node /ethernet@fe1c0000 failed
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: no regulator found
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: clock input or output? (output).
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: TX delay(0x42).
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: Can not read property: rx_delay.
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: set rx_delay to 0xffffffff
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: integrated PHY? (no).
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: cannot get clock mac_clk_rx
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: cannot get clock mac_clk_tx
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: cannot get clock clk_mac_speed
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: init for RGMII_RXID
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: User ID: 0x30, Synopsys ID: 0x51
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet:         DWMAC4/5
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: DMA HW capability register supported
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: RX Checksum Offload Engine supported
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: TX Checksum insertion supported
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: Wake-Up On Lan supported
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: TSO supported
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: Enable RX Mitigation via HW Watchdog Timer
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: rk_vendor_read eth mac address failed (-1)
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: generate random eth mac address: f2:fc:39:46:ef:1d
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: rk_vendor_write eth mac address failed (-1)
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: id: 1 rk_vendor_read eth mac address failed (-1)
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: mac address: f2:fc:39:46:ef:1d
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: device MAC address f2:fc:39:46:ef:1d
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: Enabled Flow TC (entries=2)
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: TSO feature enabled
Dec 21 14:11:31 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet: Using 32 bits DMA width
Dec 21 14:11:32 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet eth0: PHY [stmmac-1:01] driver [YT8531 Gigabit Ethernet] (irq=POLL)
Dec 21 14:11:32 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet eth0: No Safety Features support found
Dec 21 14:11:32 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
Dec 21 14:11:32 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet eth0: registered PTP clock
Dec 21 14:11:32 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet eth0: configuring for phy/rgmii-rxid link mode
Dec 21 14:11:35 DietPiOPi5 kernel: rk_gmac-dwmac fe1c0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
root@DietPiOPi5:~#

[MichaIng]

And eth1addr=8a:33:ce:b3:b0:b9 does neither, right? As an alternative until we found a better solution, you can add the following line below the iface eth0 line in /etc/network/interfaces

pre-up /bin/ip l set dev eth0 address 8a:33:ce:b3:b0:b9

[thuehlinger]

Creating /etc/network/interfaces.d/eth0 with content

iface eth0 inet dhcp
hwaddress ether 8a:33:ce:b3:b0:b9

has worked for me, which is of course essentially equivalent to what @MichaIng has proposed above.

[MichaIng]

Ah, hwaddress is the option I somehow failed to find on the man pages. Yeah it will do the same behind the scenes, but is clearly easier and the more native/preferred way. Thanks for sharing.

For others: Note that iface eth0 should then be removed from /etc/network/interfaces, or above option added there. IIRC ifup does not like doubled iface definitions.

[Joulinar]

But /etc/network/interfaces will be overwritten using dietpi-config right?

[MichaIng]

Jep, and as well iface eth0 will be re-added when using dietpi-config to change network settings. So for now, use it once to setup network access initially, then add the hwaddress setting either to /etc/network/interfaces or a separate config, then do not use dietpi-config anymore.

[el-bakkali]

I have the same problem with the orange pi 3b is this a known issue and ssomething to do with the kernel or realtek driver ?

wiil this likely be fixed in the future. Also i own a orange Pi zero 3, and that doesnt have the problem, is the issue only with rockchip ?

Does the above fix work also the same for my orange pi 3b ?

[MichaIng]

First of all, on my Orange Pi 5, the MAC address is static:

root@DietPi:~# ip l
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b6:88:86:ed:09:3c brd ff:ff:ff:ff:ff:ff
    altname end1
root@DietPi:~# reboot
root@DietPi:~# ip l
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b6:88:86:ed:09:3c brd ff:ff:ff:ff:ff:ff
    altname end1
root@DietPi:~# uname -a
Linux DietPi 5.10.160-legacy-rk35xx #1 SMP Fri Feb 2 07:51:33 UTC 2024 aarch64 GNU/Linux
root@DietPi:~# cat /proc/device-tree/model
Orange Pi 5
root@DietPi:~# dmesg | grep random
[    7.861660] random: crng init done

@thuehlinger @Joulinar is yours still getting a new one every (re)boot?

I do not own an Orange Pi 3B, but on the Orange Pi 5 Plus, the MAC addresses of both Ethernet addresses are static as well.

Orange Pi 3B however has a different chip (RK3566 vs RK3588) and uses a kernel build based on mainline Linux (just with a device tree based on Orange Pi's one), instead of Rockchip's legacy kernel sources. So the situation is quite different.

Mainline Linux does not provide any Orange Pi 3B device tree, hence that one is based on the one from Xunlong, and indeed they are identical mostly, definitely in everything related to Ethernet:

• https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.8/dt/rk3566-orangepi-3b.dts
• https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.6-rk35xx/arch/arm64/boot/dts/rockchip/rk3566-orangepi-3b.dts

Btw, Armbian took that board out of (community) support, due to reports where Ethernet was not working at all (for some, for others it works), pointing to a Xunlong/Orange Pi information that the SBC was taken out of sale for investigation hardware-related Ethernet issues, likely resulting in a new revision. So I do not expect any development done any time soon: https://github.com/armbian/build/issues/6587

However, just to have a look, and the option to test some device tree changes which fixed such on other SBCs, two things:

• I am building a new kernel, based on latest upstream Linux 6.8 and Armbian build system: https://github.com/MichaIng/DietPi/actions/runs/9064063483
• And could you check whether you see any similar kernel messages/errors than reported above?

  dmesg -l 0,1,2,3
  dmesg | grep -E 'gmac|eth|random'
  

[thuehlinger]

I can confirm that with the current kernal (now the one you are building now), Linux orange 5.10.160-legacy-rk35xx #1 SMP Fri Feb 2 07:51:33 UTC 2024 aarch64 GNU/Linux , the issue still persists:

[    4.331423] rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: rk_vendor_read eth mac address failed (-1)
[    4.331437] rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: generate random eth mac address: 2a:13:e4:cd:4b:3f
[    4.331448] rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: rk_vendor_write eth mac address failed (-1)
[    4.331458] rk_gmac-dwmac fe1c0000.ethernet: rk_get_eth_addr: id: 1 rk_vendor_read eth mac address failed (-1)

For me the issue appeared after I had flashed the SPI bootloader using the option in dietpi-config. Now I actually want to repeat this step, but it turns out that when trying to navigate to Advanced Options, dietpi-config just returns to the main menu. So this part is now either broken or empty on my system. Any idea why?

[MichaIng]

So then the bootloader (MMC vs SPI) seems to make the difference. I use an SD card, hence MMC bootloader. There is no way to switch to the SPI bootloader, is it? I'll try to just erase the MMC one from the SD card, so I must try with SPI.

[MichaIng]

Regarding advenced options, a syntax error: https://github.com/MichaIng/DietPi/commit/da7af8e I'll push a live patch: #7070 EDIT: Done, so dietpi-update should offer you a live patch to fix it.

[MichaIng]

Tested with (recent) SPI bootloader now, by erasing the MMC one:

U-Boot SPL board init
U-Boot SPL 2017.09 (Feb 25 2024 - 00:42:52)
Trying to boot from MMC1
Trying fit image at 0x4000 sector
Not fit magic
Trying fit image at 0x5000 sector
Not fit magic
Trying to boot from MMC2
Card did not respond to voltage select!
spl: mmc init failed with error: -95
Trying to boot from MTD2
Trying fit image at 0x4000 sector
## Verified-boot: 0
## Checking atf-1 0x00040000 ... sha256(7efcd01a0f...) + OK
## Checking uboot 0x00200000 ... sha256(9452905bf1...) + OK
## Checking fdt 0x00349578 ... sha256(bcb1d629f4...) + OK
## Checking atf-2 0xff100000 ... sha256(1163474a5b...) + OK
## Checking atf-3 0x000f0000 ... sha256(da90adf3a4...) + OK
Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000)
Total: 529.914 ms

root@DietPi:~# dmesg | grep random
[    8.502687] random: crng init done
[   11.248191] systemd[1]: Starting systemd-random-seed.service - Load/Save Random Seed...

And my MAC address is still the same. Just to be sure, retested with a cold boot, and still the same MAC. So seems that the U-Boot upgrade fixed it. Please verify your end.

[thuehlinger]

Thanks for the advanced option fix, works like a charm! I have flashed the most recent SPI bootloader and indeed, it fixes my random MAC address issue as well. MAC address is now static again. Thanks!

[MichaIng]

Okay great. I wonder whether it's worth to flash it automatically on next DietPi update, or at least offer it or inform about it. Based on $G_ROOTFS_DEV being /dev/mmcblk* or something else, we know whether the MMC bootloader or SPI bootloader is used. We can then flash the respective one, or tell users which one they would need to flash, to fix the volatile MAC address.

[thuehlinger]

Forcing the user to flash their bootloader is maybe a bit intrusive and dangerous, but offering it as an option could be a viable way. After all, the original bootloader shipped with OrangePi distributions did allow to correctly read out the static MAC. It was just me eager to update it on an ealier DietPi distribution that broke it.