Marco Schirrmeister

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

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.