Marco Schirrmeister

It said "archlinux" because I took something from my notes for my Arch Linux images. It was only an example command and you can put there anything on how you named the image. I did not include image creating and bootrapping an OS into the image. I mainly wanted to show you how you can build and flash your custom u-boot. You get these "idbloader.img" and "u-boot.itb" files from the steps I laid out. If you download u-boot, bl31, ddr and compile it, you will see the files in the folder. I am sure you will understand this pretty fast. :-) Create an empty img file Create a rootfs partition (should start at 16MB) Bootstrap Debian or Ubuntu into the image Then start with the u-boot stuff above. By the time 6.19 drops, you will be a master in building images. :-)

Rock 5-whatever are really picky with power supplies. They are skipping like a school girl if the power supply is not right. I have for example one relative dumb little power supply with 2 outputs and using both outputs with Orange Pis works just fine. When I used one output with the Rock 5b+ I saw many crashes. It just hard reset at various stages. After connecting it to a usb output from a powerstrip it worked just fine. Radxas devices are really really picky is what everybody needs to keep in mind.

@humanus I would argue that if you build your own image with your own u-boot that uses the vendor versions of BL31 Elf and DDR Bin plus some rootfs, you can test very quickly different kernel versions to see if latest mainline kernel 6.18 or 6.19-rc is working. U-Boot is quickly to build # extract u-boot cd u-boot-2026.01-rc5 # Get bl31 and ddr. Maybe even try newer versions of BL31 and DDR curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/0b3e87afc2abd8dd6eb0052cd1be00de94a96637/bin/rk35/rk3528_ddr_1056MHz_v1.09.bin curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/bf63f186b9d6ffeca758278f8cadb5d5e5dc7f86/bin/rk35/rk3528_bl31_v1.17.elf # Create the u-boot config make rock-2-rk3528_defconfig # Enable more config options like this, ONLY if really needed scripts/config --enable CONFIG_USE_PREBOOT scripts/config --set-str CONFIG_PREBOOT 'led green on; sleep 0.1; led green off' scripts/config --set-val CONFIG_LOGLEVEL '7' scripts/config --set-val CONFIG_SPL_LOGLEVEL '7' # If you enabled more than default, update the config make olddefconfig # Build u-boot make EXTRAVERSION=-MyAwesomeUboot-1 BL31=rk3528_bl31_v1.17.elf ROCKCHIP_TPL=rk3528_ddr_1056MHz_v1.09.bin # use u-boot files to flash - idbloader.img - u-boot.itb sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/idbloader.img seek=64 sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot.itb seek=16384 # or the combined file - u-boot-rockchip.bin sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot-rockchip.bin seek=64 This is just an idea to get you started and created relative quickly a base image for a boot test. If you have a process to build that quickly, flash it and try to boot. Hook up a serial console and if it boots interrupt the u-boot to get to the u-boot prompt. If you get there, you don't need to think about to much about the boot loader in the image. Because at that prompt you can test various boot options live, instead of editing something on the sdcard or to whatever medium you flashed it. Here are some thoughts and notes on how you can debug and try to boot from the u-boot prompt. # Lets assume device 1 is the SDCARD with the system on it # Check you disks (sdcard / emmc) mmc list mmc dev 1 mmc list mmc part # Maybe that will show you something like this. => mmc list sdhci@2a330000: 0 (eMMC) mmc@2a310000: 1 (SD) mmc@2a320000: 2 (SDIO) # 'dev part' will show you the partitions. # Lets assume you have 3 partitions on and part 3 is your system # Check if you can read files ls mmc 1:3 ls mmc 1:3 /boot/ # Now if you know your Linux kernel image, initrd and DTB name, you can try to boot load the files and boot # You get the PARTUUID from the 'mmc part' above load mmc 1:3 ${kernel_addr_r} /boot/Image load mmc 1:3 ${fdt_addr_r} /boot/dtbs/rockchip/rk3528-rock-2f.dtb load mmc 1:3 ${ramdisk_addr_r} /boot/initramfs-linux.img setenv bootargs 'root=PARTUUID=ab3ede6d-b4b9-4368-80a9-a029b67cca29 console=ttyS0,1500000 rootwait' booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} Most important is you need to figure out what the serial console really is. If it is not ttyS0, try ttyS1 or ttyS2. The above "bootargs" at very basic. If you don't see much, try adding more. Here are some example you can add. Not all at ones! earlycon=uart8250,mmio32,0xfeb50000 console=tty1 console=ttyS2,1500000 console=both consoleblank=0 loglevel=7 panic=10 rootwait rw init=/sbin/init rootfstype=ext4 The "earlycon" parameter is also board specific. Not sure if it is valid for a Rock 2F or what the correct address would be. Again, this is not a working step by step guide but something that I would try to use for development and debugging. Once you have something working, I would think about integrating it into the Armbian config files.

