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>
Introduce a mechanism so that coreboot can provide a list of options to
post-coreboot code. The options are grouped together into forms and
have a meaning name and optional help text. This can be used to let
payloads know which options should be displayed in a setup menu,
for instance. Although this system was written to be used with edk2,
it has been designed with flexibility in mind so that other payloads
can also make use of this mechanism. The system currently lacks a way
to describe where to find option values.
This information is stored in a set of data structures specifically
created for this purpose. This format is known as CFR, which means
"coreboot forms representation" or "cursed forms representation".
Although the "forms representation" is borrowed from UEFI, CFR can
be used in non-UEFI scenarios as well.
The data structures are implemented as an extension of cbtables records
to support nesting. It should not break backwards compatibility because
the CFR root record (LB_TAG_CFR_ROOT) size includes all of its children
records. The concept of record nesting is borrowed from the records for
CMOS options. It is not possible to reuse the CMOS records because they
are too closely coupled with CMOS options; using these structures would
needlessly restrict more capable backends to what can be done with CMOS
options, which is undesired.
Because CFR supports variable-length components, directly transforming
options into CFR structures is not a trivial process. Furthermore, CFR
structures need to be written in one go. Because of this, abstractions
exist to generate CFR structures from a set of "setup menu" structures
that are coreboot-specific and could be integrated with the devicetree
at some point. Note that `struct sm_object` is a tagged union. This is
used to have lists of options in an array, as building linked lists of
options at runtime is extremely impractical because options would have
to be added at the end of the linked list to maintain option order. To
avoid mistakes defining `struct sm_object` values, helper macros exist
for supported option types. The macros also provide some type checking
as they initialise specific union members.
It should be possible to extend CFR support for more sophisticated
options like fan curve points. Feedback about this is highly
appreciated.
Change-Id: I304de7d26d79245a2e31a6d01f6c5643b31cb772
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74121
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a new event log type, ELOG_TYPE_FW_CSE_SYNC. The
purpose of this event type is to log successful completion of CSE
synchronization.
BUG=b:379585294
TEST=boot verified on google/rex0 and google/rex64
Change-Id: Id73fa3a77e5fbbae5c61dfb30ae26b4ba3dca6ab
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85217
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a generic optimization to calculate a machine-word-sized
"wide sum" for the ipchksum() algorithm. This is often not as
efficient as handcrafted assembly (about half as fast on arm64 and
x86_32, about the same speed on x86_64), but likely still much better
than nothing on architectures that we don't have handcrafted assembly
for.
Change-Id: I8f0fe117e2788d1b6801b73824b97e1e31ecc694
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80304
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the FDT specification the FDT_END token is supposed to be
the last token in the structure block, not a free-floating token
immediately outside of it. That means we're supposed to count it in
struct_size. It seems that the kernel never cared about this, but some
FDT parsing utilities like `fdtgrep` do.
Change-Id: Icdeadbeefcafed00dbabefeed1337c0debc86836
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85462
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a helper function to get the mem_chip_info entry size.
Change-Id: Ibf2a2006fb3e7772688b80807589e8f2d64d1147
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
