Image | Raspberry Pi 5: Testing and firmware migration script

[TDuffinNTU]

ADMIN EDIT

First Raspberry Pi 5 testing images are available now on our download page: https://dietpi.com/#download You can also find images with the new kernel/firmware package set for other RPi models here: https://dietpi.com/downloads/images/testing/ The ones with the new firmware have "RPi1", "RPi2" and "RPi234" (64-bit) in their names. To migrate an existing system, use the migration script:

bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')

WARNING: This is currently a one-way ticket. dietpi-backup cannot be used to restore the old system, since the boot partition mount point has changed. If you want to be able to revert, create an image of the whole SD card/drive. dietpi-imager can be used from another DietPi (or Debian/Ubuntu) system, to minimise partition and filesystem automatically, to have a small compressed backup image.

---

• Device name | Raspberry Pi 5
• Official product URL | https://www.raspberrypi.com/products/raspberry-pi-5/
• GitHub resource URL (if available) | https://github.com/raspberrypi
• Image download URL |https://www.raspberrypi.com/software/

Is the SBC officially supported by the Debian installer?

• Yes(?) Looks like the board is inter-compatible with the same distro images as the 4B. That's pure speculation, mind you, but I did see a video of a reviewer transferring a Raspbian installation from a Pi4B to a Pi5 with no configuration necessary.

Notes

