Werner

Available images are here:https://www.armbian.com/orangepi3b/ If your desired flavor and kernel combination isn't available build your own:https://github.com/armbian/build

Why? Are you an expert? Never heard of that one before.

Probably because they are not intended to be used as build switches but in board configuration file

Compare contents of /etc/apt/sources.list:1 and /etc/apt/sources.list.d/ubuntu.sources:1 and remove duplicates

iirc xtables-addons was never a part of linux-headers. Though it can be installed separately and needs linux-headers installed to build the necessary kernel module. Have you tried to build your own set of firmware packages using the build framework? code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=odroid-c2 BRANCH=current kernel

Hm indeed there is something wrong. Tested something similar but the patch file was shown empty. Though this used to work in the past. I suggest to report this here https://github.com/armbian/build/issues since this is clearly an framework issue. Edit: Alright, there seems to be a cosmetic bug. New files aren't shown for whatever reason in the patchfile preview. However if you press y to finish up patching the patchfile in the output folder looks just fine. From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: John Doe <john.doe@somewhere.on.planet> Date: Wed, 5 Mar 2025 05:41:52 +0100 Subject: Patching u-boot rk35xx files arch/arm/dts/rk3328-nanopi-r2s-plus.dts configs/nanopi-r2s-plus-rk3328_defconfig Signed-off-by: John Doe <john.doe@somewhere.on.planet> --- arch/arm/dts/rk3328-nanopi-r2s-plus.dts | 1 + configs/nanopi-r2s-plus-rk3328_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/dts/rk3328-nanopi-r2s-plus.dts b/arch/arm/dts/rk3328-nanopi-r2s-plus.dts new file mode 100644 index 00000000000..f33568d63c5 --- /dev/null +++ b/arch/arm/dts/rk3328-nanopi-r2s-plus.dts @@ -0,0 +1 @@ +gzuweggzuerguiwigwegi diff --git a/configs/nanopi-r2s-plus-rk3328_defconfig b/configs/nanopi-r2s-plus-rk3328_defconfig new file mode 100644 index 00000000000..9561b6e6ed7 --- /dev/null +++ b/configs/nanopi-r2s-plus-rk3328_defconfig @@ -0,0 +1 @@ +iuhgiuagiauhigahihgiawugiawugiwu -- Created with Armbian build tools https://github.com/armbian/build

Well on the bright sight both max and ultra are very similar. Though overlays might differ but that would need investigation. Easiest route is the one you actually already got on by checking the vendor source. Maybe they also provide a handful of matching overlays for this board. Maybe they can be ported.

So you are using a device tree for a different device and complain that things don't work as expected?

Sure https://docs.armbian.com/Process_Contribute/

I just check the sources from ti and it seems like they dont provide much overlays by themselves, so it seems you have to come up with something on your own.

The image you are using is intended for 5 max instead of 5 ultra?

I don't think any board has spi, i2c or similar enabled by default. It is all done via device tree overlays. Check if there are some available for your board by navigating to /boot/dtb/whateverstandshere/overlay

I don't know. You can send a PR with the suggested code so it can be reviewed.

both lite and zero 2w have nothing in common besides the name ingredient orange. I suggest to create a individual topic for that one and dont forget providing proper logs. "doesnt work" is probably the worst possible issue description.

Use this one instead

This is expected for current. If it boots its good enough for server application. To make use of all the other hw features either wait a few years or try to make vendor kernel work.

I did a last minute fix when you read through the pr. Please test https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.05.0-trunk_Orangepi5-ultra_bookworm_current_6.12.17_minimal.img.xz

maybe related https://askubuntu.com/questions/1217252/boot-process-hangs-at-systemd-networkd-wait-online

moved

Well then there are two options, either use an older kernel with the image or try latest mainline. edge got bumped to 6.14.0-rc4 recently and desktop usage becomes better and better with it. Though no idea if these overlays are already present there.

I assume you mean device tree overlays rather than kernel modules. Sometimes due to naming scheme armbian-config does not detect available overlays for specific hardware correctly. You can check manually by looking into /boot/dtb/rockchip/overlay As for me with an 5+ and vendor kernel I have these available: test@orangepi5-plus:/boot/dtb/rockchip/overlay$ ls|grep -i i2c rk3576-i2c0-m1.dtbo rk3576-i2c1-m0.dtbo rk3576-i2c2-m0.dtbo rk3576-i2c3-m0.dtbo rk3576-i2c4-m3.dtbo rk3576-i2c5-m3.dtbo rk3576-i2c6-m0.dtbo rk3576-i2c7-m1.dtbo rk3576-i2c8-m2.dtbo rk3588-i2c0-m1.dtbo rk3588-i2c1-m0.dtbo rk3588-i2c1-m2.dtbo rk3588-i2c1-m4.dtbo rk3588-i2c2-m0.dtbo rk3588-i2c2-m4.dtbo rk3588-i2c3-m0.dtbo rk3588-i2c3-m1.dtbo rk3588-i2c4-m3.dtbo rk3588-i2c5-m3.dtbo rk3588-i2c6-m0.dtbo rk3588-i2c6-m3.dtbo rk3588-i2c6-m4.dtbo rk3588-i2c7-m3.dtbo rk3588-i2c8-m2.dtbo rk3588-i2c8-m4.dtbo rock-5a-i2c5-rtc-hym8563.dtbo test@orangepi5-plus:/boot/dtb/rockchip/overlay$ uname -a Linux orangepi5-plus 6.1.99-vendor-rk35xx #1 SMP Fri Feb 21 18:11:03 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux To enable an overlay edit /boot/armbianEnv.txt Edit: Yeah just checked, I bet if you rename (for example) rk3588-i2c2-m4.dtbo to rockchip-rk3588-i2c2-m4.dtbo it will pop up in armbian-config.

No. And I don't know further. Maybe anyone else got an idea. if you have a usb uart adapter you can grab u-boot log output while booting from serial console. It will tell whether the overlays are correctly loaded.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbianmonitor -U sends output to stdout instead of paste service

Having HDMI or video output work in U-Boot is more an exception rather than standard. While I don't know the reason I guess it is just too much effort to port such drivers into U-Boot while using the debug serial console is dirt cheap and always works.