The X2APIC_LATE_WORKAROUND kconfig allows bringing APs in XAPIC mode initially hence, it won't work if LAPIC ID is > 0xff.
This patch ensures the MAX_CPUS logic is appropriate while selecting X2APIC_LATE_WORKAROUND kconfig from SoC.
BUG=b:219061518, b:219053812
TEST=Able to build Google/Rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I466e6cc568024a9dea80af21e0ebf3572e74a1f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66110
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Most of these changes are suggested by clang-format(13.0-54) tool on
Debian testing.
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Ie4fe0e872e94f38079945970848fefd153ab7cb5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Intel Meteor Lake SoC expects to select late x2APIC enablement where
AP bring up will use xAPIC and later x2APIC gets enabled using CPU init.
This patch provides an option where SoC code choose the correct
LAPIC access mode using choice selection.
BUG=b:219061518, b:219053812
TEST=Able to build Google/Rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6b50a0f5e39a95c25cd2c72219d2b402550a6fad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65786
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add option to do AP bringup with LAPICs in XAPIC mode and
switch to X2APIC later in CPU init.
Change-Id: I94c9daa3bc7173628f84094a3d5ca59e699ad334
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65766
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
The do_smm struct element in the mp_state struct was an int even though
it only had two possible states, so change it to bool to make this more
obvious. Also change the return type of is_smm_enabled from int to bool.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8d2d95f0497649d67565243d14a5ab9c9cdda412
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
This patch introduces a newer API to reload the microcode patch when
SoC selects RELOAD_MICROCODE_PATCH config.
Expected to call this API being independent of CPU MP Init regular
flow hence, doesn't regress the boot time.
BUG=b:233199592
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: If480e44b88d04e5cb25d7104961b70f7be041a23
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65156
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
There is a lot of going back-and-forth with the KiB arguments, start
the work to migrate away from this.
Change-Id: I329864d36137e9a99b5640f4f504c45a02060a40
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64658
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prior commit hash 0310d34c2 (cpu/intel/microcode: Have provision to
re-load microcode patch) introduces an option to reload the microcode
based on SoC selecting RELOAD_MICROCODE_PATCH config.
This patch might potentially introduce a boot time regression (~30ms)
when RELOAD_MICROCODE_PATCH kconfig is enabled as all cores might end up
reloading the microcode without the proper need.
Note: RELOAD_MICROCODE_PATCH kconfig is not yet selected by any SoC
hence, it doesn't impact any coreboot project.
The idea is reloading microcode depends on specific use case
(for example: Skip FSP doing MP Init from Alder Lake onwards) hence,
a follow up patch will create a newer API to allow reloading of
microcode when RELOAD_MICROCODE_PATCH config is enabled.
BUG=b:233199592
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie320153d25cefe153fc8a67db447384f1f20f31f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65155
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
When switching to different board, 'make clean' needs to happen because
not everything gets properly regenerated. Microcode updates are among
those. You could end up with the microcode updates from the previous
build which can be incorrect. Adding $(DOTCONFIG) as a dependency which
gets updated when you change something in Kconfig fixes this.
TESTED: swap between boards that use different microcode and see that
the size changes.
Change-Id: Id1edecc28d492838904e3659f1fe8c9df0a69134
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65148
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This fixes following errors when building GA-945GCM-S2L with clang 14.0.5.
CC ramstage/cpu/x86/smm/smm_module_loader.o
src/cpu/x86/smm/smm_module_loader.c:180:10: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
region_offset(&cpus[i].stub_code), i);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/cpu/x86/smm/smm_module_loader.c:184:20: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
__func__, region_offset(&cpus[0].stub_code),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/cpu/x86/smm/smm_module_loader.c:185:10: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
region_offset(&cpus[i].stub_code), size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/cpu/x86/smm/smm_module_loader.c:349:52: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
printk(BIOS_DEBUG, "%-12s [0x%lx-0x%lx]\n", name, region_offset(®ion),
~~~ ^~~~~~~~~~~~~~~~~~~~~~
%zx
src/cpu/x86/smm/smm_module_loader.c:350:9: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
region_end(®ion));
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I59f20aacf91cb50fb194a84082a643b34c6c1ae5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65154
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It might be possible to have this used for more than x86, but that
will be for a later commit.
Change-Id: I4968364a95b5c69c21d3915d302d23e6f1ca182f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch provides an option to reload the microcode patch a.k.a
second microcode patch if SoC selects the required
RELOAD_MICROCODE_PATCH config.
There is a new feature requirement starting with ADL to re-load the
microcode patch as per new Mcheck initialization flow.
BUG=b:233199592
TEST=Build and boot google/taeko to ChromeOS. Able to re-load
microcode patch as below:
[INFO ] microcode: Re-load microcode patch
[INFO ] microcode: updated to revision 0x41b date=2022-03-08
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0a3c29b3c25fccd31280a2a5a8d4fb22a6cf53bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64833
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Use the common code to save data for fast boot or S3 resume.
An notable improvement that comes with this, is that the same 4K page
is not rewritten all the time. This prolongs the hardware's life.
TESTED on pcengines/apu1 and lenovo/g505s: S3 resume works fine.
Change-Id: I0f4f36dcead52a6c550fb5e606772e0a99029872
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44295
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Save the regular boot MTRRs that are restored on the S3 path during
the CPU init in cbmem instead of storing them to the SPI flash.
This was probably done because historically this code run with late
cbmem init (in ramstage).
TESTED on pcengines/apu1 and lenovo/g505s: S3 resume works fine.
Change-Id: Ia58e7cd1afb785ba0c379ba75ef6090b56cb9dc6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44294
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
We use a region later on so we might as well use a region from the
start. This simplifies the computations too.
Change-Id: Iffa36ccb89c36401d3856b24364216e83ca35f91
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64609
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This allows for some runtime checks on all SMM elements and removes
the need for manual checks.
We can drop completely separate codepaths on SMM_TSEG & SMM_ASEG as the
only difference is where permanent handler gets placed.
TESTED on prodrive/hermes and qemu with SSM_ASEG with 4 cores & SMM_TSEG
with 128 cores. This code figured out quite some problems with
overlapping regions so I think this is the right approach.
Change-Id: Ib7e2e3ae16c223ecfd8d5bce6ff6c17c53496925
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63602
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Some logging is superfluous and logging that code is being copied is
'SPEW' level.
Change-Id: I84d49a394cc53d78f1e1d3936502ac16810daf9f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When each AP needs to do a lot of printing 1 sec is not enough.
Change-Id: I00f0a49bf60f3915547924c34a62dd0044b0c918
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64828
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Starting from Intel Pentium 4, cpus featured SSE2.
This will be used in the follow-up patches to determine whether to use
mfence as this instruction was introduced with the SSE2 feature set.
Change-Id: I8ce37d855cf84a9fb9fe9e18d77b0c19be261407
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Checking if the stack encroaches on the entry points is done in other
parts of the code.
Change-Id: I275d5dda9c69cc89608450ae27dd5dbd581e3595
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The Intel Firmware Interface Table (FIT) is a bit of an annoying outlier
among CBFS files because it gets manipulated by a separate utility
(ifittool) after cbfstool has already added it to the image. This will
break file hashes created for CBFS verification.
This is not actually a problem when booting, since coreboot never
actually loads the FIT from CBFS -- instead, it's only in the image for
use by platform-specific mechanisms that run before coreboot's
bootblock. But having an invalid file hash in the CBFS image is
confusing when you want to verify that the image is correctly built for
verification.
This patch adds a new CBFS file type "intel_fit" which is only used for
the intel_fit (and intel_fit_ts, if applicable) file containing the FIT.
cbfstool will avoid generating and verifying file hashes for this type,
like it already does for the "bootblock" and "cbfs header" types. (Note
that this means that any attempt to use the CBFS API to actually access
this file from coreboot will result in a verification error when CBFS
verification is enabled.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1c1bb6dab0c9ccc6e78529758a42ad3194cd130c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64736
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested with SMI_DEBUG: SMM prints things on the console.
Change-Id: I7db55aaabd16a6ef585c4802218790bf04650b13
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/coreboot/+/61494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This code is only meant to be used in early stages so move it back to
earlymtrr.c.
This reverts commit 3ad00d0c89.
Change-Id: I9bc1ac4b863eb43d3e398e6462ee139a7751bf62
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64804
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that mtrr_use_temp_range() can deal with multiple ranges there is no
need to expose this to restore the MTRR solution.
This reverts commit 00aaffaf47.
Change-Id: Ib77a0f52228cd2f19f3227824f704ac690be4aba
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64803
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Temporary MTRR setup usually covers the memory mapped flash. On recent
Intel hardware the mapping is not coherent. It uses an external window
for parts of the BIOS region that exceed 16M.
This now allows up to 10 temporary memory ranges.
TESTED: Qemu with multiple MTRR temporary MTRR ranges sets up a valid
and optimized temporary MTRR solution.
Change-Id: I23442bd2ab7602e4c5cbd37d187a31413cf27ecc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
There is NULL dereference in adjust_apic_id_map() and updating
apic_id_to_cpu[] array within SMM stub fails.
Initial apic_id_to_cpu[] array may have worked for platforms
where APIC IDs are consecutive.
Change-Id: Ie59a731bfc883f8a47048b2ceacc66f44aa5b68c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64798
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Intel Meteor Lake SoC expects to select x2APIC for accessing LAPIC
hence, this patch provides an option where SoC code choose the correct
LAPIC access mode using choice selection.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I39c99ba13ad6e489c300bd0d4ef7274feeca9d4f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64647
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Now that the save state size is handled properly inside the smm_loader
there is no reason to make that distinction in the mp_init code anymore.
Change-Id: Ia0002a33b6d0f792d8d78cf625fd7e830e3e50fc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
This code was hard to read as it did too much and had a lot of state
to keep track of.
It also looks like the staggered entry points were first copied and
only later the parameters of the first stub were filled in. This
means that only the BSP stub is actually jumping to the permanent
smihandler. On the APs the stub would jump to wherever c_handler
happens to point to, which is likely 0. This effectively means that on
APs it's likely easy to have arbitrary code execution in SMM which is a
security problem.
Change-Id: I42ef9d6a30f3039f25e2cde975086a1365ca4182
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
We don't want to keep track of the real smm size all the time.
As a bonus now ss_start is now really the start of the save state
instead of top - MAX(stub_size, save state size).
Change-Id: I0981022e6c0df110d4a342ff06b1a3332911e2b7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
This code is much easier to read if one does not have to keep track of
mutable variables.
This also fixes the alignment code on the TSEG smihandler setup code.
It was aligning the code upwards instead of downwards which would cause
it to encroach a part of the save state.
Change-Id: I310a232ced2ab15064bff99a39a26f745239f6b9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
This is a duplicate of code_start.
Change-Id: I38e8905e3ed940fb34280c939d6f2f1fce8480a7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This code was very hard to read so rewrite it using as few mutable local
variables as possible.
Tested on qemu with 128 cores.
Change-Id: I7a455ba45a1c92533a8ecfd1aeecf34b4a63e409
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Currently no smihandler uses heap.
coreboot's heap manager also is quite limited in what it will
free (only the latest alloc). This makes it a bad idea to use it inside
the smihandler, as depending on the alloc usage the heap might actually
be full at some point, breaking the smihandler.
This also reduces the ramstage by 448 bytes on google/vilboz.
Change-Id: I70cd822be17c1efe13c94a9dbd2e1038808b9c56
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The postcar frame can now be a local variable to that function.
Change-Id: I873298970fff76b9ee1cae7da156613eb557ffbc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Setting up postcar MTRRs is done when invd is already called so there
is no reason to do this in assembly anymore.
This also drops the custom code for Quark to set up MTRRs.
TESTED on foxconn/g41m and hermes/prodrive that MTRR are properly set
in postcar & ramstage.
Change-Id: I5ec10e84118197a04de0a5194336ef8bb049bba4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54299
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MTRR is a core level register which means 2 threads in one core share
same MTRR. There is a race condition could happen that AP overrides
BSP MTRR unintentionally.
In order to prevent such race condition between BSP and APs, this
patch provides a function to let BSP assign tasks to all APs and wait
them to complete the assigned tasks.
BUG=b:225766934
Change-Id: I8d1d49bca410c821a3ad0347548afc42eb860594
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63566
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the `set_power_limits()` declaration is copy-pasta leftovers
from `cpu/intel/model_206ax`. As it's unused, get rid of it.
Change-Id: I81704e883e52fea42488f52be116b6fcc2c6af4b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The lowest bound for L2 cache size on Socket P is 512 KiB.
This allows the use of cbfs mcache on all platforms.
This fixes building when some debug options are enabled.
Change-Id: I0d6f7f9151ecd4c9fbbba4ed033dfda8724b6772
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There is plenty of cache available to increase DCACHE_RAM_SIZE to
allow the use of cbfs mcache.
Tested on Gigabyte GA-D510UD, still boots and resumes.
Change-Id: I1487ba9decd3aa22424a3ac111de7fbdb867d38d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This removes the need for a tool to generate simple identity pages.
Future patches will link this page table directly into the stages on
some platforms so having an assembly file makes a lot of sense.
This also optimizes the size of the page of each 4K page by placing
the PDPE_table below the PDE.
Change-Id: Ia1e31b701a2584268c85d327bf139953213899e3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
