Dear team,

On Armbian_25.11.1_Orangepi5-plus_trixie_current_6.12.58_minimal.img
not possible to boot kernel, only u-boot seems available ?

Bellow is the debug log on tty

DDR V1.13 25cee80c4f cym 23/08/11-09:31:58
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=18 CS1 Row=18 CS=2 Die BW=8 Size=8192MB
Manufacturer ID:0xff
CH0 RX Vref:28.5%, TX Vref:22.8%,21.8%
CH1 RX Vref:27.1%, TX Vref:21.8%,21.8%
CH2 RX Vref:27.9%, TX Vref:21.8%,21.8%
CH3 RX Vref:28.5%, TX Vref:20.8%,20.8%
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
out
U-Boot SPL board init
U-Boot SPL 2017.09-orangepi (Nov 15 2023 - 16:53:25)
Trying to boot from MMC1
Trying fit image at 0x4000 sector
## Verified-boot: 0
## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK
## Checking u-boot 0x00a00000 ... sha256(e17d8b540a...) + OK
## Checking fdt-1 0x00ad1370 ... sha256(5411c775cf...) + OK
## Checking atf-2 0x000f0000 ... sha256(b2af21b504...) + OK
## Checking atf-3 0xff100000 ... sha256(70505bb764...) + OK
Jumping to U-Boot(0x00a00000) via ARM Trusted Firmware(0x00040000)
Total: 719.759 ms

 

....and nothing 

 

I also changed the verbosity level in /boot/armbianEnv.txt, but
without success!

Thanks in advance for your help

moved to staging

wrong image. you cannot simply use an image for board X and assume it works on board Y

Thanks Werner. 

Could you please point to me where is best last download file reference for Orangepi5b plus ?

There is no such board. There is either Orangepi5 plus or Orangepi5b. Check your hw what you actually have.

If there is indeed a "Orangepi5b plus" then it must be fairly new and is totally unsupported.

Sorry for the bad identification of my SBC.

My model is one Orangepi5 plus, therefore it seems that Armbian_25.11.1_Orangepi5-plus_trixie_current_6.12.58_minimal.img.xz is the good choice ?

After reinstalling  one fresh SDCARD based on  Armbian_25.11.1_Orangepi5-plus_trixie_current_6.12.58_minimal.img then behavior is the same, noting after following message....

 

Trying to boot from MMC1
Trying fit image at 0x4000 sector
## Verified-boot: 0
## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK
## Checking u-boot 0x00a00000 ... sha256(e17d8b540a...) + OK
## Checking fdt-1 0x00ad1370 ... sha256(5411c775cf...) + OK
## Checking atf-2 0x000f0000 ... sha256(b2af21b504...) + OK
## Checking atf-3 0xff100000 ... sha256(70505bb764...) + OK
Jumping to U-Boot(0x00a00000) via ARM Trusted Firmware(0x00040000)
Total: 715.486 ms
 

Other question ?

When looking to previous boot log, it is strange to view u-boot date ?

U-Boot SPL board init
U-Boot SPL 2017.09-orangepi (Nov 15 2023 - 16:53:25)
Trying to boot from MMC1

3 hours ago, Jean-Marc said:

_6.12.58_minimal.img.xz is the good choice ?

Actually no. While 6.12.y may be an LTS kernel, support for rk3588 was barely there so very few boards actually work with this. I suggest to download/build an image with either "vendor" kernel 6.1.115 or "edge" with >=6.18.y. This should work better.

 

 

 

3 hours ago, Jean-Marc said:

When looking to previous boot log, it is strange to view u-boot date ?

You may have a pre-written uboot on your SPI flash which you really want to get rid of. It may prevent booting mainline kernel (perhaps this is even the issue you having booting 6.12). I believe mainline uboot (2025.10 or later) allows booting both mainline and vendor kernels. No warranty though.

 

moved and title adjusted

I have Orange Pi 5 Plus 32GB RAM version (no longer being sold).

Known good kernel is 6.1.75-vendor-rk35xx

I just ran sudo apt update and apt upgrade, and I knew this kernel 6.12.xx wouldn't work but I rebooted to try it anyway.  Broken, dead, thought it may be DTB.

I kept good notes from the prior problem. This board has been rock solid stable with 6.1.75 and I'm running with NPU for AI inference (requires rknn2, not the regular rknn, current version I was working on upgrading to tonight is rknn 2.30 as loadable module (.so).

I have serial connected so I can recover via U-Boot and get the kernel back to 6.1.75. 

Here are the fixes Claude provided based on my prior notes.

I hope this helps someone. Find me on X @iDare

---
Claude Opus 4.6:

This is a confirmed, well-documented upstream kernel bug. Here's the full picture:

Confirmed: Known RK3588 GPU Power Domain Bug

The Bug (Exact Match)

Sebastian Reichel from Collabora reported that the Linux kernel crashes on Rock 5B when the panthor driver is loaded. The crash involves the rockchip power management domain failing to enable the GPU domain, followed by an SError Interrupt causing a kernel panic. Patchwork

The Armbian forum thread from a Rock 5B user shows the identical crash signature to yours:

The crash trace shows rockchip-pm-domain fd8d8000.power-management:power-controller: failed to get ack on domain 'gpu' followed by SError Interrupt on CPU5, code 0x00000000be000411 with the panic originating from panthor_init calling through rockchip_pd_power_on. Armbian Community Forums

That user confirmed downgrading to kernel 6.12 fixed it for the edge branch.

Root Cause

