Hi,
a strange phenomenon has recently been occurring on one RPi4 and three RPi Zeros.
In the DietPi banner, the RPi4 now displays ‘Generic Device (aarch64)’ instead of the correct designation ‘RPi 4 Model B (aarch64)’.
On the three Zeros, ‘Generic Device (arm6l)’ also appears.
This is surprising in that all other Pi’s have the correct names.
So it is not a fundamental error in the DietPi banner, but must only affect these four Pi’s.
Well, it is only a minor flaw, but I am still interested in how this could have come about.
The only thing I’ve deliberately done on these, and indeed on all the other Pi’s, was to enable or disable ZRAM and SWAP depending on usage.
But why does this effect not occur on all devices, but only on these four Pi’s?
Regards, Carsten
check following
cat /boot/dietpi/.hw_model
echo $G_HW_MODEL_NAME
root@adguard-home:\~# cat /boot/dietpi/.hw_model
G_HW_MODEL=22
G_HW_MODEL_NAME=‘Generic Device (aarch64)’
G_HW_ARCH=3
G_HW_ARCH_NAME=‘aarch64’
G_HW_CPUID=0
G_HW_CPU_CORES=4
G_DISTRO=8
G_DISTRO_NAME=‘trixie’
G_ROOTFS_DEV=‘/dev/sda2’
G_HW_UUID=‘135cd3fe-4458-46dc-be34-6fd1675c8b51’
root@adguard-home:\~# echo $G_HW_MODEL_NAME
Generic Device (aarch64)
root@adguard-home:\~# cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.5
But it is a Pi 4, after all – it’s not just the latest version that shows it, I can see it with my own eyes too.
So why is it being misinterpreted?
try
ls -la /boot/{,firmware/}bcm*-rpi-*\.dtb
cat /etc/.dietpi_hw_model_identifier
rm /etc/.dietpi_hw_model_identifier
rm /boot/dietpi/.hw_model
/boot/dietpi/func/dietpi-obtain_hw_model
cat /boot/dietpi/.hw_model
root@adguard-home:~# ls -la /boot/{,firmware/}bcm*-rpi-*\.dtb
ls: cannot access '/boot/bcm*-rpi-*.dtb': No such file or directory
-rwxr-xr-x 1 root root 26457 May 14 2023 /boot/firmware/bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 25797 May 14 2023 /boot/firmware/bcm2708-rpi-b-rev1.dtb
-rwxr-xr-x 1 root root 26186 May 14 2023 /boot/firmware/bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 26108 May 14 2023 /boot/firmware/bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 27282 May 14 2023 /boot/firmware/bcm2708-rpi-zero-w.dtb
-rwxr-xr-x 1 root root 25931 May 14 2023 /boot/firmware/bcm2708-rpi-zero.dtb
-rwxr-xr-x 1 root root 27332 May 14 2023 /boot/firmware/bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root 29253 Jul 28 2022 /boot/firmware/bcm2709-rpi-cm2.dtb
-rwxr-xr-x 1 root root 32495 Mar 11 16:54 /boot/firmware/bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root 35322 Mar 11 16:54 /boot/firmware/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 34687 Mar 11 16:54 /boot/firmware/bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 33676 Mar 11 16:54 /boot/firmware/bcm2710-rpi-cm0.dtb
-rwxr-xr-x 1 root root 32258 Mar 11 16:54 /boot/firmware/bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 33664 Mar 11 16:54 /boot/firmware/bcm2710-rpi-zero-2-w.dtb
-rwxr-xr-x 1 root root 33664 Mar 11 16:54 /boot/firmware/bcm2710-rpi-zero-2.dtb
-rwxr-xr-x 1 root root 56249 Mar 11 16:54 /boot/firmware/bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 56253 Mar 11 16:54 /boot/firmware/bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root root 39913 Mar 11 16:54 /boot/firmware/bcm2711-rpi-cm4-io.dtb
-rwxr-xr-x 1 root root 56770 Mar 11 16:54 /boot/firmware/bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root root 53760 Mar 11 16:54 /boot/firmware/bcm2711-rpi-cm4s.dtb
-rwxr-xr-x 1 root root 78740 Mar 11 16:54 /boot/firmware/bcm2712-d-rpi-5-b.dtb
-rwxr-xr-x 1 root root 78744 Mar 11 16:54 /boot/firmware/bcm2712-rpi-5-b.dtb
-rwxr-xr-x 1 root root 78700 Mar 11 16:54 /boot/firmware/bcm2712-rpi-500.dtb
-rwxr-xr-x 1 root root 79689 Mar 11 16:54 /boot/firmware/bcm2712-rpi-cm5-cm4io.dtb
-rwxr-xr-x 1 root root 79755 Mar 11 16:54 /boot/firmware/bcm2712-rpi-cm5-cm5io.dtb
-rwxr-xr-x 1 root root 79730 Mar 11 16:54 /boot/firmware/bcm2712-rpi-cm5l-cm4io.dtb
-rwxr-xr-x 1 root root 79796 Mar 11 16:54 /boot/firmware/bcm2712-rpi-cm5l-cm5io.dtb
-rwxr-xr-x 1 root root 78748 Mar 11 16:54 /boot/firmware/bcm2712d0-rpi-5-b.dtb
root@adguard-home:~# cat /etc/.dietpi_hw_model_identifier
cat: /etc/.dietpi_hw_model_identifier: No such file or directory
root@adguard-home:~# rm /etc/.dietpi_hw_model_identifier
rm: cannot remove '/etc/.dietpi_hw_model_identifier': No such file or directory
root@adguard-home:~# rm /boot/dietpi/.hw_model
root@adguard-home:~# /boot/dietpi/func/dietpi-obtain_hw_model
root@adguard-home:~# cat /boot/dietpi/.hw_model
G_HW_MODEL=4
G_HW_MODEL_NAME='RPi 4 Model B (aarch64)'
G_HW_ARCH=3
G_HW_ARCH_NAME='aarch64'
G_HW_CPUID=0
G_HW_CPU_CORES=4
G_DISTRO=8
G_DISTRO_NAME='trixie'
G_ROOTFS_DEV='/dev/sda2'
G_HW_UUID='6279994a-108d-403c-98d5-873f918ece60'
G_HW_REVISION='c03115'
G_RASPBIAN=1
G_HW_ONBOARD_WIFI=1
G_HW_PCB_REVISION=5
G_HW_MEMORY_SIZE=4096
G_HW_MANUFACTURER='Sony UK'
It might be worth mentioning that I had forgotten to say I upgraded this one—as well as many others—to Trixie using your script from Bookworm a while back. But I’m pretty sure the device model was fine after that; it’s correct on all the other Pi’s after the upgrade, too.
The specifications for the Pi 4 listed above are just examples. For the sake of clarity, I’ve omitted the Pi Zero.
If you need them, I’d be happy to provide them later.
this looks good as the board is detected as RPI4 now
Wow, the Pi 4 is now a Pi 4 again and the Pi Zeros are Pi Zeros once more.
Thank you so much for your brilliant help!
Even though I don’t know much about it, could you explain what the problem was?
I don’t have a full explanation. It’s quite clear that the /boot/dietpi/.hw_model file was created incorrectly. It contains information about the system being used. It may have happened during a kernel package update. Normally, RPI systems are identified by the existing of .dtb files in /boot/firmware/. Anyway, deleting and recreating /boot/dietpi/.hw_model has sorted everything out.