Orange Pi 5 Plus: NPU Driver Support for Docker Projects (e.g., rkllama)?

Douky · 10 August 2025 18:16

Hello everyone,

I’m currently trying to get the NPU on my Orange Pi 5 Plus working to run various AI-related Docker projects, with a specific focus on getting the rkllama project up and running. I’m hoping to get some guidance or share experiences with anyone who might have attempted something similar.

My Hardware:

Device: Orange Pi 5 Plus (32GB RAM)
Storage: NVMe SSD
OS: DietPi v9.15.2

My Goal:

My plan is to use DietPi as the base OS, install OpenMediaVault (OMV) on top of it, and then use Docker to run several different containers. A primary goal is to leverage the NPU for performance in projects like rkllama.

What I’ve Tried So Far:

Unfortunately, I’ve already had a few unsuccessful attempts. I’ve tried this with the official Orange Pi image and also with Armbian, but in every case, I’ve failed to get access to the NPU driver from within the operating system or the Docker container.

I’m relatively new to the world of single-board computers with NPUs, so I’m still learning. My current setup is a Raspberry Pi 4 running OMV with a few Docker containers, and I’m looking to migrate and expand on my new Orange Pi.

Has anyone had success with accessing the NPU on the Orange Pi 5 Plus with a recent DietPi build? I would be very grateful for any help, tips, or pointers on how to get the driver recognized and passed through to Docker containers.

Thanks in advance for your help!

makinikm · 29 December 2025 19:37

Hi,
Just installed v9.20.1 on OPi 5 Max and can’t get the NPU to work either, no kernel module present and it seems to be as if disabled by firmware… The vendor repo - RKlinux do have the driver, yet it doesn’t seem to be in the kernel (or initrd) image, or maybe disabled somehow?

MichaIng · 30 December 2025 18:26

The kernel module should be rknpu and shipped with the kernel.

Mainline Linux 6.18 (edge branch) ships a mainline Rocket NPU driver for the first time.

Both drivers provide an interface on a /dev/render* device node.

makinikm · 31 December 2025 18:42

The 6.18.0-edge-rockchip64 (from mainline image) identifies the NPU - loads the hantro_vpu module, but doesn’t recognize wireless wlan on OPi 5 Max…

urostor · 31 December 2025 21:25

What’s the chip on this board? If it’s aic8800, you need a dkms kernel module.
Also, what does hantro vpu have to do with the NPU?

makinikm · 31 December 2025 22:25

On the Trixie image with 6.1.115-vendor-rk35xx, the rknpu driver seems to fail initializing:

[   19.651699] RKNPU fdab0000.npu: Adding to iommu group 0
[   19.653969] RKNPU fdab0000.npu: RKNPU: rknpu iommu is enabled, using iommu mode
[   19.656222] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree
[   19.662346] RKNPU fdab0000.npu: Looking up mem-supply from device tree
[   19.667447] RKNPU fdab0000.npu: can’t request region for resource [mem 0xfdab0000-0xfdabffff]
[   19.669631] RKNPU fdab0000.npu: can’t request region for resource [mem 0xfdac0000-0xfdacffff]
[   19.671541] RKNPU fdab0000.npu: can’t request region for resource [mem 0xfdad0000-0xfdadffff]
[   19.672232] [drm] Initialized rknpu 0.9.8 20240828 for fdab0000.npu on minor 1
[   19.678986] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree
[   19.685198] RKNPU fdab0000.npu: RKNPU: bin=0
[   19.686447] RKNPU fdab0000.npu: leakage=9
[   19.687499] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree
[   19.687514] debugfs: Directory ‘fdab0000.npu-rknpu’ with parent ‘vdd_npu_s0’ already present!
[   19.695969] RKNPU fdab0000.npu: pvtm=916
[   19.701432] RKNPU fdab0000.npu: pvtm-volt-sel=5
[   19.702531] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree
[   19.702549] debugfs: Directory ‘fdab0000.npu-rknpu’ with parent ‘vdd_npu_s0’ already present!
[   19.704149] RKNPU fdab0000.npu: Looking up mem-supply from device tree
[   19.705525] RKNPU fdab0000.npu: avs=0
[   19.706653] RKNPU fdab0000.npu: rockchip_pvtpll_set_volt_sel: error cfg clk_id=6 voltsel (-1)
[   19.707822] RKNPU fdab0000.npu: l=15000 h=85000 hyst=5000 l_limit=0 h_limit=800000000 h_table=0

The /dev/render* doesn’t appear…

MichaIng · 1 January 2026 15:17

No, we patched this driver into our mainline Linux builds, no DKMS needed: rockchip64: add AIC8800 SDIO driver · MichaIng/build@79457dc · GitHub
But OPi 5 Max/Ultra use a different one anyway.

Yes that is sadly expected. The Max and Ultra use this Rockchip WiFi chip with bcmdhd driver which does not exist in mainline Linux:

