v1.9.0 — multi-core NPU (all 3 cores)

Orange Pi 5 Pro — Armbian/Ubuntu resolute, mainline kernel 6.18.38, KDE Plasma. Everything from v1.8.0 (working NPU inference at 800 MHz, GPU + Vulkan, HW video decode) plus the NPU now runs on all three cores.

💿 Images

• opi5pro-v1.9.0-desktop.img.xz — KDE Plasma desktop (~1.05 GB).
• opi5pro-v1.9.0-minimal.img.xz — headless CLI (~395 MB).

Both carry the identical, working GPU + NPU stack.

⚡ Flashing — use Etcher, not Rufus

Flash with Balena Etcher, USBImager, or Raspberry Pi Imager (no "customization"). These write the image byte-for-byte.

Rufus in "ISO Image mode" re-creates the filesystem and changes its UUID, which hangs boot at "mounting root" ((initramfs) BusyBox prompt). Use Etcher, or Rufus "DD Image mode".

Verify: sha256sum -c opi5pro-v1.9.0-desktop.img.xz.sha256

🚀 New in v1.9.0 — multi-core NPU (all 3 cores)

The RK3588 NPU has three cores, but the driver previously shipped clamped to core 0 only: mainline's rockchip-iommu faults the moment the driver programs cores 1/2's MMU banks, because those banks live in power domains that are still off at that point. This release fixes it entirely in the DKMS module + devicetree overlay — no in-tree kernel patch:

• A 4-bank single-IOMMU overlay folds all three cores' MMU banks into one IOMMU node, so every core translates through the same page table — no core is left on a bypassed MMU (which would silently corrupt memory).
• rknpu-multicore.patch pre-powers the NPU core power domains + core1/core2 bus clocks at module load (before the kernel resumes the shared IOMMU), restoring core_mask = 0x7 behind a runtime coverage gate that keeps the driver safe on any devicetree.

Verified on hardware, from a clean flash, with no manual steps: MobileNet v1 classifies correctly (ImageNet class 156) on core_mask 0x1, 0x2, 0x4, and combined 0x7 — cores 1 and 2 each proven to translate through their own MMU — with no rk_iommu faults under stress. ~385 inf/s single-core/auto, ~558 inf/s across cores at mask 0x7; larger/parallel workloads benefit most.

Check it: orangepi-npu-benchmark, or select cores from your app via rknn_set_core_mask().

⚡ NPU DVFS (from v1.8.0, still here)

Auto-pins 800 MHz @ 0.9 V on boot (up from the 200 MHz stock floor). Real devfreq with a voltage-coordinated OPP table; orangepi-npu-performance.service pins the production frequency.

🧠 NPU inference (from v1.7.0, still here)

Real RKNN model inference out of the box, non-root — dma-buf import, ioctl, and IOMMU fixes; udev rules for /dev/rknpu + /dev/dma_heap; librknnrt 2.3.2 + rknn_server + a sample model.

🎨 GPU / Vulkan (from v1.7.0)

Mali-G610 via Panfrost (OpenGL ES 3.1) + PanVK Vulkan 1.4, HW video decode (MPP + rockchip-vaapi), Brave.

v1.8.0 — NPU DVFS: ~3× throughput (800 MHz)

Orange Pi 5 Pro — Armbian/Ubuntu resolute, mainline kernel 6.18.38, KDE Plasma. Everything from v1.7.0 (working NPU inference, GPU + Vulkan, HW video decode) plus the NPU now runs at 800 MHz via proper DVFS — ~3× the throughput.

💿 Images

• opi5pro-v1.8.0-desktop.img.xz — KDE Plasma desktop (~1 GB).
• opi5pro-v1.8.0-minimal.img.xz — headless CLI (~440 MB).

Both carry the identical, working GPU + NPU stack.

⚡ Flashing — use Etcher, not Rufus

Flash with Balena Etcher, USBImager, or Raspberry Pi Imager (no "customization"). These write the image byte-for-byte.

Rufus in "ISO Image mode" re-creates the filesystem and changes its UUID, which hangs boot at "mounting root" ((initramfs) BusyBox prompt). Use Etcher, or Rufus "DD Image mode".

Verify: sha256sum -c opi5pro-v1.8.0-desktop.img.xz.sha256

🚀 New in v1.8.0 — NPU DVFS (~3× throughput)

The NPU was running at its 200 MHz boot floor because the driver shipped with DVFS stubbed out. It now scales up properly and auto-pins 800 MHz @ 0.9 V on boot — verified on a fresh flash: MobileNet v1 at ~330–385 inferences/s (vs ~108 at 200 MHz), correct output, stable across reboots.

