Antwort: Re: x86: apl: PCI enumeration issue

Bernhard Messerklinger bernhard.messerklinger at
Mon Mar 30 10:25:40 CEST 2020

Hi Bin,

>Hi Bernhard,
>On Mon, Mar 30, 2020 at 3:35 PM Bernhard Messerklinger
><bernhard.messerklinger at> 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
>> 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

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 

>> In my configuration PCI 0.13.0 is a X2 port. So, if the
>> 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,
>>                                           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
>> like it's done here with "pci,no-autoconfig":
>> 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
>> 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
>> 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?


More information about the U-Boot mailing list