I don't think I forgot anything. I was just curious about the conditions for the current version, since these sentences are relative generic and don't list issues, before I layout the details that I noticed. I flashed the image to a SanDisk Ultra, A1, Class 10 sdcard. System booted fine, but was relative slow which seemed to be related to constant sdcard speed switching issues. The following was constantly going on in the logs. [Wed Dec 3 13:30:34 2025] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [Wed Dec 3 13:30:34 2025] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 200000000Hz, actual 198000000HZ div = 0) [Wed Dec 3 13:30:34 2025] dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 235 The workaround for this was changing power control from auto to on. Messages stopped after executing the following. cat /sys/devices/platform/soc/2a310000.mmc/power/control auto echo on > /sys/devices/platform/soc/2a310000.mmc/power/control cat /sys/devices/platform/soc/2a310000.mmc/power/control on My permanent workaround was this, to avoid manual intervention after a reboot. # /usr/local/sbin/fix‑sd‑pm.sh #!/bin/sh # Disable runtime PM for SD controller (fixes repeated re-init) echo on > /sys/devices/platform/soc/2a310000.mmc/power/control # /etc/systemd/system/fix-sd-pm.service [Unit] Description=Disable runtime‑PM for SD controller After=multi-user.target [Service] Type=oneshot ExecStart=/usr/local/sbin/fix‑sd‑pm.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target # Enable chmod +x /usr/local/sbin/fix‑sd‑pm.sh systemctl daemon-reload systemctl enable --now fix-sd-pm.service systemctl status fix-sd-pm.service Without the workaround the mmc1 switched between 2 states. root@nanopir76s ~# cat /sys/class/mmc_host/mmc1/mmc1:*/name SD128 root@nanopir76s ~# grep . /sys/kernel/debug/mmc1/ios clock: 400000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 0 (1 bits) timing spec: 0 (legacy) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) # OR clock: 200000000 Hz actual clock: 198000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 6 (sd uhs SDR104) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) With the workaround it always showed this and system felt also snappy. root@nanopir76s ~# cat /sys/class/mmc_host/mmc1/mmc1:*/name SD128 root@nanopir76s ~# grep . /sys/kernel/debug/mmc1/ios clock: 200000000 Hz actual clock: 198000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 6 (sd uhs SDR104) signal voltage: 1 (1.80 V) driver type: 0 (driver type B) root@nanopir76s ~# --- EMMC was visible under Linux. But the emmc problem I noticed is related to u-boot. When I flashed the image to emmc and started from sdcard nothing at all happened. If I boot from sdcard and interrupt the u-boot prompt, the emmc card was not really visible. or accessible. I do not have the full serial output anymore when the Armbian image was flashed to emmc. => mmc list mmc@2a310000: 0 (SD) mmc@2a320000: 2 => # switching to emmc gives this => mmc dev 2 Card did not respond to voltage select! : -110 mmc_init: -95, time 22 => To debug this better, I build my own u-boot and image based on Armbians dts and defconfig. Here is what it looks like when booted from emmc with no sdcard inserted. U-Boot SPL 2026.01-msc-1 (Dec 02 2025 - 23:42:14 +0100) Trying to boot from MMC1 Card did not respond to voltage select! : -110 mmc_init: -95, time 21 spl: mmc init failed with error: -95 Error: -95 SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I created a patch for the dts, which modifies the sdmmc and sdhci nodes in the dts file. The patch is in my u-boot repo. https://github.com/mschirrmeister/PKGBUILDs/blob/f02af83ae5e0180ae1fd50706624dee348b820d7/core/uboot-rk3576-nanopi-r76s/arm64-dts-rockchip-rk3576-nanopi-r76s-fix-sdmmc-sdhci-coexistence.patch I added also the following Kconfig options to the u-boot defconfig. CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_HS400_ES_SUPPORT=y Here is the raw patch data. From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: Marco Schirrmeister <mschirrmeister@gmail.com> Date: Sat, 6 Dec 2025 23:56:46 +0100 Subject: [PATCH] arm64: dts: rockchip: rk3576-nanopi-r76s: fix sdmmc/sdhci coexistence The NanoPi R76S (RK3576) features both a DW‑MMC controller for the microSD socket (sdmmc) and an Arasan SDHCI controller for the on‑board eMMC (sdhci). When both were enabled, the shared I/O voltage rail caused initialisation conflicts: the eMMC required 1.8 V signalling while the SD card logic expected 3.3 V. This patch aligns the DTS and U‑Boot configuration so that both storage controllers operate correctly: - Enable CONFIG_MMC_SDHCI and CONFIG_MMC_SDHCI_ROCKCHIP in U‑Boot. - Add explicit `vmmc-supply` and `vqmmc-supply` properties to the eMMC (sdhci) node. - Add `no-1-8-v;` to the SDMMC node to keep the µSD socket fixed at 3.3 V. With these adjustments the board can access both the microSD and eMMC devices simultaneously, and U‑Boot can boot directly from either medium. Signed-off-by: Marco Schirrmeister <mschirrmeister@gmail.com> --- diff --git a/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts b/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts index 11111111111..22222222222 100644 +++ a/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts 2025-12-06 23:33:40.013947291 +0100 +++ b/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts 2025-12-06 23:56:46.961392491 +0100 @@ -772,6 +772,7 @@ status = "okay"; }; +/* eMMC on the Arasan/SDHCI host */ &sdhci { bus-width = <8>; full-pwr-cycle-in-suspend; @@ -781,9 +782,13 @@ no-sdio; no-sd; non-removable; + /* add the supply rails for completeness */ + vmmc-supply = <&vcc_3v3_s3>; /* main VCC rail */ + vqmmc-supply = <&vcc_1v8_s3>; /* I/O rail */ status = "okay"; }; +/* µSD socket on the DW‑MMC host */ &sdmmc { max-frequency = <200000000>; no-sdio; @@ -795,6 +800,8 @@ sd-uhs-sdr104; vmmc-supply = <&vcc_3v3_s3>; vqmmc-supply = <&vccio_sd_s0>; + /* keep this host at 3.3 V so it works when eMMC uses 1.8 V */ + no-1-8-v; pinctrl-names = "default"; status = "okay"; }; With this patch and config changes u-boot detects emmc fine and I can boot from either emmc or sdcard. If this changes are good or bad, I have absolutely no idea.

