Werner

I tried this and works with zero2 https://paste.armbian.com/enipilazib

if you need working hdmi use vendor or edge kernels. current (which is 6.12.y) does not have all the necessary patches already since they were (and still are) under heavy development.

I think so, yes root@pihole-v2:~# dmesg|grep -i gpu [ 5.922915] panfrost 1800000.gpu: clock rate = 432000000 [ 5.922952] panfrost 1800000.gpu: bus_clock rate = 200000000 [ 5.923733] panfrost 1800000.gpu: mali-t720 id 0x720 major 0x1 minor 0x1 status 0x0 [ 5.923762] panfrost 1800000.gpu: features: 00000000,00000408, issues: 00000000,21054400 [ 5.923770] panfrost 1800000.gpu: Features: L2:0x07110206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002821 AS:0xf JS:0x7 [ 5.923779] panfrost 1800000.gpu: shader_present=0x3 l2_present=0x1 [ 5.931337] [drm] Initialized panfrost 1.2.0 for 1800000.gpu on minor 1

Seems indeed broken for H61* H6 is fine.

root@pihole-v2:~# uname -a Linux pihole-v2 6.12.16-edge-sunxi64 #1 SMP Fri Feb 21 13:01:47 UTC 2025 aarch64 GNU/Linux

We had the case on various boards over a couple of years that sometimes warm reboots fail. Since the reason is always individual, hard to tell by heart. Anyway I suggest to extract proper logs from debug uart console. If you don't know what I am talking about: https://debug.armbian.de

Sure thing: https://github.com/armbian/linux-rockchip

The kernel you are trying to modify is a heavily modified vendor bsp kernel that is some sort of weird mixture of Android and Linux. My suggestion is don't waste your time... You may have better chances with 6.1.y vendor bsp since it is some sort of proper Linux.

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