The EFER MSR is in the SMM save state and RSM properly restores it.
Returning to 32bit mode was only done so that fxsave was done in the
same mode as fxrstor, but this is no longer done.
See commit 1efca4d570 (cpu/x86/smm: Drop fxsave/fxrstor logic)
TESTED on qemu: the smihandler works fine.
Change-Id: Ie0e9584afd1f08f51ca57da5c4350042699f130d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68895
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
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>
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.
header="src/soc/amd/common/block/include/amdblocks/post_codes.h \
src/include/cpu/intel/post_codes.h \
src/soc/intel/common/block/include/intelblocks/post_codes.h"
array=`grep -r "#define POST_" $header | \
tr '\t' ' ' | cut -d ":" -f 2 | cut -d " " -f 2`
for str in $array; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r $str src | cut -d ':' -f 1 | \
xargs sed -i'' -e "s/$str/POSTCODE_$splitstr/g"
done
Change-Id: Id2ca654126fc5b96e6b40d222bb636bbf39ab7ad
Signed-off-by: Yuchen He <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76044
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
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>
This patch fixes the boot hang due to commit 053a45bcdb ("cpu/x86/lapic: Fix X2APIC_ONLY regression") on platform which selects X2APIC_LATE_WORKAROUND config.
[EMERG] Switching from X2APIC to XAPIC mode is not implemented.
Without this patch: Boot gets stuck inside at BS_WRITE_TABLES when enable_lapic() gets called after X2APIC mode has been enabled. The fix is to change enable_lapic() to track when late enablement for X2APIC mode happens with X2APIC_LATE_WORKAROUND.
TEST=Able to build and boot google/rex to chromeos.
Change-Id: I41e72380e9cfb59721d0df607ad875d7b6546974
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76384
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
At the time of writing SMM runtime does not make register
accesses to LAPIC registers, but such breakage has been
reported.
S3 resume failure, where OS switched back from X2APIC
to XAPIC mode, can be reproduced with a sandybridge SKU
that has VT-d disabled.
Change-Id: I300ba87c3d8fde548dbaf95703bd7e2fe54cff57
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Some ancient CPUs may have had LAPIC disabled at power-up, so
semantically enable_lapic() should always come before attempting
to access the register banks.
With X2APIC_ONLY option it is necessary to ensure enable_lapic()
is called prior to any other lapic register space accesses,
since the XAPIC mode MMIO accessors are optimised away build-time
and CPU's do not yet initialise for X2APIC mode at reset.
Change-Id: I96eaa5c43108c802375e184e0c68b5091ca0198f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76195
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Held <felix-coreboot@felixheld.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>
Since we now explicitly compile both ramstage and smihandler code
without floating point operations and associated registers we don't need
to save/restore floating point registers.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I180b9781bf5849111501ae8e9806554a7851c0da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75317
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Improve boot time performances by replacing the wbinvd instruction
with multiple clflush to ensure that the SIPI data is written back to
RAM.
According to some experimental measurements, the wbinvd execution
takes between 1.6 up and 6 milliseconds to complete. In the case of
the SIPI data, wbinvd unnecessarily flushes and invalidates the entire
cache. Indeed, the SIPI module is quite small (about 400 bytes) and
cflush'ing the associated cache lines is almost instantaneous,
typically less than 100 microseconds.
BUG=b/260455826
TEST=Successful boot on Skolas and Rex board
Change-Id: I0e00db8eaa6a3cb41bec3422572c8f2a9bec4057
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Suggested-by: Erin Park <erin.park@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75391
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Before the bootblock stage starts setting up the CAR mode, it sends
`POST_BOOTBLOCK_CAR` POST code. However, before the definition for
`POST_BOOTBLOCK_CAR` was introduced in the commit
0d34a50a36 , the value `0x20` was used.
At that point, `0x20` means "entry into CAR mode" and `0x21` means
"the cache memory region is cleared". Right now we are sending the
same POST code twice, which makes no sense.
So we can do the following (todo: drop me after we decided which one is
more appropriate):
1) Drop it (current patchset does exactly that)
2) Introduce POST code similar to POST_SOC_CLEARING_CAR and use it
before the cache memory region is cleared.
Change-Id: I5d9014c788abdf5a4338c9e199138d1e514450b3
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
In ACPI 1.0 the processor objects were inside the \_PR scope, but since
ACPI 2.0 the \_SB scope can be used for that. Outside of coreboot some
firmwares still used the \_PR scope for a while for legacy ACPI 1.0 OS
compatibility, but apart from that the \_PR scope is deprecated.
coreboot already uses the \_SB scope for the processor devices
everywhere, so move the \_SB scope out of the ACPI_CPU_STRING to the
format string inside the 3 snprintf statements that use the
ACPI_CPU_STRING.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I76f18594a3a623b437a163c270547d3e9618c31a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Instead of having the maximum number of possible CPU objects defined in
the DSDT, dynamically generate the number of needed CPU devices in the
SSDT like it's done on all other x86 platforms in coreboot.
TEST=APU2 still boots and Linux doesn't show any ACPI errors with this
patch applied and it prints "ACPI: \_SB_.P000: Found 2 idle states".
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6f057ad130a27b371722fa66ce0a982afc43c6c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73073
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
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>
Use coreboot's native PCI access functions instead of using the
vendorcode's PCI access functions to set up the CPU IO routing in
function 1 of the HT PCI device. This file still has room for
improvement, but at least it's now using coreboot-native functionality.
Stoneyridge has a nicer implementation, but looking into possibly
unifying those is out of scope for this patch.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ieecc0e5f6576a838d79220b061de81e21b5d976c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The BSP might have non-zero lapicid so set the topology accordingly,
without assuming it is 0. This fixes a cpu exception on at least Intel
Meteorlake. This was caused by FSP CPU PPI being giving incorrect
information about the BSP topology.
This problem was introduced by 8b8400a "drivers/fsp2_0/mp_service_ppi:
Use struct device to fill in buffer" which sets the PPI struct based on
struct device.
TESTED on google/rex
Change-Id: I3fae5efa86d8efc474c129b48bdfa1d1e2306acf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74374
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some systems the BSP cannot know how many CPUs are present in the
system. A typical use case is a multi socket system. Setting the enable
flag only on CPUs that actually exist makes it more flexible.
Change-Id: I6c8042b4d6127239175924f996f735bf9c83c6e8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68892
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the current design the relocatable parameters are used to know the
offset of the 32bit startpoint. This requires back and forward
interaction between the stub, the loader and the mp init code. This
makes the code hard to read.
This is static information known at buildtime, so a better way to deal
with this is to generate a header that contains this offset.
Change-Id: Ic01badd2af11a6e1dbc27c8e928916fedf104b5b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64625
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the 'verstage_x86' make target for the mode_switch.S compilation
unit instead of making adding it to the 'verstage' target depending on
VBOOT_STARTS_BEFORE_BOOTBLOCK not being selected. The only case where
VBOOT_STARTS_BEFORE_BOOTBLOCK is selected is the verstage on PSP case,
so I find using the 'verstage_x86' target here a bit easier to
understand.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iab618d4b9e325b07a648b91fcdce99c63644fbfc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74196
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When cbmem is initialized in romstage and postcar placed in the stage
cache + cbmem where it is run, the assumption is made that these are
all in UC memory such that calling INVD in postcar is OK.
For performance reasons (e.g. postcar decompression) it is desirable
to cache cbmem and the stage cache during romstage.
Another reason is that AGESA sets up MTRR during romstage to cache all
dram, which is currently worked around by using additional MTRR's to
make that UC.
TESTED on asus/p5ql-em, up/squared on both regular and S3 resume
bootpath. Sometimes there are minimal performance improvements
when cbmem is cached (few ms).
Change-Id: I7ff2a57aee620908b71829457ea0f5a0c410ec5b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37196
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
