commit | b6c3a0325b9b0462cca81ea4134efb6b73756577 | [log] [tgz] |
---|---|---|
author | Subrata Banik <subratabanik@google.com> | Sun Jun 05 22:39:34 2022 +0530 |
committer | Felix Held <felix-coreboot@felixheld.de> | Mon Jun 27 13:45:22 2022 +0000 |
tree | ba78537ad49591cf562fdaa970cbc75fff9732a4 | |
parent | 1e98e733c1fc6ea7e558ad87297e51eafd7c985c [diff] |
soc/intel/alderlake: Implement MultiPhase SI Init Index 2 callback The details about how the CPU multiprocessor init (MP) has migrated from coreboot to FSP can be found in https://doc.coreboot.org/soc/intel/mp_init/mp_init.html. The major reason behind this migration is to support the Intel proprietary and restricted CPU feature programming which can't be performed if coreboot sets the BIOS_DONE or BIOS Reset CPL as part of coreboot MP Init flow (prior to calling FSP-S). Hence, the new flow introduced with Tiger Lake platform forced having monolithic MP Init peformed by FSP (using coreboot MP PPI wrapper code). The last 3-4 years of FSP doing MP Init has demonstrated ample issues during platform bringup which is specific to UEFI MP Service implementation and not relevant to open source coreboot. This new flow makes the debug and validation aspect complicated where any FSP MP Init code changes should have been validated with coreboot MP PPI wrapper else might cause some failure, unfortunately, the validation commitment has never been met, hence, issue debugging is the only solution that remains in practice. Most importantly, the restricted feature programming which demanded closed source MP Init (for features like SGX and C6DRAM) has never been enabled in coreboot (starting with Alder Lake, the SGX feature has been dropped). This patch attempts to decouple FSP-S doing MP Init from the rest of the FSP-S silicon init and introduces 2nd MultiPhase SI init which allows bootloader to perform the mandatory SoC programming before FSP-S has done with PM programming (a.k.a set the reset CPL). The core/uncore BWG suggests the minimum SoC programming before BIOS Reset CPL is set. coreboot uses the MultiPhaseSI Init Index 2 to perform the required CPU programming before enabling the BIOS Reset CPL. This implementation would allow us to get rid of FSP running CPU feature programming and additionally make several EDK2 MP service modules optional (those are packed to create FSP-S blob). In summary, this change would allow coreboot to utilize open source MP init without running into FSP-S related code blocks. Note: At present, Intel Alder Lake FSP doesn't have support for MultiPhase SI Init, Index 2 (submitted a FSP code changes over chrome-internal to enable this feature to decouple MP Init from FSP-S init). BUG=b:233199592 TEST=Build and boot google/taeko to ChromeOS. Perform several thousands cycles of suspend test and power cycle without running into any issue. Signed-off-by: Subrata Banik <subratabanik@google.com> Change-Id: I314c63c917ef6fdd32f364b2c60bae22486b8b74 Reviewed-on: https://review.coreboot.org/c/coreboot/+/64979 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
coreboot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a payload.
With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like PC BIOS services or UEFI. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.
coreboot was formerly known as LinuxBIOS.
After the basic initialization of the hardware has been performed, any desired "payload" can be started by coreboot.
See https://www.coreboot.org/Payloads for a list of supported payloads.
coreboot supports a wide range of chipsets, devices, and mainboards.
For details please consult:
ANY_TOOLCHAIN
Kconfig option if you're feeling lucky (no support in this case).Optional:
make menuconfig
and make nconfig
)Please consult https://www.coreboot.org/Build_HOWTO for details.
If you want to test coreboot without any risks before you really decide to use it on your hardware, you can use the QEMU system emulator to run coreboot virtually in QEMU.
Please see https://www.coreboot.org/QEMU for details.
Further details on the project, a FAQ, many HOWTOs, news, development guidelines and more can be found on the coreboot website:
You can contact us directly on the coreboot mailing list:
https://www.coreboot.org/Mailinglist
The copyright on coreboot is owned by quite a large number of individual developers and companies. Please check the individual source files for details.
coreboot is licensed under the terms of the GNU General Public License (GPL). Some files are licensed under the "GPL (version 2, or any later version)", and some files are licensed under the "GPL, version 2". For some parts, which were derived from other projects, other (GPL-compatible) licenses may apply. Please check the individual source files for details.
This makes the resulting coreboot images licensed under the GPL, version 2.