• Restored real devfreq (vendored the one missing kernel header; dropped RKNPU_NO_DEVFREQ).
• Voltage-coordinated frequency via an OPP table (dev_pm_opp_set_rate) — raises vdd_npu before the clock.
• Root cause of the earlier clock hangs was gated peripheral clocks, not voltage: an NPU clock change reprograms the PVTPLL through the NPU GRF over APB, and mainline gates pclk_npu_root/grf/pvtm at boot — accessing them while gated wedges the SoC. The driver now holds those clocks live during the rate change.
• orangepi-npu-performance.service pins the production frequency (NPU_FREQ_HZ, default 800 MHz; 1000 MHz proven if you want max).

Check it: orangepi-npu-benchmark → ~330+ inf/s @ 800 MHz.

🧠 NPU inference (from v1.7.0, still here)

Real RKNN model inference works out of the box, non-root — dma-buf import, ioctl, and IOMMU fixes; udev rules for /dev/rknpu + /dev/dma_heap; librknnrt 2.3.2 + rknn_server + a sample model.

🎨 GPU / Vulkan (from v1.7.0)

Mali-G610 via Panfrost (OpenGL ES 3.1) + PanVK Vulkan 1.4, HW video decode (MPP + rockchip-vaapi), Brave.

⚠️ Known limitations

• NPU is single-core (core 0) — full per-model speed; multi-core (for parallel/large workloads) needs a different devicetree shape, tracked as a follow-up.

v1.7.0 — NPU inference actually works + Vulkan

Orange Pi 5 Pro desktop image — Armbian/Ubuntu resolute, mainline kernel 6.18.38, KDE Plasma. The headline: the NPU now runs real model inference — previous images could load the driver but no model would actually execute. Verified on hardware.

💿 Images

• opi5pro-v1.7.0-desktop.img.xz — KDE Plasma desktop (~939 MB).
• opi5pro-v1.7.0-minimal.img.xz — headless CLI (~439 MB).

Both include the identical, working NPU + Vulkan stack; pick by whether you want a GUI.

⚡ Flashing — use Etcher, not Rufus

Flash the image with Balena Etcher, USBImager, or Raspberry Pi Imager (without "customization"). These write the image byte-for-byte.

Rufus in "ISO Image mode" re-creates the filesystem and changes its UUID, which makes the board hang at boot on "mounting root" (drops to an (initramfs) BusyBox prompt). If you must use Rufus, choose "DD Image mode".

Verify the download first:

sha256sum -c opi5pro-v1.7.0-desktop.img.xz.sha256

🧠 NPU: real model inference now works

Earlier images loaded the rknpu driver but could not run any model — RKNPU_SUBMIT/RKNPU_MEM_SYNC returned EINVAL and the hardware-version register read 0, so librknnrt misdetected the SoC and rejected RK3588 models. This release fixes the whole path. Verified: MobileNet v1 runs at ~110 inferences/s as a non-root user and classifies correctly (the sample dog image → class 156 "Blenheim spaniel", 88%).

