Hi Bin,
On 3 November 2014 20:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
Thanks for the comments.
On Tue, Nov 4, 2014 at 10:09 AM, Simon Glass sjg@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