Marco Schirrmeister

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

If you want poweroff working, then you need to apply the following patch. https://lore.kernel.org/lkml/pqvmguq77qbxmuxsushrz4ykxtmvkugirbxnckmbfk47gx2u5n@cz2kllnjr6ba/T/ Just out of curiosity, do you see a kernel irq "hym8563" process with high cpu usage? 10% give or take. I would assume yes, because in interrupt output from your paste board has high numbers. 48: 19767 39 36 42 18 16 16 2850824 GICv3 355 Level fec80000.i2c 49: 3291 7 5 7 4 2 3 475101 rockchip_gpio_irq 8 Level hym8563

Which image did you use, that you do not see the hym8563 irq issue on your OPI5+? Would like to try that exact image.

Final comment for the sshd start problem on some systems during the first boot. That should probably discussed in its own thread though. It really seems to come down to the start time of the armbian-firstrun service. I guess it starts too early. Either of the following changes in the armbian-firstrun.service file will have it started later and avoids the issue. [Service] Type=idle or [Unit] After=multi-user.target

I know now why sshd is not running. The directory /run/sshd is missing. dpkg-reconfigure openssh-server or service ssh restart from armbian-firstrun delete the directory if it is there. Just restarting sshd via the console recreates it (as defined in its service). sshd -t Missing privilege separation directory: /run/sshd It can easily reproduced by enabling the armbian-firstrun service and a reboot. It runs through its things on the next boot and the directory is gone. I assume it has to do with the way the sshd restart is executed. Something where it is executed in a script, that in turn is executed via a systemd service during a boot. If you restart it via the console shell where you logged in, it works just fine.

In my case, they are not always empty. Maybe early on, I don't know. Have not tried to mount the disk after each first boot to see the status. They keys are often fine, after I ran through the first boot setup wizard (armbian-firstlogin). Then a restart of the daemon or a reboot is all to get it started. The other day when I looked at it, I found this one. https://github.com/armbian/build/issues/3771 In the armbian-firstrun script are the commands to delete the keys, re-create them and restart the service. Given that this commands are run in serial, I wonder if the "dpkg-reconfigure openssh-server" can fail in a why to generate 0 byte files. But given that they are most of the time ok, I don't understand why a restart of the service later in the script would fail. Unless there is something else besides the firstrun script that tries to do the same thing.

@adr3nal1n27, for you initial question #3. If you want poweroff working on the OPi5(+), then you need to patch your system for now. This patch here from the Rock 5b seems to work on the OPi5(+) as well. https://lore.kernel.org/lkml/170389050012.2630399.8754217298577818519.b4-ty@sntech.de/T/ Maybe the Armbian maintainer will add these things at one point. Otherwise it might eventually show up upstream in the mainline kernel.

@David Pottage, like Werner said, ssh is enabled, but it does not start. From what I have seen it fails to start because there is a problem with the ssh host keys. They are 0 bytes. At least this was the case for me, when I tried to debug this. If you do not want to go through the first setup wizard via the console, then try to delete the host key files in the /etc/ssh/ directory, when you mount your sd card on another machine. Or check if they are indeed 0 bytes and if so, delete them. Then try to boot again. It should re-create them automatically. No idea what why they are empty. There is an armbian-firstrun script, which seems to delete and re-configures sshd, but no idea what or if it is even invoked.