DEV Community: Ashwin

How to debug why your PCIe device doesn't enumerate during bring up

Ashwin — Sat, 11 Jul 2026 00:07:29 +0000

Notes from bringing up a PCIe WiFi module on i.MX8MQ; symptoms and how to diagnose them.

`Phy link never came up` — what does this mean?

This message is typically seen in dmesg as shown below.

[    3.828121] imx6q-pcie 33800000.pcie: iATU: unroll T, 4 ob, 4 ib, align 64K, limit 4G
[    4.807241] imx6q-pcie 33c00000.pcie: Phy link never came up
[    4.841482] imx6q-pcie 33800000.pcie: Phy link never came up
[    5.821279] imx6q-pcie 33c00000.pcie: Phy link never came up
[    5.830481] imx6q-pcie 33c00000.pcie: PCI host bridge to bus 0001:00
[    5.854997] imx6q-pcie 33800000.pcie: Phy link never came up
[    5.862205] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00

It means one of the following

The PCIe peripheral is not powered up.
PCIe reset is not deasserted, so the chip is in reset. This could be because the DTB is deasserting an incorrect GPIO.
Reference clock is not enabled
Using the incorrect PCIe controller in the device tree.
As we can see that both the PCIe controllers can report this. So first determine which controller is the peripheral hooked to. More on this in the next section.

Which PCIe controller is my device on? (`&pcie0` vs `&pcie1`)

The rule here is to match by address and not by label/name. If the schematic calls out controllers as PCIE1 and PCIE2, and the device tree lists pcie0 and pcie1, understand the mapping. The DTS label is arbitrary - match by register base (@address in the node name), which is the same in the DTS reg and the reference memory map. For definitive addresses look in the .dtsi, as sometimes the manuals are misleading.

Given below is a mapping table for i.MX8MQ

DTS.     |  ADDRESS (in .dtsi)  | Silicon (RM) Label
&pcie0   | 0x33800000          |     PCIe1 
&pcie1   | 0x33c00000          |     PCIe2

The addresses are listed in the chip’s memory layout are from processor reference manual. Below is snapshot from the i.MX8MQ reference manual, where the layout for the core A-53 is listed.

Start Address | End Address |  Size   | Description
3381_0000     | 3381_3FFF   |  4MB    | PCIe-2   << incorrect in the RM
3380_0000     | 3380_3FFF   |  4MB    | PCIe-1

As you can see from above there are two discrepancies:

The size is listed at 4MB (0x400000), but the end address points to a 16K address space.
PCIe-2's address region lies within PCIe-1, which is incorrect. Lesson: When in doubt, look at the definitions in .dtsi