The GPU power domain requires the GPU voltage regulator to be enabled before the power domain can be turned on. The regulator is enabled at boot time but automatically gets disabled when there are no users. If the GPU driver probes late, the system tries to enable the power domain without the regulator, causing an SError. Patchwork

Your boot log confirms this exactly:

rockchip-pm-domain: Looking up gpu-supply property in node /power-management@fd8d8000/power-controller failed

No gpu-supply in the DT = panthor tries to power on GPU domain = bus fault = SError = kernel panic.

The Fix (Upstream, Merged)

The patch series adds GPU power domain regulator dependency for RK3588, including a specific DTS change for the Orange Pi 5 Plus (rk3588-orangepi-5-plus.dts). Linaro

The v6 patchset was merged (commit f94500eb7328) into Heiko Stübner's tree. It landed in the regulator tree for-next and was applied to the Rockchip DTS tree. Patchew

However, this fix is in kernel 6.15+ (merge window). Your vendor kernel 6.1.75 doesn't have it, and the panthor DT overlay is apparently being applied without the matching power domain fix.

What Happened on Your Board

Your apt upgrade likely updated the panthor DT overlay (rockchip-rk3588-panthor-gpu.dtbo) to a newer version that activates the mainline panthor driver path, but the vendor kernel 6.1.75's rockchip-pm-domain driver lacks the regulator handling code. The overlay enables the GPU node for panthor but doesn't add the gpu-supply property to the power domain controller node.

Other Users Hit This Too

Multiple Armbian forum threads report the OPi5 with kernel 6.12 failing to boot with kernel panic, and the 6.12.58 minimal image also has non-boot reports. Armbian Community Forums

Another user reported their OPi5 Plus stayed stuck on kernel 6.1.75 even after apt upgrade to Armbian 25.2.2, suggesting the kernel package wasn't being updated through normal channels. Armbian Community Forums

Recovery Plan

Step 1: Boot via U-Boot serial (known-good commands)

setenv initrd_addr_r 0x0a000000 ext4load nvme 0:4 ${kernel_addr_r} /boot/vmlinuz-6.1.75-vendor-rk35xx ext4load nvme 0:4 0x0a000000 /boot/uInitrd-6.1.75-vendor-rk35xx ext4load nvme 0:4 ${fdt_addr_r} /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb setenv bootargs console=ttyS2,1500000 root=/dev/nvme0n1p1 rw rootwait rootfstype=ext4 booti ${kernel_addr_r} ${initrd_addr_r}:${filesize} ${fdt_addr_r}

This bypasses the panthor overlay entirely (loads base DTB directly).

Step 2: Once booted, disable the overlay and pin the kernel

bash

# Comment out panthor overlay sudo sed -i 's/^overlays=panthor-gpu/#overlays=panthor-gpu/' /boot/armbianEnv.txt # Pin ALL kernel packages sudo apt-mark hold linux-image-vendor-rk35xx linux-dtb-vendor-rk35xx \ linux-headers-vendor-rk35xx linux-u-boot-orangepi5-plus-vendor
# Verify apt-mark showhold cat /boot/armbianEnv.txt

Step 3: Check what actually changed

bash

# See if a new kernel was installed dpkg -l | grep linux-image ls -lt /boot/vmlinuz* ls -lt /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb # Check overlay timestamp ls -lt /boot/dtb/rockchip/overlay/rockchip-rk3588-panthor-gpu.dtbo # Check apt history cat /var/log/apt/history.log | tail -50

Step 4 (Future): Proper Fix Options

Once stable, you have two paths to properly restore GPU acceleration:

A) Stay on 6.1.75 vendor + add gpu-supply to a custom overlay:

dts

// Custom overlay that adds gpu-supply to power-controller // This is the DTS fix from the upstream patchset &power_controller { gpu-supply = <&vdd_gpu_s0>; };

B) Wait for Armbian to ship a vendor kernel with the fix backported, or move to a mainline kernel (6.15+) once the full patchset is in a stable release.
 

Are you at the serial console now? Let's get you booted.

15 minutes ago, iDare said:

Known good kernel is 6.1.75-vendor-rk35xx

 

 v25.11.2 for Orange Pi 5 Plus running Armbian Linux 6.1.115-vendor-rk35xx

on mine. Just saying.

 

You should use a spoiler for the slop. tl;dr: vendor kernel has exactly nothing in common with mainline besides the fact that it is supposed to run in the same hw.

Solid write-up from iDare.

Two things worth adding from a vendor perspective, since we shiped RK3588 boards and hit this failure mode in the field:

1.  The gpu-supply fix is board-specific. vdd_gpu_s0 exists on the OPi5 Plus. On other RK3588 boards the GPU rail is fed by a different
regulator (some use a PWM-controlled DC-DC), so check your own DTS before copying the overlay - a wrong phandle either fails the DTB
build or still panics at panthor probe because the regulator never gets enabled.

 2.  For anyone deploying fleets (signage, kiosks, industrial), treat this as a fleet-management problem, not a recovery problem. One unattended apt upgrade bricking a rack of displays overnight is the kind of thing that kills a project. On our production images we apt-mark hold the kernel packages and only roll kernel updates through a controlled test gate - the panthor overlay update is exactly that class of change.  
If you stay on 6.1.75 + custom overlay, also check regulator-enable-ramp-delay on the GPU rail; some boards need it to
avoid transient SErrors under load even with gpu-supply present.
Mainline 6.15+ (f94500eb7328) had fixed; the overlay keeps deployed fleets running in the meantime.