The page for the NanoPi R76S has also an edge kernel (6.18) image. I noticed some issues related to sdcard and emmc. I know edge images are not officially supported and that is fine. But given the image is available I would like the parameters/configuration/conditions for the current available image. Could you explain the background or assumptions behind the 6.18 edge image for the R76S? (e.g., test conditions you used when building it)

With the following options configured as a built-in module, the issue does not happen anymore on a poweron. CONFIG_TYPEC=y CONFIG_TYPEC_TCPM=y CONFIG_TYPEC_TCPCI=y CONFIG_TYPEC_FUSB302=y CONFIG_PHY_ROCKCHIP_USBDP=y I can create a pull request for the linux-rockchip64-edge.config file. But not sure what the general consensus on the kernel options for Armbian kernels is. Maybe it is also fixable via some code change, but that would be something for a real kernel developer.

This also happens on other kernels. Issue is present on final 6.18.0 kernel as well as on the older 6.12 kernel. It seems to be related to some kernel options that are set to "m". Need to figure out which kernel options would need to be set to "y" (built-in) on Armbian to avoid this issue on power-on.

Just an information about the `edge` kernel (6.18) when used on the cm3588-nas system. The rtc driver is not initialized on a `poweron`. After a poweron, you will see the following in the log. Nov 11 01:17:10 uhutest kernel: rtc-hym8563 6-0051: could not init device, -6 Nov 11 01:17:10 uhutest systemd[1]: System time advanced to built-in epoch: Tue 2025-11-11 01:17:09 CET If you have `fake-hwclock` running, you will see the following a moment later. fake-hwclock restores the time, but the service will not properly start, because of the rtc device error. Nov 11 01:17:12 uhutest fake-hwclock.sh[461]: Restoring saved system time Nov 20 13:22:43 uhutest fake-hwclock.sh[466]: Thu Nov 20 01:22:43 PM CET 2025 Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Cannot access the Hardware Clock via any known method. Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Use the --verbose option to see the details of our search for an access method. Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Main process exited, code=exited, status=1/FAILURE Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Failed with result 'exit-code'. Nov 20 13:22:43 uhutest systemd[1]: Failed to start Restore system time on boot and save it on shutdown. You would need to restart the fake-hwclock service, if you want that it saves time before the next restart. If you do a `restart` of the system, the rtc device will get properly initialized and time is good. Following is seen in the logs. Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: registered as rtc0 Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: setting system clock to 2025-11-20T12:26:11 UTC (1763641571) Nov 20 13:26:16 uhutest fake-hwclock.sh[455]: Not restoring old system time I have seen the issue right now only with the 6-18-RC kernel. The following patch mentioned here works as a pure workaround. https://patchwork.kernel.org/project/linux-rockchip/patch/20220608161150.58919-2-linux@fw-web.de/ Lets see how the development of kernel 6.18 goes and if the final version will not have this issue.

