[U-Boot] [RFC] x86: Intel FSP integration
Hi Simon,
I am preparing patches for my U-Boot port on Intel Crown Bay CRB which uses Intel FSP for the memory and chipset initialization. Intel FSP is a binary blob inside which 3 pre-defined entry pointes are available for 3rd party bootloader to call to perform various jobs at different initialization stage. With the help of FSP, U-Boot can boot directly from the x86 reset vector without knowing any secrect Intel wants to hide in their chipset. Before I post them, I would like to hear your thoughts about whether it is OK to get such stuff into the U-Boot mainline.
My patches integrate the FSP binary blob into the U-Boot ROM image directly and update the U-Boot to call these 3 routines at proper timing. There are other supported codes like parsing FSP image header and HOB (hand over blob, a UEFI concept) in the FSP package that can be integrated as well. Per the license header from the FSP package released by Intel, it looks to me that the FSP binary as well as the utility source codes can be redistributed as is, however I would like post it here to hear your comments.
Additional information can be found at http://www.intel.com/fsp.
Here is the license extracted from the FSP package.
/** @file
Copyright (C) 2013, Intel Corporation
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Intel Corporation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
**/
Regards, Bin
Hi Bin,
On 2 November 2014 19:26, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
I am preparing patches for my U-Boot port on Intel Crown Bay CRB which uses Intel FSP for the memory and chipset initialization. Intel FSP is a binary blob inside which 3 pre-defined entry pointes are available for 3rd party bootloader to call to perform various jobs at different initialization stage. With the help of FSP, U-Boot can boot directly from the x86 reset vector without knowing any secrect Intel wants to hide in their chipset. Before I post them, I would like to hear your thoughts about whether it is OK to get such stuff into the U-Boot mainline.
My patches integrate the FSP binary blob into the U-Boot ROM image directly and update the U-Boot to call these 3 routines at proper timing. There are other supported codes like parsing FSP image header and HOB (hand over blob, a UEFI concept) in the FSP package that can be integrated as well. Per the license header from the FSP package released by Intel, it looks to me that the FSP binary as well as the utility source codes can be redistributed as is, however I would like post it here to hear your comments.
Additional information can be found at http://www.intel.com/fsp.
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.
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.
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.
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.
The license header should be OK - you can add it to Licenses/ if this license is already available in SPDX.
Here is the license extracted from the FSP package.
/** @file
Copyright (C) 2013, Intel Corporation
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Intel Corporation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
**/
Regards, Bin
Regards, Simon
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.
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
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
participants (2)
-
Bin Meng -
Simon Glass