• Bus clocks wired into the NPU devicetree — the core register interfaces are clocked by aclk/hclk_npuN (which live on the IOMMU nodes on mainline); without them every core-register read returned 0. HW version now reads correctly.
• dma-buf import path implemented in rknpu_mem.c so the buffers librknnrt allocates from /dev/dma_heap/system actually reach the NPU (the vendor port only handled driver-allocated memory).
• Batched-ioctl result-clobber fixed — the misc-ioctl wrapper was overwriting MEM_CREATE's obj_addr/dma_addr with stale input, so every submit/sync failed.
• Single-IOMMU devicetree + core_mask clamp — mainline of_xlate is last-wins, so binding three IOMMUs left cores on a bypassed MMU (garbage reads / corruption risk). Bind core 0 only.
• RKNPU_GET_VOLT NULL-guard — the ioctl dereferenced a NULL regulator (DT names the supply npu-supply, the driver looked up rknpu-supply), a kernel oops any render-group process could trigger.
• udev rules open /dev/rknpu and /dev/dma_heap/* to the render group, so inference works without root.
• Ships librknnrt 2.3.2, rknn_server (connected-mode/profiling), a MobileNet sample model, and orangepi-npu-benchmark.

Check it after boot:

orangepi-npu-benchmark      # ~110 inferences/s

🎨 GPU / Vulkan

• Vulkan now works — mesa-vulkan-drivers (PanVK) added; previously vulkaninfo was present but every Vulkan app failed with no ICD. Mali-G610 MC4, Vulkan 1.4.
• OpenGL ES 3.1 via Panfrost, HW video decode (MPP + rockchip-vaapi), Brave — as before.

📦 Build

• Builds cleanly against the current Armbian framework (kernel 6.18.38); the framework bug workarounds and short image naming are folded into 02-build-resolute.sh.

⚠️ Known limitations

• NPU is single-core (core 0) — safe and full-speed for typical models; true 3-core use needs a different devicetree shape (single IOMMU node, three reg banks), tracked as a follow-up.

v1.6.1 — first-boot UX hotfix

What's new in v1.6.1

Hotfix: first-boot screen no longer looks frozen

v1.6.0's SDDM-blocked-until-setup gate worked correctly at the systemd level — the unit was inactive after firstrun, no Plasma loaded prematurely. But armbian-firstlogin still took its sddm-detected branch, which:

1. Created an autologin sddm.conf.d for passwordless Plasma login (security regression we didn't want).
2. Printed Now starting desktop environment via sddm... to TTY.
3. Called systemctl enable --now sddm (silently no-op'd by our gate, but firstlogin doesn't know that).
4. exit 1'd out, leaving the user looking at the "starting desktop" message with no obvious next prompt — even though a clean bash prompt was waiting underneath. Looked frozen.

Fix

Patch armbian-firstlogin during chroot build to take its no display manager detected else-branch on first boot — which clears the screen, runs MOTD (showing the orangepi-setup reminder), and exits cleanly so the login shell drops to a real prompt. Implemented as three idempotent sed prefixes (false &&) on the [[ -f /usr/bin/sddm ]] / lightdm / gdm3 file-existence checks. SDDM stays installed and gated by section 3b's drop-in; it's just not auto-enabled by firstlogin anymore.

03-setup.sh now also explicitly enables/disables sddm.service based on the user's "auto-start Plasma" answer, since we can no longer rely on firstlogin to enable it.

What you'll see on first boot now

1. TTY login prompt for root (Armbian default password).
2. armbian-firstlogin asks for a new root password, creates a regular user, sets locale.
3. Screen clears, Orange Pi 5 Pro MOTD shows with the Run: orangepi-setup reminder.
4. Log in as the user you just created.
5. MOTD again. Run orangepi-setup. Answer prompts. Reboot.
6. If you picked "auto-start Plasma": land in Plasma. Otherwise: stay at TTY.

Kernel ticked up to 6.18.28 in this build (Armbian CI bumped the kernel-current package between v1.6.0 and v1.6.1).

Asset sizes

File	Size	v1.6.0	v1.5.1
*_desktop.img.xz	~907 MB	911 MB	922 MB
*_minimal.img.xz	~391 MB	384 MB	392 MB

NPU stack (unchanged from v1.5.1+v1.5.2)

All eight v1.5.1 fixes plus the v1.5.2 CMA-heap probe-fallback are still in. After firstrun + orangepi-setup + reboot:

ls /dev/rknpu                                                # exists
cat /sys/firmware/devicetree/base/npu@fdab0000/compatible    # rockchip,rk3588-rknpu
sudo dmesg | grep -i rknpu                                   # no -ENXIO, no probe failure
ldconfig -p | grep librknnrt                                 # present

If all four pass, rknn-toolkit2 model inference will run.

Known limits (unchanged)

• OpenGL Core profile capped at 3.1 (Mesa panthor maturity).
• ffmpeg-vaapi -hwaccel vaapi doesn't work with woodyst/rockchip-vaapi 0.1; browser HW decode via libva still works.
• 5 Pro is community-tier (CSC) in Armbian.
• NPU runs at fixed clock (no DVFS); cold-reset from boot only.

v1.6.0 — single clean TTY path through setup

What's new in v1.6.0

One clean path through setup: TTY → orangepi-setup → reboot → done

The previous flow was confusing — armbian-firstlogin runs systemctl enable --now sddm unconditionally at the end of its TTY user-creation prompts, so users landed in Plasma immediately, with no kdialog wizard visible (it raced firstlogin's still-running shell), no hint that orangepi-setup existed, then rebooted into TTY because default.target was still multi-user. The MOTD reminder was suppressed too because the Plasma autostart shim had pre-touched the per-user ~/.opi5pro-setup-done flag.

v1.6.0 replaces that with a single linear flow:

1. TTY pre-install — armbian-firstrun walks you through root password, user creation, locale.
2. firstlogin tries to start SDDM, but a sddm.service.d/orangepi-wait-setup.conf drop-in adds ConditionPathExists=/etc/.opi5pro-setup-done-system. Systemd silently skips activation (no journal noise, condition-mismatches aren't errors). User stays on TTY.
3. MOTD reminder shows on TTY login — Orange Pi 5 Pro branded header + the Run: orangepi-setup callout.
4. User runs orangepi-setup, answers the six prompts (Plasma auto-start, NVMe migration, SPI bootloader, HW video decode — already baked in on desktop, HDMI overscan).
5. 03-setup.sh on success touches both flags: ~/.opi5pro-setup-done (per-user, silences MOTD) and /etc/.opi5pro-setup-done-system (system-wide, unblocks SDDM). It also clearly tells the user what'll happen on next boot based on the target they chose.
6. One reboot → final state. If the user enabled auto-start at the prompt, they land in Plasma; otherwise, they stay at TTY (with a separate motd tip showing how to bring SDDM up manually).

What was dropped

• /etc/xdg/autostart/orangepi-setup-gui.desktop — the kdialog wizard no longer auto-fires on first Plasma login. The application-launcher entry stays in /usr/share/applications/ for users who want to re-run the wizard from the K menu.
• orangepi-graphical-default.service — the auto-flip-to-graphical service was the cause of the "TTY first reboot, Plasma second reboot" confusion. Now default.target is only touched by 03-setup.sh based on the user's explicit answer to "auto-start Plasma?".
• The autostart shim's pre-touch of ~/.opi5pro-setup-done — that was suppressing the MOTD even when setup never actually completed. Now only 03-setup.sh's success-touch matters.

NPU still works (carryover from v1.5.1 + v1.5.2)

All eight NPU fixes from v1.5.1 plus the v1.5.2 CMA-heap probe-fallback are in v1.6.0. After firstrun + orangepi-setup + reboot:

ls /dev/rknpu                                                # exists
cat /sys/firmware/devicetree/base/npu@fdab0000/compatible    # rockchip,rk3588-rknpu
sudo dmesg | grep -i rknpu                                   # no -ENXIO, no probe failure
ldconfig -p | grep librknnrt                                 # present

If all four pass, rknn-toolkit2 model inference will run. The desktop image also includes Plasma + Brave + HW video decode + NPU; the minimal image is CLI + NPU.

Asset sizes

File	Size	v1.5.1	v1.4.3
*_desktop.img.xz	~911 MB	922 MB	758 MB
*_minimal.img.xz	~384 MB	392 MB	291 MB

Boot flow (this is the whole user-facing thing now)

1. Flash with balenaEtcher (Pi Imager and Rufus have produced unbootable cards on this board).
2. Boot. TTY login appears. armbian-firstrun asks for root password, creates a regular user, sets locale and timezone.
3. Log in as the user you just created. The MOTD shows the Orange Pi 5 Pro banner and a reminder to run orangepi-setup.
4. Run orangepi-setup. Answer six prompts; takes a few minutes if you're migrating to NVMe (longer if you're building HW video on the minimal image).
5. Reboot once. That's it.

If you want a GUI re-run later, "Orange Pi 5 Pro Setup" is in the K menu under Settings → System after first boot into Plasma.

Known limits (unchanged)

• OpenGL Core profile capped at 3.1 (Mesa panthor maturity).
• ffmpeg-vaapi -hwaccel vaapi doesn't work with woodyst/rockchip-vaapi 0.1; browser HW decode via libva still works.
• 5 Pro is community-tier (CSC) in Armbian.
• NPU runs at fixed clock (no DVFS); cold-reset from boot only.

v1.5.1 — NPU actually works + Brave browser

What's new in v1.5.1

NPU support is actually working now

v1.5.0 shipped a half-finished NPU stack — the module loaded, the DT overlay was on disk, librknnrt.so was in /usr/lib, but /dev/rknpu never appeared and librknnrt couldn't talk to anything. v1.5.1 fixes the chain of issues required to make the vendor rknpu driver compile, bind to a DT node, and expose a misc device that librknnrt can actually open.

What had to be fixed (in order of discovery):

1. DT overlay install path was wrong. Armbian's u-boot loads user_overlays= from /boot/overlay-user/, not /boot/dtb/rockchip/overlay/. v1.5.0 had the file in the wrong place, so u-boot silently skipped it, the upstream rknn_core_* nodes stayed at compatible = rockchip,rk3588-rknn-core, and our rknpu driver's match table never hit.

2. Missing dt-bindings includes. The overlay referenced SCMI_CLK_NPU and SRST_A_RKNN_NODDR. The clock symbol exists in dt-bindings/clock/rockchip,rk3588-cru.h; the reset symbol doesn't exist in mainline at all (vendor BSP only). Added the clock include, dropped the resets ref + the optional npu_opp_table (not in mainline either).

3. IRQ + PM-domain names were wrong. Driver looks up npu0_irq, npu1_irq, npu2_irq and PM domains npu0, npu1, npu2; overlay had npu_irq0/1/2 and nputop, npu1, npu2. Fixed to match upstream rknpu_drv.c lookups exactly.

4. -DCONFIG_ROCKCHIP_RKNPU_DRM_GEM made the driver expose /dev/dri/cardN instead of /dev/rknpu. librknnrt.so only opens /dev/rknpu (the misc device). Switched the build to DMA_HEAP mode (mutually exclusive with DRM_GEM) by stripping the -D from upstream's Kbuild, adding -DCONFIG_ROCKCHIP_RKNPU_DMA_HEAP, and force-including rknpu_build_config.h to #undef DRM_GEM after autoconf.h runs.

5. Missing rk-dma-heap.h header. Rockchip BSP-only API; mainline kernels don't ship it. Added a stub at src/include/compat/linux/rk-dma-heap.h with safe -ENODEV returns so the DMA_HEAP code path compiles and degrades to "no heap" at runtime (the misc device is registered regardless).

6. rknpu_devfreq.c won't build. Armbian-current's kernel-headers package doesn't ship linux/devfreq-governor.h. Dropped rknpu_devfreq.o from the Kbuild obj list and added -DRKNPU_NO_DEVFREQ so the inline-stub path in rknpu_devfreq.h is taken everywhere. Loses DVFS — NPU runs at fixed clock — functional inference unaffected.

7. rknpu_gem.c ungated fake_dev reference. rknpu_gem_sync_ioctl references rknpu_dev->fake_dev unconditionally, but the field is only declared under CONFIG_ROCKCHIP_RKNPU_DRM_GEM. The function is dead code in DMA_HEAP mode (never reached without a DRM device), but the compiler still type-checks it. Sed-swapped the three refs to ->dev.

8. Upstream w568w/rknpu-module is missing rknpu_mem.c entirely. The memory-allocation ioctl backends rknpu_mem_create_ioctl, rknpu_mem_destroy_ioctl, rknpu_mem_sync_ioctl are declared in headers but never implemented. modpost failed with three "undefined symbol" errors. Vendored Talos's ~700-line from-scratch implementation (npu-patches/rknpu_mem.c, GPL-2.0) which provides them — IOVA cursor allocator, dma_alloc_noncontiguous(), graceful fallback when rk_dma_heap_find returns NULL.

Brave browser baked into the desktop image

Native arm64 .deb from Brave's official APT repo. Picked over Firefox because Ubuntu 26.04's snap-based Firefox is sluggish on RK3588; Brave's deb is responsive, supports VAAPI hardware video decode against the rockchip-vaapi we already build, and has a built-in ad blocker. Adds ~150 MB.

plasma-discover is also installed (came in via kubuntu-desktop's recommends — was already there in v1.5.0, just confirming).

Asset sizes

File	Size	v1.5.0	v1.4.3
*_desktop.img.xz	~923 MB	830 MB	758 MB
*_minimal.img.xz	~393 MB	421 MB	291 MB

Desktop grew ~93 MB — Brave browser plus the additional NPU patches (Talos's rknpu_mem.c, compat headers). Minimal shrank slightly vs v1.5.0 (better xz block alignment with the slightly different rootfs).

Verifying NPU after first boot

# Driver bound? Should show fdab0000.npu and three IRQs registered.
sudo dmesg | grep -i rknpu

# Misc device exposed?
ls /dev/rknpu

# Userspace runtime present?
ldconfig -p | grep librknnrt

# DT overlay applied?
cat /sys/firmware/devicetree/base/npu@fdab0000/compatible
# Should print: rockchip,rk3588-rknpurockchip,rknpu

If /dev/rknpu exists and compatible includes rockchip,rk3588-rknpu, the stack is functional and rknn-toolkit2 model inference will work.

Known limits (unchanged)

• OpenGL Core profile capped at 3.1 (Mesa panthor maturity).
• ffmpeg-vaapi -hwaccel vaapi doesn't work with woodyst/rockchip-vaapi 0.1; browser HW decode via libva still works.
• 5 Pro is community-tier (CSC) in Armbian.
• NPU runs at fixed clock (no DVFS) due to the missing linux/devfreq-governor.h workaround.
• DT overlay drops srst_a reset (no soft-reset on probe) and npu_opp_table (no OPP-driven DVFS); cold-reset from boot works fine.
• Mainline rocket driver is blacklisted because it's mutually exclusive with vendor rknpu. Can be swapped if you specifically want the rocket + Mesa Teflon path (only supports MobileNet-class models today).

Boot flow (unchanged)

1. Flash with balenaEtcher (Pi Imager and Rufus have produced unbootable cards on this board).
2. TTY login: armbian-firstrun walks you through root password, user creation, locale.
3. Desktop image: SDDM/Plasma starts → kdialog wizard pops up → reboot lands in Plasma every time.
4. Minimal image: motd shows the setup-reminder banner → run orangepi-setup at the text prompt.

v1.5.0 — RK3588 NPU support (both images)

What's new in v1.5.0

RK3588 NPU support — both images

Both desktop and minimal images now bake in the full Rockchip NPU stack on the same mainline kernel that gives you Mali-G610 GPU acceleration via panthor + Mesa panvk. Until this release it was a forced choice (vendor BSP kernel = NPU but no GPU; mainline kernel = GPU but no NPU). v1.5.0 removes that tradeoff.

What's installed:

• Kernel module: w568w/rknpu-module v0.9.8 packaged via DKMS — auto-rebuilds on kernel updates. Patched at chroot-build time to drop rknpu_devfreq.o (Armbian-current's headers package doesn't ship linux/devfreq-governor.h) and to define RKNPU_NO_DEVFREQ, forcing the inline-stub path so callers don't pull undefined symbols at link time. Loses DVFS — NPU runs at fixed clock — but functional inference is unaffected.
• Userspace: librknnrt.so 2.3.2 from airockchip/rknn-toolkit2 at /usr/lib/. Stable across the 2.x.x release line; ABI-compatible with the rknpu module 0.9.8.
• DT overlay: rk3588-rknpu-opi5pro.dtbo shipped at /boot/dtb/rockchip/overlay/, enabled via user_overlays= in /boot/armbianEnv.txt. Disables the mainline rknn_core_* nodes (the in-tree rocket driver) and inserts a single vendor-style rknpu node spanning all three NPU cores so the DKMS module binds. Adapted from schwankner/talos-rk3588-npu's Turing-RK1 overlay (same SoC). Soft-reset and OPP table refs were dropped because mainline's dt-bindings/reset/rockchip,rk3588-cru.h doesn't expose the SRST_A_RKNN_NODDR symbol the BSP uses, and the npu_opp_table reference doesn't exist in mainline DT either; both are optional in the rknpu binding.
• Module loading: rocket is blacklisted (vendor rknpu and mainline rocket are mutually exclusive — they fight over the same hardware). rknpu auto-loads at boot via /etc/modules-load.d/.

What works on this stack

The full rknn-toolkit2 model zoo: YOLOv5/v8/v9, RKLLM, ResNet50, MobileNet, Frigate's rknn detector, etc. This is the production stack Talos Linux ships on Linux 6.18 mainline.

What's intentionally not used: Rocket

Linux 6.18 also ships the in-tree rocket driver (drivers/accel/rocket/) — the upstream-blessed mainline NPU driver. It works elegantly via Mesa Teflon delegate, but as of May 2026 it only supports MobileNet-class models — no YOLO, no LLM, no Frigate rknn detector. We blacklist it on the desktop image; if you want to use Rocket-via-Teflon instead, unmask rocket, mask rknpu, and disable the DT overlay.

Asset sizes

File	Size	Pre-NPU (v1.4.3)	Delta
*_desktop.img.xz	~831 MB	758 MB	+73 MB
*_minimal.img.xz	~422 MB	291 MB	+131 MB

The minimal image takes a bigger relative hit (kernel headers are baked in via INSTALL_HEADERS=yes so DKMS can rebuild against future kernel upgrades). Future v1.5.x may add a "purge headers after DKMS install" optimization for users who don't need on-device kernel module rebuilds.

Boot flow (unchanged)

1. Flash with balenaEtcher (Pi Imager and Rufus have produced unbootable cards on this board).
2. TTY login: armbian-firstrun walks you through root password, user creation, locale.
3. Desktop image: SDDM/Plasma starts → kdialog wizard pops up → reboot lands in Plasma every time.
4. Minimal image: motd shows the setup-reminder banner → run orangepi-setup at the text prompt.

Verifying NPU after first boot

# Driver bound?
dmesg | grep -i rknpu
ls /dev/rknpu

# Userspace runtime present?
ldconfig -p | grep librknnrt

# DT overlay applied?
grep -i rknpu /sys/firmware/devicetree/base/__symbols__ 2>/dev/null

Known limits

• OpenGL Core profile capped at 3.1 (Mesa panthor maturity).
• ffmpeg-vaapi -hwaccel vaapi doesn't work with woodyst/rockchip-vaapi 0.1; browser HW decode via libva still works.
• 5 Pro is community-tier (CSC) in Armbian.
• NPU runs at fixed clock (no DVFS) due to the missing linux/devfreq-governor.h workaround.
• The DT overlay drops srst_a reset and npu_opp_table — vendor BSP names that don't exist in mainline. Soft-reset on probe and OPP-driven DVFS aren't available; cold-reset from boot works fine.

v1.4.3 — autostart fix + Plasma on every boot + minimal motd

What's new in v1.4.3

Plasma kdialog wizard actually fires now (was broken in v1.4.2)

The autostart .desktop had a single-quoted shell expression in the Exec= line — XDG/Plasma's autostart parser doesn't handle single-quote shell quoting properly and silently bailed. Plus the deprecated X-KDE-autostart-phase=2 key was inherited from Plasma 5.

Fix: extracted the conditional into a tiny shim (/usr/local/bin/orangepi-setup-gui-autostart) and made the .desktop Exec= a plain absolute path. Dropped the deprecated KDE keys.

One-shot guarantee tightened

The autostart shim now touches ~/.opi5pro-setup-done immediately on first auto-launch — so the wizard auto-fires exactly once per user, even if the user closes it mid-flow. Manual re-runs from the application launcher (or orangepi-setup-gui in a terminal) ignore the flag, so power users can still re-invoke whenever.

Desktop image now defaults to Plasma on every boot

The image still ships with default.target = multi-user.target because armbian-firstlogin (root password / user creation) needs a TTY — SDDM can't host that wizard without an existing user account. After firstlogin completes, Armbian itself starts SDDM imperatively (systemctl enable --now sddm) — that's why first boot lands in Plasma. But subsequent boots stayed at TTY because default.target wasn't being flipped.

Fix: a new boot service orangepi-graphical-default.service runs once after armbian-firstrun.service, conditional on (a) /root/.not_logged_in_yet being absent (firstlogin done), (b) SDDM existing, and (c) a sentinel marker not already set. When all three pass, it flips default.target to graphical.target and disables itself. From then on, every reboot lands in Plasma. The wizard's first prompt remains the lever to opt out for headless / server use.

Minimal image now bakes in the setup-reminder motd + branded header

Previously the minimal image was a vanilla Armbian rootfs with no chroot customization — no Orange Pi branded motd, no orangepi-setup symlink, no setup reminder. Users had to know to clone the repo themselves before running 03-setup.sh.

Fix: new customize-image-minimal.sh does the headless-friendly subset of the desktop customization — clones the repo to /usr/local/share/OrangePi5Pro/, symlinks orangepi-setup into /usr/local/bin/, replaces the Armbian motd header with Orange Pi 5 Pro branding (with (minimal image) suffix to signal the difference), drops the same 99-orangepi-setup reminder banner desktop has, and bakes consoleblank=0 into armbianEnv.txt. Does not install Plasma, the kdialog wizard, or the boot-time graphical auto-flip — those stay desktop-only.

TTY motd tip: how to start Plasma (desktop image)

For users who opt out of auto-start at the wizard prompt, or who land at a TTY (Ctrl+Alt+F2), a new 97-orangepi-plasma-tip motd fragment shows when SDDM exists but isn't running:

  Plasma desktop is not running.
  Start it now:                 sudo systemctl start sddm
  Boot into Plasma every time:  sudo systemctl set-default graphical.target

Assets

File	Size	Notes
*_resolute_current_*_desktop.img.xz	~740 MB	Plasma + HW video decode + kdialog wizard + Plasma-on-every-boot
*_resolute_current_*_minimal.img.xz	~305 MB	CLI only; motd reminds you to run orangepi-setup

Both use Ubuntu 26.04 (Resolute) on mainline 6.18.26 with Mali-G610 GPU acceleration via panthor + Mesa panvk.

Boot flow

1. Flash with balenaEtcher (Pi Imager and Rufus have produced unbootable cards on this board).
2. TTY login: armbian-firstrun walks you through root password, user creation, locale.
3. Desktop image: SDDM/Plasma starts automatically; log in → kdialog wizard pops up to finish setup. Every reboot from then on lands directly in Plasma (unless you opt out).
4. Minimal image: motd shows a setup reminder → run orangepi-setup at the text prompt.

Known limits (unchanged)

• OpenGL Core profile capped at 3.1 (Mesa panthor maturity).
• ffmpeg-vaapi -hwaccel vaapi doesn't work with woodyst/rockchip-vaapi 0.1; browser HW decode via libva still works.
• 5 Pro is community-tier (CSC) in Armbian.

v1.4.2 — Plasma kdialog setup wizard

What's new in v1.4.2

Plasma kdialog setup wizard

The TTY motd → "open konsole and run orangepi-setup" flow lost most users because they never opened a terminal. v1.4.2 adds a kdialog-based wizard that auto-launches once on first Plasma login — same setup flow, but the user can stay entirely in the GUI.

What it covers (Plasma + HW video are baked in, so it's a streamlined 3-question wizard):

• Auto-start Plasma on every boot — toggles graphical.target ↔ multi-user.target
• Migrate root filesystem to NVMe — opens a terminal running armbian-install (it's a curses TUI, can't be wrapped in kdialog), pre-explains the SPI bootloader choice via dialog beforehand
• HDMI overscan workaround — modifies /boot/armbianEnv.txt for TVs that crop edges

Privileged steps go through pkexec (Polkit's graphical sudo) — the user types their password a couple of times. Re-run any time from the application launcher ("Orange Pi 5 Pro Setup") or by running orangepi-setup-gui in a terminal. The wizard touches ~/.opi5pro-setup-done on completion so it's a one-time popup.

The TTY orangepi-setup (03-setup.sh) is unchanged and still drives the minimal image plus SSH / power-user re-runs on either image. Both front-ends share a single flag file.

Why the wizard exists

Last release I observed the desktop image landing the user directly in Plasma right after the TTY firstrun prompts, even though customize-image.sh sets default.target = multi-user.target. Mystery solved by inspecting the built image: /usr/lib/armbian/armbian-firstlogin runs systemctl enable --now sddm at line 1018 — that's a direct service start, not a target flip. default.target correctly stays at multi-user, but SDDM is launched imperatively on first login. Trying to "force TTY before Plasma" would mean patching armbian-firstlogin or masking sddm pre-firstlogin and re-enabling later — fragile, with several edge cases. The kdialog wizard auto-firing from Plasma is the clean answer.

Assets

File	Size	Notes
*_resolute_current_*_desktop.img.xz	~739 MB	Plasma + HW video decode + Orange Pi 5 Pro motd + kdialog wizard
*_resolute_current_*_minimal.img.xz	~303 MB	CLI only; run orangepi-setup post-boot

Both use Ubuntu 26.04 (Resolute) on mainline 6.18.26 with Mali-G610 GPU acceleration via panthor + Mesa panvk.

Boot flow

1. Flash with balenaEtcher (Pi Imager and Rufus have produced unbootable cards on this board).
2. TTY login: armbian-firstrun walks you through root password, user creation, locale.
3. Desktop image: SDDM/Plasma starts automatically. Log in → kdialog wizard pops up to finish setup.
4. Minimal image: motd shows the Orange Pi 5 Pro banner + a reminder to run orangepi-setup at the text prompt.

Known limits (unchanged)

• OpenGL Core profile capped at 3.1 (Mesa panthor maturity).
• ffmpeg-vaapi -hwaccel vaapi doesn't work with woodyst/rockchip-vaapi 0.1; browser HW decode via libva still works.
• 5 Pro is community-tier (CSC) in Armbian.

v1.4.1 — Orange Pi 5 Pro motd branding + flow cleanup

What's new in v1.4.1

Orange Pi 5 Pro motd branding

The login banner now identifies as Orange Pi 5 Pro instead of Armbian. customize-image.sh overwrites /etc/update-motd.d/10-armbian-header with our own header (ASCII "Orange Pi 5 Pro" banner + distro / kernel / hostname / IPv4 / uptime) and disables the Armbian-branded sysinfo and tips fragments. The setup-reminder banner (99-orangepi-setup) drops the redundant title line since the new header already announces the board. (Desktop image only — the minimal image keeps the default Armbian motd; run orangepi-setup post-flash to install Plasma + branding.)

Flow cleanup

• No more first-login auto-launch hook. Earlier versions auto-ran orangepi-setup from /etc/profile.d/orangepi-firstrun.sh on the first TTY login. That coincided with monitor DPMS blanking on slower TVs, leaving users staring at a _ cursor on a black screen and assuming the system had hung. Removed entirely. The motd reminder (which suppresses once ~/.opi5pro-setup-done is touched) now drives the user to invoke orangepi-setup themselves at a clean shell prompt.
• 03-setup.sh disables console blanking at start (setterm -blank 0 -powersave off -powerdown 0) so the prompt text stays visible during the slow ones (NVMe migration confirm, HW video build).
• consoleblank=0 baked into armbianEnv.txt belt-and-suspenders for non-hook TTYs.

Build robustness

• 02-build-resolute.sh fixes a regression where script_dir was computed after cd "$WORK", causing sibling-script lookups (apply-uutils-shim.sh, customize-image.sh) to fail when invoked as ./02-build-resolute.sh.
• New patch in apply-uutils-shim.sh: rewrites Armbian's hardcoded qemu-user-static package name to qemu-user-binfmt. Ubuntu 26.04 dropped qemu-user-static; the static binaries moved into qemu-user, and binfmt registration is in qemu-user-binfmt. Without this, prepare_host fails on a fresh resolute build host with "Package qemu-user-static has no installation candidate". (Earlier builds happened to work on hosts that had been bootstrapped from noble where the old package existed.)

Assets

File	Size	Notes
*_resolute_current_*_desktop.img.xz	~764 MB	Plasma + HW video decode + Orange Pi 5 Pro branded motd
*_resolute_current_*_minimal.img.xz	~303 MB	CLI only; run orangepi-setup post-boot for Plasma + setup

Both use Ubuntu 26.04 (Resolute) on mainline 6.18.26 with Mali-G610 GPU acceleration via panthor + Mesa panvk.

Boot flow

1. Flash with balenaEtcher (Pi Imager and Rufus have produced unbootable cards on this board).
2. Boot from SD. TTY login: armbian-firstrun walks you through root password, user creation, locale.
3. Reboot if needed; log in as your user.
4. Desktop image: motd shows the Orange Pi 5 Pro banner + a reminder to run orangepi-setup.
5. orangepi-setup walks the six prompts: Plasma autostart / NVMe migration / SPI bootloader / HW video decode / HDMI overscan workaround.

Known limits (unchanged)

• OpenGL Core profile capped at 3.1 (Mesa panthor maturity).
• ffmpeg-vaapi -hwaccel vaapi doesn't work with woodyst/rockchip-vaapi 0.1; browser HW decode via libva still works.
• 5 Pro is community-tier (CSC) in Armbian.