05 — Akida PCIe driver and the cards
The public driver refuses kernel 6.12. Two patches, one script, and a verification you can trust.
OFFICIAL BASELINE: the driver repository Brainchip-Inc/akida_dw_edma and its install.sh.
OUR OBSERVATION: on the Pi 5 kernel 6.12 the unpatched installer stops with Kernel 6.12 not supported. The two patches below were found by hand on 2026-09-06 and are reproduced by setup_akida_treiber.sh.
Before you start
Cards seated, carrier powered, Pi booted. Prove the bus sees them:
lspci | grep -i brainchip
Expected: one line per card. On our carrier they sit behind a switch on bus 0001, e.g. 0001:03:00.0 … 0001:06:00.0. No line = power or seating, not software.
The two patches
dkms.conf: remove theBUILD_EXCLUSIVE_KERNELline (the version gate).Makefile: replace the$(error Kernel … not supported)branch for kernels > 6.9 with the 6.9 build branch (the dw-edma core, v0 core, debugfs and hdma objects, with the 5.16 include path).
Then sudo ./install.sh (DKMS build), register the module for boot in /etc/modules-load.d/akida-pcie.conf (without this, cards that are already present at boot were sometimes not bound by udev), and modprobe akida-pcie.
All of that is one command:
bash ~/vorsa-m3/setup_akida_treiber.sh
Expected: Makefile gepatcht (or "evtl. schon gepatcht" on a second run), a DKMS build without errors, and the final hint to check the cards.
Verify — four layers must agree
lspci | grep -i -c brainchip
lsmod | grep akida
ls -l /dev/akd1500_*
dmesg | grep akida-pcie | tail
Expected: the card count; akida_pcie loaded; one device node per card (/dev/akd1500_0 … _3); in dmesg for each card Host ddr area: 16777216 bytes and probed (akd1500_N).
The Python check comes in chapter 06 once the runtime environment exists.
Map slots to addresses
Write the table now; you need it for the reset button and for swapping cards during fault-finding:
| Slot (your label) | PCIe address | Device node |
|---|---|---|
| 1 | 0001:03:00.0 | akd1500_0 |
| … | … | … |
The software assumes that the order of akida.devices() matches the order of the PCIe addresses. That held on our bench; after a card swap, verify it.
Kernel updates are hardware events
apt full-upgrade with a new kernel triggers a DKMS rebuild. After every kernel change: reboot, repeat the four-layer check, and repeat chapter 06's akida.devices() test before trusting the application again.
When a card hangs (seen 2026-09-20)
dmesg fills with akida-pcie 0001:06:00.0: DMA wait completion timed out every few seconds while the link stays up, and the runtime reports Error reading at 0x... errno(110). The card is stuck, not gone. Recovery without a reboot:
sudo systemctl stop vorsa
echo 1 | sudo tee /sys/bus/pci/devices/0001:06:00.0/remove
sleep 2
echo 1 | sudo tee /sys/bus/pci/rescan
dmesg | tail -5
sudo systemctl start vorsa
Expected: enabling device, Host ddr area, probed (akd1500_3) — the card is back. Since build 1.9.36 the UI does this for you (Status → Hardware → "Reset card") and the card watchdog keeps the line running on the remaining cards meanwhile.
If the same address hangs repeatedly, swap two cards: if the fault moves with the card, it is the card; if it stays with the address, it is the slot or the carrier.
Checkpoint: four layers agree, the slot/address table is written, and you know the recovery command.