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

[Simon Glass]

Hi Bin,

On 3 November 2014 20:05, Bin Meng <bmeng.cn at gmail.com> wrote:
> 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.

The microcode can perhaps be a hex file - see the bare-working repo
for how I did it. I think that is OK - after all it is CPU microcode
so there isn't any sensible public source format / language.

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

Sounds good.

Regards,
Simon