Skip to main content
Question

Metis M.2 not getting enumerated during boot

  • April 21, 2026
  • 7 replies
  • 69 views

I just got a Metis M.2 card, and and having problems getting it to show up correctly as a PCI device. During boot, the vendor and device ID are detected as [16c3:abcd], which is for a generic Synopsis PCIe bridge. Is this correct? 
During boot, I am also getting an error “dwc3-haps 0002:01:00.0: failed to enable pci device”
After boot, the Metis M.2, as well as the root port it is connected to are uninitialized and return 0xFFFF for all configuration space. I’m not sure if that is a symptom, or a result of the previous error.
The host machine is our own edge device based on a Qualcomm QRB5165 processor, running OE Linux with a 4.19 kernel. The M.2 slot currently provides a Gen 3 x1 PCIe connection.
I tried increasing the time between reset de-assertion to configuration to 500ms in case the card needed more time, but that didn’t help. I have also monitored the 3.3V supplying the M.2 slot to make sure the voltage didn’t drop.
We have used this M.2 slot for other cards, e.g. NVMe without a problem.

Dmesg snippet:

[    1.669548] msm_pcie_enable: PCIe: Assert the reset of endpoint of RC2.
[ 1.672754] msm_pcie_enable: PCIe: RC2: PCIE20_PARF_INT_ALL_MASK: 0x7f80d202
[ 1.674806] pcie_phy_init: PCIe RC2 PHY is ready!
[ 1.684826] msm_pcie_enable: PCIe: Release the reset of endpoint of RC2.
[ 2.460495] msm_pcie_link_train: PCIe RC2 link initialized
[ 2.460653] pci-msm 1c10000.qcom,pcie: host bridge /soc/qcom,pcie@1c10000 ranges:
[ 2.460664] pci-msm 1c10000.qcom,pcie: No bus range found for /soc/qcom,pcie@1c10000, using [bus 00-ff]
[ 2.460685] pci-msm 1c10000.qcom,pcie: IO 0x64200000..0x642fffff -> 0x64200000
[ 2.460699] pci-msm 1c10000.qcom,pcie: MEM 0x64300000..0x67ffffff -> 0x64300000
[ 2.461204] pci-msm 1c10000.qcom,pcie: PCI host bridge to bus 0002:00
[ 2.461211] pci_bus 0002:00: root bus resource [bus 00-ff]
[ 2.461217] pci_bus 0002:00: root bus resource [io 0x100000-0x1fffff] (bus address [0x64200000-0x642fffff])
[ 2.461223] pci_bus 0002:00: root bus resource [mem 0x64300000-0x67ffffff]
[ 2.461281] pci 0002:00:00.0: [17cb:010b] type 01 class 0x060400
[ 2.461366] pci 0002:00:00.0: reg 0x10: [mem 0x00000000-0x00000fff 64bit]
[ 2.461553] pci 0002:00:00.0: PME# supported from D0 D3hot D3cold
[ 2.477650] pci 0002:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 2.477877] pci 0002:01:00.0: [16c3:abcd] type 00 class 0x000000
[ 2.477996] pci 0002:01:00.0: reg 0x10: [mem 0x00000000-0x000fffff 64bit]
[ 2.478024] pci 0002:01:00.0: reg 0x18: [mem 0x00000000-0x000fffff]
[ 2.478072] pci 0002:01:00.0: reg 0x20: [io 0x0000-0x00ff]
[ 2.478096] pci 0002:01:00.0: reg 0x24: [mem 0x00000000-0x0000ffff]
[ 2.478121] pci 0002:01:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[ 2.478336] pci 0002:01:00.0: supports D1
[ 2.478339] pci 0002:01:00.0: PME# supported from D0 D1 D3hot
[ 2.478435] pci 0002:01:00.0: 7.876 Gb/s available PCIe bandwidth, limited by 8 GT/s x1 link at 0002:00:00.0 (capable of 31.504 Gb/s with 8 GT/s x4 link)
[ 2.484527] pci_bus 0002:01: busn_res: [bus 01-ff] end is updated to 01
[ 2.484553] pci 0002:00:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align 100000
[ 2.484555] pci 0002:00:00.0: bridge window [mem 0x00100000-0x003fffff] to [bus 01] add_size 200000 add_align 100000
[ 2.484564] pci 0002:00:00.0: BAR 8: assigned [mem 0x64300000-0x647fffff]
[ 2.484566] pci 0002:00:00.0: BAR 9: assigned [mem 0x64800000-0x649fffff 64bit pref]
[ 2.484568] pci 0002:00:00.0: BAR 0: assigned [mem 0x64a00000-0x64a00fff 64bit]
[ 2.484580] pci 0002:00:00.0: BAR 7: assigned [io 0x100000-0x100fff]
[ 2.484584] pci 0002:00:00.0: PCI bridge to [bus 01]
[ 2.484586] pci 0002:00:00.0: bridge window [io 0x100000-0x100fff]
[ 2.484593] pci 0002:00:00.0: bridge window [mem 0x64300000-0x647fffff]
[ 2.484597] pci 0002:00:00.0: bridge window [mem 0x64800000-0x649fffff 64bit pref]
[ 2.484682] pci-msm-rc 0002:00:00.0: Linked as a consumer to 15000000.apps-smmu
[ 2.485140] msm_pcie_probe: RC2 is enabled in bootup
[ 2.578091] PCI: CLS 128 bytes, default 64
[ 2.591003] pcieport 0001:01:00.0: Linked as a consumer to 15000000.apps-smmu
[ 2.594141] pci-msm-rc 0001:00:00.0: enabling device (0006 -> 0007)
[ 2.594601] pcieport 0001:02:01.0: Linked as a consumer to 15000000.apps-smmu
[ 2.595030] pcieport 0001:02:02.0: Linked as a consumer to 15000000.apps-smmu
[ 2.757156] igc 0001:03:00.0: 4.000 Gb/s available PCIe bandwidth (5 GT/s x1 link)
[ 2.862501] igc 0001:04:00.0: 4.000 Gb/s available PCIe bandwidth (5 GT/s x1 link)
[ 2.866607] dwc3-haps 0002:01:00.0: Linked as a consumer to 15000000.apps-smmu
[ 2.872474] pci-msm-rc 0002:00:00.0: enabling device (0006 -> 0007)
[ 2.872546] dwc3-haps 0002:01:00.0: can't enable device: BAR 0 [mem 0x00000000-0x000fffff 64bit] not claimed
[ 2.872551] dwc3-haps 0002:01:00.0: failed to enable pci device
[ 2.874594] msm-dwc3 a600000.ssusb: Linked as a consumer to 15000000.apps-smmu
[ 2.875178] msm-dwc3 a600000.ssusb: Linked as a consumer to regulator.63
[ 2.876523] dwc3 a600000.dwc3: Failed to get clk 'ref': -2
[ 2.876676] dwc3 a600000.dwc3: changing max_speed on rev 00000000
[ 2.878909] msm-dwc3 a600000.ssusb: unable to get ssphy device
[ 2.881030] msm-dwc3 a600000.ssusb: Dropping the link to regulator.63
[ 2.881078] msm-dwc3 a800000.ssusb: Linked as a consumer to 15000000.apps-smmu
[ 2.881506] msm-dwc3 a800000.ssusb: Linked as a consumer to regulator.64
[ 2.882766] dwc3 a800000.dwc3: Failed to get clk 'ref': -2
[ 2.885213] ehci-pci: EHCI PCI platform driver
[ 2.885611] ohci-pci: OHCI PCI platform driver
[ 2.944218] msm-dwc3 a800000.ssusb: DWC3 exited from low power mode

 

