Previously ramdetect.c was compiled only for VENDOR_EMULATION.
Hence add Kconfig option PROBE_RAM which allows board outside
the scope of VENDOR_EMULATION to select and utilize probe_ram
function to runtime detect usable RAM in emulation environment.
PROBE_RAM is default selected if VENDOR_EMULATION is set so
that existing boards under VENDOR_EMULATION scope are not
affected.
Other boards can explicitly select PROBE_RAM to use probe_ram.
TEST=Build mb/arm/rdn2 with PROBE_RAM selected & make sure
there is no any error.
Also checked qemu-aarch64 build to make sure build is success.
Change-Id: Id909ddaee6958cfa8a6c263a11f9a90d94710aa7
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79450
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
To quote its repo[0]: Wuffs is a memory-safe programming language (and
a standard library written in that language) for Wrangling Untrusted
File Formats Safely. Wrangling includes parsing, decoding and encoding.
It compiles its library, written in its own language, to a C/C++ source
file that can then be used independently without needing support for
the language. That library is now imported to src/vendorcode/wuffs/.
This change modifies our linters to ignore that directory because
it's supposed to contain the wuffs compiler's result verbatim.
Nigel Tao provided an initial wrapper around wuffs' jpeg decoder
that implements our JPEG API. I further changed it a bit regarding
data placement, dropped stuff from our API that wasn't ever used,
or isn't used anymore, and generally made it fit coreboot a bit
better. Features are Nigel's, bugs are mine.
This commit also adapts our jpeg fuzz test to work with the modified
API. After limiting it to deal only with approximately screen sized
inputs, it fuzzed for 25 hours CPU time without a single hang or
crash. This is a notable improvement over running the test with our
old decoder which crashes within a minute.
Finally, I tried the new parser with a pretty-much-random JPEG file
I got from the internet, and it just showed it (once the resolution
matched), which is also a notable improvement over the old decoder
which is very particular about the subset of JPEG it supports.
In terms of code size, a QEmu build's ramstage increases
from 128060 bytes decompressed (64121 bytes after LZMA)
to 172304 bytes decompressed (82734 bytes after LZMA).
[0] https://github.com/google/wuffs
Change-Id: If8fa7da69da1ad412f27c2c5e882393c7739bc82
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Based-on-work-by: Nigel Tao <nigeltao@golang.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78271
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This uses the size attribute to traverse the possible string.
This patch traverses the entire property for non printable characters
and not just until the first 0 is hit.
Now numbers that start with a zero (memory wise) are not falsely
recognized as strings:
before the patch:
clock-frequency = "";
after the patch:
clock-frequency = < 0x1c2000 >;
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I229c07b76468fe54f90fa9df12f103d7c7c2859d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch sets the default locales to English for platforms that
do not have support for VBOOT configuration. This ensures that the
system will use English locales if the platform does not provide
its own locale settings.
TEST=Built and booted the google/rex platform successfully.
Change-Id: I7554c8bfd58411f460deeb22cf7218059ca8ba9f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79054
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a fixup to CB:78914 which inadvertently broke the RK3288 SoC.
Unfortunately we can only accommodate very little PRERAM_CBFS_CACHE in
the tiny SRAM for that chip, so we would not be able to map an entire
FMAP. Solve this problem for now by mapping less space when CBFS
verification is disabled, and disallowing CBFS verification on that SoC.
Change-Id: I2e419d157dc26bb70a6dd62e44dc6607e51cf791
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Now that VBOOT_CBFS_INTEGRATION exists, it is possible to use
TOCTOU_SAFETY with VBOOT.
Change-Id: I9f84574f611ec397060404c61e71312009d92ba7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78915
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When the FMAP cache is enabled, it cannot fail in pre-RAM stages unless
flash I/O in general doesn't work. Therefore, it is unnecessary and a
waste of binary size to also link a fallback path for this case.
Similarly, once the cache is written to CAR/SRAM/CBMEM there should be
no way for it to become magically corrupted between boot stages. Many
other parts of coreboot blindly assume that persistent memory stays
valid between stages so there is no reason why this code should link in
extra fallback paths in case it doesn't.
This saves a little over 200 bytes per affected (uncompressed) stage on
aarch64.
Change-Id: I7b8251dd6b34fe4f63865ebc44b9a8a103f32a57
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78904
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A recent security audit has exposed a TOCTOU risk in the FMAP
verification code: if the flash returns a tampered FMAP during the first
setup_preram_cache(), we will abort generating the cache but only after
already filling the persistent CAR/SRAM region with the tampered
version. Then we will fall back into the direct access path, which could
succeed if the flash now returns the original valid FMAP. In later
stages, we will just use the data from the persistent CAR/SRAM region as
long as it looks like an FMAP without verifying the hash again (because
the hash is only linked into the initial stage).
This patch fixes the issue by just calling die() immediately if FMAP
hash verification fails. When the verification fails, there's no
recourse anyway -- if we're not dying here we would be dying in
cbfs_get_boot_device() instead. There is no legitimate scenario where
it would still be possible to continue booting after this hash
verification fails.
Change-Id: I59ec91c3e5a59fdd960b0ba54ae5f15ddb850480
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78903
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The rarely-used fallback path for accessing the FMAP without a cache
currently only maps the FMAP header for the initial verify_fmap() call.
This used to be fine when we were just checking the magic number, but
with CBFS verification we may need to hash the entire FMAP.
Since this path is so rarely used anyway and the size difference only
has a practical impact on a few platforms, lets keep things simple and
just always map the whole FMAP.
Change-Id: Ie780a3662bf89637de93a36ce6e23f77fed86265
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78914
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code was written in a romcc bootblock time. There is no reason why
it would not work in bootblock now.
Untested but expected to work.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I708e8a3b503eb3a7fdf6063803d666529096f651
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The macro ENV_HAS_CBMEM achieves the same as this inline function.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6d65ca51c863abe2106f794398ddd7d7d9ac4b5e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77166
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `RAMSTAGE_CBFS_CACHE_SIZE' Kconfig to
set a ramstage CBFS cache size. A cache size of zero disables the
CBFS cache feature. The default size is 16 KB which seems a
reasonable minimal value large enough to satisfy basic needs such as
the decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
To support S3 suspend/resume use-case, the CBFS cache memory cannot be
released to the operating system. There are two options to meet this
requirement:
1. Define a static CBFS cache buffer (located in the .bss section)
2. Create a new CBMEM entry
Option #2 seems more powerful but considering that:
1. The CBFS cache is actually not a cache but just a scratch pad
designed to be isolated between stages
2. postcar is a very short stage not really needing CBFS cache
3. The static initialization of the `cbfs_cache' global
variable (cf. src/lib/cbfs.c) offers a simple and robust design
=> It is simpler to use a static buffer and limit the support to
ramstage.
Since some AMD SoCs (cf. `SOC_AMD_COMMON_BLOCK_NONCAR' Kconfig) define
a `_cbfs_cache' region, an extra `POSTRAM_CBFS_CACHE_IN_BSS' Kconfig
must be set to enable the use of a static buffer as the CBFS cache
scratchpad.
TEST=Decompression of vbt.bin in ramstage on rex using cbfs_map()
Change-Id: I7fbb1b51cda9f84842992e365b16c5ced1010b89
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77885
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With commit b7832de026 ("x86: Add .data
section support for pre-memory stages"), this comment is not correct
anymore and should be removed.
Change-Id: I61597841cd3f90cebe7323a68738f91d6d64b33d
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
With commit b7832de026 ("x86: Add .data
section support for pre-memory stages"), the `ENV_HAS_DATA_SECTION'
flag and its derivatives can now be removed from the code.
Change-Id: Ic0afac76264a9bd4a9c93ca35c90bd84e9b747a2
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77291
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
We only checked that the resource fits below the given `limit` in
memranges_find_entry(), but then accidentally placed it at the top
of the found memrange. As most resources have only a coarse limit,
e.g. the 4G barrier of 32-bit space, this became only visible when
artificially setting an unusual, lower limit on a resource.
So, for the final placement, use `MIN(limit, range end)` instead
of the range's end alone.
Change-Id: I3cc62ac3d427683c00ba0ac9f991fca62e99ce44
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: Iad9cbe16a2d1881d74edcc702be843168df8a4ff
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I3d716b29d8e28584a0c9e4056d4c93dca2873114
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76780
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce new parsing rules for ux_locales.c:ux_locales_get_text():
* Add a version byte: PRERAM_LOCALES_VERSION_BYTE in the beginning. This
provides more flexibility if we want to change the format of
preram_locales region.
* Add a new delimiter 0x01 between two string_names. This could fix the
issue that 'string_name' and 'localized_string' might be the same.
Also fix two bugs:
1. We would search for the language ID exceeding the range of current
string_name.
2. In 'move_next()', we would exceed the 'size' due to the unconditional
increase of offset.
Finally, make some minor improvements to some existing comments.
BUG=b:264666392, b:289995591
BRANCH=brya
TEST=emerge-brya coreboot chromeos-bootimage
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: Ic0916a0badd7071fa2c43ee9cfc76ca5e79dbf8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
In the JPEG decoder, use `bytes_per_line` instead of `width` for
address calculations, to allow for bigger framebuffers. When
calling jpeg_decode(), add an offset to the framebuffer address
so the picture gets centered.
Change-Id: I0174bdccfaad425e708a5fa50bcb28a1b98a23f7
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
In VBOOT_STARTS_IN_ROMSTAGE=y case, vboot_run_logic() did not
get called when postcar was loaded from TSEG stage cache on
ACPI S3 resume path. Resume failed as MP init attempts to
access microcode update from unverified FW_MAIN_A/B section.
In a similar fashion, for POSTCAR=n, loading ramstage from
TSEG stage cache would bypass the call to vboot_run_logic().
TEST=samsung/lumpy with VBOOT_STARTS_IN_ROMSTAGE=y is able
to complete S3 resume.
Change-Id: I77fe86d5fd89d22b5ef6f43e65a85a4ccd3259d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The function ux_locales_get_text() should expect to have a correct
preram_locales region to read, hence we need to adjust the log levels
inside lib/ux_locales.c:ux_locales_get_text():
* If the region does not exist or is not in a correct format, we should
print in BIOS_ERR
* If the arguments are not correct but we have a good workaround (e.g.
the lang_id from vboot API seems weird), we should print in
BIOS_WARNING.
Also change some minor syntax issues.
BUG=b:264666392, b:289995591
BRANCH=brya
TEST=emerge-brya coreboot chromeos-bootimage
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: Ic8a8856c883f6ca78fed69542a7d388f57c5c508
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76316
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
BIOS Vendor in SMBIOS Type 0 would be who built the firmware so create a
config string with default "coreboot" to make it changeable. Vendors
could update it by adding a Kconfig in the site-local directory.
Change-Id: I6dfcca338ffc48b150c966b9aefcefe928704d24
Signed-off-by: Yiwei Tang <tangyiwei.2022@bytedance.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75737
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Commit d054bbd4f1 ("Makefile.inc: fix multiple jobs build issue")
added a dependency on $(obj)/fmap_config.h to all .c source files in all
stages, so it's not needed any more to add it as a dependency to files
that include fmap_config.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b62917f32ae9f51f079b243a606e5db07ca9099
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76002
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
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>
SMBIOS is not specific to architecture, and this is mostly a generic
implementation. Therefore, move it to common code, having
architecture-specific code define some functions to fill this data.
Change-Id: I030c853f83f8427da4a4c661b82a6487938b24e6
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75886
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch adds a new Kconfig that controls whether CBFS APIs for
unverified areas will allow file decompression when CBFS verification is
enabled. This should be disallowed by default because it exposes the
attack surface of all supported decompression algorithms. Make
allowances for one legacy use case with CONFIG_SOC_INTEL_CSE_LITE_
COMPRESS_ME_RW that should become obsolete with VBOOT_CBFS_INTEGRATION.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ieae420f51cbc01dae2ab265414219cc9c288087b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75457
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move fw_config_is_provisioned() implementation to header file and make
it static inline.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I2ea21b19339cd93ba78dbe25213cbfb40e012937
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
To support the localized text, we need to get the locale id by vboot
APIs and read raw string content file: preram_locales located at either
RO or RW.
The preram_locales file follows the format:
[string_name_1] [\x00]
[locale_id_1] [\x00] [localized_string_1] [\x00]
[locale_id_2] [\x00] [localized_string_2] ...
[string_name_2] [\x00] ...
This code will search for the correct localized string that its string
name is `memory_training_desc` and its locale ID matches the ID vb2api
returns. If no valid string found, we will try to display in English
(locale ID 0).
BUG=b:264666392
BRANCH=brya
TEST=emerge-brya coreboot chromeos-bmpblk chromeos-bootimage
Change-Id: I7e3c8d103c938a11b397c32c9228e44e31c3f01d
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add newlines to log messages to prevent them from running into each
other.
Change-Id: I4f61c80385f384a3734a5122ccb4161c1ed7c6c5
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75589
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
During the cleanup of copyright lines, this file was incorrectly changed
to remove the copyright line. It is not originally a part of the
coreboot project, having been pulled in and adapted for use in coreboot.
As such, and with the ISC license specifying that the copyright line
should be maintained, the copyright line has been restored.
See coreboot ticket # 479 for more information.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia234cebd0a6d49d03e40c5a57cd346a07f3e4b09
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Traditionally, display init during vboot "verified/secure/normal
boot mode" relies on the VB2_CONTEXT_DISPLAY_INIT. This is the
default behavior for vboot, meaning skip display init during verified
boot mode.
However, if the intention is to show the OEM splash screen (using
BMP_LOGO config) during boot, then the policy enforced by vboot needs
to be overridden. This can be done by setting the BMP_LOGO config flag.
If BMP_LOGO is not enabled, then the vboot policy will be followed and
display init will be skipped.
This change was made to allow OEMs to show their splash screen during
boot, even if the system is in verified/secure/normal mode.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ice1f02ad5c02a6a7e74a97ed23c5f11c7ecfb594
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75197
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
These strings are now only expanded in lib/identity.c.
This improves ccache hit rates slightly, as one built object file
lib/version.o is used for all variants of a board. Also one built
object file lib/identity.o can become a ccache hit for successive
builds of a variant, while the commit hash changes.
Change-Id: Ia7d5454d95c8698ab1c1744e63ea4c04d615bb3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
CXL (Compute Express Link) [1] is a cache-coherent interconnect
standard for processors, memory expansion and accelerators.
CXL memory is provided through CXL device which is connected
through CXL/PCIe link, while regular system memory is provided
through DIMMs plugged into DIMM slots which are connected to
memory controllers of processor.
With CXL memory, the server's memory capacity is increased.
CXL memory is in its own NUMA domain, with longer latency
and added bandwidth, comparing to regular system memory.
Host firmware may present CXL memory as specific purpose memory.
Linux kernel dax driver provides direct access to such differentiated
memory. In particular, hmem dax driver provides direct access to
specific purpose memory.
Specific purpose memory needs to be represented in e820 table as
soft reserved, as described in [2].
Add IORESOURCE_SOFT_RESERVE resource property to indicate (memory)
resource that needs to be soft reserved.
Add soft_reserved_ram_resource macro to allow soc/mb code to add
memory resource as soft reserved.
[1] https://www.computeexpresslink.org/
[2] https://web.archive.org/web/20230130233752/https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.32&id=262b45ae3ab4bf8e2caf1fcfd0d8307897519630
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Ie70795bcb8c97e9dd5fb772adc060e1606f9bab0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52585
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
TCPA usually refers to log described by TPM 1.2 specification.
Change-Id: I896bd94f18b34d6c4b280f58b011d704df3d4022
Ticket: https://ticket.coreboot.org/issues/423
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Previously, LZMA was included in romstage because it was almost always
needed to decompress ramstage. When compressing ramstage with LZ4, but
using LZMA compression for FSP-M, we still need the LZMA decompression
to be present, so update when the Makefile includes the LZMA decoder.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Id52d25a13420f05db8b2b563de0448f9d44638e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When ramstage is loaded asynchronously, as on the skyrim boards, the
faster decompression of LZ4 allows for faster boot times than the
tighter compression of LZMA.
To make this change, the name of the existing ramstage_compression
option needs to be updated.
BUG=b:264409477
TEST=Boot skyrim, look at boot speed
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I27dd1a8def024e0efd466cef9ffd9ca71717486a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71673
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There seem to be some recurring vague concerns about the alignment of
coreboot table entries. While the existing implementation has been
producing tables with a well-defined alignment (4 bytes) for a long
time, the code doesn't always make it very clear. This patch adds an
explicit constant to codify that alignment, assertions to check it after
each entry, and adds explicit padding to the few entry structures that
were relying on compiler padding to return a correct sizeof() value.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaeef29ef255047a855066469e03b5481812e5975
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70158
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
Move a "NOTE" message from BIOS_DEBUG to BIOS_NOTICE log level.
Change-Id: If92c1ccb5b10a4b29a5006a41ebd0855294f354e
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69498
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Adapted from WIP (and abandoned) patch CB:25334, this patch:
1. Ensures SSP endpoint InstanceId is 0
2. Adds capability_size parameter at the end of the nhlt
3. Adsd more config_type enum values to accommodate feedback stream
4. Programs virtual_slot values for max98373, max98927,
and rt5514 nhlt files
5. Adds NHLT feedback_config parameters
Default feedback configs are added here to the max98373, max98927, and
rt5514 codecs; in a follow-on patch, these will be overridden at the
board level.
TEST=tested with subsequent patch
Change-Id: I59285e332de09bb448b0d67ad56c72a208588d47
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
It's hidden behind the configuration option `CONFIG_ROMSTAGE_LIBHWBASE'.
This also adds some glue code to use the coreboot console for debug
output and our monotonic timer framework as timer backend.
Running Ada code in romstage and more particular libhwbase brings a few
challenges as global initialized variables are not supported in
Cache-As-Ram mode.
1. The libhwbase dynamic mmio driver implementation makes the Gnat
compiler generate some global initialized variables.
For this reason, when compiled for romstage or for romstage and
ramstage the static mmio driver is enforced (`HWBASE_STATIC_MMIO').
2. The Gnat compiler generates elaboration functions to initialize
program data at runtime. These elaboration functions are called by
the romstage_adainit() function.
The data references symbols suffixed by `_E'. Even though these
symbols, at compilation time, do not contain any data and are
filled with zeros, the Gnat compiler installs them in the .data
section.
Since these symbols are actually filled with zeros, it is safe to
install them in the .bss section.
cf. https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/elaboration_order_handling_in_gnat.html#elaboration-code
This patch requires the libhwbase
https://review.coreboot.org/c/libhwbase/+/69854 CL.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=libhwbae compiles for romstage and loads successfully
Change-Id: I670249d33506e886a683e55d1589cb2bf9b16aa3
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70275
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If selected, libgnat is linked into romstage. In addition, a call to
romstage_adainit() is added to support Ada program data
initialization.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=Ada code compiles for romstage and loads successfully
Change-Id: I74f0460f6b14fde2b4bd6391e1782b2e5b217707
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70274
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In some cases, fw_config is used for ids like sar_id, sku_id etc.
To avoid calling fw_config_probe over and over, hence provide the
method to return the value then caller can use the switch case
instead of if else statement.
TEST=get fw_config field value on nivviks.
[INFO ] fw_config get field name=DB_USB, mask=0x3, shift=0, value =0x1
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Iae89668e8fe7322d5a4dcbf88a97d7ed36619af5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70745
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
