BayTrail PCIe problems (hangup) in FSP (in U-Boot)

[Stefan Roese]

Hi,

I'm facing a PCIe init related problem most likely caused in the
Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you
don't mind me posting this question on this coreboot list, since
here many more people are present with Intel FSP knowledge.

So here we go:

We are currently struggling with an FSP PCIe related issue on our
BayTrail target. Here we use an PLX / Avago PCIe switch, connected
to the PCIe root port of the CPU with a PCIe x4 link.

The BIOS always boots fine. Only U-Boot doesn't boot at all. No
output on the console. This is on some boards, 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

Here the log from a different board, with stable and working
4 times x1 PCIe links (different board with 4 times x1 PCIe
links -> pci-good):

...
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
...

I've attached the logs, so that you can review them yourself
as well.

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 with coreboot
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

[Peter Stuge]

Hi Stefan,

Stefan Roese wrote:
> I'm facing a PCIe init related problem most likely caused in the
> Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you
> don't mind me posting this question on this coreboot list, since
> here many more people are present with Intel FSP knowledge.

I think you are actively hurting the overall ecosystem by working on
a different project (FSP in U-Boot) which overlaps with coreboot
efforts.

The only thing that makes sense is for U-Boot to focus on being a
payload that is started by coreboot (this has already been done) and
for your issues to be solved within the coreboot frame.

Anything else is an obviously selfish effort by Denx and I don't see
why the coreboot community would support that. Please know that I
have no bias against Denx, since I had no experience with Denx I
thus far always erred on the side of giving benefit of the doubt.

At the very least, you should have framed your question in a coreboot
setting, if you want to engage with the coreboot community.

That is of course still very much possible.

//Peter

[ron minnich]

Simon Glass has done excellent work with making u-boot run as a coreboot
payload for at least 5 years now. You might want to talk to him. It might
help avoid a lot of unnecessary work. Just a thought.

On Thu, Nov 2, 2017 at 7:31 AM Peter Stuge  wrote:
> Hi Stefan,
>
> Stefan Roese wrote:
> > I'm facing a PCIe init related problem most likely caused in the
> > Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you
> > don't mind me posting this question on this coreboot list, since
> > here many more people are present with Intel FSP knowledge.
>
> I think you are actively hurting the overall ecosystem by working on
> a different project (FSP in U-Boot) which overlaps with coreboot
> efforts.
>
> The only thing that makes sense is for U-Boot to focus on being a
> payload that is started by coreboot (this has already been done) and
> for your issues to be solved within the coreboot frame.
>
> Anything else is an obviously selfish effort by Denx and I don't see
> why the coreboot community would support that. Please know that I
> have no bias against Denx, since I had no experience with Denx I
> thus far always erred on the side of giving benefit of the doubt.
>
> At the very least, you should have framed your question in a coreboot
> setting, if you want to engage with the coreboot community.
>
> That is of course still very much possible.
>
> //Peter