DietPi is using an out-of-date u-boot that doesn't set a fixed MAC address on Quartz64A

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN


  • Kernel version | uname -a

Linux DietPi 6.5.8 #1 SMP PREEMPT Sat Oct 21 20:01:59 UTC 2023 aarch64 GNU/Linux

  • Architecture | dpkg --print-architecture


  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

Quartz64 (aarch64)

  • Power supply used | (EG: 5V 1A RAVpower)

12V 5A POWER SUPPLY with 5.5mm OD/2.1mm ID DC Jack - EU version

  • SD card used | (EG: SanDisk ultra)

Samsung Evo Select MB-ME256KA/EU microSDXC UHS-I U3

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
  • Was the software title installed freshly or updated/migrated?
  • Can this issue be replicated on a fresh installation of DietPi?
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. Plug the Quartz64A to a router via Ethernet cable ;
  2. Assign a static IP address to the Quartz64A from the router.

Expected behaviour

  • The static IP address keeps working indefinitely.

Actual behaviour

  • The static IP address eventually stops working because the Quartz64A’s MAC address changed.

Extra details

  • counterpillow on Discord told me the following :

your dietpi image is using an out-of-date u-boot that doesn’t set a fixed MAC address
Plebian doesn’t suffer from this.

I have no idea what that means but I hope someone here does and fixes the issue.


@MichaIng could you have a look pls.


I’m noticing that the person you pinged hasn’t posted anything in a week and a half, could there possibly be someone else who could manage this ?

I bought this SBC so it could replace this old energy-consuming desktop PC that I was using as a server, and I already installed it where the PC was, expecting the migration to be fast.

Because of this issue that prevents me to get my services online on it, I had to power the desktop back up, except it doesn’t have dedicated space and cables anymore, so, additionally to eating electricity, it’s in the middle of the living room, in the way between everything.


Well this is our core developer or better to say the only developer the project has. Be patient, as we work on this project within our spare time :wink: and sometimes real life takes priority.


It has no fixed Ethernet MAC address? I never recognised this, let me have a look. Ideally there would be a serial number based (fixed) MAC.

I always wanted to switch to recent U-Boot. The changes previously required (when mainline support was not there) could at some point not be rebased anymore, respectively I filed to do, when mainline U-Boot started to implement an own solution for external SPL and DDR blobs. However, now that it is there, it should work without the custom commits.

Lets see whether this works: v8.25 · MichaIng/DietPi@fd38be5 · GitHub
Builds are running: quartz64 · MichaIng/DietPi@880ed24 · GitHub
Packages can be found here once done: Index of /downloads/binaries/testing

EDIT: Do not install them, they are not booting. I need to look into it tomorrow.

EDIT2: Okay, they actually seem to work fine and I just run into an issue I face sometimes with my SOQuartz, when it becomes too hot, I think:

U-Boot 2023.10 (Nov 21 2023 - 22:37:53 +0000)

Model: Pine64 RK3566 SoQuartz with CM4-IO Carrier Board
DRAM:  4 GiB (effective 3.7 GiB)
PMIC:  RK8090 (on=0x10, off=0x00)
Core:  308 devices, 25 uclasses, devicetree: separate
MMC:   mmc@fe2b0000: 1, mmc@fe2c0000: 2, mmc@fe310000: 0
Loading Environment from nowhere... OK
In:    serial@fe660000
Out:   serial@fe660000
Err:   serial@fe660000
Model: Pine64 RK3566 SoQuartz with CM4-IO Carrier Board
Net:   No ethernet found.
Hit any key to stop autoboot:  0
** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with extlinux
1:      DietPi
Retrieving file: /boot/vmlinuz
append: root=PARTUUID=edcf3e8d-01 rootfstype=ext4 rootwait earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 console=tty1 consoleblank=0 net.ifnames=0
Retrieving file: /boot/rk3566-soquartz-cm4.dtb
   Uncompressing Kernel Image
Moving Image from 0x2080000 to 0x2200000, end=44c0000
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
Boot failed (err=-14)

It finds the partition with the extlinux config, appends the correct cmdline, loads the kernel image and the device tree into memory. But then it somehow fails to load the device tree from memory (as far as I interpret the output). I will check back tomorrow.

Looking forward to it, thanks !

I am waiting for the MAC fix as well. :slight_smile:

How is it going ?

Managed to get it working now. The default RAM address for the compressed kernel image seems to be too close to the address of the device tree, though actually there should be 1 MiB space between them. However, moving the compressed kernel to another region (matching the one used by our old/forked U-Boot), it works: v8.25 · MichaIng/DietPi@79fd7d5 · GitHub
Not sure whether I am interpreting something wrong, we are doing something wrong or it is a bug or too strict for some cases (e.g. depending on the actual size of the kernel image). I am checking back with U-Boot folks: [RK3568] Default kernel_comp_addr_r can be too narrow

The new U-Boot environment shows as well the MAC address variables:


I hope they are different in your case, i.e. not hardcoded but based on the individual adapter/hardware. ethaddr is the one which is finally effective, I guess it sets the address for eth0 and eth1addr for eth1 it that even exists:

root@SOQuartz:~# ip l
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 1a:80:0a:2c:9f:50 brd ff:ff:ff:ff:ff:ff

Just to be sure (because it is a major U-Boot change), would be great if one of you could test it as well: Index of /downloads/binaries/testing

There’s no IMG file in there. What am I supposed to do with the DEBs ?

Hello ?

deb files to be download and install.

So these will have to be manually installed everytime someone flashes DietPi on a new device ?

actually, this is for testing only. If this is working, it will become part of regular image / install process.

Well, it’s working. However, I’ll still wait for an IMG so that I’ll have no surprises in case I need to format. Thanks

ping @MichaIng

With a Quartz64 A it would be:

cd /tmp
curl -fO ''
dpkg -i firmware-quartz64a.deb
rm firmware-quartz64a.deb

I’ll generate images with them: DietPi-Build · MichaIng/DietPi@7b30914 · GitHub
You can find them here once done in ~30 minutes: Index of /downloads/images/testing

Is that the one ?


Yes should be the one within testing folder.