1 Reply Latest reply on Nov 3, 2017 5:33 AM by Carlos_A

    BayTrail PCIe problems (hangup) in FSP

    stroese Community Member

      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