| Age | Commit message (Collapse) | Author |
|---|
|
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the cpu directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3033f2a9eebc75220f7666325857b3ddd60c8f75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68979
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
This patch drops the unnecessary alignment of 64 bytes that was
introduced when implementing the split Intel microcode packing logic
into CBFS.
- The 16-byte alignment that is already used for Intel microcode is
sufficient.
- Removes unnecessary alignment check of 64 bytes against an AMD
platform specific config.
TEST=Able to build and boot google/rex without any functional
impact.
Change-Id: Icc44e9511e321592de7ab8d1346103d0a9951c9b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76397
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
Change-Id: I8243be7c9a57402b2ac1cfa1c0552990d4a4ba74
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37891
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Make microcode lib available in bootblock. Now that microcode.c is compiled
in bootlock no need to include it explicitly, hence remove its references.
Change-Id: I419da6af70222902e3ca39fc2133d5dc8558e053
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35278
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ie3c2d2e1bc79dcaffd9901e17f83ceeaabd1d659
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The option to specify a binary file name was added later for platforms
that do not provide microcode updates in our blobs repository. Alas,
it wasn't visible what platforms these are. And if you specified a file
for a platform that already had one, they were all included together.
Make it visible which platforms don't provide binaries with the new con-
figs MICROCODE_BLOB_NOT_IN_BLOB_REPO, MICROCODE_BLOB_NOT_HOOKED_UP and
MICROCODE_BLOB_UNDISCLOSED. Based on that we can decide if we want to
include binaries by default or explicitly show that no files are inclu-
ded (default to CPU_MICROCODE_CBFS_NONE).
Also split CPU_MICROCODE_CBFS_GENERATE into the more explicit
CPU_MICROCODE_CBFS_DEFAULT_BINS and CPU_MICROCODE_CBFS_EXTERNAL_BINS.
And clean up the visibility of options: Don't show CBFS related options
on platforms that don't support it and don't show external file options
if the platform uses special rules for multiple files (CPU_MICROCODE_
MULTIPLE_FILES).
Change-Id: Ib403402e240d3531640a62ce93b7a93b4ef6ca5e
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/29934
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Hardcoding the microcode filenames into the makefiles is great when
the microcode is in the blobs directory. When the microcode isn't
posted to the blobs directory, we need some method of supplying the
microcode binary into the build. This can of course be done manually
after the build has completed, as can be done with everything that
we're including in the ROM image. Instead of making life hard for
everyone though, let's just add a way to specify where the microcode
rom comes from.
BUG=chrome-os-partner:53013
Change-Id: I7c5127234809e8515906efa56c04af6005eecf0b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/16386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I58d5c16de796a91fa14d8db78722024266c09a94
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15934
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The previous usage of the intel microcode support supported using
the library under ROMCC and ramstage. Allow for microcode support
to be used in normal C-based romstage as well by:
1. Only using walkcbfs when ROMCC is defined.
2. Only using spinlocks if !__PRE_RAM__
The header file now unconditionally exposes the declarations
of the supporting functions.
Change-Id: I903578bcb4422b4c050903c53b60372b64b79af1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The sequence to inject microcode updates is virtually the same for all
Intel CPUs. The same function is used to inject the update in both CBFS
and hardcoded cases, and in both of these cases, the microcode resides in
the ROM. This should be a safe change across the board.
The function which loaded compiled-in microcode is also removed here in
order to prevent it from being used in the future.
The dummy terminators from microcode need to be removed if this change is
to work when generating microcode from several microcode_blob.c files, as
is the case for older socketed CPUs. Removal of dummy terminators is done
in a subsequent patch.
Change-Id: I2cc8220cc4cd4a87aa7fc750e6c60ccdfa9986e9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4495
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
|
|
This patch aims to improve the microcode in CBFS handling that was
brought by the last patches from Stefan and the Chromium team.
Choices in Kconfig
- 1) Generate microcode from tree (default)
- 2) Include external microcode file
- 3) Do not put microcode in CBFS
The idea is to give the user full control over including non-free
blobs in the final ROM image.
MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode
is handled by a special class, cpu_microcode, as such:
cpu_microcode-y += microcode_file.c
MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is
needed by intel microcode updating. Once all intel cpus are converted to
cbfs updating, this variable can go away.
These files are then compiled and assembled into a binary CBFS file.
The advantage of doing it this way versus the current method is that
1) The rule is CPU-agnostic
2) Gives user more control over if and how to include microcode blobs
3) The rules for building the microcode binary are kept in
src/cpu/Makefile.inc, and thus would not clobber the other makefiles,
which are already overloaded and very difficult to navigate.
Change-Id: I38d0c9851691aa112e93031860e94895857ebb76
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1245
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
When microcode storage in CBFS is enabled, the make system is supposed
to generate the microcode blob and place it into the generated ROM
image as a CBFS component.
The microcode source representation does not change: it is still an
array of 32 bit constants. This new addition compiles the array into a
separate object file and then strips all sections but data.
The raw data section is then included into CBFS as a file named
'microcode_blob.bin' of type 0x53, which is assigned to microcode
storage.
Change-Id: I84ae040be52f520b106e3471c7e391e64d7847d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1295
Tested-by: build bot (Jenkins)
|
|
at the same time let the user specify sources instead
of object files:
- objs becomes ramstage-srcs
- initobjs becomes romstage-srcs
- driver becomes driver-srcs
- smmobj becomes smm-srcs
The user servicable parts are named accordingly:
ramstage-y, romstage-y, driver-y, smm-y
Also, the object file names are properly renamed now, using
.ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently.
Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't
easily fit in the build system and aren't useful anyway.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coreystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Works on Kontron, qemu, and serengeti.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
tested on abuild only.
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
