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

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).

Hi @itan,

Thanks for the detailed diagnosis and suggestions!

For context, I am using the Axelera Embedded 110m module (Metis AIPU).

Following your advice and suggestions from another thread, I also tested this with the Armbian 26.8.3 NanoPC LTS image, but the issue persists.

I have tried:

1. Adding the recommended kernel parameters (pci=realloc=on and pcie_aspm=off) to the boot configuration.

2. Decompiling and manually updating the ranges property in the Device Tree (.dtb) to expand the non-prefetchable MMIO window for the PCIe controller node.

3. Performing a full cold power cycle (completely disconnecting the power cable) after each attempt.

Unfortunately, the issue remains unresolved. Here are the key outputs from the latest test:

1. cat /proc/cmdline: Confirms that pci=realloc=on pcie_aspm=off is actively loaded by the kernel.

2. sudo dmesg | grep -iE 'axl|pcie|0000:01:00.0':

   Plaintext

    

   pci 0000:01:00.0: BAR 2 [mem size 0x02000000]: can't assign; no space
   pci 0000:01:00.0: BAR 0 [mem size 0x00001000 64bit]: can't assign; no space
   axl 0000:01:00.0: Failed to request resources
   axl 0000:01:00.0: probe with driver axl failed with error -12
   

3. axdevice: Still reports WARNING: PCI device count mismatch: lspci=1, triton=0.

The kernel is still unable to assign the 32MB BAR 2 region due to space limitations (can't assign; no space).

Is there an officially patched Device Tree (.dtb) or a verified OS image for the NanoPC-T6 Plus that properly allocates the MMIO space for the Embedded 110m module?

Thank you for your support!

Hi @itan,

Thanks for the detailed diagnosis and suggestions!

For context, I am using the Axelera Embedded 110m module (Metis AIPU) on a NanoPC-T6 Plus board.

Please note that I am using the NanoPC-T6 Plus (LPDDR5 architecture), not the standard NanoPC-T6 (LPDDR4X). The official image provided for the standard NanoPC-T6 does not resolve the PCIe memory allocation failure (error -12) on the T6 Plus due to hardware and Device Tree differences between the two boards.

I have also tested the Armbian 26.8.3 NanoPC LTS image and attempted the following troubleshooting steps:

1. Added the recommended kernel parameters (pci=realloc=on and pcie_aspm=off) to the boot configuration.

2. Decompiled and manually updated the ranges property in the Device Tree (.dtb) to expand the non-prefetchable MMIO window for the PCIe controller node.

3. Performed a full cold power cycle (completely disconnecting the power cable) after each attempt.

Unfortunately, the kernel is still unable to assign the 32MB BAR 2 region due to space limitations (can't assign; no space):

1. cat /proc/cmdline: Confirms pci=realloc=on pcie_aspm=off is active.

2. sudo dmesg | grep -iE 'axl|pcie|0000:01:00.0':

    

   pci 0000:01:00.0: BAR 2 [mem size 0x02000000]: can't assign; no space
   pci 0000:01:00.0: BAR 0 [mem size 0x00001000 64bit]: can't assign; no space
   axl 0000:01:00.0: Failed to request resources
   axl 0000:01:00.0: probe with driver axl failed with error -12
   

3. axdevice: Still reports WARNING: PCI device count mismatch: lspci=1, triton=0.

Do you have an officially verified OS image or a pre-patched .dtb file specifically configured for the NanoPC-T6 Plus to support the Embedded 110m module?

Thank you for your support!