• Not sure if this needs any specific developer legwork as the previous Pis seem to be inter-compatible with OS images for the most part (though I'm sure testing and drivers will be necessary!). Thought I'd make this issue now since it might be good to mark the Pi5 as provisionally supported on the website if it at least works out of the box.

[MichaIng]

Hmm I applied beta to an existing system, runs fine on 4 still, put into 5 and fan just stays on full speed and no boot.

Did you run the second command/migration script after applying the beta? The beta (DietPi v8.25) is required for the migration script, but it does not imply the migration.

3. All kernel packages supported will be installed with the first boot, but will be replaced with its specific kernel packages (unnecessary one deleted) after it's complete setup, if the user says so via input (or 'dietpi-config' for headless setups). Non-headless would require an input from the user.

This is basically my option 1: The images would be shipped with all kernel packages pre-installed. The dietpi-config option to (de)select kernel packages (only those which are not required for the current model) will be added in both cases. The question is really only about whether we should provide less but larger images, compatible with more RPi models each, or more but smaller more targeted images, compatible with less RPi models each. "Diet" would be of course the 2nd option, but it would be also a change compared to our current RPi image lineup.

It would allow to install dietpi on an existing/running raspbian os

This works regardless which of those options we choose. The dietpi-installer will allow both ways anyway, an "all models" option as well as separate options for individual RPi models, at least if we chose option 2. Because I want to offer the new images separately for testing first, and the old ones (with old kernel) as stable releases for now. And when we switch to the new images with new kernel, there is no reason to remove the "all models" option from the installer. And the userland architecture is anyway given by the base OS you run the installer on.

For us, our traffic, build systems (with is GitHub Actions runners anyway) etc it does not matter. We have plenty of free traffic and I do not mind if images builds take some hours longer over night. The question really is whether OOTB flexibility to flash the same image on multiple different RPi models and switching SD card between them without needing to select an additional kernel first, is worth the added disk usage, increased downloads/processing/disk writes on kernel upgrades this implies, unless you deselect unneeded kernels first.

We could even host images for both variants 😄. But I would not want to overload the already overloaded download page with this, but keep them behind some "all downloads" button or so.

On the download page, option 2 would practically add two more RPi tiles: RPi 4 became a dedicated one, and RPi 5 an additional one. With option 1, RPi 5 would become part of the Raspberry Pi 2/3/4 tile: https://dietpi.com/#downloadinfo Side note: While we do already offer RPi images split this way, the "Raspberry Pi 1/Zero (1)" image is actually compatible with all RPi models, just not recommended (as 32-bit Raspbian based) for other RPi models. With option 2, this would change, and the RPi 1/Zero image would be indeed compatible with RPi 1/Zero only.

[LittleFreak]

Personally, I'm planning to use docker images (because the respective backups are smaller) for everything, so I don't need the flexibility to use the same SD card on different raspi gens. So °2 would be sufficient for me. I proposed °3 as compromise, because I'm not the center of the world (thanks god, we would be doomed XD)

[MichaIng]

I think I did not understand the difference between my option 1 and your option 3 yet. Option 1 means all kernel packages are pre-installed, but users can de-select unneeded kernels via dietpi-config. Could you explain what would be different in your option 3?

[jboots07]

Hmm I applied beta to an existing system, runs fine on 4 still, put into 5 and fan just stays on full speed and no boot.

Did you run the second command/migration script after applying the beta? The beta (DietPi v8.25) is required for the migration script, but it does not imply the migration.

EDIT: I didn't realize the

G_DEV_BRANCH beta

was needed before

I'll admit I am a noob, but I did my best.

The results were:

root@DietPi:~# bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')
[FAILED] dietpi-rpi-firmware-migration | You can run this script on Debian Bookworm or Trixie systems only!

[LittleFreak]

I think I did not understand the difference between my option 1 and your option 3 yet. Option 1 means all kernel packages are pre-installed, but users can de-select unneeded kernels via dietpi-config. Could you explain what would be different in your option 3?

Basically there is no difference, unless the required (specific) kernel could be downloaded on the fly. Now when I think it through, It would basically assume the opposite of °1=> Installing all other kernel packages only on the user's behalf

On the fly would be nice though

[jboots07]

Hmm I applied beta to an existing system, runs fine on 4 still, put into 5 and fan just stays on full speed and no boot.

Did you run the second command/migration script after applying the beta? The beta (DietPi v8.25) is required for the migration script, but it does not imply the migration.

EDIT: I didn't realize the

G_DEV_BRANCH beta

was needed before

I'll admit I am a noob, but I did my best.

The results were:

root@DietPi:~# bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')
[FAILED] dietpi-rpi-firmware-migration | You can run this script on Debian Bookworm or Trixie systems only!

Error persists

[MichaIng]

@jboots07 You are running a Bullseye system, I guess?

echo $G_DISTRO_NAME

You would need to upgrade to Bookworm first: https://dietpi.com/blog/?p=3128 The new firmware packages, including the ones required for RPi 5, are available on Bookworm only.

@LittleFreak Jep, all kernel packages can be installed on the fly. It is really not much more than an apt install call or some clicks through dietpi-config and waiting some minute(s) for download and install.

[btb23]

Best is to use root user for such activities. Anyway. Did you moved to latest DietPi v8.25 Beta before? And the Zero W was running 32bit before? Right?

I think I know the problem. I was told that the 2712 kernel supports 64-bit userland only, while you run 32-bit userland. I guess the RPi 5 picks this kernel with priority, but then fails to load the 32-bit init system. The v8 kernel supports RPi 5 as well and 32-bit.

Hence, please attach the card to the RPi Zero again, then:

G_AGP linux-image-rpi-2712

Then try again to boot it on RPi 5.

Thank you both. I abandoned the first zero W migration as I'd messed up, went again as root this time with a rpi2 i also had running and this time the migration went ahead.

Many thanks.

[jboots07]

All is well and working when I followed proper procedure, thank you!

[alfredoanton82]

Installed from an old Rpi3B, everything well and running! Thanks a lot @MichaIng, much appreciated all your work guys. Regarding the options, I would prefer 2nd, as I love dietpi for being light, so I would prefer install only the required kernel... but if it is less work for you or simplifies for rookies/starters... go ahead with 1st... Best regards!

[thejimp]

I created a first alpha version of a firmware migration script. Would be great if you guys could test it on your RPi systems. With this done, it should also support the RPi 5, i.e. you should be able to swap the SD card (or whichever boot media you use) to the RPi 5 and boot it.

But you must apply the current DietPi v8.25 beta first: #6801

Then apply the script like that:

G_DEV_BRANCH beta # for a quick switch + update to beta branch :)
bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')

It worked well on RPi Zero. Will migrate my RPi 2 now.

Can confirm this works fine going from RPi4 to RPi5 for me ,thanks!

I'd say option 1 was probably the most beginner-friendly option (and allows unexpected swapping between different models (e.g. if your main RPi dies, straightforward to swap to another one, no need to downlaod the relevant kernels). If someone wanted a super-minimal install, they can just uninstall them. I think that's a fair trade-off as a user.

Cheers for all your work maintaining DietPi, I've had my RPi for a couple of weeks, but I have been saving it until I can run DietPi on it!

[tonystower]

I created a first alpha version of a firmware migration script.

Thank you so much for this @MichaIng Once I had figure out that I had to do this using a root shell rather than just sudo, it worked perfectly.

I was moving from a Pi 400 to a pi5 and all seems fine so far. No hiccups at all. thanks again

[sorriso93]

Hello I assume 8.25.1 is ok to try the migration script for RPI5, correct?

[Joulinar]

Yes

[LittleFreak]

I'd like to test the install script for a setup on a running/existing arm64 raspbian os, to give it a diet 🫠😉 @MichaIng Pls hit me up, once it's ready for testing in that flavour =)