7 replies

Forum|alt.badge.img+2

Hi ​@STU940652 ,

Can you share the output of running these commands:

lspci

lspci -tv

Can you try the following? :

Remove and rescan PCIe device and/or PCIe bridge manually

1 - Metis

Find the port addresses of your Metis device with lspci and lspci -tv

Remove the Metis device by doing (in this example we consider the Metis device is in port 0000:01:00.0) :

echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/remove > /dev/null

Then rescan by doing:

echo 1 | sudo tee /sys/bus/pci/rescan > /dev/null


2 - PCIe bridge to Metis

Find the port addresses of your PCIe bridges with lspci and lspci -tv

Remove the Metis device by doing (in this example we consider the bridge is in port 0000:01:00.0):

echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/remove > /dev/null

Then rescan by doing:

echo 1 | sudo tee /sys/bus/pci/rescan > /dev/null

  • Author
  • Cadet
  • April 22, 2026

Victor,

Thank you for your help. In case 1, the Metis did not reappear after a rescan. In case 2, the PCIe bridge did not appear after the rescan.

Is  [16c3:abcd] the correct vendor and device id? I just want to make sure the card is “alive”.

Thanks,
Andy


Forum|alt.badge.img+2

Hi ​@STU940652 ,

That should not be the ID.

You can do sudo update-pciids

Can you share lspci and lspci -tv in you r current status. Then can you reboot your host and share again lspci and lspci -tv?

Thanks!


  • Author
  • Cadet
  • April 22, 2026

The results are the same before and after running update-pciiids:

root@410059a427a1:/# lspci
0000:00:00.0 PCI bridge: Qualcomm Device 010b (rev ff)
0000:01:00.0 Network controller: Qualcomm QCA6390 Wireless Network Adapter [AX500-DBS (2x2)] (rev ff)
0001:00:00.0 PCI bridge: Qualcomm Device 010b
0001:01:00.0 PCI bridge: Pericom Semiconductor Device b304 (rev 01)
0001:02:01.0 PCI bridge: Pericom Semiconductor Device b304 (rev 01)
0001:02:02.0 PCI bridge: Pericom Semiconductor Device b304 (rev 01)
0001:03:00.0 Ethernet controller: Intel Corporation Device 125c (rev 04)
0001:04:00.0 Ethernet controller: Intel Corporation Device 125c (rev 04)
0002:00:00.0 PCI bridge: Qualcomm Device 010b (rev ff)
0002:01:00.0 Non-VGA unclassified device: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev ff)
root@410059a427a1:/# lspci -tv
-+-[0002:01]---00.0 Synopsys, Inc. DWC_usb3 / PCIe bridge
+-[0002:00]---00.0 Qualcomm Device 010b
+-[0001:00]---00.0-[01-04]----00.0-[02-04]--+-01.0-[03]----00.0 Intel Corporation Device 125c
| \-02.0-[04]----00.0 Intel Corporation Device 125c
+-[0000:01]---00.0 Qualcomm QCA6390 Wireless Network Adapter [AX500-DBS (2x2)]
\-[0000:00]---00.0 Qualcomm Device 010b

One thing I neglected to mention is that the M.2 slot in our device is currently B-keyed, so I am using an M to B+M adapter. I tried the Metis M.2 in a desktop with an M-keyed M.2, and it showed up with vendor and device id 1f9d:1100 which looks correct. However, when I used it with the adapter, it doesn’t show up at all.
Using the adapter means about half of the power pins are unconnected, and PCIe can only link as at x1. We are getting a new revision of our board next month that has an M-keyed M.2 connector (but only supports PCIe x2), so I will resume testing then. In them meantime, can you confirm if the Metis M.2 operates correctly with a PCIe link width of x1 and x2 as well as x4?  


Spanner
Axelera Team
Forum|alt.badge.img+3
  • Axelera Team
  • April 24, 2026

HI ​@STU940652 ! Ah, you might have found it there. If the power is being limited through the adapter (as your tests show) it’s likely low enough to stop the board controller completing its boot sequence, which is why you're seeing the generic Synopsys ID.

That was a good diagnostic test putting it into the other machine.

In terms of x1, x2 etc, I think early Raspberry Pi 5 tests ran at x1, but not out of the box. I don’t think it’s recommended, either way. I might be wrong about that - ​@Victor Labian will likely know better. But I think x2 should work with the stock driver 👍


Forum|alt.badge.img+2

Hi ​@STU940652 , 

FYI ​@Spanner 

PCIe is backwards compatible. Therefore, although Metis works best with PCIe Gen 3 x4 lanes, it is capable of working with lower generation and fewer number of lanes. But, as expected, the performance will be reduced comparing to its maximum.

 

Thank you for explaining the details of the situation, it clarifies things. We have never tried B to M adaptor but it is interesting, can you share the details of the adaptor?

 

If you M.2 card works on another machine, I recommend updating the firmware and board controller in that machine. For that, install the latest v1.6 version of Voyager SDK (https://github.com/axelera-ai-hub/voyager-sdk) and follow the instructions here: https://github.com/axelera-ai-hub/voyager-sdk/blob/latest/docs/tutorials/firmware_flash_update.md .

 

Once you have updated the FW and BC, please share the output of

axdevice -v

with the venv activated, in the host that now works with the card.

 

Then move the card to the host with the B to M adapter and:

  • Check if the card is detected in lspci -tv
  • If not, please reboot and check again if it is detected
  • If not, check under which bridge the synopsys device is (share lspci -tv details with us and the command you use), remove the bridge and rescan, as I explained in a previous comment in this thread.

Note that the usual reason Metis might appear as Synopsys is that the host completes its boot sequence faster than Metis takes to initialize. During this window, the firmware hasn't had enough time to write the correct PCIe device ID. As a result, Metis is enumerated with the wrong device ID. 

 

Please let us know how it goes.

Kind regards,

Victor


  • Author
  • Cadet
  • April 30, 2026

Victor. 

Thanks for the reply. After updating firmware and extending the PCIe reset time to 500ms, the device is correctly showing up in PCI space. On to the next step….

Do you know what the minimum required time is from PCIe deassertion to accessing the Metis M.2?

Thanks,
Andy