Hi Bjron, Yes, I had trouble finding PCIe cards to test with Solidrun Clearfog Base mPCIe slot and indeed the Coral Edge TPU card does not have an open-source driver and the proprietary one that exists does not work in 32-bit architectures. So, yes it had no driver. I have now connected a mPCIe to PCIe extender and installed a Marvell 4-port SATA controller card and I will also include my Armada Duo system which is based on a Solidrun A388 SoM anyway and the Clearfog Base logs hope this information further helps with the analysis, So for Solidrun Clearfog Base with Kernel 6.14-rc5 we have: dmesg output: https://pastebin.com/aw0X9Fb5 lspci -vv: https://pastebin.com/5mDHJZ2C cat /proc/interrupts: https://pastebin.com/ASHN8cx7 grep -r . /proc/irq: https://pastebin.com/mskASwYL decompiled armada-388-clearfog-base.dtb: https://pastebin.com/KuNFDmYP ------------------------------------------------------ For PowerInno ArmadaDuo (2-slots PCIe) with Kernel 6.8.9 we have: dmesg output: https://pastebin.com/54HHrPVP lspci -vv: https://pastebin.com/KpE6Hc0r cat /proc/interrupts: https://pastebin.com/6L64ztse grep -r . /proc/irq: https://pastebin.com/raPkRBVk Best Regards, Luís On Tue, Mar 11, 2025 at 4:24 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Sun, Mar 09, 2025 at 11:10:58PM +0000, Luís Mendes wrote: > > All logs presented were obtained from a SolidRun A388 ClearFog Base, > > if more detailed PCI logs are needed I have the other machine, the > > Armada Duo that has 2 PCIe slots and handles an AMD RX 550 GPU. Just > > let me know. > > > > - Complete dmesg log, booted with "pci=nomsi" is available here: > > https://pastebin.com/wDj0NGFN > > - Complete output of "sudo lspci -vv" is available here: > > https://pastebin.com/f4yHRhLr > > - Contents of /proc/interrupts is available here: https://pastebin.com/ejDUuhbJ > > - Output of "grep -r . /proc/irq/" is available here: > > https://pastebin.com/4jvFBBhy > > Thank you very much for these. > > It looks like the only PCI device is 01:00.0: [1ac1:089a], a Coral > Edge TPU, and I don't see any evidence of a driver for it or any IRQ > usage. Do you have any other PCI device you could try there? > Something with a driver that uses interrupts? > > Not critical right now, but I'm puzzled by this part of the dmesg log: > > mvebu-pcie soc:pcie: host bridge /soc/pcie ranges: > mvebu-pcie soc:pcie: MEM 0x00f1080000..0x00f1081fff -> 0x0000080000 > mvebu-pcie soc:pcie: MEM 0x00f1040000..0x00f1041fff -> 0x0000040000 > mvebu-pcie soc:pcie: MEM 0x00f1044000..0x00f1045fff -> 0x0000044000 > mvebu-pcie soc:pcie: MEM 0x00f1048000..0x00f1049fff -> 0x0000048000 > pci_bus 0000:00: root bus resource [mem 0xf1080000-0xf1081fff] (bus address [0x00080000-0x00081fff]) > pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff] (bus address [0x00040000-0x00041fff]) > pci_bus 0000:00: root bus resource [mem 0xf1044000-0xf1045fff] (bus address [0x00044000-0x00045fff]) > pci_bus 0000:00: root bus resource [mem 0xf1048000-0xf1049fff] (bus address [0x00048000-0x00049fff]) > pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff] > > The first four mvebu-pcie lines make good sense and match the > first four pci_bus lines. But I don't know where the > [mem 0xe0000000-0xe7ffffff] aperture came from. It should be > described in the devicetree, but I don't see it mentioned in the > /soc/pcie ranges. > > Can you include the devicetree as well?