TL;DR: Does modprobe brcmfmac actually work instead?
While the driver is located below some Rockchip vendor subdir, and the chip is labelled AP6611, it is a Broadcom chip (indicated by the module name, but also clearly stated in source files). There is some info that the bcmdhd driver is actually an Android Broadcom WiFi driver, while Linux ships its brcmfmac. That wouldn’t be so surprising, since Rockchip had shared Android and Linux sources earlier, one of the issues with earlier Rockchip vendor kernels throwing a bunch of additional errors and warnings since Android-only flags were enabled. I gave them a hint a while ago related to some particular prominent multi-line warning caused by a flag that really made sense on Android only, and they separated sources with 5.10 IIRC. But I would not wonder if some (originally) Android drivers remained in the sources.

Let’s see, the two supplies it looks up are defined here:

github.com/armbian/linux-rockchip

arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts

b908c7339


      
          &rknpu {
          	rknpu-supply = <&vdd_npu_s0>;
          	mem-supply = <&vdd_npu_mem_s0>;
          	status = "okay";
          };
          
          &rknpu_mmu {
          	status = "okay";
          };

This is the same for all RK3588 boards (with vendor kernel). The nodes are defined here:

github.com/armbian/linux-rockchip

arch/arm64/boot/dts/rockchip/rk3588s.dtsi

b908c7339


      
          	rknpu: npu@fdab0000 {
          		compatible = "rockchip,rk3588-rknpu";
          		reg = <0x0 0xfdab0000 0x0 0x10000>,
          		      <0x0 0xfdac0000 0x0 0x10000>,
          		      <0x0 0xfdad0000 0x0 0x10000>;
          		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
          			     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
          			     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
          		interrupt-names = "npu0_irq", "npu1_irq", "npu2_irq";
          		clocks = <&scmi_clk SCMI_CLK_NPU>, <&cru ACLK_NPU0>,
          			 <&cru ACLK_NPU1>, <&cru ACLK_NPU2>,
          			 <&cru HCLK_NPU0>, <&cru HCLK_NPU1>,
          			 <&cru HCLK_NPU2>, <&cru PCLK_NPU_ROOT>;
          		clock-names = "clk_npu", "aclk0",
          			      "aclk1", "aclk2",
          			      "hclk0", "hclk1",
          			      "hclk2", "pclk";
          		assigned-clocks = <&scmi_clk SCMI_CLK_NPU>;
          		assigned-clock-rates = <200000000>;
          		resets = <&cru SRST_A_RKNN0>, <&cru SRST_A_RKNN1>, <&cru SRST_A_RKNN2>,

This file has been truncated. show original

There we have the regions it can’t request. And then it seems to retry 2 times, causing the “already present” errors from debugfs.

No idea, neither the driver nor those parts in the device trees (which are all the same across all boards) have seen any changed within 2 years. Do you have any overlays active? Also maybe try with an older kernel builds:

apt policy linux-image-vendor-rk35xx

Don’t forget to downgrade the linux-dtb-vendor-rk35xx package as well. Reminds me that I want to merge those two packages.

urostor · 1 January 2026 16:39

It may be a stupid question but I thought Teflon only works with the mainline driver (rocket) and not rknpu?

makinikm · 2 January 2026 14:24

Didn’t use overlays (except the ones present in the images, if any). The board appears to be of “rev 1.1”, no idea if this may be the reason, but doubtful. The npu is initialized perfectly in the mainline - 6.18.0-edge-rockchip64:
[ 0.997022] platform fdab0000.npu: Adding to iommu group 0
[ 0.998374] platform fdac0000.npu: Adding to iommu group 1
[ 0.999665] platform fdad0000.npu: Adding to iommu group 2
[ 10.949953] rocket fdab0000.npu: Rockchip NPU core 0 version: 1179210309
[ 10.950294] rocket fdac0000.npu: Rockchip NPU core 1 version: 1179210309
[ 10.950584] rocket fdad0000.npu: Rockchip NPU core 2 version: 1179210309

My bad about the vpu and hantro module mixup, it was a bad grep output very similar to npu initialization… Trying the modprobe brcmfmac on the edge has yielded only this:

[ 512.582827] usbcore: registered new interface driver brcmfmac

wlan didn’t turn up:(

Please, I beg of you to merge these two! Silly me tried to switch kernels using apt install, rendering the setup unbootable. Due to that, I must add that armbian’s Kernel menu is awesome, makes switching pretty automated.

P.S.

After witnessing armbian’s setup, I must extend deepest gratitude and respect to Michalng and the Team for all the efforts! Und a Happy New Year to everyone!

P.P.S

Not a bot

usual-user · 6 January 2026 10:04

The TensorFlow Lite delegate Teflon also works as a liteRT backend for etnaviv
(VeriSilicon VIPNano NPU), which has long been upstream, as well as for the upcoming ethosu (Arm Ethos-U65/U85 NPU).

urostor · 7 January 2026 12:22

OK, I’m talking about RK3588 only here. The vendor driver is not Rocket.

MichaIng · 31 January 2026 16:14

Newer sources for the WiFi driver: GitHub - StreamUnlimited/broadcom-bcmdhd-4359: GPL Broadcom driver for bcm4359 / AP6398S

Though it might not contain all needed chip IDs. Always a problem with scattered sources patched independently, everyone adds own chip IDs and firmware paths as needed.

CoreELEC has also sources, but the base is a little older: GitHub - CoreELEC/ap6xxx-aml: WiFi Broadcom drivers ap6xxx