BayTrail PCIe problems (hangup) in FSP

[SRoes1]

Hi,

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

ConfigureUsb() End

PchInitRootPorts() Start

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

links):

...

CommonUsbInit() - End

ConfigureUsb() End

PchInitRootPorts() Start

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

PchInitRootPorts() End

ConfigureSata() Start

...

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?

BTW:

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

expected.

Thanks,

Stefan

[CarlosAM_INTEL]

Hello, stroese:

Thank you for contacting Intel Embedded Community.

In order to help you with your third-party design questions, you should address them as a reference to the channels listed at the http://www.congatec.com/en/support.html congatec AG Technical Support website, because they have all the proper information related to the affected device.

On the other hand, your Intel(R) Firmware Support Package [Intel(R) FSP] consultations should be addressed by filling out the https://firmware.intel.com/content/support Intel(R) Architecture Firmware Resource Center Support form.

We hope that this information may help you.

Best regards,

Carlos_A.