Continuing from the PCIe issues discussed in the attached link — I’m seeing a related but distinct problem with the Radxa AICore AX-M1 (not a GPU) on the O6N.
I’ve been trying to get the AX-M1 detected in the top M.2 M-key slot (the one intended for accelerator/storage use). The module is not detected at all — not in lspci, and critically, not even attempted in the kernel’s PCIe probe sequence.
Tested configurations:
-
Default/shipped BIOS
-
BIOS updated to 1.2.4
-
Both M.2 slots (top and bottom) — same result in both
dmesg | grep -i pcie shows only 3 PCIe controller instances ever probe and link up (CIXH2020:00, :03, :04), corresponding to:
-
NVMe SSD (bus
c0/c1) -
LAN port 1 (bus
00/01) -
LAN port 2 (bus
30/31)
There is no fourth controller instance in the log at all for the AX-M1’s slot; it looks like that root port/controller instance simply isn’t being brought up by firmware in either slot.
The AX-M1’s driver (ax_pcie_host_dev) loads fine at the OS level (ax_pcie_host_dev: loading out-of-tree module taints kernel), so this appears to be purely a hardware-enumeration gap rather than a driver or software issue.
Given @hipboi’s confirmation above that GPU testing on O6N wasn’t done either, I’m wondering whether M.2 add-in devices beyond storage (NVMe) are currently limited to a subset of the physical slots by design, or whether this is an unintended firmware gap. Any insight on:
-
Whether a specific slot/BIOS combination is expected to work
-
Any known timeline for enabling the missing controller instance, if this is indeed a firmware gap
Happy to provide full dmesg output, lspci -tv, or BIOS version details if useful.