PCI device count mismatch: lspci=1, triton=0

Question

I am trying to get the Axelera Metis M.2 module working on a NanoPC-T6 Plus board powered by the Rockchip RK3588 SoC running Ubuntu 22.04 (Linux kernel 5.10.0-1012-rockchip / ARM64).(I installed image file in this link https://support.axelera.ai/hc/en-us/articles/31859388491794-Bring-up-Voyager-SDK-in-NanoPC-T6?_gl=1*3zteth*_gcl_au*MTc5ODEwMTM1MC4xNzg3NzI0Mjgx because I have tested other OS images provided on the official NanoPC-T6 Plus wiki, but the issue persists, indicating a known PCIe memory allocation bug within the Ubuntu 22.04 kernel for this platform.)

However, the driver fails to probe the device due to PCI resource assignment failure (ENOMEM / error -12).

1. Device Identification & `lspci` Status

The PCIe device is visible on the bus (0000:01:00.0), but the Linux kernel fails to assign memory resources (MMIO) to Region 0 and Region 2:

$ lspci -vv -s 0000:01:00.0 | grep -iE 'Region|Memory|flags'
	Region 0: Memory at <ignored> (64-bit, non-prefetchable) [disabled]
	Region 2: Memory at <ignored> (32-bit, non-prefetchable) [disabled]

2. Driver Log Output (`dmesg`)

When loading the DKMS metis kernel driver (v1.6.2), the probe fails during memory resource allocation:

[   17.953792] axl_aipu: root directory for axl_aipu
[   17.954068] axl 0000:01:00.0: Failed to request resources
[   17.954098] axl: probe of 0000:01:00.0 failed with error -12

Consequently, running axdevice results in a PCI count mismatch:

WARNING: PCI device count mismatch: lspci=1, triton=0
ERROR: min() arg is an empty sequence

Is there a recommended/officially supported Device Tree (ranges) configuration for RK3588 / ARM64 architectures to map Metis BARs into 64-bit high memory space (0x0900000000)?
Does the metis kernel driver support high MMIO 64-bit relocation out of the box for ARM64 platforms?
Are there any specific kernel patches or module options recommended for Rockchip BSP Linux 5.10 kernels?

Any guidance or example Device Tree snippets for ARM64 / RK3588 integration would be greatly appreciated!

itan · Answer

Hi bmtl — seen something very similar getting Metis M.2 up on ARM64 boards. Good news: your driver install is fine. The -12 is just the consequence, the real failure happens before the driver loads.

Diagnosis

"Memory at <ignored>" means the kernel never assigned the BARs at all. On the RK3588 BSP 5.10 kernel, the PCIe root complex windows come from the Device Tree ranges of the controller node, and the non-prefetchable MMIO window is quite small. If the Metis BARs (Region 0 + Region 2) don't fit in it, the kernel silently leaves them unassigned → axl probe fails with -ENOMEM → triton=0.

To confirm, please post:

lspci -t
lspci -vvv -s 01:00.0 | grep -iE 'Region|size'
cat /proc/iomem | grep -i pcie

The [size=...] on each Region tells us exactly how much MMIO the card is asking for vs. what the root port window offers.

Quick test first

Boot with pci=realloc=on on the kernel cmdline. On several RK3588 images this alone fixes BAR assignment. If it doesn't, the DT window is genuinely too small.

Your three questions

1. Yes — the fix is usually widening/adjusting the non-prefetchable window in the ranges property of the PCIe controller node that feeds the M.2 slot (on the T6 it depends on which controller lspci -t shows as the parent bridge). The pattern is extending the 0x02000000 entry, not adding magic addresses.
2. BAR relocation on ARM64 is handled by the kernel PCI core, not by the metis driver — it uses standard pci_request_regions/pci_ioremap_bar, so no driver-side limitation there. Same code path as x86.
3. No Axelera-specific patch that I know of; the fix belongs in the board DT/kernel. If you share your controller node + the outputs above, I can suggest a concrete ranges edit.

One more RK3588 gotcha: after changing anything, do a full cold power cycle, not a warm reboot — the RK3588 PCIe enumeration can be flaky across warm reboots (similar story here: https://community.axelera.ai/support-central-47/subject-metis-aipu-detected-on-pcie-but-not-responding-stage0-load-failure-on-rk3588-compute-board-voyager-sdk-1-5-3-1280).

PCI device count mismatch: lspci=1, triton=0

1. Device Identification & `lspci` Status

2. Driver Log Output (`dmesg`)

1 reply

Idea to edge AI, in minutes

Got an edge AI idea?

1. Device Identification & lspci Status

2. Driver Log Output (dmesg)

Idea to edge AI, in minutes

Got an edge AI idea?

Sign up

Log in, or create an Axelera AI account

Login to the community

Log in, or create an Axelera AI account

1. Device Identification & `lspci` Status

2. Driver Log Output (`dmesg`)