| commit | 3c1b7b485b6a9e2213d90cd4b904c2dacf79f666 | [log] [tgz] |
|---|---|---|
| author | Subrata Banik <subratabanik@google.com> | Sat May 20 16:28:18 2023 +0530 |
| committer | Lean Sheng Tan <sheng.tan@9elements.com> | Sat Jul 08 12:06:00 2023 +0000 |
| tree | d38de1638ea744907a3e028f6c63c4294469bba3 | |
| parent | 325664f021341434eee8ed3c3a0b8ecc179af3cf [diff] |
cpu: Enable per-CPUID microcode loading in CBFS
The current design of the `ucode-<variant>.bin` file combines all
possible microcode per cpuid into a unified blob. This model increases
the microcode loading time from RW CBFS due to higher CBFS verification
time (the bigger the CBFS binary the longer the verification takes).
This patch creates a provision to pack individual microcodes (per CPUID)
into the CBFS (RO and RWs). Implementation logic introduces
CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config which relies on converting
Intel CPU microcode INC file into the binary file as per format
specified as in `cpu_microcode_$(CPUID).bin`.
For example: Intel CPU microcode `m506e3.inc` to convert into
`cpu_microcode_506e3.bin` binary file for coreboot to integrate if
CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config is enabled.
Another config named CPU_INTEL_UCODE_SPLIT_BINARIES is used to specify
the directory name (including path) that holds the split microcode
binary files per CPUID for each coreboot variants.
For example: if google/kunimitsu had built with Intel SkyLake processor
with CPUID `506e3` and `506e4` then CPU_INTEL_UCODE_SPLIT_BINARIES
refers to the directory path that holds the split microcode binary
files aka cpu_microcode_506e3.bin and cpu_microcode_506e4.bin.
Refer to the file representation below:
|---3rdparty
| |--- blobs
| | |--- mainboard
| | | |--- google
| | | | |--- kunimitsu
| | | | | |--- microcode_inputs
| | | | | | |--- kunimitsu
| | | | | | | |--- cpu_microcode_506e3.bin
| | | | | | | |--- cpu_microcode_506e4.bin
Users of this config option requires to manually place the microcode
binary files per CPUIDs as per the given format
(`cpu_microcode_$(CPUID).bin`) in a directory. Finally specify the
microcode binary directory path using CPU_UCODE_SPLIT_BINARIES config.
Additionally, modified the `find_cbfs_microcode()` logic to search
microcode from CBFS by CPUID. This change will improve the microcode
verification time from the CBFS, and will make it easier to update
individual microcodes.
BUG=b:242473942
TEST=emerge-rex sys-firmware/mtl-ucode-firmware-private
coreboot-private-files-baseboard-rex coreboot
Able to optimize ~10ms of boot time while loading microcode using
below configuration.
CONFIG_CPU_MICROCODE_CBFS_SPLIT_BINS=y
CONFIG_CPU_UCODE_SPLIT_BINARIES="3rdparty/blobs/mainboard/
$(CONFIG_MAINBOARD_DIR)/microcode_inputs"
Without this patch:
10:start of ramstage 1,005,139 (44)
971:loading FSP-S 1,026,619 (21,479)
> RO/RW-A/RW-B CBFS contains unified cpu_microcode_blob.bin
Name Offset Type Size Comp
...
cpu_microcode_blob.bin 0x1f740 microcode 273408 none
intel_fit 0x623c0 intel_fit 80 none
...
...
bootblock 0x3ee200 bootblock 32192 none
With this patch:
10:start of ramstage 997,495 (43)
971:loading FSP-S 1,010,148 (12,653)
> RO/RW-A/B CBFS that stores split microcode files per CPUID
FMAP REGION: FW_MAIN_A
Name Offset Type Size Comp
fallback/romstage 0x0 stage 127632 none
cpu_microcode_a06a1.bin 0x1f340 microcode 137216 none
cpu_microcode_a06a2.bin 0x40bc0 microcode 136192 none
...
...
ecrw 0x181280 raw 327680 none
fallback/payload 0x1d1300 simple elf 127443 none
At reset, able to load the correct microcode using FIT table (RO CBFS)
[NOTE ] coreboot-coreboot-unknown.9999.3ad3153 Sat May 20 12:29:19
UTC 2023 x86_32 bootblock starting (log level: 8)...
[DEBUG] CPU: Genuine Intel(R) 0000
[DEBUG] CPU: ID a06a1, MeteorLake A0, ucode: 00000016
Able to find `cpu_microcode_a06a1.bin` on google/rex with ES1 CPU
stepping (w/ CPUID 0xA06A1) (from RW CBFS)
localhost ~ # cbmem -c -1 | grep microcode
[DEBUG] microcode: sig=0xa06a1 pf=0x80 revision=0x16
[INFO ] CBFS: Found 'cpu_microcode_a06a1.bin' @0x407c0 size 0x21800 in
mcache @0x75c0d0e0
[INFO ] microcode: Update skipped, already up-to-date
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic7db73335ffa25399869cfb0d59129ee118f1012
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
coreboot is a Free Software project aimed at replacing the proprietary firmware (BIOS/UEFI) found in most computers. coreboot performs the required hardware initialization to configure the system, then passes control to a different executable, referred to in coreboot as the payload. Most often, the primary function of the payload is to boot the operating system (OS).
With the separation of hardware initialization and later boot logic, coreboot is perfect for a wide variety of situations. It can be used for specialized applications that run directly in the firmware, running operating systems from flash, loading custom bootloaders, or implementing firmware standards, like PC BIOS services or UEFI. This flexibility allows coreboot systems to include only the features necessary in the target application, reducing the amount of code and flash space required.
All source code for coreboot is stored in git. It is downloaded with the command:
git clone https://review.coreboot.org/coreboot.git.
Code reviews are done in the project's Gerrit instance.
The code may be browsed via coreboot's Gitiles instance.
The coreboot project also maintains a mirror of the project on github. This is read-only, as coreboot does not accept github pull requests, but allows browsing and downloading the coreboot source.
After the basic initialization of the hardware has been performed, any desired "payload" can be started by coreboot.
See https://doc.coreboot.org/payloads.html for a list of some of coreboot's supported payloads.
The coreboot project supports a wide range of architectures, chipsets, devices, and mainboards. While not all of these are documented, you can find some information in the Architecture-specific documentation or the SOC-specific documentation.
For details about the specific mainboard devices that coreboot supports, please consult the Mainboard-specific documentation or the Board Status pages.
Releases are currently done by coreboot every quarter. The release archives contain the entire coreboot codebase from the time of the release, along with any external submodules. The submodules containing binaries are separated from the general release archives. All of the packages required to build the coreboot toolchains are also kept at coreboot.org in case the websites change, or those specific packages become unavailable in the future.
All releases are available on the coreboot download page.
Please note that the coreboot releases are best considered as snapshots of the codebase, and do not currently guarantee any sort of extra stability.
The coreboot build, associated utilities and payloads require many additional tools and packages to build. The actual coreboot binary is typically built using a coreboot-controlled toolchain to provide reproducibility across various platforms. It is also possible, though not recommended, to make it directly with your system toolchain. Operating systems and distributions come with an unknown variety of system tools and utilities installed. Because of this, it isn't reasonable to list all the required packages to do a build, but the documentation lists the requirements for a few different Linux distributions.
To see the list of tools and libraries, along with a list of instructions to get started building coreboot, go to the Starting from scratch tutorial page.
That same page goes through how to use QEMU to boot the build and see the output.
Further details on the project, as well as links to documentation and more can be found on the coreboot website:
You can contact us directly on the coreboot mailing list:
https://doc.coreboot.org/community/forums.html
There are many files in the coreboot tree that we feel are not copyrightable due to a lack of creative content.
"In order to qualify for copyright protection in the United States, a work must satisfy the originality requirement, which has two parts. The work must have “at least a modicum” of creativity, and it must be the independent creation of its author."
https://guides.lib.umich.edu/copyrightbasics/copyrightability
Similar terms apply to other locations.
These uncopyrightable files include:
As non-creative content, these files are in the public domain by default. As such, the coreboot project excludes them from the project's general license even though they may be included in a final binary.
If there are questions or concerns about this policy, please get in touch with the coreboot project via the mailing list.
The copyright on coreboot is owned by quite a large number of individual developers and companies. A list of companies and individuals with known copyright claims is present at the top level of the coreboot source tree in the 'AUTHORS' file. Please check the git history of each of the source files for details.
Because of the way coreboot began, using a significant amount of source code from the Linux kernel, it's licensed the same way as the Linux Kernel, with GNU General Public License (GPL) Version 2. Individual files are licensed under various licenses, though all are compatible with GPLv2. The resulting coreboot image is licensed under the GPL, version 2. All source files should have an SPDX license identifier at the top for clarification.
Files under coreboot/Documentation/ are licensed under CC-BY 4.0 terms. As an exception, files under Documentation/ with a history older than 2017-05-24 might be under different licenses.
Files in the coreboot/src/commonlib/bsd directory are all licensed with the BSD-3-clause license. Many are also dual-licensed GPL-2.0-only or GPL-2.0-or-later. These files are intended to be shared with libpayload or other BSD licensed projects.
The libpayload project contained in coreboot/payloads/libpayload may be licensed as BSD or GPL, depending on the code pulled in during the build process. All GPL source code should be excluded unless the Kconfig option to include it is set.
Since 2017, coreboot has been a member of The Software Freedom Conservancy, a nonprofit organization devoted to ethical technology and driving initiatives to make technology more inclusive. The conservancy acts as coreboot's fiscal sponsor and legal advisor.