I'm facing a PCIe init related problem most likely caused in the
Intel FSP in our BayTrail U-Boot port (not coreboot!).
We are currently struggling with an FSP PCIe related issue on our
BayTrail target. We are using U-Boot as the bootloader which also
uses the Intel FSP for HW setup (similar to coreboot etc). Currently
we have the BayTrail-Gold4 FSP version installed. Here we use an
PLX / Avago PCIe switch, connected to the PCIe root port of the CPU
with a PCIe x4 link.
Using the original board-vendor (congatec) BIOS always boots fine. Only
U-Boot using the Intel FSP shows the PCIe related hangup on some
board types - somehow depending on the PLX switch that is connected.
Measuring has shown, that the PCIe clock is only stable for ~20ms
before data is transferred in the U-Boot case. In the BIOS case,
the time between clock stable and data is ~120ms. The PCIe spec
mentions, that the clock should be asserted for more than 100ms.
So U-Boot is violating the spec here, which might be the root cause.
I've now instrumented the U-Boot with many early debug and delay
code and found, that it hangs inside of the FSP code. I then
installed the DEBUG FSP blob and have found, that its stuck (as
expected) in the FSP PCIe init:
CommonUsbInit() - End
Nothing more. Here the board is completely stuck!
Here the log from a different board, with stable and working
4 times x1 PCIe links (different board with 4 times x1 PCIe
CommonUsbInit() - End
Root Port 1 device enabled. RpEnableMask: 0xF
Root Port 2 device enabled. RpEnableMask: 0xF
Root Port 3 device enabled. RpEnableMask: 0xF
Root Port 4 device enabled. RpEnableMask: 0xF
Do you have any ideas, whats going on in the PCI init stuff in the
FSP? Or if and how we can influence this PCIe related configuration
to solve this hangup inside of the FSP? Has such a problem or a
similar one been noticed on some BayTrail platforms before?
I've just found a workaround (more ugly hack) to solve this issue.
If I disable the link in the PCIe root port (PCI BDF 0,0x1c,0)
in the LCTL register before jumping into the FSP, the FSP
"survives" the init phase and jumps back into U-Boot. I can
then re-force the link before the U-Boot PCI scan is done
and then everything is fine. The PCIe PLX switch is detected
correctly and all downstream ports seem to be working as