The 6.12.17-current-rockchip64 now works for me just fine. Wanted to test again and capture some verbose boot logs if it fails. But now it works just fine. Not sure if it is related to the patch from the pull request 7887, that was mentioned above.

On my OPi4LTS I do not have EMMC and it is stuck. Like I wrote it is stuck during hardware initialization, so I think it has no problem with finding the right kernel to boot.

I think the "apt list --upgradable" still shows packages that are hold. Run a "apt upgrade" and in there you should see what is held back. If all looks good, you can hit Y.

Of course can the OPi4LTS users install the rolling image. Which works fine, so no need for a custom build. But typically you don't want to run this on a production or stable machine. You never know what else will break down the road. Given that this works, the question is why does the 6.12 kernel images break the stable supported version. There is also no good way to debug, since all you see is initializing the hardware and then it is stuck at one point. But it is not fully clear what it does not like.

The real question is, why is is not booting or if it is supposed to be working. The download page has all kinds of images for the OPi4 with kernel 6.12, but it seems they do not work?

I would go with, like you wrote, ext4 or xfs. If something breaks, you can still mount the disk on any other linux system without any issue. Ext4 should also not have any problems with big file sizes. I am running xfs without any problems since years. Even if there was a hard crash, the filesystem could easily be mounted since nothing really happened on it or the recovery was smooth. I would probabyl still argue that ext4 is even more robust. For a simple disk to store some data it might still be the best choise.

I noticed the same and since I mainly run server stuff and don't rely on a monitor, my current workaround is modprobe -r synopsys_hdmirx. Don't know what this module is for, but console output is still working via hdmi. And to do it permanently, I have the following: root@dumpster ~# cat /etc/modprobe.d/hdmi.conf blacklist synopsys_hdmirx

A while ago I debugged the ssh problem and added some comments in this thread here. I don't remember if I used bookworm or trixie. Seems to me a timing issue or in which order things start. For now, whenever I do some dev work, I just do either another reboot after the first setup or restart the sshd service.

I think this issue here https://github.com/htop-dev/htop/issues/1160 describes the problem. Might be a problem that needs to be fixed within htop. If you are willing to switch tools, have a look at btop. That should give you should give you the overall temperature.

@Efe Çetin, PR is created. https://github.com/armbian/build/pull/6276 Bear with me, it is my first PR. So let me know whatever is wrong or needs to be changed.

