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>
This patch changes the default behaviour of the MICROCODE_UPDATE_PRE_RAM
config for the platform with FIT (CPU_INTEL_FIRMWARE_INTERFACE_TABLE)
enabled. If FIT is enabled then microcode update will be taken care of
by FIT at pre-cpu reset hence, microcode update at pre-ram phase can be
skipped.
BUG=b:242473942
TEST=Able to build and boot google/rex with MICROCODE_UPDATE_PRE_RAM
remains disabled. No functional impact.
Without this patch:
CONFIG_MICROCODE_UPDATE_PRE_RAM=y
With this patch:
CONFIG_MICROCODE_UPDATE_PRE_RAM is not set
Change-Id: I603e064115869aba2bffa5589ffe47a44a90b848
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Now -mno-mmx is statically set in arch/x86 so remove this option.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I0da7f9f1afb0c8ecae728c45591897ca1d4dfb11
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75318
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Some of the chip.h files in the tree are missing the include guards.
This patch adds them in order to avoid potential redefinions of symbols
contained in these headers, when they are included multiple times in
static.c generated by sconfig.
Change-Id: I550a514e72a8dd4db602e7ceffccd81aa36446e3
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Take variable names from soc/intel and adjust counter to
start from zero.
Change-Id: I14e1120e74e1bd92acd782a53104fabfb266c3b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having a magic entry in the CPU device ID table list to tell
find_cpu_driver that it has reached the end of the list, introduce and
use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is
compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID
instead of the 0 in the CPU_TABLE_END definition.
TEST=Timeless build for Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Use CPUID_ALL_STEPPINGS_MASK to only need one CPU device ID table entry
per family & model combination and not one per stepping.
TEST=Thinkpad x230 with Ivy Bridge stepping 9 CPU still boots with this
patch applied.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I46020d5b1b1fba8449c3823fac1369e5670d91c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72854
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of always doing exact matches between the CPUID read in
identify_cpu and the device entries of the CPU device ID table,
offer the possibility to use a bit mask in the CPUID matching. This
allows covering all steppings of a CPU family/model with one entry and
avoids that case of a missing new stepping causing the CPUs not being
properly initialized.
Some of the CPU device ID tables can now be deduplicated using the
CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this
patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0540b514ca42591c0d3468307a82b5612585f614
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for samsung boards lumpy and stumpy. 0x8000 unused
flash space is allocated for RW_NVRAM.
Previously BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES was selected for
CPU_INTEL_HASWELL, CPU_INTEL_MODEL_{2065X,206AX} and others (see [2]).
However, there seems to be no particular reason on those platforms.
We've dropped the config for haswell. Now drop it for
CPU_INTEL_MODEL_{2065X,206AX}, so that VBOOT_VBNV_FLASH can be enabled.
[1] https://web.archive.org/web/20230115020833/https://issuetracker.google.com/issues/235293589?pli=1
[2] commit 6c2568f4f5
("drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config")
BUG=b:235293589
TEST=./util/abuild/abuild -a -t SAMSUNG_LUMPY -x
Change-Id: I833edd4f7a328b21e81c971ba8a9aec0aad7d3d3
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70296
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
If selected, libgnat is linked into romstage. In addition, a call to
romstage_adainit() is added to support Ada program data
initialization.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=Ada code compiles for romstage and loads successfully
Change-Id: I74f0460f6b14fde2b4bd6391e1782b2e5b217707
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70274
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clang generates R_X86_64_32S symbols that get truncated.
TESTED:
- prodrive/hermes boots with GCC and clang
- MTRR are properly cleared (tested by filling in both
MTRR_FIX_64K_00000 and MTRR_FIX_4K_F8000 before clearing)
Change-Id: I6a5139f7029b6f35b44377f105dded06f6d9cbf9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The struct device passed to this function is the cpu cluster and not
individual lapic. This fixes a regression introduced by
cdb26fd (cpu/intel/model_206ax: Remove fake lapic device)
Change-Id: I586e13a723303b8d639d526a175bd6828465a607
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
C5, C6 and slfm depend on the southbridge and the northbridge to be able
to provide this functionality, with some just lacking the possibility to
do so. Move the devicetree configuration to the southbridge.
This removes the need for a magic lapic in the devicetree.
Change-Id: I4a9b1e684a7927259adae9b1d42a67e907722109
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of using a fake lapic device hook up the cpu cluster to chip
cpu/intel/model_206ax.
The lapic device is also not needed as the mp init will allocate it for
the BSP at runtime.
Change-Id: Id3b1c4ca027e2905535e137691c3e3e60417dbf3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Also remove the now unnecessary comments from the devicetree.
Change-Id: Iebbe12fd413b7a2eb1078a579e194eba821ada7c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Both SMM_ASEG and SMM_TSEG choices work.
There is periodic TCO timeout occurring.
At least with DEBUG_SMI kernel reports low memory corruption.
Change-Id: If20a7092117612a1a9e25eb6ac480e105acd57d7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Move the chip configuration to the cpu cluster device.
It looks like none of the devicetree were featuring a lapic 0xacac,
nor was tcc_offset ever set, so this remains a NOP.
Change-Id: I296631511b0e31b0ed43ca8193552483bdab4482
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59315
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The cpu cluster is always present and it's the proper device to contain
the settings that need to be applied to all cpus. This makes it possible
to remove the fake lapic from devicetrees.
Change-Id: Ic449b2df8036e8c02b5559cca6b2e7479a70a786
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59314
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This moves a lot of post code values, but unifies them between
platforms, so that the same value means the same thing as much as
possible.
The P4-netburst code was the most extensive and most different, so that
dictated the majority of the values. Three were two values there that
didn't match the other files, so those two values, 0x22 & 0x29 have
duplicate entries in the table.
The rest of the entries are similar between platforms, though the values
for many of them were moved to match the P4-netburst values.
POST_BOOTBLOCK and POST_POSTCAR values are intended to eventually become
global, while POST_SOC would be specific to the Intel platforms.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If13e40b700a41d56bca85510d68da0ab31a235a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69866
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The disablement of SSE2 was not honoured since there is explicit
select under CPU_INTEL_MODEL_F2X. The removed commentary originates
probably from ROMCC romstage implementation.
Change-Id: I7d9ac007406a82c498f3ed23568e2ff064504983
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69443
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit eb76a455cd
and applies minor fixes to make it build again.
PARALLEL_MP was working prior to board removal and no
relevant SMI handlers were implemented. So NO_SMM choice
is now selected.
Change-Id: Ia1cd02278240d1b5d006fb2a7730d3d86390f85b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These symbols and codepaths are unused now so drop them.
Change-Id: I7c46c36390f116f8f8920c06e539075e60c7118c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69361
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This board use the LEGACY_SMP_INIT which is to be deprecated after
release 4.18.
Change-Id: Idf37ade31ddb55697df1a65062c092a0a485e175
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69114
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The patch fixes the typecasting issue, that is conversion from 'int' to
'unsigned long long int'. This changes value from '0x8000 0000' to
'0xFFFF FFFF 8000 0000'.
During unit testing, the argument is getting changed to an unexpected
number which is resulting to an exception when IA32_HWP_REQUEST MSR is
updated. In this update, the MSR's reserved bits are getting updated, so
this causes exception.
TEST= Verified the code on the Gimble.
No exception is seen after the fix.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I35d382c792b9df260381b7696f3bbff43d6c4dc2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for Haswell.
Currently BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is selected for
CPU_INTEL_HASWELL (see [2]). However, there seems to be no
particular reason on those platforms. Flashconsole works on Broadwell,
at least, and it writes to flash as early as bootblock. Therefore,
remove BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES, so that VBOOT_VBNV_FLASH
can be enabled.
[1] https://issuetracker.google.com/issues/235293589
[2] commit 6c2568f4f5 (CB:45740)
drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config
BUG=b:235293589
TEST=./util/abuild/abuild -t LENOVO_THINKPAD_T440P -a (with VBOOT)
Change-Id: If1430ffd6115a0bc151cbe0632cda7fc5f6c26a6
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
use is_enabled_cpu() on cycles over device list to check
whether the current device is enabled cpu.
TEST: compile test and qemu run successfully with coreinfo
payload
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: If64bd18f006b6f5fecef4f606c1df7d3a4d42883
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67797
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The µcode updates for Broadwell come from coreboot's blobs submodule
and have not been updated in at least 7 years. Use the µcode updates
available in the intel-microcode submodule. This change forgoes some
µcode updates for old Broadwell ULT/ULX steppings with CPUID 0x306d2
and 0x306d3, as well as an old µcode update for Haswell ULT/ULX CPUs
with CPUID 0x40651 in favor of a newer intel-microcode revision that
was already being used: when the µcode updates are concatenated into
one file, the newer µcode update revision would be placed before the
older revision, so the latter would never be used.
Change-Id: I67f8a58552bd211095c183e6f7a219d60e3be162
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67526
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Commit 27126f135d (cpu/intel/haswell: add
Crystal Well CPU IDs) introduced new Haswell CPUIDs but did not include
any µcode updates for them. It is unknown how this could have worked as
the initial µcode inside the CPU can be quite unstable. Intel CPUs with
support for FIT (Firmware Interface Table) can have their µcode updated
before the x86 reset vector is executed.
The µcode updates for Crystal Well CPUID 0x40661 can be found inside the
intel-microcode submodule. There are no publicly available µcode updates
for Crystal Well CPUID 0x40660 as it is a pre-production stepping, which
is not meant to be used anymore. Hook up the available µcode updates for
Crystal Well CPUs.
Change-Id: If5264f333e681171a2ca4a68be155ffd40a1043b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
There are two types of Haswell/Broadwell platforms: Trad(itional) with
separate CPU and PCH packages, and ULT/ULX where the CPU and PCH share
one package. Mainboards can specify which platform type they are using
the `INTEL_LYNXPOINT_LP` Kconfig option. There are so many differences
between Trad and ULT/ULX that it's not worth doing runtime detection.
The CPUIDs are different for Trad and ULT/ULX platforms, and so are the
µcode updates. So, including Trad µcode updates in a coreboot image for
an ULT/ULX mainboard makes no sense, and vice versa.
Adapt the Makefile so that only relevant µcode updates are added. Also,
add a few comments to indicate which updates correspond to which CPUs.
TEST=Run binwalk on coreboot.rom to verify included µcode updates for:
- Asrock B85M Pro4 (Haswell Trad)
- HP Folio 9480M (Haswell ULT/ULX)
- Purism Librem BDW (Broadwell ULT/ULX)
Change-Id: I6dc9e94ce9fede15cbcbe6be577c48c197a9212a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Haswell and Broadwell platforms usually stitch six microcode
patches. It has worked so far with the default value of four thanks a
bug which is being fixed by `util/ifittool: Error out if microcodes do
not fit the FIT table' commit.
BUG=b:245380705
TEST=Jenkins build without failing on the FIT table size
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I23bf79a3e8918499f6c51e6ef829312d5872181a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This moves the die() statement to a common place.
Change-Id: I24c9f00bfee169b4ca57b469c089188ec62ddada
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch changes the serial message type to BIOS_WARNING as sometimes
it may raise a wrong signal when microcode resides inside other part
of the IFWI instead /CBFS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I714bf74a91c2d783982c5e5ca76a70deed872473
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65316
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds an error msg if intel_microcode_find() is unable to
find a microcode for the CPU SKU.
TEST=Able to see the error msg in coreboot serial log in case packed
with wrong microcode binary.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib4865575a44d2c8c6c3a20c2823a546d8f261e52
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65285
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the microcode loading and reloading API with a
helper function that perform the actual MSR write operation after
taking the microcode pointer from the caller function.
Also, convert the microcode loading failure msg type from `BIOS_INFO`
to `BIOS_ERR` to catch the error in proper.
TEST=Able to perform microcode loading on google/kano.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I9a7cdc2d2c9211f1e0c7921015126f7a1be87761
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65249
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
