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>
Follow-up patches will add more to this makefile.
Change-Id: I8da6265b4c810e39a67f5ec27e26eeb26e3679a4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
<arch/cpu.h> is chain included through <cpu/cpu.h>.
Change-Id: I54a837394f67ac2a759907c7212ab947d07338dc
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <martinroth@google.com>
None of these options make sense on different ARCH.
Change-Id: Ie90ad24ff9013e38c42f10285cc3b546a3cc0571
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63673
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The printed address ranges in the tree (resource allocator and even
some MTRR code) usually shows the range inclusive (meaning from start
address to the real end address of the range). Though there is still
some code in the MTRR context which prints the ranges with an exclusive
end. This patch aligns the printing of ranges in the MTRR code to be
consistent among the tree so that the shown end addresses are now
inclusive.
Change-Id: I0ca292f9cf272564cb5ef1c4ea38f5c483605c94
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
This patch calls into need_restore_mtrr() from the mtrr_use_temp_range
function to set `put_back_original_solution` to discard any temporary
MTRR range prior to boot to payload.
BUG=b:225766934
TEST=Able to build and boot google/brya to verify that
`remove_temp_solution()` is able to discard any temporary MTRR range
before booting to payload.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2e00ec593847e1eb173d5ac77b15b50342860f89
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
`put_back_original_solution` variable in mtrr.c is static, but there is
a need to set put_back_original_solution outside of mtrr.c in order to
let `remove_temp_solution` to drop any temporary MTRRs being set
outside `mtrr_use_temp_range()`, for example: `set_var_mtrr()` function
is used to set MTRRs for the ROM caching.
BUG=b:225766934
TEST=Able to build and boot google/redrix.
Change-Id: Ic6b5683b2aa7398a5e141f710394ab772e9775e7
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The sinkhole exploit exists in placing the lapic base such that it
messes with GDT. This can be mitigated by checking the lapic MSR
against the current program counter.
Change-Id: I49927c4f4218552b732bac8aae551d845ad7f079
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There is no reason to do this in a separate loop.
Change-Id: I7fe9f1004597602147aae72f4b754395b6b527cf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63473
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch delays removing `temporary` MTRR snapshots to avoid conflicts
with other operations attached with same `BS_PAYLOAD_BOOT/BS_ON_EXIT`
boot state.
BUG=b:225766934
TEST=Having variable MTRR snapshot using display_mtrrs() is able to
list only the permanent MTRRs and all temporary MTRRs are removed
prior to boot to payload.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I602dca989745159d013d6573191861b296f5d3ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch replaces the implementation that is used to get the number of
variable MTRRs with `get_var_mtrr_count()` function.
BUG=b:225766934
TEST=Able to build and boot google/redrix board to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4751add9c45374e60b7a425df87d06f52e6fcb8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch migrates a few useful MTRR functions as below from
`earlymtrr.c` file to newly created common stage file `mtrrlib.c`.
1. get_free_var_mtrr
2. set_var_mtrr
3. clear_all_var_mtrr
These functions can be used to perform the MTRR programming from IA
common code SPI driver as `fast_spi.c` without requiring two separate
implementations for early boot stage (till romstage) and for ramstage
onwards.
BUG=b:225766934
TEST=Able to build and boot google/redrix board to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2c62a04a36d3169545c3128b4231992ad9b3699d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
When rebuilding coreboot the empty fit table added to added to CBFS
stays the same so the build process sees no reason to update the file.
In the meantime ifittool did update that file for instance to add
microcode update entries. So each time coreboot is rebuilt the entries
are appended to the FIT table which runs out of space at some point.
One way to deal with this is to clear the fit table when setting the
pointer inside the bootblock.
TESTED: Now running 'make' again on prodrive/hermes does not report an
error with a filled FIT table.
Change-Id: Ia20a489dc90a4ae704e9ee6d532766899f83ffcc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63036
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change provides hooks for the SoC so it can perform any
initialization and cleanup in the SMM handler.
For example, if we have a UART enabled firmware with DEBUG_SMI, the UART
controller could have been powered off by the OS. In this case we need
to power on the UART when entering SMM, and then power it off before we
exit. If the OS had the UART enabled when entering SMM, we should
snapshot the UART register state, and restore it on exit. Otherwise we
risk clearing some interrupt enable bits.
BUG=b:221231786, b:217968734
TEST=Build test guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I946619cd62a974a98c575a92943b43ea639fc329
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change will allow the SMI handler to write to the cbmem console
buffer. Normally SMIs can only be debugged using some kind of serial
port (UART). By storing the SMI logs into cbmem we can debug SMIs using
`cbmem -1`. Now that these logs are available to the OS we could also
verify there were no errors in the SMI handler.
Since SMM can write to all of DRAM, we can't trust any pointers
provided by cbmem after the OS has booted. For this reason we store the
cbmem console pointer as part of the SMM runtime parameters. The cbmem
console is implemented as a circular buffer so it will never write
outside of this area.
BUG=b:221231786
TEST=Boot non-serial FW with DEBUG_SMI and verified SMI messages are
visible when running `cbmem -1`. Perform a suspend/resume cycle and
verify new SMI events are written to the cbmem console log.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia1e310a12ca2f54210ccfaee58807cb808cfff79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
