Hi Bin, On 3 November 2014 20:05, Bin Meng <bmeng...@gmail.com> wrote: > Hi Simon, > > Thanks for the comments. > > On Tue, Nov 4, 2014 at 10:09 AM, Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
