Hi Simon, Bin,
I am facing problems with the PCI enumeration at SPL loader stage. On our HW we have PCIe x2 port connected to a FPGA. Since SPL does pci enumeration before FSP-S has been called the enumeration of the second port of the pci x2 connection causes the system to hang.
In my configuration PCI 0.13.0 is a X2 port. So, if the pci_bind_bus_devices function wants to read the PCI_VENDOR_ID from the PCI device 0.13.1 the system hangs.
int pci_bind_bus_devices(struct udevice *bus) { ulong vendor, device; ulong header_type; pci_dev_t bdf, end; bool found_multi; int ret;
found_multi = false; end = PCI_BDF(bus->seq, PCI_MAX_PCI_DEVICES - 1, PCI_MAX_PCI_FUNCTIONS - 1); for (bdf = PCI_BDF(bus->seq, 0, 0); bdf <= end; bdf += PCI_BDF(0, 0, 1)) { struct pci_child_platdata *pplat; struct udevice *dev; ulong class;
if (!PCI_FUNC(bdf)) found_multi = false; if (PCI_FUNC(bdf) && !found_multi) continue;
#if defined(CONFIG_SPL_BUILD) if (PCI_DEV(bdf) == 0x13 && PCI_FUNC(bdf) == 1) continue; #endif
/* Check only the first access, we don't expect problems */ ret = pci_bus_read_config(bus, bdf, PCI_VENDOR_ID, &vendor, PCI_SIZE_16);
At the moment, I fixed this issue by adding an #ifdef which skips the config read on this device.
I think a way to solve this issue could be to add a new devic-tree property like it's done here with "pci,no-autoconfig": https://lists.denx.de/pipermail/u-boot/2020-March/402276.html
But i don't know if it's good to put more apollolake specific stuff into the pci-uclass.
Maybe we should add an apollolake specific pci_uclass_post_probe override. This could maybe be done by adding a spcecific pci driver like pci_x86 for apollolake platform and override the post_probe argument of the pci_uclass. Then we could also move the other apollolake specific things into this driver.
What do you think about this? Do you have better/other ideas?
Regards, Bernhard