Hi Bin,
Hi Bernhard,
On Mon, Mar 30, 2020 at 3:35 PM Bernhard Messerklinger bernhard.messerklinger@br-automation.com wrote:
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.
Do you know why the 2nd port hang happens, but not the 1st port? Is that because in order to get 2nd port working something is done in FSP-S?
I know that the problem happens because of the PCIe FIT tool configuration. If I change the configuration to PCIe x1 on all root ports of the SoC the issue doesn't occur. I think FSP-S hides the second port because it's no real PCIe root port, it's just the second lane of the first port. I also did some research in the intel FSP-S code. In the FSP-S code some not documented fuse registers are accessed and then the second port is deactivated depending of the FIT configuration.
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 expectproblems */
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, Bin
Regards, Bernhard