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>
How it approximately works:
(During a normal system run):
1. OS puts a capsule into RAM and calls UpdateCapsule() function of EFI
runtime
2. If applying the update requires a reboot, EFI implementation creates
a new CapsuleUpdateData* EFI variable pointing at the beginning of
capsules description (not data, but description of the data) and does
a warm reboot leaving capsule data and its description in RAM to be
picked by firmware on the next boot process
(After DEV_INIT:)
3. Capsules are discovered by checking for CapsuleUpdateData* variables
4. Capsule description in memory and capsule data is validated for
sanity
5. Capsule data is coalesced into a continuous piece of memory
(On BS_WRITE_TABLES via dasharo_add_capsules_to_bootmem() hook:)
6. Buffer with coalesced capsules is marked as reserved
(On BS_WRITE_TABLES via lb_uefi_capsules() hook:)
7. coreboot table entry is added for each of the discovered capsules
(In UEFI payload:)
8. CapsuleUpdateData* get removed
9. coreboot table is checked for any update capsules which are then
applied
Change-Id: I162d678ae5c504906084b59c1a8d8c26dadb9433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
The current region_end() implementation is susceptible to overflow
if the region is at the end of the addressable space. A common case
with the memory-mapped flash of x86 directly below the 32-bit limit.
Note: This patch also changes console output to inclusive limits.
IMO, to the better.
Change-Id: Ic4bd6eced638745b7e845504da74542e4220554a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
EFI System Resource Table (ESRT) is an informational structure that
reports basic details about current system or device firmware. This is
chiefly used to perform firmware updates.
New CONFIG_DRIVERS_EFI_FW_INFO is off by default, enabling it adds
DRIVERS_EFI_FW_{GUID,VERSION,LSV} to be used to specify firmware
version/update information.
Existing forms of versions wouldn't be sufficient because there is no
universal way of converting string versions to 32-bit unsigned integers
and there are no GUIDs or lowest supported versions.
Change-Id: Ic1b768d7bed43edf7ca8e41552087734054de033
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83421
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: coreboot org <coreboot.org@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the strnlen() implementation to fix a small issue
where we would dereference once more byte than intended when not finding
a NUL-byte within the specified amount of characters. It also changes
the implementation to rely on a pre-calculated end pointer rather than a
running counter, since this seems to lead to slightly better assembly
(one less instruction in the inner loop) on most architectures.
Change-Id: Ic36768fd3a26e2b64143904e78cd0b52ba66898d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
When `maxlen` is large (such as SIZE_MAX), the `end` pointer will
overflow, causing strnlen() to incorrectly return 0.
To not make the implementation over-complicated, fix the problem by
using a counter.
BUG=b:359951393
TEST=make unit-tests -j
BRANCH=none
Change-Id: Ic9d983b11391f5e05c2bceb262682aced5206f94
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83914
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Add strlen() and strnlen() to commonlib/bsd by rewriting them from
scratch, and remove the same functions from coreboot and libpayload.
Note that in the existing libpayload implementation, these functions
return 0 for NULL strings. Given that POSIX doesn't require the NULL
check and that other major libc implementations (e.g. glibc [1]) don't
seem to do that, the new functions also don't perform the NULL check.
[1] https://github.com/bminor/glibc/blob/master/sysdeps/i386/strlen.c
Change-Id: I1203ec9affabe493bd14b46662d212b08240cced
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83830
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This change includes the <stdint.h> header file to resolve the
compilation error "'SIZE_MAX' undeclared". This issue was introduced
by commit hash af0d4bce65 (region:
Introduce region_create() functions).
TEST=Able to build google/rex.
Change-Id: I0dbd839e3573d5c74375911903c8f9d6a66bbf28
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83886
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We introduce two new functions to create region objects. They allow us
to check for integer overflows (region_create_untrusted()) or assert
their absence (region_create()).
This fixes potential overflows in region_overlap() checks in SMI
handlers, where we would wrongfully report MMIO as *not* overlapping
SMRAM.
Also, two cases of strtol() in parse_region() (cbfstool), where the
results were implicitly converted to `size_t`, are replaced with the
unsigned strtoul().
FIT payload support is left out, as it doesn't use the region API
(only the struct).
Change-Id: I4ae3e6274c981c9ab4fb1263c2a72fa68ef1c32b
Ticket: https://ticket.coreboot.org/issues/522
Found-by: Vadim Zaliva <lord@digamma.ai>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently a warning is printed even if the maximum amount of nodes is
not exceeded.
Remove the warning, since in most cases the maximum amount of nodes
for a given prefix is usually well known. For example the /cpu nodes
always have a maximum of CONFIG_MAX_CPUS.
One may also just want to read the first X amount of nodes matching a
given prefix.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ic1111e8acb72ea1e9159da0d8386f40cbbdbc63f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add a helper function to read the reg property from an unflattened
device tree.
It also factors out the common code into a new function called
`read_reg_prop`.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I7846eb8af390d709b0757262025cb819e9988699
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add a new eventLog type of ELOG_TYPE_FW_LATE_SOL to support logging
when we show late (from payload) Signs Of Life (SOL) to the user.
BUG=b:305898363
TEST=Event shows in eventlog tool after CSE sync:
```
Late Sign of Life | CSE Sync Late SOL Screen Shown
```
Change-Id: Ibbe9f37a791e5c2a0c6e982942cf3043a2bd4b45
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Currently the HiFive Unleashed produces the following exception:
[DEBUG] Exception: Load address misaligned
[DEBUG] Hart ID: 0
[DEBUG] Previous mode: machine
[DEBUG] Bad instruction pc: 0x080010d0
[DEBUG] Bad address: 0x08026ab3
[DEBUG] Stored ra: 0x080010c8
[DEBUG] Stored sp: 0x08010cc8
The coreboot LZ4 decompression code does some misaligned access during
decompression which the FU540 apparently does not support in SRAM.
Make the compiler generate code that adheres to natural alignment by
fixing the LZ4_readLE16() function and creating LZ4_readLE32().
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Id165829bfd35be2bce2bbb019c208a304f627add
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81910
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename fdt_node_name to the actual function name and also rename the
references.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I527146df26264a0c3af1ad01c21644d751b80236
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83084
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Now that the device tree code has been made available in libpayload, we
should reintroduce the node and property allocation optimization for
libpayload's memory allocator that was originally dropped when porting
this code from depthcharge to coreboot.
On a Qualcomm SC7180 unflattening a normal ChromeOS kernel device tree,
this saves roughly ~145ms. The total scratch space used is about ~1350
nodes and ~5200 properties, so we leave a little room to grow with the
constants hardcoded here.
Change-Id: I0f4d80a8b750febfb069b32ef47304ccecdc35af
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add support for PE32+ binaries which can be found on X64 UEFI
builds.
TEST: Able to relocate and boot a X64 FSP.
Change-Id: I22586834d7c9f3ab3a5e31bba957584587ec14e0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82680
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Define a new timestamp to identify the completion of Auxiliary Firmware
Sync. Without that, it gets accounted into a different timestamp ID in a
misleading way.
BUG=None
TEST=Build Brox BIOS image and boot to OS. Confirm the timestamp is
recorded in cbmem.
Change-Id: Icd01c68a5848e2aed7bbdcc794987bc780e78dab
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Shelley Chen <shchen@google.com>
This patch adds timestamp entries for eSOL (early Sign-Off Life).
This is critical to tracking the panel initialization time while
rendering the eSOL screen.
TEST=Able to build and boot google/omnigul.
555: started early sign-off life (eSOL) notification 643,694 (40)
556: finished early sign-off life (eSOL) notification 1,072,143 (428,449)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I33f7f3a8622600ef23163faf45e2da7b96d6bbdb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81386
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop RMRR entry for XHCI controller since it's not under BIOS control.
There's no USB-PS/2 emulation done in SMM, hence it's not needed.
TEST=intel/archercity CRB
Change-Id: I5afd68371d71a00988fe0f8a6045ec5ce2adc6a1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81297
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
The list macros use uintptr_t, so they need to include the header that
declares it.
Change-Id: I56b2a988bb11d40c8761717bcd02a8199c077046
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81288
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch moves commonlib/stdlib.h -> commonlib/bsd/stdlib.h, since
all code is BSD licensed anyway.
It also moves some code from libpayloads stdlib.h to
commonlib/bsd/stdlib.h so that it can be shared with coreboot. This is
useful for a subsequent commit that adds devicetree.c into commonlib.
Also we don't support DMA on arm platforms in coreboot (only libpayload)
therefore `dma_malloc()` has been removed and `dma_coherent()` has been
moved to architecture specific functions. Any architecture that tries to
use `dma_coherent()` now will get a compile time error. In order to not
break current platforms like mb/google/herobrine which make use of the
commonlib/storage/sdhci.c controller which in turn uses `dma_coherent` a
stub has been added to arch/arm64/dma.c.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I3a7ab0d1ddcc7ce9af121a61b4d4eafc9e563a8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77969
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
PAYLOAD_INFO is a very old feature that can add a key/value information
section to a payload file. It seems to have only ever been generated by
coreinfo and never really read by anything.
Since CB:1721 in 2012, the feature has been inadvertently broken in
practice since the `.note.pinfo` sections that contain the information
get discarded from the payload before cbfstool gets to see them. Since
CB:28647 in 2018, support for the section in the SELF loader was
(inadvertently?) dropped, so if someone actually fed cbfstool a payload
ELF that did have a `.note.pinfo` section, modern coreboot would refuse
to boot the payload entirely (which is probably not a good state to
leave things in).
This patch removes the code to generate PAYLOAD_INFO entries entirely,
but leaves the support to parse and extract those sections from old
payloads in place in cbfstool.
Change-Id: I40d8e9b76a171ebcdaa2eae02d54a1ca5e592c85
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Intel Firmware Support Package 2.4 specification (document 736809)
brings some significant changes compared to version 2.3 (document
644852):
1. It supports FSP-M multi-phase init. Some fields have been added to
the FSP header data structure for this purpose.
2. The `FSPM_ARCH2_UPD' and `FSPS_ARCH2_UPD' data structures must be
used in place of `FSPM_ARCH_UPD' and `FSPS_ARCH_UPD' respectively.
3. It support 64-bits FSP but 64-bits support will be provided by
subsequent patch.
Note that similarly to what is done for silicon initialization,
timestamps and post-codes are used during the memory initialization
multi-phase.
[736809]
https://cdrdv2-public.intel.com/736809/736809_FSP_EAS_v2.4_Errata_A.pdf
[644852]
https://cdrdv2-public.intel.com/644852/644852_2.3_Firmware-Support-Package-External-Architecture-Specification.pdf
TEST=verified on Lunar Lake RVP board (lnlrvp)
Change-Id: I1c24d26e105c3dcbd9cca0e7197ab1362344aa97
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
It is needed in order to move device_tree.c into commonlib in a
subsequent commit.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I16eb7b743fb1d36301f0eda563a62364e7a9cfec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77968
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It seems that we have some applications where we need to calculate a GCD
in 64 bits. Now, we could instantiate the algorithm multiple times for
different bit width combinations to be able to use the most efficient
one for each problem... but considering that the function usually only
gets called once per callsite per stage, and that software emulation of
64-bit division on 32-bit systems doesn't take *that* long either, we
would probably usually be paying more time loading the second instance
of the function than we save with faster divisions. So let's just make
things easy and always do it in 64-bit and then nobody has to spend time
thinking on which version to call.
Change-Id: I028361444c4048a0d76ba4f80c7334a9d9983c87
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80319
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