Thank you for the confirmation @Vijay Gill. Here is the patch I use. I did also add the poweroff support. Splitting it into multiple files might be better, but it is good enough for my test builds. root@dumpster /m/t/t/n/build (main)# cat userpatches/kernel/rockchip-rk3588-edge/1000-arm64-dts-fix-rtc-add-poweroff-support-Orange-Pi-5-Plus.patch From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: John Doe <john.doe@somewhere.on.planet> Date: Mon, 29 Jan 2024 12:51:13 +0100 Subject: Patching kernel rockchip-rk3588 files arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts Signed-off-by: John Doe <john.doe@somewhere.on.planet> --- arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts index 88bfce6237db..70cc6bd5a0af 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts @@ -462,11 +462,11 @@ &pcie3x4 { }; &pinctrl { hym8563 { hym8563_int: hym8563-int { - rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; + rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>; }; }; leds { blue_led_pin: blue-led { @@ -572,10 +572,12 @@ pmic@0 { pinctrl-names = "default"; pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>, <&rk806_dvs2_null>, <&rk806_dvs3_null>; spi-max-frequency = <1000000>; + system-power-controller; + vcc1-supply = <&vcc5v0_sys>; vcc2-supply = <&vcc5v0_sys>; vcc3-supply = <&vcc5v0_sys>; vcc4-supply = <&vcc5v0_sys>; vcc5-supply = <&vcc5v0_sys>; @@ -592,11 +594,11 @@ pmic@0 { gpio-controller; #gpio-cells = <2>; rk806_dvs1_null: dvs1-null-pins { - pins = "gpio_pwrctrl2"; + pins = "gpio_pwrctrl1"; function = "pin_fun0"; }; rk806_dvs2_null: dvs2-null-pins { pins = "gpio_pwrctrl2"; -- Created with Armbian build tools https://github.com/armbian/build

Building on an Orange Pi 5 works just fine. I build image for the OPi5+ and Rock5b on my OPi5. @Gullik, what improvements do you expect to see in rc2 or rc3? Like Werner wrote the other day, he has not changed it to rc2, since there were no relevant changes. Same most likely goes for rc3. There are no commits for rk3588 or at least none where you would say, I need this right now. Even if there are changes, many are board specific.

I think that is normal. Same for me, fut fan should stop and if you measure the power on the outlet, you will see it is not drawing anything. I don't remember how it behaves on the Rock-5b. But I can power it on another day and check.

If you installed an image from the nightly builds, then the apt source list should have the beta repo in it. Which means you will see kernel and other updates relative often. root@orangepi5-plus ~# cat /etc/apt/sources.list.d/armbian.list deb [signed-by=/usr/share/keyrings/armbian.gpg] http://beta.armbian.com trixie main trixie-utils trixie-desktop

The edge or mainline kernel version is defined in config/sources/mainline-kernel.conf.sh. So yes, an update/PR to that file is needed, I think. If you want to change to your own newer version, you can define it for the compile.sh script. builder@dumpster /m/t/t/n/build (main)# cat userpatches/lib.config KERNELBRANCH="tag:v6.8-rc2"

That looks about right. Load around 1 and the hym8563 changes for me between 5-10%. Here is the patch I created for the OPi5+ and apply during my image builds. Tested with 6.8-rc1, rc2 and rc3 with bookworm and trixie. I hope that this things make it sooner than later in the mainline kernel. builder@dumpster /m/t/t/n/build (main)# cat userpatches/kernel/rockchip-rk3588-edge/1000-arm64-dts-fix-rtc-add-poweroff-support-Orange-Pi-5-Plus.patch From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: John Doe <john.doe@somewhere.on.planet> Date: Mon, 29 Jan 2024 12:51:13 +0100 Subject: Patching kernel rockchip-rk3588 files arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts Signed-off-by: John Doe <john.doe@somewhere.on.planet> --- arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts index 88bfce6237db..70cc6bd5a0af 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts @@ -462,11 +462,11 @@ &pcie3x4 { }; &pinctrl { hym8563 { hym8563_int: hym8563-int { - rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; + rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>; }; }; leds { blue_led_pin: blue-led { @@ -572,10 +572,12 @@ pmic@0 { pinctrl-names = "default"; pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>, <&rk806_dvs2_null>, <&rk806_dvs3_null>; spi-max-frequency = <1000000>; + system-power-controller; + vcc1-supply = <&vcc5v0_sys>; vcc2-supply = <&vcc5v0_sys>; vcc3-supply = <&vcc5v0_sys>; vcc4-supply = <&vcc5v0_sys>; vcc5-supply = <&vcc5v0_sys>; @@ -592,11 +594,11 @@ pmic@0 { gpio-controller; #gpio-cells = <2>; rk806_dvs1_null: dvs1-null-pins { - pins = "gpio_pwrctrl2"; + pins = "gpio_pwrctrl1"; function = "pin_fun0"; }; rk806_dvs2_null: dvs2-null-pins { pins = "gpio_pwrctrl2"; -- Created with Armbian build tools https://github.com/armbian/build

