The main quirk with the hardware topology is that the root port's address space is outside of the ECAM address space used for the devices below it. For Arm SystemReady compliance, and to allow distros to boot out of the box the only option was to only expose the devices on the bus and configure the root port in the firmware. This was not our first choice but at the time quirks for the PCIe ACPI setup were no longer being accepted in mainline.
I would be happy to resurrect the ACPI quirk patch needed so the bus would look more normal if that would be accepted now. -Jon On Fri, Jul 31, 2026 at 12:15 PM Liz Fong-Jones <[email protected]> wrote: >> Maybe this is a tangent, but I'm curious about this topology. Is this >> running as a virtualized guest? At the hardware level, a PCIe >> endpoint must have a Root Port somewhere, even if it isn't visible to >> the OS (as is often the case in virtualized guests). > > Defer to Jon on what the actual hardware configuration is, but this is > physical hardware, no virtualisation, running as the UEFI rather than U-Boot > (devicetree) variant. See: > https://dev.solid-run.com/nxp/lx2160a/com-som/lx2160a-com-hardware-user-manual#block-diagram I guess this must be the drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c driver. The commit log mentioned this: >>> amdgpu 0004:01:00.0: BAR 0 [mem 0xa400000000-0xa40fffffff 64bit pref]: >>> releasing so the GPU is on bus 01, which isn't a nice round bus number like root buses usually are. The typical thing would be a root port on bus 00 with a secondary bus 01, and amdgpu being on that bus 01. Can you share a dmesg log? It should include the lx2160a host bridge details and the PCIe topology below it.
