Orange Pi 5 Pro – Device Tree overlays not loading from armbianEnv.txt

[ManeeshaC]

BOARD - Orange Pi 5 Pro

 

PROBLEM

 

Device Tree overlays defined in armbianEnv.txt are not being applied during boot.

The overlay file exists but is not loaded by the system.

 

verbosity=1
bootlogo=false
console=both
extraargs=cma=256M
fdtfile=rockchip/rk3588s-orangepi-5-pro.dtb
rootdev=UUID=a8beb1c4-8079-4e64-8216-8e893f7809d4
rootfstype=ext4
overlays=orangepi-5-pro-disable-leds
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

I also tried with 

 

overlay_prefix=rockchip
overlays=orangepi-5-pro-disable-leds

 

The Kernel is
 

Linux orangepi5pro 6.1.115-vendor-rk35xx #1 SMP Mon Feb 23 05:39:00 UTC 2026 aarch64 GNU/Linux

 

Additional Information

 

I tested the same overlay using the official build system from:

https://github.com/orangepi-xunlong/orangepi-build

and it works correctly there.

 

This suggests the issue may be related to how Armbian loads overlays for RK3588 boards.

 

Question

 

Is overlay loading from armbianEnv.txt supported on the Orange Pi 5 Pro with the vendor-rk35xx kernel, or is there another mechanism required (extlinux overlays, user overlays, etc.)?

 

https://paste.armbian.com/xiteginoku

[Werner]

Attach debug serial console so you can follow u-boot logs and get an idea what the overlay is not applied.

[ManeeshaC]

 

picocom v3.1

port is        : /dev/tty.usbserial-A5069RR4
flowcontrol    : none
baudrate is    : 1500000
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready
?DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
ch0 ttot7
LPDDR5, 2400MHz
channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
ch1 ttot7
channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
ch2 ttot7
channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
ch3 ttot7
channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
Manufacturer ID:0xff
DQS rds:h1,l0, 
CH0 RX Vref:26.7%, TX Vref:20.0%,0.0%
DQ rds:h7 l0 h2 l0 l0 h1 h1 l0 , h2 h1 l0 h1 h4 h3 h2 h1 

DQS rds:h1,h1, 
CH1 RX Vref:26.7%, TX Vref:20.0%,0.0%
DQ rds:h4 h3 h1 h3 l0 h2 h1 h1 , h2 h5 h3 h1 h7 l0 h5 h2 

DQS rds:h1,h1, 
CH2 RX Vref:26.3%, TX Vref:21.0%,0.0%
DQ rds:h2 h3 h1 h4 h6 h1 h4 h7 , h1 h1 h4 h1 h5 h6 h4 h3 

DQS rds:l0,l0, 
CH3 RX Vref:28.5%, TX Vref:21.0%,0.0%
DQ rds:h1 h2 h3 l0 h3 h2 h1 h1 , h1 h2 h1 h1 h4 l0 h6 h1 

stride=0x2, ddr_config=0x2
hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0x0
change to F1: 534MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F2: 1320MHz
ch0 ttot8
ch1 ttot8
ch2 ttot8
ch3 ttot8
change to F3: 1968MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F0: 2400MHz
ch0 ttot7
ch1 ttot7
ch2 ttot7
ch3 ttot7
out
U-Boot SPL board init
U-Boot SPL 2017.09 (Feb 16 2026 - 04:05:08)
Trying to boot from MMC1
Trying fit image at 0x4000 sector
## Verified-boot: 0
## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK
## Checking uboot 0x00200000 ... sha256(31ad8d4f92...) + OK
## Checking fdt 0x003495b0 ... sha256(0195fe7e17...) + OK
## Checking atf-2 0xff100000 ... sha256(70505bb764...) + OK
## Checking atf-3 0x000f0000 ... sha256(b2af21b504...) + OK
Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000)
Total: 353.110 ms

INFO:    Preloader serial: 2
NOTICE:  BL31: v2.3():v2.3-868-g040d2de11:derrick.huang, fwver: v1.48
NOTICE:  BL31: Built : 15:02:44, Dec 19 2024
INFO:    spec: 0x13
INFO:    code: 0x88
INFO:    ext 32k is valid
INFO:    ddr: stride-en 4CH
INFO:    GICv3 without legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
INFO:    l3 cache partition cfg-0
INFO:    system boots from cpu-hwid-0
INFO:    enable memory repair
INFO:    idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
INFO:    dfs DDR fsp_params[0].freq_mhz= 2400MHz
INFO:    dfs DDR fsp_params[1].freq_mhz= 534MHz
INFO:    dfs DDR fsp_params[2].freq_mhz= 1320MHz
INFO:    dfs DDR fsp_params[3].freq_mhz= 1968MHz
INFO:    BL31: Initialising Exception Handling Framework
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2017.09 (Feb 24 2026 - 17:20:14 +0000)