I want to share some information about an issue that I see on my OPi5+. Since I got it I am messing around with it and everything works great so far with the edge 6.7 kernel. One thing I noticed though was, that right after installation with nothing connected and when idle, there was one kernel process that was constantly consuming around 10% CPU time and the load stays at 1. The process was irq/136-hym8563. The number varies of course after each boot. Kernel driver is rtc_hym8563. Since it is build into the kernel I was not able to unload it as a first test. Side node, the issue is not seen on the Rock5b, so it seems OPi5+ hardware specific. Even if both are relative similar. I have not found anything useful so far on the internet. Don't know if it is just my device or if others are seeing a similar thing on their OPi5+ with the 6.7 edge kernel. IRQs going up like crazy for a few interrupts, compared to when driver rtc-hym8563 is not there. arch_timer rk_timer fec80000.i2c hym8563 Here are some debugging information. top output. root@orangepi5-plus ~# top -b -n 4 -p (pgrep hym) top - 16:30:43 up 3 min, 1 user, load average: 1.08, 0.63, 0.27 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 1.2 sy, 0.0 ni, 97.6 id, 0.0 wa, 1.2 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 D 0.0 0.0 0:16.90 irq/136-hym8563 top - 16:30:46 up 3 min, 1 user, load average: 1.08, 0.63, 0.27 Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.7 sy, 0.0 ni, 97.9 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 R 7.7 0.0 0:17.13 irq/136-hym8563 top - 16:30:49 up 3 min, 1 user, load average: 1.07, 0.63, 0.27 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.7 sy, 0.0 ni, 97.9 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 D 8.0 0.0 0:17.37 irq/136-hym8563 top - 16:30:52 up 4 min, 1 user, load average: 0.99, 0.62, 0.27 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.8 sy, 0.0 ni, 97.9 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st MiB Mem : 15718.1 total, 15299.5 free, 422.6 used, 212.1 buff/cache MiB Swap: 7859.0 total, 7859.0 free, 0.0 used. 15295.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 438 root -51 0 0 0 0 D 8.0 0.0 0:17.61 irq/136-hym8563 Interrupt increase over 1 minute. 100k for hym8563 and 1million for fec8000.i2c root@orangepi5-plus ~# uptime && date && cat /proc/interrupts | grep -iE "(hym|fec80000|_timer)" && sleep 60 && date && cat /proc/interrupts | grep -iE "(hym|fec80000|_timer)" 17:28:15 up 35 min, 1 user, load average: 1.01, 1.07, 1.00 Mon Jan 22 05:28:15 PM CET 2024 19: 26038 125123 73155 438814 46260 13649 3574 299665 GICv3 26 Level arch_timer 25: 22900 83767 54823 279426 36468 15155 10963 9513 GICv3 321 Level rk_timer 48: 0 0 0 0 0 0 0 30250774 GICv3 355 Level fec80000.i2c 136: 0 0 0 0 0 0 0 5041747 rockchip_gpio_irq 8 Level hym8563 Mon Jan 22 05:29:15 PM CET 2024 19: 26366 125128 91142 438815 46849 13652 3574 307458 GICv3 26 Level arch_timer 25: 23366 84133 67225 279722 37149 15171 10976 9752 GICv3 321 Level rk_timer 48: 0 0 0 0 0 0 0 31073437 GICv3 355 Level fec80000.i2c 136: 0 0 0 0 0 0 0 5178856 rockchip_gpio_irq 8 Level hym8563 irq cpu time is also visible in mpstat root@orangepi5-plus ~# mpstat -P ALL Linux 6.7.1-edge-rockchip-rk3588 (orangepi5-plus) 01/22/2024 _aarch64_ (8 CPU) 07:43:50 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 07:43:50 PM all 0.13 0.00 0.68 0.01 1.33 0.03 0.00 0.00 0.00 97.82 07:43:50 PM 0 0.03 0.00 1.30 0.01 0.98 0.08 0.00 0.00 0.00 97.61 07:43:50 PM 1 0.03 0.00 0.26 0.01 0.18 0.02 0.00 0.00 0.00 99.51 07:43:50 PM 2 0.03 0.00 3.06 0.01 2.46 0.07 0.00 0.00 0.00 94.37 07:43:50 PM 3 0.02 0.00 0.77 0.01 0.58 0.02 0.00 0.00 0.00 98.60 07:43:50 PM 4 0.59 0.00 0.11 0.01 0.03 0.02 0.00 0.00 0.00 99.24 07:43:50 PM 5 0.22 0.00 0.05 0.01 0.01 0.01 0.00 0.00 0.00 99.70 07:43:50 PM 6 0.06 0.00 0.01 0.01 0.01 0.00 0.00 0.00 0.00 99.91 07:43:50 PM 7 0.04 0.00 0.02 0.01 6.49 0.03 0.00 0.00 0.00 93.42 procinfo output shows as well the high number for irq 136 and 48. root@orangepi5-plus ~# procinfo Memory: Total Used Free Buffers RAM: 16095284 585248 15510036 22584 Swap: 8047640 0 8047640 Bootup: Mon Jan 22 16:53:14 2024 Load average: 1.29 1.09 1.02 1/231 9335 user : 00:01:51.76 0.1% page in : 238872 nice : 00:00:00.03 0.0% page out: 118633 system: 00:09:19.33 0.7% page act: 59088 IOwait: 00:00:09.19 0.0% page dea: 0 hw irq: 00:18:07.58 1.3% page flt: 1335085 sw irq: 00:00:24.98 0.0% swap in : 0 idle : 22:09:57.44 97.8% swap out: 0 uptime: 02:51:46.79 context : 142704160 irq 18: 0 irq 66: 0 427819017 Edge ae irq 19: 4672570 irq 77: 0 570425352 Edge PC irq 20: 0 irq 78: 0 570425353 Edge ae irq 23: 0 irq 89: 0 285212680 Edge PC irq 25: 2504720 irq 90: 0 285212681 Edge ae irq 31: 0 irq 91: 2 irq 32: 15 irq 92: 0 irq 33: 1 irq 93: 32 irq 34: 0 irq 94: 0 irq 35: 0 irq 95: 75881 428343296 Edge en irq 36: 0 irq 96: 0 570949632 Edge en irq 37: 0 irq 97: 0 irq 38: 0 irq 98: 0 irq 39: 0 irq 99: 0 irq 40: 0 irq 100: 0 irq 41: 2 irq 101: 514 irq 43: 653459 irq 102: 0 irq 44: 2278 irq 119: 0 irq 45: 1346 irq 130: 0 8 Edge PCIe PME irq 46: 203 irq 131: 0 9 Edge aerdrv irq 47: 41964 irq 132: 99660 irq 48: 141047548 irq 133: 56265 irq 49: 108 irq 135: 0 irq 50: 0 irq 136: 23507838 irq 51: 0 irq 137: 324 irq 52: 2 irq 138: 0 irq 53: 0 irq 139: 0 irq 54: 0 irq 140: 0 irq 65: 0 427819016 Edge PC Since I do not need the RTC on my system, my idea was to create an own custom image, where rtc_hym8563 is build as a module. Where I can disable the module in the hope the process is gone and nothing is consuming cpu time when idle. It turns out that worked for me and I am running it like this for now. Here are my steps. Change kernel config in the build system. # config/kernel/linux-rockchip-rk3588-edge.config CONFIG_RTC_DRV_HYM8563=y After new image is installed and booted, it is indeed now a module. root@orangepi5-plus ~# zcat /proc/config.gz | grep -i hym CONFIG_RTC_DRV_HYM8563=m Disabling the rtc_hym8563 driver echo "blacklist rtc_hym8563" > /etc/modprobe.d/blacklist-rtc.conf update-initramfs -u reboot I just wanted to share this information in case someone else see this. For now I will live with my workaround and keep an eye on the kernel development to see, if there will be a change. In case there is some hardware expert and has some other tips, please feel free to share. Cheers, Marco