Testing the LibreComputer Alta AML-A311D-CC NPU

A few years ago I won (!) a SBC and have been trying to figure out what to do with it ever since. The board is called LibreComputer Alta AML-A311D-CC and this post will outline how I got it’s NPU working, even though I still don’t know what to do with it¹.

Table of Contents

Hardware & compatibility

LibreComputer is a fairly niche SBC manufacturer, at least for a hobbyist like me. I was initially hesitant to test this board as niche SBCs typically have issues with software support and compatibility, requiring downloading OS images from strangers google drives, never receiving any updates and so forth.

The Alta AML-A311D-CC uses standard UEFI. That means you can download and run standard ARM64 ISOs and boot it, at least in theory. It’s devicetree seems to be upstreamed and embedded in the Linux kernel – at least for Debian. This is potentially really nice!

Another interesting hardware detail is it’s NPU. I suspect this chipset is more geared towards sitting in a CCTV camera doing object detection, but we might use this capability for other things as well – if we can get it running. There is an open-source driver for said NPU and it is upstreamed, so no proprietary drivers. As of yesterday (2026-08-22) said driver also supports YOLOX (whatever that is), so development is ongoing which is nice.

Aside from that, this is a 6 core machine with 4 GB of RAM, plus an 16 GB eMMC drive I bought. I missed the chance to buy a PoE HAT which is unfortunate.

Getting the NPU to work

I thought this project was going to be tricky & complicated – but it really wasn’t! I just needed a modern kernel and have the kernel load the correct devicetree.

Backports

To get a newer kernel in Debian we can rely on Debian backports.

Add below to /etc/apt/sources.list.d/debian-backports.sources:

Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: trixie-backports
Components: main
Enabled: yes
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Then install a newer kernel:

apt install -t trixie-backports linux-image-arm64 linux-headers-arm64

devicetree

This proved to be the “trickiest” part of the project. I had to read a shell script and add one (1) line of configuration!!

At the end of the function linux_entry () in /etc/grub.d/10_linux I added this line:

  sed "s/^/$submenu_indentation/" << EOF
        devicetree /usr/lib/modules/$version/dtb/amlogic/meson-g12b-a311d-libretech-cc.dtb
}
EOF

This will make the kernel load the device tree on boot. Reboot, and see if you can see any devices under /dev/dri like card0 and renderD128.²

Testing the NPU

Test if the etnaviv driver was loaded on boot:

# sudo dmesg | grep -i etnaviv
[    8.908502] etnaviv etnaviv: bound ff100000.npu (ops gpu_ops [etnaviv])
[    8.909718] etnaviv-gpu ff100000.npu: model: GC8000, revision: 7120
[    8.915861] etnaviv-gpu ff100000.npu: etnaviv has been instantiated on a NPU, for which the UAPI is still experimental
[    8.952415] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0

There is a github repository which seems to contain a test suite for these drivers – but I couldn’t make it run. I found another github repository (rpardini/mesa-teflon-etnaviv-rocket-docker) which builds the mesa with the necessary components and runs tests on it:

podman run -it --device=/dev/dri/card0 --device=/dev/dri/renderD128 ghcr.io/rpardini/mesa-teflon-etnaviv-rocket-docker:latest

See the repository for expected output on a successful test!

Conclusion

Now I just have to figure out what to do with this NPU. :)