This patch changes the vboot EC sync code to use the new CBFS API. As a
consequence, we have to map the whole EC image file at once (because the
new API doesn't support partial mapping). This should be fine on the
only platform that uses this code (Google_Volteer/_Dedede family)
because they are x86 devices that support direct mapping from flash, but
the code was originally written to more carefully map the file in
smaller steps to be theoretically able to support Arm devices.
EC sync in romstage for devices without memory-mapped flash would be
hard to combine with CBFS verification because there's not enough SRAM
to ever hold the whole file in memory at once, but we can't validate the
file hash until we have loaded the whole file and for performance (or
TOCTOU-safety, if applicable) reasons we wouldn't want to load anything
more than once. The "good" solution for this would be to introduce a
CBFS streaming API can slowly feed chunks of the file into a callback
but in the end still return a "hash valid/invalid" result to the caller.
If use cases like this become pressing in the future, we may have to
implement such an API.
However, for now this code is the only part of coreboot with constraints
like that, it was only ever used on platforms that do support
memory-mapped flash, and due to the new EC-EFS2 model used on more
recent Chrome OS devices we don't currently anticipate this to ever be
needed again. Therefore this patch goes the easier way of just papering
over the problem and punting the work of implementing a more generic
solution until we actually have a real need for it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7e263272aef3463f3b2924887d96de9b2607f5e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52280
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
RETURN_FROM_VERSTAGE is a somewhat tricky construct that we don't
normally do otherwise in coreboot. While it works remarkably well in
general, new development can lead to unintentional interactions with
confusing results. This patch adds a debug print to the verstage right
before returning to the bootblock so that it's obvious this happens,
because otherwise in some cases the last printout in the verstage is
about some TPM commands which can be misleading when execution hangs
after that point.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9ca68a32d7a50c95d9a6948d35816fee583611bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52086
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using brackets here seems to break the build for _some_ environments.
Removing the brackets fixes it and works just fine.
Change-Id: I965b0356337fe74281e7f410fd2bf95c9d96ea93
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51974
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Deomid "rojer" Ryabkov <rojer9@fb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The PCR algorithms used for vboot are frequently causing confusion (e.g.
see CB:35645) because depending on the circumstances sometimes a
(zero-extended) SHA1 value is interpreted as a SHA256, and sometimes a
SHA256 is interpreted as a SHA1. We can't really "fix" anything here
because the resulting digests are hardcoded in many generations of
Chromebooks, but we can document and isolate it better to reduce
confusion. This patch adds an explanatory comment and fixes both
algorithms and size passed into the lower-level TPM APIs to their actual
values (whereas it previously still relied on the TPM 1.2 TSS not
checking the algorithm type, and the TPM 2.0 TSS only using the size
value for the TCPA log and not the actual TPM operation).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib0b6ecb8c7e9a405ae966f1049158f1d3820f7e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This add an option to generate BPM using the 9elements bg-prov tool
using a json config file.
A template for the json config file can be obtained via
"bg-prov template".
Another option is to extract it from a working configuration:
"bg-prov read-config".
The option to just include a provided BPM binary is kept.
Change-Id: I38808ca56953b80bac36bd186932d6286a79bebe
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50411
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is useful if you have external infrastructure to sign KM.
Change-Id: If5e9306366230b75d97e4e1fb271bcd7615abd5f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51572
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an option to generate the Key Manifest from Kconfig options.
Change-Id: I3a448f37c81148625c7879dcb64da4d517567067
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50410
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This add an option to generate KM using the 9elements bg-prov tool
using a json config file.
The option to just include a provided KM binary is kept.
A template for the json config file can be obtained via
"bg-prov template".
Another option is to extract it from a working configuration:
"bg-prov read-config".
Change-Id: I18bbdd13047be634b8ee280a6b902096a65836e4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50409
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Private and/or public keys will be provided as user input via Kconfig.
As a private key also contains the public key, only ask what is required.
Change-Id: I86d129bb1d13d833a26281defad2a1cb5bf86595
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Make sure the bytes in RTC cmos used by CBNT don't collide with the
option table. This depends on what is set up in the BPM, Boot Policy
Manifest. When the BPM is provided as a binary the Kconfig needs to be
adapted accordingly. A later patch will use this when generating the
BPM.
Change-Id: I246ada8a64ad5f831705a4293d87ab7adc5ef3aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With CBnT a digest needs to be made of the IBB, Initial BootBlock, in
this case the bootblock. After that a pointer to the BPM, Boot Policy
Manifest, containing the IBB digest needs to be added to the FIT
table.
If the fit table is inside the IBB, updating it with a pointer to the
BPM, would make the digest invalid.
The proper solution is to move the FIT table out of the bootblock.
The FIT table itself does not need to be covered by the digest as it
just contains pointers to structures that can by verified by the
hardware itself, such as microcode and ACMs (Authenticated Code
Modules).
Change-Id: I352e11d5f7717147a877be16a87e9ae35ae14856
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50926
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In pursuit of the eventual goal of removing cbfs_boot_locate() (and
direct rdev access) from CBFS APIs, this patch replaces all remaining
"simple" uses of the function call that can easily be replaced by the
newer APIs (like cbfs_load() or cbfs_map()). Some cases of
cbfs_boot_locate() remain that will be more complicated to solve.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icd0f21e2fa49c7cc834523578b7b45b5482cb1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch removes the prog_locate() step for stages and rmodules.
Instead, the stage and rmodule loading functions will now perform the
locate step directly together with the actual loading. The long-term
goal of this is to eliminate prog_locate() (and the rdev member in
struct prog that it fills) completely in order to make CBFS verification
code safer and its security guarantees easier to follow. prog_locate()
is the main remaining use case where a raw rdev of CBFS file data
"leaks" out of cbfs.c into other code, and that other code needs to
manually make sure that the contents of the rdev get verified during
loading. By eliminating this step and moving all code that directly
deals with file data into cbfs.c, we can concentrate the code that needs
to worry about file data hashing (and needs access to cbfs_private.h
APIs) into one file, making it easier to keep track of and reason about.
This patch is the first step of this move, later patches will do the
same for SELFs and other program types.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia600e55f77c2549a00e2606f09befc1f92594a3a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In both the Kconfig and Makefile in this directory,
"STM_TTYS0_BASE" is used. Therefore, fix the typo.
Change-Id: Ie83ec31c7bb0f6805c0225ee7405e137a666a5d3
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51206
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add marshaling and unmarshaling support for cr50 vendor sub-command to
reset EC and a interface function to exchange the same.
BUG=b:181051734
TEST=Build and boot to OS in drawlat. Ensure that when the command is
issued, EC reset is triggered.
Change-Id: I46063678511d27fea5eabbd12fc3af0b1df68143
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change allows VBOOT to build when the mainboard hasn't implemented
any of the VBOOT functions yet.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I42ca8f0dba9fd4a868bc7b636e4ed04cbf8dfab0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50341
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds the missing `GBB_FLAG_ENABLE_UDC` as a config in
vboot/Kconfig (just like the other GBB flags) and uses its value to
configure GBB_FLAGS Makefile variable. This is done to allow the
mainboard to configure GBB flags by selecting appropriate configs in
Kconfig.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I6b397713d643cf9461294e6928596dc847ace6bd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50110
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
They all operate on that file, so just add it globally.
Change-Id: I953975a4078d0f4a5ec0b6248f0dcedada69afb2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Target added to INTERMEDIATE all operate on coreboot.pre, each modifying
the file in some way. When running them in parallel, coreboot.pre can be
read from and written to in parallel which can corrupt the result.
Add a function to create those rules that also adds existing
INTERMEDIATE targets to enforce an order (as established by evaluation
order of Makefile.inc files).
While at it, also add the addition to the PHONY target so we don't
forget it.
BUG=chromium:1154313, b:174585424
TEST=Built a configuration with SeaBIOS + SeaBIOS config files (ps2
timeout and sercon) and saw that they were executed.
Change-Id: Ia5803806e6c33083dfe5dec8904a65c46436e756
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49358
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This functionality only exists on legacy TXT.
Change-Id: I4206ba65fafbe3d4dda626a8807e415ce6d64633
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
intel_txt_memory_has_secret() checks for ESTS.TXT_ESTS_WAKE_ERROR_STS
|| E2STS.TXT_E2STS_SECRET_STS and it looks like with CBNT the E2STS
bit can be set without the ESTS bit.
Change-Id: Iff4436501b84f5c209add845b3cd3a62782d17e6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47934
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION
feature. It's not useful to end-users in this stage so it cannot be
selected in menuconfig (and should not be used other than for
development) yet. With this patch coreboot can verify the metadata hash
of the RO CBFS when it starts booting, but it does not verify individual
files yet. Likewise, verifying RW CBFSes with vboot is not yet
supported.
Verification is bootstrapped from a "metadata hash anchor" structure
that is embedded in the bootblock code and marked by a unique magic
number. This anchor contains both the CBFS metadata hash and a separate
hash for the FMAP which is required to find the primary CBFS. Both are
verified on first use in the bootblock (and halt the system on failure).
The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes
to show some paths that need to be different when full protection
against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For
normal verification it is sufficient to check the FMAP and the CBFS
metadata hash only once in the bootblock -- for TOCTOU verification we
do the same, but we need to be extra careful that we do not re-read the
FMAP or any CBFS metadata in later stages. This is mostly achieved by
depending on the CBFS metadata cache and FMAP cache features, but we
allow for one edge case in case the RW CBFS metadata cache overflows
(which may happen during an RW update and could otherwise no longer be
fixed because mcache size is defined by RO code). This code is added to
demonstrate design intent but won't really matter until RW CBFS
verification can be supported.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfs_boot_locate() is supposed to be deprecated eventually, after slowly
migrating all APIs to bypass it. That means common features (like
RO-fallback or measurement) need to be moved to the new
cbfs_boot_lookup().
Also export the function externally. Since it is a low-level API and
most code should use the higher-level loading or mapping functions
instead, put it into a new <cbfs_private.h> to raise the mental barrier
for using this API (this will make more sense once cbfs_boot_locate() is
removed from <cbfs.h>).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4bc9b7cbc42a4211d806a3e3389abab7f589a25a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds a new CBFS "mcache" (metadata cache) -- a memory buffer
that stores the headers of all CBFS files. Similar to the existing FMAP
cache, this cache should reduce the amount of SPI accesses we need to do
every boot: rather than having to re-read all CBFS headers from SPI
flash every time we're looking for a file, we can just walk the same
list in this in-memory copy and finally use it to directly access the
flash at the right position for the file data.
This patch adds the code to support the cache but doesn't enable it on
any platform. The next one will turn it on by default.
Change-Id: I5b1084bfdad1c6ab0ee1b143ed8dd796827f4c65
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function is no longer required to be implemented since
EC/AUXFW sync was decoupled from vboot UI. (See CL:2087016.)
BUG=b:172343019
TEST=Compile locally
BRANCH=none
Signed-off-by: Joel Kitching <kitching@google.com>
Change-Id: I43e8160a4766a38c4fa14bcf4495fc719fbcd6c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Actual support CBnT will be added later on.
Change-Id: Icc35c5e6c74d002efee43cc05ecc8023e00631e0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46456
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generally, this size probably doesn't matter very much, but in the
case of picasso's psp_verstage, the hash is being calculated by
hardware using relatively expensive system calls. By increasing the
block size, we can save roughly 140ms of boot and resume time.
TEST=Build & boot see that boot time has decreased.
BRANCH=Zork
BUG=b:169217270 - Zork: SHA calculation in vboot takes too long
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I68eecbbdfadcbf14288dc6e849397724fb66e0b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Provide necessary romstage hooks to allow unblocking the memory with
SCLEAN. Note that this is slow, and took four minutes with 4 GiB of RAM.
Tested on Asrock B85M Pro4 with tboot. When Linux has tboot support
compiled in, booting as well as S3 suspend and resume are functional.
However, SINIT will TXT reset when the iGPU is enabled, and using a dGPU
will result in DMAR-related problems as soon as the IOMMU is enabled.
However, SCLEAN seems to hang sometimes. This may be because the AP
initialization that reference code does before SCLEAN is missing, but
the ACM is still able to unblock the memory. Considering that SCLEAN is
critical to recover an otherwise-bricked platform but is hardly ever
necessary, prefer having a partially-working solution over none at all.
Change-Id: I60beb7d79a30f460bbd5d94e4cba0244318c124e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
SCLEAN has specific requirements and needs to run in early romstage,
since the DRAM would be locked when SCLEAN needs to be executed.
Change-Id: I77b237342e0c98eda974f87944f1948d197714db
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This is consistent with how other binaries (e.g. FSP) are added via
Kconfig. This also makes it more visible that things need to be
configured.
Change-Id: I399de6270cc4c0ab3b8c8a9543aec0d68d3cfc03
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Kconfig variables are used in the C code for cbfs file names but
not in the Makefiles adding them.
Change-Id: Ie35508d54ae91292f06de9827f0fb543ad81734d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Julius Werner