[U-Boot] [RFC] x86: Intel FSP integration

[Bin Meng]

Hi Simon,

Thanks for the comments.

On Tue, Nov 4, 2014 at 10:09 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> Well it's certainly not ideal but from what I can tell these blobs are
> a fact of life on Intel machines still. For the ivybridge stuff, I've
> found I need a microcode blob, a video BIOS blob and a memory
> reference code blob. Ugggh.

Yep, the microcode is needed for Tunnel Creek as well and is not
integrated into the FSP. One of the 3 pre-defined FSP entry takes one
parameter as the microcode address in the ROM and do the microcode
update itself. MRC is included in the Tunnel Creek FSP so we don't
need care about that. As for the vbios, the Tunnel Creek FSP does not
touch the graphics unit on the chipset thus graphics support will not
be there.

> Is the chipset init completely within the blob? Do you have any source
> code for this? The license seems to indicate that this is available.

According to its FSP integration guide, the FSP performs all the
required steps as needed for the chipset initialization that is
documented in the BWG (BIOS Writer Guide), except the following: power
management (ACPI), bus enumeration, security, 64-bit long mode and
Pre-OS graphics. I don't have any source code of the FSP binary blob
itself. What the license header mentions is the supporting codes (pure
software logic) shipped in the FSP package, like parsing FSP binary
blob header and HOB data, though one could completely rewrite these
codes according to FSP integration guide and the UEFI specs.

> Anyway from my point of view if this is the only way to support the
> platform then we might as well go with it. It is better than nothing.
> The only caveat is that we can't check in the binary blobs - they
> would have to be downloaded separately from a suitable place.

We can reverse engineer the FSP binary blob to find out what is
initialized and rewrite the chipset initialization, which is
definitely a long path, but I doubt I will do that :) Yep, coreboot is
doing the same thing that FSP binary blobs are not checked in the git
tree. But I do see microcode is in coreboot tree. How about CMC binary
blob? coreboot does not ship that too.

> In terms of patches, take a look at u-boot-x86/bare-working which has
> various patches. I've been splitting the code out into patches but
> haven't had a lot of time lately. I'm pretty close though and my goal
> is to send the first series out midweek. Still, if you ignore the top
> patch it is fairly clean, and does boot to a prompt on an ivybridge
> board. Please see if your patches apply on top of those.

I think I can submit some patches first which is not related to the
FSP integration. And I will check the u-boot-x86/bare-working. Thanks!

Regards,
Bin