| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds support for showing different logos on the ChromeOS
firmware splash screen based on the device model (between
Chromebook-Plus and regular ChromeOS devices like Chromebook and
Chromebox). This allows OEMs to customize the branding on their
devices.
This patch also introduces three new Kconfigs:
- CHROMEOS_FW_SPLASH_SCREEN
- CHROMEOS_LOGO_PATH
- CHROMEBOOK_PLUS_LOGO_PATH
which allow users to enable the fw splash screen feature in the
vendorcode. Previously, we were using the BMP_LOGO Kconfig in
drivers/intel/fsp2_0, but we didn't want the top level Kconfigs to be
located inside the architecture specific files.
BUG=b:317880956
BRANCH=None
TEST=emerge-rex coreboot chromeos-bootimage
verify that FW splash screen appears
Change-Id: I56613d1e7e81e25b31ad034edae0f716c94c4960
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79775
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
When caching the ramstage for suspend/resume, we copy the entire image
as it resides in RAM. The last part of that, CONFIG_HEAP_SIZE bytes, is
the heap that will be reinitialized when the ramstage is started again.
As such, copying doesn't make sense and complicates HEAP_SIZE
configuration (because it needs to fit the space-constrained cache
location) and costs time and space. Therefore, skip the heap.
Side notes:
- When building with ASAN, program.ld indicates that it will allocate
some more space after the heap. This is not a problem, we just copy
an ASAN-sized copy of the heap.
- Heap use is managed in src/lib/malloc with statically allocated
variables. Because ramstage is cached before it's executed, these
values will be reset to their compile-time default values, too.
Change-Id: I6553dc8b758196f2476af2e692c0421d0fa2b98e
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79525
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
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>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I926ec4c1c00339209ef656995031026935e52558
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77637
Reviewed-by: Eric Lai <ericllai@google.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 b7832de0260b042c25bf8f53abcb32e20a29ae9c ("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 b7832de0260b042c25bf8f53abcb32e20a29ae9c ("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 d054bbd4f1ba ("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>
|
|
Only expand these strings in lib/identity.o.
Change-Id: I8732bbeff8cf8a757bf32fdb615b1d0f97584585
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74907
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
Change-Id: I7d0718b5d2e0dd16eb90f63dd9d33329a2d808ba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
|
|
'pragma Compiler_Unit_Warning' is removed upstream:
https://gcc.gnu.org/git/?p=gcc.git&a=search&h=HEAD&st=commit&s=pragma+Compiler_Unit_Warning
Fix:
GCC libgnat-x86_32/lib/gnat/interfac.o
interfac.ads:36:08: warning: unrecognized pragma "Compiler_Unit_Warning" [-gnatwg]
Change-Id: I6d7efab132441dd3cc62a53b7322e9fd355e5059
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73162
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Change-Id: I87e383ce2f28340dbc3c843dbf2ed0e47c00a723
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
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>
|
|
Change-Id: I63abe019490f72bd73bcdbddb974aff2b2bfd803
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70473
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: Ic64625bdaf8c4e9f8a5c1c22cece7f4070012da7
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69903
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It is no longer necessary to explicitly add "Warning" in front of
BIOS_WARNING message.
Change-Id: I6e4341555a3b03a531bd94ba5e36cbcadda9c663
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69624
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Get rid of a lot of casts.
Change-Id: I93645ef5dd270905ce421e68e342aff4c331eae6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
|
|
coreboot already has a ram failure post code defined, but the ram test
functions weren't using it, and were using 0xea instead.
This changes those failures to display 0xe3, the value defined in
post_codes.h by POST_RAM_FAILURE.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I21ef196e48ff37ffe320b575d6de66b43997e7eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69202
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
This patch introduces support signing and verification of firmware
slots using CBFS metadata hash verification method for faster initial
verification. To have complete verification, CBFS_VERIFICATION should
also be enabled, as metadata hash covers only files metadata, not their
contents.
This patch also adapts mainboards and SoCs to new vboot reset
requirements.
TEST=Google Volteer/Voxel boots with VBOOT_CBFS_INTEGRATION enabled
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I40ae01c477c4e4f7a1c90e4026a8a868ae64b5ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66909
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=none
TEST=Able to build and boot Google, Rex SKU2 (Micron LPDDR5x
MT62F1G32D2DS-026).
Without this code change:
[INFO ] SPD: module type is UNKNOWN
With this code change:
[INFO ] SPD: module type is LPDDR5X
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: If620cf51133ca295fd3f1cbecbb472beb337b9fc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69226
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
By convention 'fill_lb_xxx' is used.
Change-Id: I046016b3898308bb56b4ad6a5834ab942fdd50f2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69183
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of having callbacks into serial console code to set up the
coreboot table have the coreboot table code call IP specific code to get
serial information. This makes it easier to reuse the information as the
return value can be used in a different context (e.g. when filling in a
FDT).
This also removes boilerplate code to set up lb_console entries by
setting entry based on the type in struct lb_uart.
Change-Id: I6c08a88fb5fc035eb28d0becf19471c709c8043d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68768
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
CBFS verification on boards where VBOOT starts before bootblock eg. PSP
verstage has been accommodated by keeping metadata hash outside the
bootblock. Hence the dependency can be removed.
BUG=b:227809919
TEST=Build and boot to OS in skyrim with CBFS verification enabled using
both x86 verstage and PSP verstage.
Change-Id: I0a3254728a51a8ee7d7782afcea15ea06d93da7d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66947
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
On boards where vboot starts before bootblock, build metadata_hash in
verstage. This will allow to enable CBFS verification for such
platforms.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled using
x86 verstage and PSP verstage.
Change-Id: I4269069b66ed66c7b1a47fdef2fd0a8054b2e6a1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68134
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Only edk2 used this to fill in a different struct but even there the
entries go unused, so removing this struct element from coreboot has
no side effects.
Change-Id: Iadd2678c4e01d30471eac43017392d256adda341
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
Some platform run early stages like romstage and verstage from CAR
instead of XIP. This allows to link them like other arch inside the
_program region. This make in place LZ4 decompression possible as it
needs a bit of extra place to extract the code which is now provided by
the .bss.
Tested on up/squared (Intel APL).
Change-Id: I6cf51f943dde5f642d75ba4c5d3be520dc56370a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48156
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I80f3d2c90c58daa62651f6fd635c043b1ce38b84
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The decompression is critical for speed of boot. So we sacrifice some
generated code size to optimize for speed.
This change speeds up the LZMA decompression between 3% and 6% at a
cost of just over 2k of additional code space.
BUG=b:223985641
TEST=Majolica
The test is done on Majolica and the result is listed below.
Time saved:
We tested the boot time with each flag for 10 times. The duration of
each decompression process is listed as below.
Load FSP-M Load ramstage Load payload
Ofast Os Ofast Os Ofast Os
------------------------------------------
62543 62959 20585 22458 9945 10626
62548 62967 20587 22461 9951 10637
62560 62980 20588 22478 9951 10641
62561 62988 20596 22478 9954 10643
62569 62993 20596 22479 9954 10643
62574 63000 20605 22492 9958 10647
62575 63026 20615 22495 9959 10647
62576 63038 20743 22614 9960 10647
62587 63044 20758 22625 9961 10647
62592 63045 20769 22637 9961 10647
-----------------------------------------
average 62568 63004 20644 22521 9955 10642
(unit: microseconds)
Size sacrificed:
The size of object file with -Os:
./build/ramstage/lib/lzmadecode.o: file format elf32-i386
4 .text.LzmaDecode 00000d84 00000000 00000000 00000076 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
The size of object file with -Ofast:
./build/ramstage/lib/lzmadecode.o: file format elf32-i386
4 .text.LzmaDecode 00001719 00000000 00000000 00000080 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
(Output by running "objdump -h ./build/ramstage/lib/lzmadecode.o")
We can see that size is increased from 3460 bytes to 5913 bytes, a
change of 2453 bytes or 171%.
Change-Id: Ie003164e2e93ba8ed3ccd207f3af31c6acf1c5e2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I00e9636fa49c402f38119ba0bfc85c8c193fec12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68052
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Ibacf704d362eecea3f7216ffcb02c2ef6f9a6d8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
The timer_sched_callback function signature was changed in timer.h as
part of commit d522f38c7bfccdc4af71bcad133aec20096f3f6c (timer: Change
timer util functions to 64-bit) but the implementation was not updated
to match.
TEST=Enable timer queue and build
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ie00b027790131f42bd79fbc6ea400a056e67949b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67767
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Since mono_time is now 64-bit, the utility functions interfacing with
mono_time should also be 64-bit so precision isn't lost.
Fixed build errors related to printing the now int64_t result of
stopwatch_duration_[m|u]secs in various places.
BUG=b:237082996
BRANCH=All
TEST=Boot dewatt
Change-Id: I169588f5e14285557f2d03270f58f4c07c0154d5
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Add xxhash functions. This is a very fast hash function, running at RAM
speed limits.
This code was adapted from the linux kernel with minor modifications to
make it fit in coreboot.
BUG=b:193557430
TEST=compile
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I8108af5ab14d8e6c6f5859bd36155c7d254e892c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Add option to resource allocator v4 that restores the top-down
allocation approach at the domain level.
This makes it easier to handle 64-bit resources natively. With
the top-down approach, resources that can be placed either above
or below 4G would be placed above, to save precious space below
the 4G boundary.
Change-Id: Iaf463d3e6b37d52e46761d8e210034fded58a8a4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41957
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
CL:3825558 changes all vb2_digest and vb2_hash functions to take a new
hwcrypto_allowed argument, to potentially let them try to call the
vb2ex_hwcrypto API for hash calculation. This change will open hardware
crypto acceleration up to all hash calculations in coreboot (most
notably CBFS verification). As part of this change, the
vb2_digest_buffer() function has been removed, so replace existing
instances in coreboot with the newer vb2_hash_calculate() API.
Due to the circular dependency of these changes with vboot, this patch
also needs to update the vboot submodule:
Updating from commit id 18cb85b5:
2load_kernel.c: Expose load kernel as vb2_api
to commit id b827ddb9:
tests: Ensure auxfw sync runs after EC sync
This brings in 15 new commits.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I287d8dac3c49ad7ea3e18a015874ce8d610ec67e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
|
|
This adds SPDX identifiers to the remaining source files in the
lib directory that don't already have them.
A note on gcov-iov.h - As machine generated content, this file is
believed to be uncopyrightable, and therefore in the public domain, so
gets the CC-PDDC license even though there is code in the file.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Ifcb584d78a55e56c1b5c02d424a7e950a7f115dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
This allows the compiler to optimize out code called after run_ramstage.
Also remove some die() statements in soc code as run_ramstage already
has a die_with_postcode statement.
Change-Id: Id8b841712661d3257b0dc67b509f97bdc31fcf6f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Aligning the "memory" ranges in devicetree is supposedly only needed on
very old arm32 kernels. So let's get rid of it.
Incidentally this fixes smaller than 1MB memory regions where the size
would end up being 0.
Change-Id: Ibbf5e331c79ed4ae3ed8dd37bf7a974d2412ce12
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
With a combined bootblock+romstage ENV_ROMSTAGE might no
longer evaluate true.
Change-Id: I733cf4e4ab177e35cd260318556ece1e73d082dc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63376
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
There are too many "FIT" in firmware land. In order to reduce possible
confusion of CBFS_TYPE_FIT with the Intel Firmware Interface Table, this
patch renames it to CBFS_TYPE_FIT_PAYLOAD (including the cbfstool
argument, so calling scripts will now need to replace `-t fit` with `-t
fit_payload`).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I826cefce54ade06c6612c8a7bb53e02092e7b11a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.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>
|
|
On some x86 targets it the bootblock is loaded via a different
mechanism, like via the AMD PSP or Intel IFWI. Some payloads need that
pointer so add it to cbfs.
Note that on Intel APL this file is not used, which is why the
bootblock still needs to contain the pointer in the ARCH_X86 part.
It is not worth it to add logic to specifically deal with APL as this is
a legacy feature anyway.
For AMD non-car platform this fixes cbfs access in SeaBIOS.
Change-Id: If46e80e3eed5cc3f59964ac58e507f927fc563c4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
There are efforts to have bootflows that do not follow a traditional
bootblock-romstage-postcar-ramstage model. As part of that CBMEM
initialisation hooks will need to move from romstage to bootblock.
The interface towards platforms and drivers will change to use one of
CBMEM_CREATION_HOOK() or CBMEM_READY_HOOK(). Former will only be called
in the first stage with CBMEM available.
Change-Id: Ie24bf4e818ca69f539196c3a814f3c52d4103d7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Add 'lb_fill_pcie' function to pass PCIe information from coreboot to
libpayload, and add CB_ERR_NOT_IMPLEMENTED to the cb_err enum for the
__weak function.
ARM platform usually does not have common address for PCIe to access the
configuration space of devices. Therefore, new API is added to pass the
base address of PCIe controller for payloads to access PCIe devices.
TEST=Build pass and boot up to kernel successfully via SSD on Dojo
board, here is the SSD information in boot log:
== NVME IDENTIFY CONTROLLER DATA ==
PCI VID : 0x15b7
PCI SSVID : 0x15b7
SN : 21517J440114
MN : WDC PC SN530 SDBPTPZ-256G-1006
RAB : 0x4
AERL : 0x7
SQES : 0x66
CQES : 0x44
NN : 0x1
Identified NVMe model WDC PC SN530 SDBPTPZ-256G-1006
BUG=b:178565024
BRANCH=cherry
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: I6cdce21efc66aa441ec077e6fc1d5d1c6a9aafb0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
|
|
Builds are failing sporadically with:
src/lib/master_header_pointer.c:5:10: fatal error: fmap_config.h: No such file or directory
5 | #include <fmap_config.h>
| ^~~~~~~~~~~~~~~
Correct the filename in the Makefile from header_pointer.c to
master_header_pointer.c so that there's a dependency from
master_header_pointer.c to fmap_config.h.
Change-Id: I41bcb2a21fdbc48f09d5b6be3e211ca56607d849
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64431
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use 'ENV' consistently and drop the redundant 'STAGE' in the naming.
Change-Id: I51f2a7e70eefad12aa214e92f23e5fd2edf46698
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64296
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Demote log level from error to notice. People should aware the SPD
decode might be wrong if it's not the support type.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I55f0968b78baaa2fc9a6bbebf6712fb8bfd349f6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Some targets don't need this as the bootblock is loaded differently.
Change-Id: Ia42448f7e9dd0635c72857fbc1fab54508932721
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
The makefiles don't like cbfs file names with spaces in them so update
the file name with '_' instead of spaces. To keep the master header at
the top of cbfs, add a placeholder.
This removes the need to handle the cbfs master header in cbfstool.
This functionality will be dropped in a later CL.
On x86 reserve some space in the linker script to add the pointer.
On non-x86 generate a pointer inside a C struct file.
As a bonus this would actually fix the master header pointer mechanism
on Intel/APL as only the bootblock inside IFWI gets memory mapped.
TESTED on thinkpad X201: SeaBIOS correctly finds the cbfs master
header.
Change-Id: I3ba01be7da1f09a8cac287751497c18cda97d293
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
BUG=b:229437061
TEST=Not seeing default msg "Defaulting to using DDR4 params." with
this CL.
Signed-off-by: Scott Chao <scott_chao@wistron.corp-partner.google.com>
Change-Id: I98ba9e87b1a093b93434334a75c9a9252effa933
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
hardwaremain.c is the common ramstage entry to all platforms so move
out ACPI code generation (x86 specific) to boot state hooks.
Another reason to do this is the following:
On some platforms that start in dram it makes little sense to have
separate stages. To reduce the complexity we want to call the ramstage
main function instead of loading a full stage. To make this scheme
more maintainable it makes sense to move out as much functionality
from the 'main' function as possible.
Change-Id: I613b927b9a193fc076ffb1b2a40c617965ce2645
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63414
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>
|
|
Change-Id: Ib1257c57c64322c8c3dccdf1a754afb9b54ce7f8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
If a combo bootblock+romstage was created, it may
not have ENV_ROMSTAGE set, while the timestamp of
(embedded) romstage should remain in its place.
Change-Id: I713732a291b6a6c0d8fcb23266f765fd33816db8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I9fb22ff647f824872dc35648bb4b5078f0cbde96
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <martinroth@google.com>
|
|
Unused <stdlib.h> found using:
diff <(git grep -l '#include <stdlib.h>' -- src/) <(git grep -l 'memalign(\|malloc(\|calloc(\|free(' -- src/)
Change-Id: I5ad171679cbfa67d522bd1105fb58e0f84b9cb89
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <martinroth@google.com>
|
|
Change-Id: Ie874fe2c023157fad0adc021faa45e70822208da
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63711
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Treat dimm addr_map 0 non-existent. addr_map default is 0, we don't set
it if Hw is not present. Also change the test case default to avoid 0.
SODIMM SMbus address 0x50 to 0x53 is commonly used.
BUG=b:213964936
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot chromeos-bootimage
The MRC training does not be performed again after rebooting.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I2ada0109eb0805174cb85d4ce373e2a3ab7dbcac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Replace 'struct lb_uint64' with 'typedef __aligned(4) uint64_t
lb_uint64_t', and remove unpack_lb64/pack_lb64 functions since it's no
longer needed.
Also replace 'struct cbuint64' with 'cb_uint64_t' and remove
'cb_unpack64' in libpayload for compatible with lb_uint64_t.
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: If6b037e4403a8000625f4a5fb8d20311fe76200a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Prevents bad things from happening later when these new nodes are used.
This issue is hard to observe because:
1. Heap is zero-initialized, so you need to use allocated memory
filling it with non-zero values, free, allocate it again, use
uninitialized.
2. Most of allocated memory is not freed.
3. Implementation of free() does something only for one last malloc'ed
block, making most of freed memory unavailable for future
allocation.
Change-Id: I38a7ec1949d80f7a2564fac380ce94de6056a0c7
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62928
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
If the DRAM part number is not available in the SPD data (meaning filled
with 0x00) do not print it in the log.
Change-Id: If7224c6e114731b1c03915a2bde80f57369d0cee
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This is passing through a cb_err from cbfs_prog_stage_load(), so it
should be declared to return that as well.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I5510d05953fe8c0e2cb511f01f862b66ced154ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62656
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
