Orange Pi 5 PLUS and DietPI

Hi there!

Does anyone here know if DIETPI runs with the new Orange PI 5 PLUS?

I know it works with ORANGE 5B (Rockchip RK3588S), but ORANGE PI PLUS carries Rockchip RK3588.

@MichaIng can you do a quick check?

I’m awaiting a developer sample for the plus variant, but I am pretty sure our Orange Pi 5 image (not explicitly “plus”) works just fine.

I’ve tried using emmc and sd and it the image doesn’t work on pi 5 plus. :frowning:

Will test it later today. The developer sample arrived.

1 Like

I was able to do it, first installing the armbian and then using the script to install dietpi over Generic Devices. I’m using an EMMC.
I got an error during the process but I was able to circunvent it.
[FAILED] DietPi-Installer | /var/lib/dpkg/info/base-files.postinst configure

Checked this page and I kinda fixed, at least it finished the installation.

HOWEVER, I’m facing serious problems with the internet connection. Sometimes when I REBOOT it, it can’t find the connection, even setting it as fixed IP.

It’s very annoying. I have to turn off the device manually and turn it on again.


I can confirm that v8.20 does not work with the Orange Pi 5 Plus.

I have the 16gb variant of the OP5+ with a NVMe SSD installed and a 128gb Samsung MicroSD card.

The OP5+ works fine with the Official Debian BookWorm XFCE OS provided on Google Drive by the manufacturer.

With DietPi v8.20 I get thousands of rk3x-i2c timeout errors upon boot.

orange-pi-5-plus-doesnt-boot-rk3x-i2c-problem-please-help-v0-hyhja7my0eab1 hosted at ImgBB — ImgBB < screenshot of the errors.

Please make DietPi compatible with the OP5+

It’s my favorite Linux OS. Thanks for your work!

Best to my knowledge @MichaIng was successfully testing the plus version on a SD card. Let’s wait on his feedback.

1 Like

Support added via own hardware ID: Image | Add support for Orange Pi 5 Plus by MichaIng · Pull Request #6533 · MichaIng/DietPi · GitHub
Images ready for testing: Index of /downloads/images/testing

They work well here. After flashing the SPI bootloader once via dietpi-config > Advanced Options > Update SPI bootloader, it also boots from USB, and I am sure also form NVMe. Would be great if you could test this, as I need to order an NVMe SSD first to test.

1 Like

System has one load in idle.
up 31 min, 1 user, load average: 1.00, 1.02, 1.00

DietPi_OrangePi5Plus-ARMv8-Bookworm.7z 2023-08-07 18:28 113M

Does htop is showing any load?

Nothing weid in htop. But using top command, there is a kworker/4:1+events status D

keep it running for a couple of hours and check again. At boot, we will execute some maintenance task that could increase CPU usage. Therefore picture could be incorrect if you check it right after boot process.

After 20 hours, the system still has one load and power consume up and down quickly.

@MichaIng I guess you have a developer sample. How does it behave for you?

That is interesting, I see it as well, and as well not a single kernel or userland process or thread which does actually use this 100% CPU time. The kernel worker uses 3%, so that would be 0.03, not 1.00.

htop can btw also show threads, it just needs to be enabled in its options.

One thing to note is that CPU frequencies are still quite low, so this is 100% of just a fraction of what one core can do:

root@DietPi:~# cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
# CPU 0-4, the small cores
408000 8594
600000 84
816000 49
1008000 46732
1200000 759
1416000 459
1608000 203
1800000 2287
# CPU 4+5, two big cores
408000 9803
600000 26
816000 17
1008000 12
1200000 47949
1416000 52
1608000 39
1800000 18
2016000 25
2208000 28
2256000 1196
# CPU 6+7, the last two big cores
408000 57805
600000 73
816000 72
1008000 94
1200000 62
1416000 85
1608000 46
1800000 32
2016000 42
2208000 20
2256000 833

All shown and sorted by overall CPU time also does not reveal anything. I started htop with 50 refreshes per second, trying to spot short peeks, but also nothing. While it still is far away from using one core fully, it quickly overtook the mentioned kernel thead:

I wonder what the spi2 thread is, and why it is consuming CPU all the time when nothing is attached to GPIO. Two SPI interfaces are enabled:

root@DietPi:~# for i in /proc/device-tree/spi*/status; do echo -n "$i: "; cat "$i"; echo; done
/proc/device-tree/spi@fe2b0000/status: okay
/proc/device-tree/spi@feb00000/status: disabled
/proc/device-tree/spi@feb10000/status: disabled
/proc/device-tree/spi@feb20000/status: okay
/proc/device-tree/spi@feb30000/status: disabled
/proc/device-tree/spi@fecb0000/status: disabled

We could disable them and see what the effect is.

Checked also loaded kernel modules, which really is just a few. I disabled all but those needed for WiFi to see whether this changes everything:

root@DietPi:~# lsmod
Module                  Size  Used by
8821cu               1884160  0
ipv6                  438272  26

I switched to the ondemand governor, but this didn’t really change much. load average still a 1 and CPU frequencies pretty similarly used, just the intermediates a little less. Just to check the effect, I enabled performance governor. This also did not change something about the uptime. My suspicion was that the load average is probably oriented somehow on the load of a small core on its lowest frequency, which would be pretty low and could easily match e.g. 3% on a large core when its frequency is a little scaled up.

I am btw quite impressed that running the board with performance governor das increase its CPU temperature by only about 1 °C in idle (43 °C => 44 °C), without any a heat sink attached. Of course it becomes hotter on load.

So basically I have no idea and cannot see anything which could cause this. Disabling device tree nodes could be further tested, but I highly doubt that it will chance something. I think we’d need to find out more about how the average load is estimated in case of such ARM SoCs with multiple different CPU cores being scaled individually.

Also interesting is whether the official Orange Pi images show the same. We use the Armbian kernel build which uses the same Rockchip kernel sources, but of course with different kernel configurations.


Hi people , before starting , i just wanted to let you know that i think this is a great project and i want see this going forward.
Regarding the thread , i have also a Opi 5+ and after installing dietpi (bookworm) variant from the testing repo i get the same load (1.00)
I see that the system has a lot of perks (software that i need, the dietpi-launcher who makes the job easier) so i am very interested in seeing what is the issue here.
I’m not a kernel developer or any expert on the matter , but based on your last comment regarding the Armbian kernel , is that some configuration in the kernel is causing this (naturally, if using armbian os does not put any load on the system)
Load using the official orange pi image with debian:

Wanted to add the htop output as well , but i am not allowed to post more than one pic here.

Regardless, let me know if i can help in some way :slight_smile:

Just tested Armbian and it has the same load running the jammy with cli image.(1.00)

Try using SSH and copy/past information directly from SSH terminal. Even possible for htop :wink:

Sorry to resurrect an old thread but booting from the eMMC wasn’t working for me until I updated the SPI: Orange Pi 5 Plus boot from EMMC not working · Joshua-Riek/ubuntu-rockchip · Discussion #494 · GitHub

Never mind, I see it mentioned above:

dietpi-config > Advanced Options > Update SPI bootloader