Update the values of CB_MEM_TAG and LB_MEM_TAG from 7 to 17. This change
is necessary to avoid conflicts with the ACPI System Address Map
Interfaces specification.
Change-Id: I802cd724b8f330a9f814fb952ab824cfc23c0e67
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90676
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds the option to compress ramstage and payloads with zstd.
zstd compressed ramstages are typically +5% bigger than lzma compressed
ramstages. The decompressor .text section grows by 20KiB and the
decompressor needs 16KiB more heap than the lzma decompressor.
To use less heap inside the zstd decompressor the build time define
ZSTD_DECODER_INTERNAL_BUFFER is used.
Quote:
The build macro `ZSTD_DECODER_INTERNAL_BUFFER` can be set to control
the amount of extra memory used during decompression to store
literals. This defaults to 64kB. Reducing this value reduces the
memory footprint of `ZSTD_DCtx` decompression contexts, but might
also result in a small decompression speed cost
TEST=Booted on Lenovo X220 with zstd ramstage showed no disadvantage
over a bigger internal buffer used.
TEST=Booted on Lenovo X220. The zstd decompressor is twice as fast
as the lzma decompressor.
cbmem -t shows:
- finished ZSTD decompress (ignore for x86) 79,444 (24,494)
- finished LZMA decompress (ignore for x86) 94,971 (45,545)
TEST=Booted on QEMU Q35, QEMU aarch64 virt, QEMU riscv RV64 with
zstd compressed ramstage.
Change-Id: Ic1b1f53327c598d07bd83d4391e8012d41696a16
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69893
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds zstd support to cbfstool. The code is taken from zstd-1.5.7
with modifications:
- renaming bits.h to zstd_bits.h to avoid conflicts with coreboot's
bits.h used on riscv
- renaming compiler.h to zstd_compiler.h to avoid conflicts with
coreboot's compiler.h
- Dropped all streaming API functions
- Dropped multithreaded support, since it's now unused
- Dropped local DDict support
zstd offers similar compression ratios to LZMA, but a vastly fast
decompress speed. Typically zstd results in slightly larger binaries
than LZMA. Whether zstd should then be preferred over LZMA depends on
a few things:
- Caching: When loading from memory mapped boot devices, zstd will read
the boot medium multiple times, while LZMA will not. If the memory
mapped boot medium is not cached zstd results in much slower
decompression.
- Boot medium speed: Often, but not always LZMA results in smaller
binaries. If the boot medium is the bottleneck, than loading smaller
binaries might actually be faster. On a fast boot medium (high spi
freq, using quad/dual io), the performance benefits from zstd might be
more substantial
- zstd decompression code has a much larger footprint than LZMA. If the
stage (postcar) is loaded in uncached memory the size increase might
slow things down.
On QEMU Q35 postcar .text section size doubled, while heap section
has growen by 50%.
- zstd uses a lot of .bss (CTX is about 32KiB large). This might not be
available in some environments.
Orignal commit from 2022 was using zstd-1.5.2. Updated to zstd-1.5.7.
Change-Id: I34508268f8767008ef25cb9e466d201345881232
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69753
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the xxhash lib to commonlib/bsd folder so that it can be
easily included by tools. Update use of standard headers to
allow compilation on POSIX compatible systems as well.
Use the new xxhash lib in cbfstool over the existing duplicated
xxhash lib residing in lz4/lib.
Change-Id: I21041409d5b734cecf43294dcaf3bf17531dbc15
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89682
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Armv9-A architecture introduces the Memory Tagging Extension (MTE),
which uses a dedicated memory region for tag storage.
This patch adds a new memory type, BM_MEM_TAG, to allow for the proper
accounting and reservation of this memory region. This ensures that the
payload, e.g. depthcharge, can correctly identify and utilize the tag
storage area.
BUG=b:438666196
Change-Id: I2f6d2b3c2c1a8e1f0e9b2c3d4e5f6a7b8c9d0e1f
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90470
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
GCC generates correct code for __builtin_bswapXX() on all architectures,
including ArmV4. It seems that whatever bug caused this to not work back
in commit 879ea7fce8 ("endian: Replace explicit byte swapping with
compiler builtin") has been fixed now. We can eliminate the swabXX()
functions and simplify the code.
All instances that had been calling these functions directly should have
been using real endianness conversions anyway.
Change-Id: I19713fd009aa5c0e01c4a42e0cf012364d6bed60
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90438
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
We've accumulated a number of endianness-handling and related macros
that are duplicated between coreboot and libpayload. This patch reduces
duplication by merging them into a commonlib header. This has the added
side-benefit of bringing the coreboot implementation of beXXenc/dec()
functions to libpayload, which lead to better code generation by
avoiding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716.
Keep the htobell()-style functions in libpayload only since they're not
needed in coreboot and not preferred. Keep the cpu_to_beXX()-style
functions in coreboot only -- maybe we should deprecate those
eventually.
This patch is explicitly copying and relicensing some of the code I
originally added as GPLv2 in commit e8e92d60c4 ("endian.h: Add
be32dec/be32enc family of functions") to BSD-3.
Change-Id: I5eb83d44a98b3aa59bba65b8e22df668874d2668
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90308
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current code doesn't make much sense. The offset created by the
skipping of NOP tokens is just ignored.
Reorder the lines to skip the NOP tokens first.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I860a57e4a773b634149e84271b8322d78ac20e32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some silcon initialization modules may provide more detailed
information about the DIMMs, like type details or voltages.
Extend the memory_info structure with type_detail and max/min
voltage. Use the new fields when producing SMBIOS tables if their
value is non-zero. Otherwise, keep previous behavior.
Change-Id: I01ae8ea1f5a8fec53e151c040d893376c3d23be2
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89483
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a new CBMEM ID, CBMEM_ID_BOOT_MODE (0x444D5442, "BTMD"),
to provide a dedicated storage location for the system's detected
boot mode (e.g., normal boot, low-battery, off-mode boot etc).
Storing the boot mode in CBMEM ensures that the initial detection
performed early in the boot process (e.g., in romstage by reading
PMIC logs) is securely passed to subsequent stages like ramstage,
where different boot modes require distinct logic paths.
Key changes:
- Define CBMEM_ID_BOOT_MODE in cbmem_id.h.
- Add "BOOT MODE" entry to the CBMEM_ID_TO_NAME_TABLE.
BUG=b:439819922
TEST=Verify boot mode stored in CBMEM.
Change-Id: I7ebf29385a99ac1be491bfefe1c74c8c9e58b55d
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90175
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
memory_info with dimm_info entries is available as CBMEM_ID_MEMINFO.
Moving the structures definitions to the commonlib allows the payloads
to easily access the memory information.
BUG=b:450374306
TEST=Build and boot Google/Brya
Change-Id: I25e788d5afd668e93f8ea60adaefb7b8b5d5ec28
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch adds new timestamp IDs to track the execution flow within
the Qualcomm QCLib and the loading of the Secure OS (BL32) by the ARM
Trusted Firmware (TFA).
The following new IDs are introduced:
- TS_QUALCOMM_QCLIB_INIT_START (980)
- TS_QUALCOMM_QCLIB_INIT_END (981)
- TS_QUALCOMM_QCLIB_REINIT_START (982)
- TS_QUALCOMM_QCLIB_REINIT_END (983)
- TS_TFA_LOAD_BL32_START (998)
- TS_TFA_LOAD_BL32_END (999)
The reserved ID ranges are updated to accommodate these new vendor-
specific and architecture-specific timestamps:
- Intel/FSP range reduced from 950-989 to 950-980.
- A new range 980-990 is allocated for qualcomm/qclib.
- The Intel ME continued range is updated from 990-999 to 990-997.
- A new range 998-999 is allocated for ARM Trusted Firmware.
Change-Id: I904ac36862212a86961383dfe5e9b0f7ef0f02ea
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90111
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Extend the lb_framebuffer_flags struct to include one more bitfield
'has_dual_pipe' to indicate dual pipe support.
TEST=firmware display ok, in depthcharge with https://crrev.com/c/7129839
BRANCH=none
BUG=b:424782827
Change-Id: I082be80b4606090ed219820a407d80d9f429ea7e
Signed-off-by: Nancy Lin <nancy.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90038
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add dt_is_overlay() API to check whether the input devicetree is
actually an overlay DT. Payload will use this API when parsing an input
image which is a collection of base and overlay devicetree blobs.
BUG=b:394980221
TEST=Build firmware image for Rauru/Hylia and boot to OS. Ensure that
the API correctly identifies the base and overlay DTs.
Change-Id: I2fc54e3d9e63ebc993c8ce6a7d4a7224a9251497
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90028
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We have a hard alignment to LB_ENTRY_ALIGN (4). We check for an
alignment of 4 bytes at the beginning of each lb_record. But since it
was 8 byte aligned, it was also automatically 4 byte aligned.
It therefore wasn't detected by coreboot.
This will break payload implementations that rely on the 8 byte
alignment for this specific struct. But since lb_smmstorev2 has only
been recently updated in commit 5bf88a44e9 ("drivers/smmstore:
Support 64-bit MMIO addresses"), one can only hope that no payloads
were updated to this yet.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ib6171b7d4bd08b8a1559833ddb048644ff082b73
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit 668ea97075.
Let's just keep using --param=min-pagesize=1024 in xcompile to sweep
the -Warray-bounds warnings under the rug in the coreboot tree.
Change-Id: I0f76c27bcbaac9d0927160fcab9cbf9aaefa9095
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89915
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit cfdaff3f70.
Let's just keep using --param=min-pagesize=1024 in xcompile to sweep
the -Warray-bounds warnings under the rug in the coreboot tree.
Change-Id: I875cb140aacd44f1aaddd410de0f154af585b1c1
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89914
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add 2 new timestamps for measuring the time to generate pKVM
deterministic random number generator seed in depthcharge.
First indicate when the generation has started and
a second when the setup is complete.
BUG=b:449097147
TEST=builds
Change-Id: I1bced5a331e4d10a1ec1c305b9b2a41d1e913579
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89872
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
commit 668ea970 ("commonlib/endian: Silence GCC -Warray-bounds false
positives") added `#pragma GCC diagnostic ignored "-Warray-bounds"` but
forgot to restore the diagnostic state at the end of the file.
Change-Id: I41b38758ce862490777ede63ff92d95d6ba21521
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89867
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Recent GCC versions (>=12) warn about out-of-bounds accesses when
writing through *(volatile uint8_t *)dest in endian.h.
This is a false positive since these pointers intentionally alias
hardware/physical memory.
Change-Id: Ia47aa1214998dbc17bd4a58f7d996bcc6fff7b6a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89328
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
*information* does not have plural, so use *This* instead of *These*.
Change-Id: I966373371cac4edd681f3b503e5f3a637fc28913
Fixes: a45c8441af ("lib: Add boot mode information to coreboot tables")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89227
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`dt_add_reg_prop` and the newly introduced `dt_add_iommu_addr_prop`
share identical logic for building the binary data buffer, differing
only in the property name written to the Device Tree. Therefore,
refactor the shared logic into a new static helper function,
`dt_add_addr_and_size_prop`.
The existing `dt_add_reg_prop` is converted to a wrapper around this new
helper.
`dt_add_iommu_addr_prop` is introduced as a separate wrapper to
specifically add the `iommu-addresses` property. This property defines
reserved IOVA ranges or identity-mapped regions, such as a display
framebuffer configured by the bootloader. It is typically utilized
within the `reserved-memory` subsystem.
BUG=b:435289727
TEST=The below translation fault does not occur.
[ 0.171028] arm-smmu-v3 30800000.iommu: TBU_id-2-fault_id:0x2000008(0x8), TF read in NORMAL world, iova:0xa3000000, sid:144, ssid:0, ssidv:0, secsidv:0
Change-Id: Icedcce5681a7b659b11b7e7208663bc1d920ce3b
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89152
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit introduces a new constant, ELOG_WAKE_SOURCE_PME_BLUETOOTH,
with the value 0x31 to represent Bluetooth as a wake source in the ELOG
event data structure. This change facilitates diagnostics and
event logging related to Bluetooth activity.
The cbfstool eventlog has been updated to include "PME - BLUETOOTH" in
the wake source types for event data printing.
Change-Id: Ib628502ddcccb4a781394a39b2aee6efa05ecf84
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
This change introduces `LB_TAG_BOOT_MODE` to the coreboot tables to
convey platform boot information to the payload. The new `lb_boot_mode`
struct uses `enum boot_mode_t` to specify whether the device is booting
in `normal mode`, `low-battery mode` or `off-mode charging`.
This is crucial for platforms where the Application Processor (AP)
manages the charging solution, as it provides the necessary context for
the payload's charger driver. By passing this data through the coreboot
table, we avoid redundant implementation and ensure consistent battery
and charging information is available across both coreboot and the
payload.
A new weak function, `lb_add_boot_mode`, is also introduced. This
function can be overridden by platforms that require this data to add
the boot mode information to the coreboot table.
TEST=Able to build and boot google/quenbi.
Change-Id: I5aea72c02b4d6c856e2504f4007de584c59ee89f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88992
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
When the passed `blob` is not a valid FDT, the memory allocated for
`tree` should be freed. Move the allocation after the fdt_is_valid()
check to avoid the problem.
Also remove the unnecessary cast to 'const struct fdt_header *'.
Change-Id: If591172cd511ae2a1ca9c26f2addef8d67fd0b69
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88948
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
With the introduction of the stack canary breakpoint QEMU uncovered
a different bug within coreboot. Currently the compiler optimizes
over aggressively inline functions and memory stores.
That also affects write_at_ble8(), which is supposed to store a
single byte at time. The compiler however optimizes multiple byte
stores into a single wider (and possibly unaligned) store operation.
This can be seen in the emited assembly code of write_le16(), as used
to install the EBDA:
401348a: 66 c7 04 25 13 04 00 movw $0x400,0x413
4013491: 00 00 04
Make sure that the compiler does not optimize multiple calls to
write_at_ble8() by adding the volatile qualifier.
The emitted assembly code of the same function changes to:
401394c: c6 04 25 13 04 00 00 movb $0x0,0x413
4013953: 00
4013954: c6 04 25 14 04 00 00 movb $0x4,0x414
401395b: 04
Fixes a strange bug in QEMU where it triggers the DEBUG breakpoint
handler on unaligned 16-bit stores in the first 4KiB of memory.
Aligned stores and store outside of the first 4KiB do not dispatch
the DEBUG breakpoint handler.
Change-Id: Ibbc661235a38c7f7540b656a67f067c3e51105d1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add 3 new timestamps for measuring the time to setup pvmfw in
depthcharge. First indicate when the setup has started. Second when the
comm with GSC has finished and third when the setup is complete.
BUG=b:429115233
BUG=b:359340876
TEST=build rauru
Change-Id: I0e0d069ae85997d3e4c02f257cd801e7b6787762
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Adds a new flags field to the lb_spi_flash coreboot table to indicate
if the SPI flash is operating in 4-byte address mode.
This allows payloads to query the current address mode directly from the
coreboot table, preventing redundant checks or re-enforcement of the
mode. The flag is set based on the
CONFIG_SPI_FLASH_FORCE_4_BYTE_ADDR_MODE configuration.
Important: `erase_cmd` was reduced from uint32_t to uint8_t.
Only the least significant byte was ever relevant, so this change
ensures accurate type representation, maintains backward compatibility
with existing coreboot table structures, and frees up space.
BUG=b:417900125
TEST=Able to build google/bluey.
Change-Id: I406536432b2a0c7f4108e5b33d5a20c272d917b0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
GCC 15 added a new `unterminated-string-initialization` warning. Even
though crossgcc is still using GCC 14, some Linux distributions (e.g.
Arch Linux) already started shipping GCC 15. Given that coreboot uses
`-Werror` (warnings are errors), this new warning causes build errors
for things built using the host toolchain, such as utilities. In this
case, cbfstool is affected, which prevents building coreboot images.
The nonstring attribute is used to tell the compiler whether or not a
string is intentionally not null terminated. Since the attribute is
only included in GCC 15 for multidimensional character arrays (and even
later for clang) we need to check the GCC version before using the
attribute.
On GCC version prior to GCC 15 the nonstring attribute will not be used,
but that is not a problem since the unterminated-string-initialization
warning only exists since GCC 15. So you can still build on all GCC
versions as before. This way it also works if your host toolchain is GCC
15 (which builds commonlib code for cbfstool) and your coreboot cross
toolchain is GCC 14 (which builds commonlib code for coreboot).
Clang is a diffent matter. According to the documentation, the nonstring
attribute only exists in version 21 which is not yet released by LLVM.
TEST=Build qemu/Q35 successfully
Change-Id: I919d71cb2811e91869ba1ff493a0719ddcc86c36
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87825
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Follow the recommendation at
https://review.coreboot.org/c/coreboot/+/84796/comment/21f615a2_99a41147/
and implement support for reading integer properties generically, using
their size to determine how much to read. This will be used for reading
`load`, `entry` and perhaps others.
Change-Id: I02d27eb5e23dfbfc1404d209ee8d60968e22bb80
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85643
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds a new timestamp, `TS_FIRMWARE_SPLASH_RENDERED`
(ID 557), to precisely mark the moment the firmware splash screen has
finished displaying.
The timestamp is recorded in `src/drivers/intel/fsp2_0/silicon_init.c`
within the `do_silicon_init` function. It's conditionally added based on
the platform's configuration:
- For platforms using FSP's native BMP rendering (prior to FSP 2.2, with
`CONFIG(BMP_LOGO)` and without
`CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`).
- For platforms where coreboot handles BMP rendering (`CONFIG(BMP_LOGO)`
and `CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`).
This enhancement provides better visibility into the boot process and
allows for more accurate performance analysis related to splash screen
display time.
BUG=b:418935715
TEST=Able to build and boot google/fatcat. Verified below details in
`cbmem -t`.
```
557:Firmware splash screen rendering finished 47,193,590 (2,235)
```
Change-Id: Ibef967dbc6e224741438e9708b42486ba03d0104
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87812
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
dt_find_node() looks up nodes specified by the `const char **path`
array, without modifying the strings in the array. Therefore, the char
pointers in the array could be changed to const.
Change-Id: I8d330e78d0977bae54996bb622190f6546fcb59f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Currently the SMMSTOREv2 only supports MMIO ROM below 4GiB. As the
space below 4GiB is typically limited on x86, add support for extended
MMIO ROM windows as found on recent hardware.
Allow the SMMSTOREv2 to be memory mapped above 4GiB by adding a new
field to the coreboot table called 'mmap_addr'. The users outside
of coreboot must check the size field of the coreboot struct to
determine if mmap_addr is supported. When it is it holds the
64-bit physical address to the MMIO ROM window.
The old 'mmap_addr' was renamed to 'mmap_addr_deprecated' to indicate
that it should not be used any more.
Change-Id: I1131cfa5cdbf92bbd33de3e5b22a305136eec9f7
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87114
Reviewed-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
This commit introduces a new timestamp `TS_DEVICE_INIT_CHIPS` to
specifically mark the start of the `dev_initialize_chips()` function.
Previously, the `TS_DEVICE_ENUMERATE` timestamp was incorrectly
associated with the `bs_dev_init_chips` function.
This patch corrects this by:
- Adding the `TS_DEVICE_INIT_CHIPS` enum and name definition.
- Updating `bs_dev_init_chips` in `src/lib/hardwaremain.c` to use
`TS_DEVICE_INIT_CHIPS`.
- Moving the `TS_DEVICE_ENUMERATE` timestamp addition to the
`bs_dev_enumerate` function where device enumeration actually begins.
This change provides a more accurate and meaningful timestamp for the
early chipset initialization phase.
TEST=Able to build and boot google/fatcat.
```
971:loading FSP-S 836,277 (10,658)
17:starting LZ4 decompress (ignore for x86) 847,297 (11,019)
18:finished LZ4 decompress (ignore for x86) 847,376 (79)
30:early chipset initialization 854,579 (7,203)
17:starting LZ4 decompress (ignore for x86) 863,483 (8,903)
18:finished LZ4 decompress (ignore for x86) 863,490 (6)
17:starting LZ4 decompress (ignore for x86) 875,196 (11,705)
18:finished LZ4 decompress (ignore for x86) 875,237 (41)
954:calling FspSiliconInit 875,344 (107)
955:returning from FspSiliconInit 942,740 (67,396)
962:calling FspMultiPhaseSiInit 942,744 (4)
963:returning from FspMultiPhaseSiInit 1,081,355 (138,610)
31:device enumeration 1,081,708 (352)
40:device configuration 1,085,721 (4,013)
50:device enable 1,091,517 (5,795)
```
Change-Id: Ib6860901c6b1528ec5098fc93240c6e65777642b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Add an allocation of an empty buffer for the Android protected virtual
machine firmware within cbmem. The buffer will be filled by the payload
and the purpose is to just reserve the memory. cbmem is used to make
sure that the region won't overlap with other reserved regions
or device regions.
BUG=b:354045389
BUG=b:359340876
TEST=depthcharge receives the buffer through lib_sysinfo
BRANCH=main
Change-Id: I48efc033ac0f5fbfcf3a52fabf40be016cd4c6f7
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When CONFIG_PCI is disabled, but COMMONLIB_STORAGE and
COMMONLIB_STORAGE_SD are enabled, the compilation of
pci_sdhci.c fails. This is because the code attempts to use
pci_s_read_config32() with the PCI_BASE_ADDRESS_0 macro, which
are only defined when CONFIG_PCI is enabled.
Add an early return NULL check based on !CONFIG(PCI) at the
beginning of new_pci_sdhci_controller(). This prevents the
compiler from attempting to process the PCI-specific code path
when PCI support is not configured, resolving the build failure
in this specific Kconfig scenario.
TEST=Able to build herobrine.
Change-Id: I5c70d9b9ebcac13b47bba2c260fdf2ad7d56d4d7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit renames the cbmem ID from CBMEM_ID_FSP_LOGO to
CBMEM_ID_BMP_LOGO.
This change:
- Standardizes the naming to reflect the actual content, which is a
BMP logo.
- Removes the FSP-specific prefix, making the ID more generic and
suitable for use in the common library.
- Aligns the code with the recent Kconfig changes that moved BMP_LOGO
related options to the common library.
BUG=b:400738815
TEST=Able to build and boot google/brox.
Change-Id: I838d4e6ad0efdef063f2cc78bb83d1d37e065f45
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
QEMU has a maximum of 512 of emulated harts supported.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I149c8d8a43733c8ba3e02a84b0a3606d98f8b2c1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Carlos López <carlos.lopezr4096@gmail.com>
This commit adds a new event type, `ELOG_TYPE_LOW_BATTERY_INDICATOR`,
to the event log. This event is logged when the system boots due to
a low battery condition. It includes the reason for the shutdown,
currently only supporting "Power Off".
BUG=b:339673254
TEST=Able to capture the eventlog for low battery boot event.
```
> elogtool list
9 | 2025-02-03 09:44:19+0530 | Low Battery Boot | Power Off
```
Change-Id: I5cc5e5f540657c7dfd174a4928e697a272da813a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This commit adds support for minimum/maximum limit values as well as
step sizes for CFR number options. Additionally, add a new flag that
specifies the option should be displayed in hexadecimal notation instead
of decimal.
Change-Id: I2e70f1430fb1911f1ad974832f8abfe76f928ac3
Signed-off-by: Filip Brozovic <fbrozovic@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Implements a way for CFR options to depend on another option
being set to one or more specific values. This is achieved
by writing a list of values as a varbinary struct.
Change-Id: Iaf7965551490969052eb27c207fa524470d4dd6a
Signed-off-by: Filip Brozovic <fbrozovic@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85987
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a version field to the CFR root struct so parsers can check
compatibility when parsing structs.
Change-Id: Ifcb950f1bdedc0ab925f3841befb7e7001c0f7f4
Signed-off-by: Filip Brozovic <fbrozovic@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86080
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
dt_find_node() calls dt_read_cell_props() for every node it walks, but
this is only actually necessary when the caller is interested in the
`#address-cells` and `#size-cells` values and passed out-parameters to
receive them. Most callers don't actually do that, and we scan through
all properties needlessly on every node. This patch adds a fast path to
skip that.
Change-Id: I114f824a7d88b0bac4a96aca3f7dced459503b02
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85989
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
This patch wraps `dt_find_node()` in a function that initializes the
addr_cells and size_cells values to the defaults provided in the FDT
specification before potentially updating them from found values, so
that we always return the correct result and remove the burden of
correctly initializing them from the caller.
Change-Id: I39ba2c82d3a0d0b39a2ed5eba2420a04fbccb2f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85988
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
In Flattened Device Trees, there exist special properties called
`#address-cells` and `#size-cells` that determine how large addresses
and sizes in `reg` properties are. According to the FDT specification,
each `reg` node cares about the `...cells` property in the _parent_ of
its node. Our current implementation looks for those properties in the
node it finds and returns, which would presumably be the node with the
`reg` property itself. Therefore, we're returning the wrong `...cells`
values.
This isn't really a problem in practice because we also allow inheriting
these properties from the parent when they don't exist in the child, and
nodes that contain `reg` properties usually don't contain `...cells`
properties themselves (because those properties would be incorrect and
useless there), so we usually just end up falling back to the (correct)
value we inherited from the parent. But it's still better to just fix
the mistake, and if we ever happen to have a situation where the node
containing the `reg` property still has children that require different
`...cells` values as well, it could make a difference. (The fact that
we're inheriting these properties is also technically incorrect
according to the spec, but we're doing that intentionally to match
behavior in the Linux kernel.)
This issue was already correctly implemented in the recently added
fdt_find_node() from commit 33079b8174 ("lib/device_tree: Add some FDT
helper functions"), and this patch also fixes it in the older
dt_find_node().
Change-Id: I323066477a4d4be17225e0915a81ce2ff39c1e40
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85964
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Fix some typos and also update the naming convention of
`CFR_OPTFLAG_GRAYOUT` to `CFR_OPTFLAG_INACTIVE` as per reviews.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Id66808382b93e32c58024462c18b20c2a89d6d23
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
This patch enhances the readability of the CSE sync event
ELOG_TYPE_FW_CSE_SYNC by updating the event naming from "early and late
bootstage" to "pre and post memory."
BUG=b:379585294
TEST=boot verified on google/rex0 and google/rex64
without change:
```
rex-rev3 ~ # elogtool list
rex64-rev3 ~ # /media/usb/elogtool list
3 | 2024-01-01 22:25:59-0800 | Firmware CSE sync | Late CSE Sync
```
with change:
```
rex64-rev3 ~ # elogtool list
3 | 2024-12-17 02:22:36-0800 | Firmware CSE sync | Post RAM CSE Sync
```
Change-Id: Ia5db3ffb43b2ceac821de72ef9e88ed62e617d41
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