Model: RK3588 Orange Pi 5 Pro
PreSerial: 2, raw, 0xfeb50000
DRAM:  8 GiB
Sysmem: init
Relocation Offset: eda2d000
Relocation fdt: eb9f9268 - eb9fecb8
CR: M/C/I
Using default environment

mmc@fe2c0000: 0, mmc@fe2e0000: 1
Bootdev(atags): mmc 0
MMC0: Legacy, 52Mhz
PartType: EFI
DM: v2
boot mode: None
Model: RK3588 Orange Pi 5 Pro
CLK: (sync kernel. arm: enter 1008000 KHz, init 1008000 KHz, kernel 0N/A)
  b0pll 24000 KHz
  b1pll 24000 KHz
  lpll 24000 KHz
  v0pll 24000 KHz
  aupll 24000 KHz
  cpll 1500000 KHz
  gpll 1188000 KHz
  npll 24000 KHz
  ppll 1100000 KHz
  aclk_center_root 702000 KHz
  pclk_center_root 100000 KHz
  hclk_center_root 396000 KHz
  aclk_center_low_root 500000 KHz
  aclk_top_root 750000 KHz
  pclk_top_root 100000 KHz
  aclk_low_top_root 396000 KHz
Net:   No ethernet found.
Hit key to stop autoboot('CTRL+C'):  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
4149 bytes read in 11 ms (368.2 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 0:1
286 bytes read in 10 ms (27.3 KiB/s)
15612135 bytes read in 1264 ms (11.8 MiB/s)
47405568 bytes read in 3810 ms (11.9 MiB/s)
244832 bytes read in 479 ms (499 KiB/s)
325 bytes read in 201 ms (1000 Bytes/s)
Applying kernel provided DT overlay rockchip-rk3588-orangepi-5-pro-disable-leds.dtbo
Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards.
Unknown command 'kaslrseed' - try 'help'
Fdt Ramdisk skip relocation
## Loading init Ramdisk from Legacy Image at 0a200000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    15612071 Bytes = 14.9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0x0a100000
   Booting using the fdt blob at 0x0a100000
   reserving fdt memory region: addr=a100000 size=a2000
  'reserved-memory' ramoops@110000: addr=110000 size=e0000
   Using Device Tree in place at 000000000a100000, end 000000000a1a4fff
Adding bank: 0x00200000 - 0xf0000000 (size: 0xefe00000)
Adding bank: 0x100000000 - 0x200000000 (size: 0x100000000)
Adding bank: 0x2f0000000 - 0x300000000 (size: 0x10000000)
Total: 6405.175 ms

Starting kernel ...

[!p]104[?7h[6n[32766;32766H[6n[40;1H[!p]104[?7h[6n[32766;32766H[6n[40;1H

Armbian_community 26.2.0-trunk.493 Trixie ttyFIQ0 

orangepi5pro login: 

 

[Werner]

Applying kernel provided DT overlay rockchip-rk3588-orangepi-5-pro-disable-leds.dtbo

Meaning the overlay was applied successful. If it does not work, perhaps this means some pin definitions or whatever differ from opi sources vs ours. 

[ManeeshaC]

UPDATE
 

I was able to figure out what was happening.

The board initially boots with the LEDs enabled. Because of this, applying the device tree overlay alone did not seem to disable them, even across reboots.

However, after manually turning the LEDs off once using:

 

echo 0 | tee /sys/class/leds/blue_led/brightness
echo 0 | tee /sys/class/leds/green_led/brightness

 

and then enabling the overlay, the LEDs remained disabled, and the overlay appeared to work as expected.

So it seems the LEDs needed to be turned off once manually before the overlay behaviour became consistent.

Everything now works as intended.

It appears that when overlay_prefix is either not defined or is empty, the system behaves unexpectedly during overlay lookup. In such cases, the loader seems to attempt resolving overlays starting with -, rather than correctly resolving the overlay name.