x86: apl: PCI enumeration issue
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
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?
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, Bin
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
Hi Bernhard,
On Mon, Mar 30, 2020 at 4:25 PM Bernhard Messerklinger bernhard.messerklinger@br-automation.com wrote:
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,
That's not common. If FSP-S is hiding the 2nd port, it should not be visible in the PCI configuration space. Do you know if this is a bug of the silicon or it just behaves like this?
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.
Regards, Bin
Hi Bin,
Hi Bernhard,
On Mon, Mar 30, 2020 at 4:25 PM Bernhard Messerklinger bernhard.messerklinger@br-automation.com wrote:
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,
That's not common. If FSP-S is hiding the 2nd port, it should not be visible in the PCI configuration space. Do you know if this is a bug of the silicon or it just behaves like this?
No I think the point is, that at the time (SPL) where the first pci enumeration is done the FSP-S init is not done. The FSP-S init is called later in the main u-boot. After FSP-S init it works fine.
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.
Regards, Bin
Regards, Bernhard
Hi Bernhard,
On Mon, Mar 30, 2020 at 4:41 PM Bernhard Messerklinger bernhard.messerklinger@br-automation.com wrote:
Hi Bin,
Hi Bernhard,
On Mon, Mar 30, 2020 at 4:25 PM Bernhard Messerklinger bernhard.messerklinger@br-automation.com wrote:
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,
That's not common. If FSP-S is hiding the 2nd port, it should not be visible in the PCI configuration space. Do you know if this is a bug of the silicon or it just behaves like this?
No I think the point is, that at the time (SPL) where the first pci enumeration is done the FSP-S init is not done. The FSP-S init is called later in the main u-boot. After FSP-S init it works fine.
I meant that if 2nd port is disabled by default, and devices under 2nd port should not be made visible and should not cause hang. This to me is a silicon bug.
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.
Regards, Bin
participants (2)
-
Bernhard Messerklinger -
Bin Meng