[terminet85]

G_EXEC mount "$G_ROOTFS_DEV" rootfs

G_EXEC mount "$G_ROOTFS_DEV" rootfs

If you have an btrfs's rootfs this is failing because subvol isn't passed correctly to mount command

[terminet85]

In an system where kernel is 64bit and userland 32bit, linux-headers is not installable because depends to gcc-12:arm64 that isn't available in http://raspbian.raspberrypi.org/raspbian bookworm repo.

[Trainax]

Great work!

Is there any ETA on when the compiled image for Raspberry Pi 5 will be released? I would like to test it however I don't have another Pi to run the migration script. Thanks

[MichaIng]

@terminet85 Thanks for the hind. It is basically the same underlying issue why arm64 needs to be added as foreign arch on 32-bit systems because the 64-bit kernel itself is not available on the armhf repo either. On Debian-based images this is not an issue, since Debian supports arm64, so this gcc can be installed from there, but I am actually wondering whether this causes conflicts with the armhf variant of the package, or whether it has sane multi-arch support. However, Raspbian of course does not support arm64 at all.

I reported this to the RPi maintainers as well.

[terminet85]

@MichaIng Almost they have included the headers... they forgot the dependence LoL https://github.com/raspberrypi/linux/issues/5408

Anyway my 2 cents, as workaround (what I've do) you can skip the headers installation, avarage users doesn't recompile.

[MichaIng]

Ah, so it is not even possible to install both (native) compilers side-by-side, but the cross-compiler package would be required. However, the used debhelper tools add the native compiler as dependency automatically, so a patch would need to be required on the tool sources to remove this auto-expansion. Same is the case for removing the initramfs dependency. We will see if RPi maintainers (respectively XECDesign) are willing to do this.

But for us this means that we must skip installing 64-bit headers on 32-bit userland, regardless whether its Raspbian or Debian. Kernel modules cannot be compiled anymore then, without switching to 32-bit kernel via arm_64bit=0 config.txt entry on RPi 4 and 5.

[terminet85]

Beware about 32bit kernel... There is a severe bug active about OOM. This is the reason i switched to 64bit. https://github.com/raspberrypi/linux/issues/5395

[MichaIng]

So this is the reason why the 64-bit kernel is now selected by default. Nothing is perfect. Best clearly is to use a 64-bit userland/OS with 64-bit kernel, but you cannot upgrade an old 32-bit OS to 64-bit sadly.

[sorriso93]

Hello is it foreseen to support with the migration script also bullseye?

[MichaIng]

This is impossible since the new packages are offered by the RPi Bookworm repository only. You will need to upgrade to Bookworm first: https://dietpi.com/blog/?p=2809

[sorriso93]

Hello finally I tried myself from Raspb4 to 5 with a plain bookworm install 64 bit downloaded today. Here some problems I find till now:

• I can't change display resolution (tried both from launcher and copying my setting of rpi4 on config.txt) my config I should use, Hdmi_group = 2 Hdmi_mode = 87 Hdmi_cvt 1024 600 60 3 0 0 0
• no shutdown command (I get "Failed to connect to bus: No such file or directory")
• Performance from launcher gets stucked
• CPU FAN (the original from raspberry org) gets stopped during the boot and the remain stopped! with raspbian the fan run with no problem!

[Joulinar]

no shutdown command (I get "Failed to connect to bus: No such file or directory")

Something expected as we don't install dbus on a default system

[MichaIng]

Use poweroff, reboot, halt commands. These are meant for immediate actions, while the shutdown command is actually for scheduling shutdowns in X seconds.

The HDMI settings you are trying to use work with the legacy framebuffer display driver only, not with the modern KMS one. I guess RPi 5 does not support the old one at all. See some documentation about how to change resolution via cmdline.txt: https://www.raspberrypi.com/documentation/computers/configuration.html#the-kernel-command-line

Some related issue: #5641 Basically what is documented here, seems to not work consistently across all SBCs. But would be good to know whether it works well on RPis at least.

Performance from launcher gets stucked

You mean the "Performance Options" from dietpi-config?

[sorriso93]

Use poweroff, reboot, halt commands. These are meant for immediate actions, while the shutdown command is actually for scheduling shutdowns in X seconds.

yes I never knew about poweroff, good to know

The HDMI settings you are trying to use work with the legacy framebuffer display driver only, not with the modern KMS one. I guess RPi 5 does not support the old one at all. See some documentation about how to change resolution via cmdline.txt: https://www.raspberrypi.com/documentation/computers/configuration.html#the-kernel-command-line

Some related issue: #5641 Basically what is documented here, seems to not work consistently across all SBCs. But would be good to know whether it works well on RPis at least.

ok I'll test it

Performance from launcher gets stucked

You mean the "Performance Options" from dietpi-config?

correct

[MichaIng]

CPU FAN (the original from raspberry org) gets stopped during the boot and the remain stopped! with raspbian the fan run with no problem!

It is attached with the dedicated white fan port, right? With DietPi, the cpu temperature is high, so that the fan is expected to run? Not sure how it is controlled, at least I see no overlay or such. There is no dtoverlay=gpio-fan on RPi OS, right?

Can you check the content of these directories (in case they even exist):

ls -l /sys/devices/platform/pwm-fan/hwmon/hwmon0/
ls -l /sys/devices/virtual/thermal/thermal_zone0/

[sorriso93]

Use poweroff, reboot, halt commands. These are meant for immediate actions, while the shutdown command is actually for scheduling shutdowns in X seconds.

yes I never knew about poweroff, good to know

The HDMI settings you are trying to use work with the legacy framebuffer display driver only, not with the modern KMS one. I guess RPi 5 does not support the old one at all. See some documentation about how to change resolution via cmdline.txt: https://www.raspberrypi.com/documentation/computers/configuration.html#the-kernel-command-line Some related issue: #5641 Basically what is documented here, seems to not work consistently across all SBCs. But would be good to know whether it works well on RPis at least.

ok I'll test it

I tried to change resolution with no success. As a good workaround I used Terminus 16x32 that is readible on my lcd monitor via: sudo dpkg-reconfigure console-setup

[MichaIng]

About hanging performance options: We have currently no overclocking profiles for RPi 5 yet. Probably the missing hardware model definition in dietpi-config is causing a hang at some point. I'll have a look.

If someone finds time to play a bit with the CPU/GPU frequencies and voltage to find some stable overclocking profiles with defined cooling solution, that would be great. Also I do not know the default frequencies yet, or which ones can even be changed on RPi 5. E.g. RAM frequency is fixed on RPi 4, so I guess as well on RPi 5. But I have no idea how to actually check it, as there is no vcgencmd measure_clock mem command or similar. GPU frequency can be checked with:

vcgencmd measure_clock core

CPU easiest with cpu command, which includes min/max etc.

I tried to change resolution with no success.

So the same as with my tests. Strange why it is documented everywhere to work like this, but practically does not work ...

[sorriso93]

Below the directory contents. I confirm I have no dtoverlay=gpio-fan on my /boot/config.txt The fan is the one that comes with the standard dissipator from raspberry.org and it is connected in the dedicated port of raspb5. With raspbian it is always on, it is not related to cpu temperature

root@RASPB5:~# ls -l /sys/devices/platform/pwm-fan/hwmon/hwmon0/
ls: cannot access '/sys/devices/platform/pwm-fan/hwmon/hwmon0/': No such file or directory
root@RASPB5:~# ls -l /sys/devices/virtual/thermal/thermal_zone0/
total 0
-r--r--r-- 1 root root 16384 Dec 21 18:31 available_policies
lrwxrwxrwx 1 root root     0 Dec 21 18:31 cdev0 -> ../cooling_device0
-r--r--r-- 1 root root 16384 Dec 21 18:31 cdev0_trip_point
-rw-r--r-- 1 root root 16384 Dec 21 18:31 cdev0_weight
lrwxrwxrwx 1 root root     0 Dec 21 18:31 cdev1 -> ../cooling_device0
-r--r--r-- 1 root root 16384 Dec 21 18:31 cdev1_trip_point
-rw-r--r-- 1 root root 16384 Dec 21 18:31 cdev1_weight
lrwxrwxrwx 1 root root     0 Dec 21 18:31 cdev2 -> ../cooling_device0
-r--r--r-- 1 root root 16384 Dec 21 18:31 cdev2_trip_point
-rw-r--r-- 1 root root 16384 Dec 21 18:31 cdev2_weight
lrwxrwxrwx 1 root root     0 Dec 21 18:31 cdev3 -> ../cooling_device0
-r--r--r-- 1 root root 16384 Dec 21 18:31 cdev3_trip_point
-rw-r--r-- 1 root root 16384 Dec 21 18:31 cdev3_weight
lrwxrwxrwx 1 root root     0 Dec 21 18:31 cdev4 -> ../cooling_device0
-r--r--r-- 1 root root 16384 Dec 21 18:31 cdev4_trip_point
-rw-r--r-- 1 root root 16384 Dec 21 18:31 cdev4_weight
drwxr-xr-x 3 root root     0 Dec 21 18:28 hwmon0
-rw-r--r-- 1 root root 16384 Dec 21 18:31 integral_cutoff
-rw-r--r-- 1 root root 16384 Dec 21 18:31 k_d
-rw-r--r-- 1 root root 16384 Dec 21 18:31 k_i
-rw-r--r-- 1 root root 16384 Dec 21 18:31 k_po
-rw-r--r-- 1 root root 16384 Dec 21 18:31 k_pu
-rw-r--r-- 1 root root 16384 Dec 21 18:31 mode
-rw-r--r-- 1 root root 16384 Dec 21 18:31 offset
-rw-r--r-- 1 root root 16384 Dec 21 18:31 policy
drwxr-xr-x 2 root root     0 Dec 21 18:31 power
-rw-r--r-- 1 root root 16384 Dec 21 18:31 slope
lrwxrwxrwx 1 root root     0 Dec 21 18:28 subsystem -> ../../../../class/thermal
-rw-r--r-- 1 root root 16384 Dec 21 18:31 sustainable_power
-r--r--r-- 1 root root 16384 Dec 21 18:31 temp
-rw-r--r-- 1 root root 16384 Dec 21 18:31 trip_point_0_hyst
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_0_temp
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_0_type
-rw-r--r-- 1 root root 16384 Dec 21 18:31 trip_point_1_hyst
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_1_temp
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_1_type
-rw-r--r-- 1 root root 16384 Dec 21 18:31 trip_point_2_hyst
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_2_temp
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_2_type
-rw-r--r-- 1 root root 16384 Dec 21 18:31 trip_point_3_hyst
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_3_temp
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_3_type
-rw-r--r-- 1 root root 16384 Dec 21 18:31 trip_point_4_hyst
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_4_temp
-r--r--r-- 1 root root 16384 Dec 21 18:31 trip_point_4_type
-r--r--r-- 1 root root 16384 Dec 21 18:31 type
-rw-r--r-- 1 root root 16384 Dec 21 18:28 uevent
root@RASPB5:~# 

[MichaIng]

So at least there are 4 trip point temperatures, that is a good sign. Can you check their content:

for i in /sys/devices/virtual/thermal/thermal_zone0/trip_point_*_temp; do echo -n "$i: "; cat "$i"; done

And checking some more possible locations to define e.g. trip point fan speeds:

ls -l /sys/class/hwmon/hwmon0/
ls -l /sys/devices/platform/

[sorriso93]

root@RASPB5:~# for i in /sys/devices/virtual/thermal/thermal_zone0/trip_point_*_temp; do echo -n "$i: "; cat "$i"; done
/sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp: 110000
/sys/devices/virtual/thermal/thermal_zone0/trip_point_1_temp: 50000
/sys/devices/virtual/thermal/thermal_zone0/trip_point_2_temp: 60000
/sys/devices/virtual/thermal/thermal_zone0/trip_point_3_temp: 67500
/sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp: 75000

root@RASPB5:~# ls -l /sys/class/hwmon/hwmon0/
total 0
lrwxrwxrwx 1 root root     0 Dec 21 18:44 device -> ../../thermal_zone0
-r--r--r-- 1 root root 16384 Dec 21 18:44 name
drwxr-xr-x 2 root root     0 Dec 21 18:44 power
lrwxrwxrwx 1 root root     0 Dec 21 18:28 subsystem -> ../../../../../class/hwmon
-r--r--r-- 1 root root 16384 Dec 21 18:44 temp1_crit
-r--r--r-- 1 root root 16384 Dec 21 18:44 temp1_input
-rw-r--r-- 1 root root 16384 Dec 21 18:28 uevent

root@RASPB5:~# ls -l /sys/devices/platform/
total 0
drwxr-xr-x  4 root root     0 Dec 21 18:28  3fd16ce0.nvram
drwxr-xr-x  4 root root     0 Dec 21 18:28 'Fixed MDIO bus.0'
drwxr-xr-x  3 root root     0 Dec 21 18:28  arm-pmu
drwxr-xr-x 18 root root     0 Dec 21 18:28  axi
drwxr-xr-x  4 root root     0 Dec 21 18:28  cam0_reg
drwxr-xr-x  4 root root     0 Dec 21 18:28  cam1_reg
drwxr-xr-x  4 root root     0 Dec 21 18:28  cam_dummy_reg
drwxr-xr-x  4 root root     0 Dec 21 18:28  cooling_fan
drwxr-xr-x  3 root root     0 Dec 21 18:28  cpufreq-dt
drwxr-xr-x  3 root root     0 Dec 21 18:28  kgdboc
drwxr-xr-x  4 root root     0 Dec 21 18:28  leds
drwxr-xr-x  3 root root     0 Dec 21 18:28  phy
drwxr-xr-x  2 root root     0 Dec 21 18:44  power
drwxr-xr-x  3 root root     0 Dec 21 18:28  psci
drwxr-xr-x  4 root root     0 Dec 21 18:28  pwr_button
drwxr-xr-x  4 root root     0 Dec 21 18:28  reg-dummy
drwxr-xr-x  4 root root     0 Dec 21 18:28  rp1_vdd_3v3
drwxr-xr-x  4 root root     0 Dec 21 18:28  sd_io_1v8_reg
drwxr-xr-x  4 root root     0 Dec 21 18:28  sd_vcc_reg
drwxr-xr-x  3 root root     0 Dec 21 18:28  serial8250
drwxr-xr-x  3 root root     0 Dec 21 18:28  snd-soc-dummy
drwxr-xr-x 32 root root     0 Dec 21 18:28  soc
drwxr-xr-x  3 root root     0 Dec 21 18:28  timer
-rw-r--r--  1 root root 16384 Dec 21 18:28  uevent
drwxr-xr-x  4 root root     0 Dec 21 18:28  wl_on_reg
root@RASPB5:~# 

[sorriso93]

About hanging performance options: We have currently no overclocking profiles for RPi 5 yet. Probably the missing hardware model definition in dietpi-config is causing a hang at some point. I'll have a look.

If someone finds time to play a bit with the CPU/GPU frequencies and voltage to find some stable overclocking profiles with defined cooling solution, that would be great. Also I do not know the default frequencies yet, or which ones can even be changed on RPi 5. E.g. RAM frequency is fixed on RPi 4, so I guess as well on RPi 5. But I have no idea how to actually check it, as there is no vcgencmd measure_clock mem command or similar. GPU frequency can be checked with:

vcgencmd measure_clock core

CPU easiest with cpu command, which includes min/max etc.

I tried to change resolution with no success.

So the same as with my tests. Strange why it is documented everywhere to work like this, but practically does not work ...

maybe this can be useful https://www.jeffgeerling.com/blog/2023/overclocking-and-underclocking-raspberry-pi-5

[MichaIng]

Thanks. Good hint with the _delta option for overvoltage, which actually takes micro volts instead of these numbers for 0.025V steps. But I guess it is only possible with the new firmware/kernel packages.

Btw, another interesting output on an unmodified RPi 5 would be:

vcgencmd get_config int

to see default clock rates.

Just a random attempt, since the power button reacts on APIC, probably the PWM fan somehow does as well. So could you try this:

apt install dbus
systemctl unmask systemd-logind
reboot

It also solves the error messages on shutdown command 😉. I see multiple trip points, which is a good thing, but I do not see any node which would tell the fan speed when each trip point is crossed. Strange is the 110000 (110 °C) on trip point 0. usually I would see "0" as the point to switch from disabled fan to lowest speed, but probably it is the critical temperature here at which frequency capping kicks in. But just to rule it out, does it change something when you set a lower value there?

echo 50000 > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp

... ah, now I see one path. Can you check this additionally:

ls -l /sys/devices/platform/cooling_fan/

[sorriso93]

About hanging performance options: We have currently no overclocking profiles for RPi 5 yet. Probably the missing hardware model definition in dietpi-config is causing a hang at some point. I'll have a look. If someone finds time to play a bit with the CPU/GPU frequencies and voltage to find some stable overclocking profiles with defined cooling solution, that would be great. Also I do not know the default frequencies yet, or which ones can even be changed on RPi 5. E.g. RAM frequency is fixed on RPi 4, so I guess as well on RPi 5. But I have no idea how to actually check it, as there is no vcgencmd measure_clock mem command or similar. GPU frequency can be checked with:

vcgencmd measure_clock core

CPU easiest with cpu command, which includes min/max etc.

I tried to change resolution with no success.

So the same as with my tests. Strange why it is documented everywhere to work like this, but practically does not work ...

maybe this can be useful https://www.jeffgeerling.com/blog/2023/overclocking-and-underclocking-raspberry-pi-5

as a temporary solution I installed: sudo apt-get install raspi-utils

and then run: pinctrl FAN_PWM op dl

but I have to do this every boot :-(

In two minutes from 45c to 30c the cpu temperature ;-) How can I add as a script on boot via dietpi-autostart ?

[MichaIng]

Ah, a raspi-utils tool. I'll have a look into this.

[MichaIng]

Btw, we recognised that reverting the migration via dietpi-backup is not easily possible. Since the mount point of the FAT partition is changed, the old kernel/bootlaoder etc would be restored to the wrong partition, and the actual boot partition cleared. It might work when manually mounting it back from /boot/firmware to /boot, but then again /boot/dietpi is overmounted, hence our scripts would be gone 🙈. Hence then they also needs to be copied.

TL;DR: At best do a full SD card/drive image backup, if you want to be able to revert.

[sorriso93]

Btw, we recognised that reverting the migration via dietpi-backup is not easily possible. Since the mount point of the FAT partition is changed, the old kernel/bootlaoder etc would be restored to the wrong partition, and the actual boot partition cleared. It might work when manually mounting it back from /boot/firmware to /boot, but then again /boot/dietpi is overmounted, hence our scripts would be gone 🙈. Hence then they also needs to be copied.

TL;DR: At best do a full SD card/drive image backup, if you want to be able to revert.

no problem I don't need to revert, I installed a new ssd that I use only for test

[sorriso93]

Thanks. Good hint with the _delta option for overvoltage, which actually takes micro volts instead of these numbers for 0.025V steps. But I guess it is only possible with the new firmware/kernel packages.

Btw, another interesting output on an unmodified RPi 5 would be:

vcgencmd get_config int

to see default clock rates.

Just a random attempt, since the power button reacts on APIC, probably the PWM fan somehow does as well. So could you try this:

apt install dbus
systemctl unmask systemd-logind
reboot

It also solves the error messages on shutdown command 😉. I see multiple trip points, which is a good thing, but I do not see any node which would tell the fan speed when each trip point is crossed. Strange is the 110000 (110 °C) on trip point 0. usually I would see "0" as the point to switch from disabled fan to lowest speed, but probably it is the critical temperature here at which frequency capping kicks in. But just to rule it out, does it change something when you set a lower value there?

echo 50000 > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp

... ah, now I see one path. Can you check this additionally:

ls -l /sys/devices/platform/cooling_fan/

root@RASPB5:~# ls -l /sys/devices/platform/cooling_fan/
total 0
lrwxrwxrwx 1 root root     0 Dec 21 21:15 driver -> ../../../bus/platform/drivers/pwm-fan
-rw-r--r-- 1 root root 16384 Dec 21 21:15 driver_override
drwxr-xr-x 3 root root     0 Dec 21 21:14 hwmon
-r--r--r-- 1 root root 16384 Dec 21 21:15 modalias
lrwxrwxrwx 1 root root     0 Dec 21 21:15 of_node -> ../../../firmware/devicetree/base/cooling_fan
drwxr-xr-x 2 root root     0 Dec 21 21:15 power
lrwxrwxrwx 1 root root     0 Dec 21 21:14 subsystem -> ../../../bus/platform
lrwxrwxrwx 1 root root     0 Dec 21 21:15 supplier:platform:1f0009c000.pwm -> ../../virtual/devlink/platform:1f0009c000.pwm--platform:cooling_fan
-rw-r--r-- 1 root root 16384 Dec 21 21:14 uevent

[MichaIng]

Hmm, so raspi-utils sets a pin called "FAN_PWM" to output driving low. Source code: https://github.com/raspberrypi/utils Theoretically this can be also done with other tools, like libgpio/gpiod, probably even with the gpio-fan overlay, but I guess we could need to know the the number of the pin with this name. That will be an internal one, not one of the 40-pin header.

I am checking the RPi OS image now. There must be some service or script or config which enables this on boot or permanently.

[MichaIng]

Strange, I can find absolutely nothing which would enable the fan on RPi OS. I think I need to ask the RPi maintainers.

[MichaIng]

Hah, here seems to be the sysfs nodes:

ls -l /sys/devices/platform/cooling_fan/hwmon/*/
for i in /sys/devices/platform/cooling_fan/hwmon/*/fan1_input; do echo -n "$i: "; cat "$i"; done

And now we found a parameter: Please try:

G_CONFIG_INJECT 'dtparam=cooling_fan=' 'dtparam=cooling_fan=on' /boot/config.txt
dtparam cooling_fan=on
# if it does not work already, reboot

This should actually be enabled automatically by the firmware, when it detects an attached PWM fan at boot 🤔.

[sorriso93]

G_CONFIG_INJECT 'dtparam=cooling_fan=' 'dtparam=cooling_fan=on' /boot/config.txt
dtparam cooling_fan=on

Seems ok! By the way I see now that wifi adapter is not seen from dietpi-config... I don't use it so no problem for me

[MichaIng]

Okay great, so manually enabling the fan works. Now we need to find out why the firmware does not do that automatically on DietPi, while it does it on RPi OS 🤔.

In dietpi-config, did you enable "Onboard WiFi" and reboot?

[sorriso93]

Okay great, so manually enabling the fan works. Now we need to find out why the firmware does not do that automatically on DietPi, while it does it on RPi OS 🤔.

In dietpi-config, did you enable "Onboard WiFi" and reboot?

Yes, in dietpi-config I see the message "adapter not available" or similar

[dirkhh]

I'm finally getting my RPi5 today (or so DigiKey claims). So I'm late to the party here. Reading through the whole thread - I'd really prefer the "DIET"Pi option (so option 2). Smaller images, targeting a specific board. Since image creation is automatic this doesn't add any real work (well, maybe for the download web page), but it makes for smaller images, faster turnaround times (faster download, faster write to SD, etc).

[alfredoanton82]

And now we found a parameter: Please try:

G_CONFIG_INJECT 'dtparam=cooling_fan=' 'dtparam=cooling_fan=on' /boot/config.txt
dtparam cooling_fan=on
# if it does not work already, reboot

This should actually be enabled automatically by the firmware, when it detects an attached PWM fan at boot 🤔.

I understand this is only if we want to keep the cooling fan active all the time. For me it seems to be working correctly with temperature, it starts automatically when +50ºC is reached.

On the other hand, I had an issue with an external USB drive, apparently following parameter on the /boot/config.txt is required: usb_max_current_enable=1

Did you know about it?

Thanks!! Alfredo