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 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.
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.
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
and sometimes real life takes priority.