pcie0: pcie@33800000 {
pcie1: pcie@33c00000 {

So we know from the schematic, the peripheral is on PCIe-1, which maps to &pcie0 in the DTB. So focus on &pcie0. As a next step validate that the reset-gpio of the selected peripheral matches to whats is specified in the device tree. If it does not match, change the GPIO specified in the device tree to match.

`lspci` shows my device but a `Kernel driver in use` is not seen in the output

This could be the next possible step, where lspci reports the device is enumerated but the bars are disabled. If the bars are enabled -> Hurrah!! You are done. The remainder of this section is for instances where the output of lspci looks as so:

0000:01:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4356 802.11ac Wireless Network Adapter (rev 02)
        Subsystem: Broadcom Inc. and subsidiaries BCM4356 802.11ac Wireless Network Adapter
        Flags: fast devsel, IRQ 222
        Memory at 18400000 (64-bit, non-prefetchable) [disabled] [size=32K] << BAR not setup
        Memory at 18000000 (64-bit, non-prefetchable) [disabled] [size=4M] << BAR not setup
        Capabilities: [48] Power Management version 3

and no Kernel driver in use shows up in the output. This means that the driver has not claimed the device and setup the BARs. In summary, the PCIe core enumerated the device but driver is not binding.

For such cases, do the following steps. Note that the steps are written for a WiFi PCIe card on the i.MX8MQ eval kit; meant to serve as an example. Adapt it for your specific bring up.

Check what the bus, the driver is built for

zcat /proc/config.gz | grep -i brcmfmac

Check if the driver is built for the wrong bus, example SDIO enabled but not PCIE

CONFIG_BRCMFMAC=m
CONFIG_BRCMFMAC_SDIO=y   << Will not work for PCIe
# CONFIG_BRCMFMAC_PCIE is not set   << Should be there for PCIe

In the example above, the driver exists but ignores the PCIe device.

Enable PCIE with CONFIG_BRCMFMAC_PCIE=y, optionally remove SDIO, rebuild, and load on the device. It might be a good idea to check your new kernel config has the option set, before loading it on device.

CONFIG_BRCMFMAC=m
CONFIG_BRCMFMAC_SDIO=n
CONFIG_BRCMFMAC_PCIE=y   << THIS

Once loaded on the device, ensure that the driver is loaded.

lsmod | grep -i brcmfmac
brcmfmac_wcc           12288  0
brcmfmac              233472  1 brcmfmac_wcc
brcmutil               16384  1 brcmfmac

You will need to determine if the driver firmware is available to load. Check /usr/lib/firmware to see if it’s available.
In case you are wondering where did the BAR addresses come from, these come from the PCIe memory regions defined in the chip address map. For example for the Cortex A-53:

Start Address  | End Address | Region  | Size   | Description
2000_0000      | 27FF_FFFF   | PCIe-2  | 128MB  | PCIe-2
1800_0000      | 1FFF_FFFF   | PCIe-1  | 128MB  | PCIe-1

Here we can see that the chip lies in the PCIe-1 region of the silicon -> &pcie0 of device tree, as we verified in the previous section.

Run lspci -v for a final confirmation.

lspci -v
snip … snip
0000:01:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4356 802.11ac Wireless Network Adapter (rev 02)
        Subsystem: Broadcom Inc. and subsidiaries BCM4356 802.11ac Wireless Network Adapter
        Flags: bus master, fast devsel, latency 0, IRQ 234
        Memory at 18400000 (64-bit, non-prefetchable) [size=32K] << BAR is setup
        Memory at 18000000 (64-bit, non-prefetchable) [size=4M] << BAR is setup
        Capabilities: [48] Power Management version 3
        Capabilities: [58] MSI: Enable+ Count=1/16 Maskable- 64bit+
        Capabilities: [68] Vendor Specific Information: Len=44 <?>
        Capabilities: [ac] Express Endpoint, IntMsgNum 0
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [13c] Device Serial Number 00-00-38-ff-ff-00-38-0f
        Capabilities: [150] Power Budgeting <?>
        Capabilities: [160] Virtual Channel
        Capabilities: [1b0] Latency Tolerance Reporting
        Capabilities: [220] Physical Resizable BAR
        Capabilities: [240] L1 PM Substates
        Kernel driver in use: brcmfmac << THIS too!!
        Kernel modules: brcmfmac

Additional points

The 100 Mhz reference clock is either provided internally by the i.MX8M or an external clock generator IC on the board. If an external clock generator is used, validate that the chip is enabled.
Check that the reset polarity specified in the device tree is correct. In the case of PCIe, it is an active low.
Verify that the fixed-voltage regulators regulator-fixed for PCIe are enabled in the device tree. These supply a constant 3.3v to the PCI slot.
Specifically for Broadcom drivers, these need a .txt NVRAM configuration file, and a .bin file present in /usr/lib/firmware directory, otherwise they fail silently. It will manifest as wlan0 not appearing. In such cases run dmesg | grep brcm to triage.

Firmware file exists, but kernel cannot find it: i.MX8MQ, imx-sdma error -2

Ashwin — Thu, 09 Jul 2026 02:56:53 +0000

The firmware file was sitting in the filesystem. The kernel insisted that it was not. Bluetooth on an i.MX8MQ evaluation board was failing with a -110 error. This meant that the chip (CYW4356) was not able to communicate.

Right after running hciconfig hci0 up there would be messages like setting baudrate failed (-110). After validating that the chip enable was properly being driven, the failures pointed issues in the chip’s communication path.

There are two modes of chip communication: PIO or SDMA. The device tree said that SDMA was being used. Looking closely at the messages indicated that SDMA was not being loaded. The common causes for those on the i.MX8MQ could be that the SDMA channels for Bluetooth were misconfigured or the chip was not working.

dmesg pointed to SDMA accessibility errors with the message We cannot prepare for the TX/RX slave dma!. To narrow this down I commented out the dma and dma-names properties for uart3, aka Bluetooth and voila - Bluetooth was up! However, SDMA firmware loading errors like [2.464348] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 persisted in dmesg.

Running ls /usr/lib/firmware, confirmed that the bin file was there. It almost looked like the kernel did not want to acknowledge its presence.

The SDMA firmware loader runs when the driver probes. The driver was loaded by default at boot time (CONFIG_IMX_SDMA=y). This meant it was trying to load firmware before the root filesystem was up. The firmware lives in the root filesystem!

You might think why not set the firmware path in the kernel using CONFIG_EXTRA_FIRMWARE. It allows the firmware to be built into vmlinux and avoids the kernel searching for it in the filesystem. This should have worked, but didn’t: darn those yocto dependencies removing it from the kernel build. Faced with the onerous task of threading through all the inc, bb, bbappends, and making multiple builds to determine the root cause, I began to question do we really build the firmware in the kernel. What if, we delayed the SDMA driver load, until something actually needed it: achievable by setting CONFIG_IMX_SDMA=m. By doing this we move the driver initialization out from vmlinux’s init (aka do_initcalls) to it being loaded via modprobe or insmod of a .ko file available on the rootfs. I was betting that as the filesystem exists, the firmware file will be available for the driver to load! Suddenly it was a one line change, just one build. Leading to rebuild, load and success!!

Below is a comparison of what was seen in the logs:

With CONFIG_IMX_SDMA=y

[    2.133882] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    2.139819] Bluetooth: HIDP socket layer initialized
[    2.464469] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 << Load at 2.46s
[    2.483924] imx-sdma 30bd0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
[    2.500030] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
[    2.510503] imx-sdma 302c0000.dma-controller: external firmware not found, using ROM firmware
[    2.524542] imx-sdma 30bd0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
[    2.535006] imx-sdma 30bd0000.dma-controller: external firmware not found, using ROM firmware
[    3.354871] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller

With CONFIG_IMX_SDMA=m

root@imx8mq-evk:/etc/systemd/system# modprobe -D imx-sdma
insmod /lib/modules/6.6.52-lts-next-ge0f9e2afd4cf-dirty/kernel/drivers/dma/imx-sdma.ko

root@imx8mq-evk:/etc/systemd/system# dmesg | grep -Ei 'sdma|mounted filesystem|Run /sbin/init'
[    6.090389] EXT4-fs (mmcblk0p1): mounted filesystem 9cb57070-175f-4761-812a-3656cb092bcd r/w with ordered data mode. Quota mode: none. << Filesystem mounted at 6.09 
[    6.117332] Run /sbin/init as init process
[    9.328588] imx-sdma 302c0000.dma-controller: firmware found.  << load at 9.32s, after FS mount
[    9.337947] imx-sdma 302c0000.dma-controller: loaded firmware 4.6
[    9.401308] imx-sdma 30bd0000.dma-controller: firmware found.

Key takeaway: A firmware file being present in the file system does not mean it is available when the driver asks for it. Look out for when the driver tries to load it vs when the filesystem is mounted. As for building the firmware into the kernel: this can wait until something actually requires it.

Next: the same board's WiFi was on a different PCIe controller than the reference device tree claimed.