Recently published Intel CedarIslandFSP binary contains PE images in
FSP-M and FSP-S. This causes coreboot boot hang on DeltaLake servers.
PI spec PI_Spec_1_7_final_Jan_2019 on uefi.org talks about FV files
requiring to support SECTION_PE32 sections and FSP specification
states that FSP images are created in alignment with PI specification.
FSP images are relocated at build time and run time using the func
fsp_component_relocate. That code only supported TE image relocation
so far.
The change required to add support for pe_relocate in fsp-relocate.c
I had to move a few functions to top of file as they need to be used
by pe_relocate but were placed below the te_relocate function. I chose
to place pe_relocate function next to te_relocate.
The code supports PE32 format, not PE32+, at this time.
Links for PE and FSP specs are provided below for reference.
Link= https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf
Link= https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
TESTED=
This code is tested with FSP version 33A for DeltaLake boot which has
FSP-M and FSP-S as PE32 sections. This FSP version does not boot on
DeltaLake without this change.
Change-Id: I01e2c123d74f735a647b994aa66419c9796f193e
Signed-off-by: Eddie Sharma <aeddiesharma@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nathaniel L Desimone <nathaniel.l.desimone@intel.com>
CL:3825558 changes all vb2_digest and vb2_hash functions to take a new
hwcrypto_allowed argument, to potentially let them try to call the
vb2ex_hwcrypto API for hash calculation. This change will open hardware
crypto acceleration up to all hash calculations in coreboot (most
notably CBFS verification). As part of this change, the
vb2_digest_buffer() function has been removed, so replace existing
instances in coreboot with the newer vb2_hash_calculate() API.
Due to the circular dependency of these changes with vboot, this patch
also needs to update the vboot submodule:
Updating from commit id 18cb85b5:
2load_kernel.c: Expose load kernel as vb2_api
to commit id b827ddb9:
tests: Ensure auxfw sync runs after EC sync
This brings in 15 new commits.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I287d8dac3c49ad7ea3e18a015874ce8d610ec67e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
I added this header in commit a6c8b4becb
(nb/intel/sandybridge: Rewrite get_FRQ). Relicense it as "BSD-3-Clause
OR GPL-2.0-or-later" and move it into the BSD-licensed commonlib part.
Change-Id: I89ebdcdf8d06e78e624e37a443696981b3b17b7d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66711
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=b:240624460
TEST=None
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: I8542c9bb624a366bc1bb01f6eae66ba97520d19c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66381
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event
logging types as below:
* ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason
while booting into recovery mode
* ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into
developer mode.
* ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into
diagnostic mode.
Drop static structure `cros_deprecated_recovery_reasons` as it has been
replaced by vb2_get_recovery_reason_string() function.
ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those
related fw boot info along with ChromeOS boot mode/reason etc.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I932952ce32337e2d54473667ce17582a90882da8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds a function to calculate best rational approximation
for a given fraction and unit tests for it.
Change-Id: I2272d9bb31cde54e65721f95662b80754eee50c2
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66010
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch calls into vboot API (vb2api_get_fw_boot_info) to retrieve
FW slot boot information like (tries count, current boot slot, previous
boot slot, previous boot status and boot mode).
Upon retrieval of the vboot information, elog callback from ramstage
records the info into the eventlog.
Additionally, this patch refactors the existing event logging mechanism
to add newer APIs to record vboot firmware boot related information.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS and run below command to
check the cbmem log:
Scenario 1:
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2_check_recovery() Recovery reason from previous boot:
0x0 / 0x0
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Developer boot`
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Success`.
....
Scenario 2:
localhost ~ # crossystem recovery_request=1
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Manual recovery boot`
VB2:vb2api_fill_boot_config() recovery_reason=0x13 / 0x00
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Unknown`.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6882cd1c4dbe5e24f6460388cd1af4e4a05fc4da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65561
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The concise multi-line comment style is for inside function bodies to
save space. Outside of it, use non-concise style.
Change-Id: I34d9ec6984b598a37c438fa3c395b5478207e31d
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
It probably was supposed to be *making these names conistent …*, but
short that a little, and add a missing article.
Change-Id: If88ff6d7b0a61aa83d5822b5e1c0b5b4c9d3bb3c
Fixes: ac136250b2 ("commonlib: Substitude macro "__unused" in compiler.h")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65884
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since there are many identifiers whose name contain "__unused" in
headers of musl libc, introducing a macro which expands "__unused" to
the source of a util may have disastrous effect during its compiling
under a musl-based platform.
However, it is hard to detect musl at build time as musl is notorious
for having explicitly been refusing to add a macro like "__MUSL__" to
announce its own presence.
Using __always_unused and __maybe_unused for everything may be a good
idea. This is how it works in the Linux kernel, so that would at least
make us match some other standard rather than doing our own thing
(especially since the other compiler.h shorthand macros are also
inspired by Linux).
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I547ae3371d7568f5aed732ceefe0130a339716a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Branding changes to unify and update Chrome OS to ChromeOS (removing the
space).
This CL also includes changing Chromium OS to ChromiumOS as well.
BUG=None
TEST=N/A
Change-Id: I39af9f1069b62747dbfeebdd62d85fabfa655dcd
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65479
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
cbfs_unverified_area_cbmem_alloc() expects a tag id to allocate space
to decompress ME_RW blobs within the CBMEM area, add a tag id for it.
BRANCH=firmware-brya-14505.B
Change-Id: I32f44496d389e3a7e4f2573ee4e46a145f7cd927
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
It seems fixup or adjustment addition for relocation type
EFI_IMAGE_REL_BASED_DIR64 is missing in the fsp rebasing code. The
patch address the miss. Without extending the fixup for the relocation
type, build system throws warnings during the rebasing of FSP-M and
FSP-S blobs which are built with 64bit.
Portion of build output containing warning with debug enabled cbfs lib:
...................................................
E: file offset: 9218
E: file type = 4
E: file attribs = 0
E: section offset: 9230
E: section type: 12
E: TE image at offset 9234
E: TE Image 0xffed80d4 -> 0xff256234 adjust value: ff37e000
E: Relocs for RVA offset 12000
E: Num relocs in block: 18
E: reloc type a offset f40
E: Unknown reloc type: a
Portion of build output after fix:
..................................
E: file offset: 9218
E: file type = 4
E: file attribs = 0
E: section offset: 9230
E: section type: 12
E: TE image at offset 9234
E: TE Image 0xffed80d4 -> 0xff256234 adjust value: ff37e000
E: Relocs for RVA offset 12000^M
E: Num relocs in block: 18
E: reloc type a offset f40
E: Adjusting 0x7f2e7f377024 ffee9192 -> ff267192
E: reloc type a offset f48
TEST: Integrate FSP blobs built with 64 bit and do boot test.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I894007ec50378357c00d635ec86d044710892aab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65383
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Some eMMCs (for example, Kingston-EMMC64G-TX29-HP) may enter the ready
state by sending CMD1 twice. If it is in the ready state, then the
payload (for example, depthcharge) will not send CMD1, but the access
mode is only available from the response of CMD1.
Therefore, we need to pass the access mode to the payload by defining
the following types:
- MMC_STATUS_CMD1_READY: in ready state and access mode is byte mode.
- MMC_STATUS_CMD1_READY_HCS: in ready state and access mode is sector
mode.
BUG=b:234672726
BRANCH=cherry
TEST=boot ok
Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com>
Change-Id: Iad905781d8ba0105911cf87a6b845cd8df57521e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65054
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch contains several minor cleanups related to compiler.h:
- Replace __always_unused() (which is a Linux-specific concept that
doesn't make sense without also having __maybe_unused(), and had zero
uses in the codebase) with __unused() which moves here from helpers.h
- Add __underscores__ to the names of all attributes in the compiler
attribute shorthand macros. This is necessary to make them work in
files where the same name was already used for an identifier (e.g.
cbfstool/cbfs.h's `unused` array of file types).
- Remove libpayload's own copy of compiler.h and make it directly pull
in the commonlib/bsd copy.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9644da594bb69133843c6b7f12ce50b2e45fd24b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Save the regular boot MTRRs that are restored on the S3 path during
the CPU init in cbmem instead of storing them to the SPI flash.
This was probably done because historically this code run with late
cbmem init (in ramstage).
TESTED on pcengines/apu1 and lenovo/g505s: S3 resume works fine.
Change-Id: Ia58e7cd1afb785ba0c379ba75ef6090b56cb9dc6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44294
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The Intel Firmware Interface Table (FIT) is a bit of an annoying outlier
among CBFS files because it gets manipulated by a separate utility
(ifittool) after cbfstool has already added it to the image. This will
break file hashes created for CBFS verification.
This is not actually a problem when booting, since coreboot never
actually loads the FIT from CBFS -- instead, it's only in the image for
use by platform-specific mechanisms that run before coreboot's
bootblock. But having an invalid file hash in the CBFS image is
confusing when you want to verify that the image is correctly built for
verification.
This patch adds a new CBFS file type "intel_fit" which is only used for
the intel_fit (and intel_fit_ts, if applicable) file containing the FIT.
cbfstool will avoid generating and verifying file hashes for this type,
like it already does for the "bootblock" and "cbfs header" types. (Note
that this means that any attempt to use the CBFS API to actually access
this file from coreboot will result in a verification error when CBFS
verification is enabled.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1c1bb6dab0c9ccc6e78529758a42ad3194cd130c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64736
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There are too many "FIT" in firmware land. In order to reduce possible
confusion of CBFS_TYPE_FIT with the Intel Firmware Interface Table, this
patch renames it to CBFS_TYPE_FIT_PAYLOAD (including the cbfstool
argument, so calling scripts will now need to replace `-t fit` with `-t
fit_payload`).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I826cefce54ade06c6612c8a7bb53e02092e7b11a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
In the last coreboot leadership meeting, the doxygen documentation was
declared to be dead. Remove it.
Doxygen style comments can still be added to files, and we may generate
doxygen based documentation, but it won't be for the entire project, but
instead just for those individual areas where it is being maintained.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8983a20793786a18d2331763660842fea836aa2a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add 'lb_fill_pcie' function to pass PCIe information from coreboot to
libpayload, and add CB_ERR_NOT_IMPLEMENTED to the cb_err enum for the
__weak function.
ARM platform usually does not have common address for PCIe to access the
configuration space of devices. Therefore, new API is added to pass the
base address of PCIe controller for payloads to access PCIe devices.
TEST=Build pass and boot up to kernel successfully via SSD on Dojo
board, here is the SSD information in boot log:
== NVME IDENTIFY CONTROLLER DATA ==
PCI VID : 0x15b7
PCI SSVID : 0x15b7
SN : 21517J440114
MN : WDC PC SN530 SDBPTPZ-256G-1006
RAB : 0x4
AERL : 0x7
SQES : 0x66
CQES : 0x44
NN : 0x1
Identified NVMe model WDC PC SN530 SDBPTPZ-256G-1006
BUG=b:178565024
BRANCH=cherry
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: I6cdce21efc66aa441ec077e6fc1d5d1c6a9aafb0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Chrome OS is experimenting with a hypervisor layer that boots after
firmware, but before the OS. From the OS' perspective, it can be
considered an extension of firmware, and hence it makes sense to emit
timestamp to track hypervisor boot latency. This change adds
timestamp IDs in the 1200-1300 range for this purpose.
BUG=b:217638034
BRANCH=none
TEST=Manual: cbmem -a TS_CRHV_BOOT to add a timestamp, cbmem -t to
verify that it got added to the timestamp table.
Change-Id: If70447eea2c2edf42b43e0198b827c1348b935ea
Signed-off-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch just adds some comments to the recently merged mem_chip_info
struct for communicating memory type information to the payload/OS, to
clarify the expected format in which values are to be written into the
fields.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2c28b3bdcdb13b7f270fb87a8f06e2cf448cddec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
The header file <inttypes.h> includes <stdint.h> and defines some
additional PRI* macros. Since elog.h and elog.c do not use any of the
PRI* macro, we should include <stdint.h> directly.
Change-Id: Iac1f4f53e43f171ecef95533cd6a3bf5dff64ec4
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Include <stddef.h> since we need it for 'size_t'.
Unused <stdlib.h> found using:
diff <(git grep -l '#include <stdlib.h>' -- src/) <(git grep -l 'memalign(\|malloc(\|calloc(\|free(' -- src/)
Change-Id: I3c2668013c16d6771268e8739b1370968c2e120b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60620
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <martinroth@google.com>
Packing structs will result in unaligned sizes, possible causing
problems for other entries.
Change-Id: Ifb756ab4e3562512e1160224678a6de23f3b84ec
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63714
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace 'struct lb_uint64' with 'typedef __aligned(4) uint64_t
lb_uint64_t', and remove unpack_lb64/pack_lb64 functions since it's no
longer needed.
Also replace 'struct cbuint64' with 'cb_uint64_t' and remove
'cb_unpack64' in libpayload for compatible with lb_uint64_t.
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: If6b037e4403a8000625f4a5fb8d20311fe76200a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add a helper function mem_chip_info_size() as the size of
mem_chip_info structure is used in multiple places.
BUG=b:182963902,b:177917361
TEST=Validated on qualcomm sc7280 development board
Signed-off-by: Ravi Kumar Bokka <rbokka@codeaurora.org>
Change-Id: Iaada45d63b82c28495166024a9655d871ba65b20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63407
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Flame graphs are used to visualize hierarchical data, like call stacks.
Timestamps collected by coreboot can be processed to resemble
profiler-like output, and thus can be feed to flame graph generation
tools.
Generating flame graph using https://github.com/brendangregg/FlameGraph:
cbmem -S > trace.txt
FlameGraph/flamegraph.pl --flamechart trace.txt > output.svg
TEST=Run on coreboot-enabled device and extract timestamps using
-t/-T/-S options
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I3a4e20a267e9e0fbc6b3a4d6a2409b32ce8fca33
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some solutions require readable form of timestamps, which does not
contain spaces. Current descriptive timestamp names do not meet this
criteria. Also, mapping enums to their text representation allows for
quick grepping (use of grep command) to find relevant timestamps in the
code.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ifd49f20d6b00a5bbd21804cea3a50b8cef074cd1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62709
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Move STRINGIFY() from coreboot string.h to commonlib/bsd/helpers.h
Remove redundant defines from libpayload.h and libpayloads' standard
headers.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I3263b2aa7657759207bf6ffda750d839e741f99c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The ACPI RSDP can only be found in:
- legacy BIOS region
- via UEFI service
On some systems like ARM that legacy BIOS region is not an option, so
to avoid needing UEFI it makes sense to expose the RSDP via a coreboot
table entry.
This also adds the respective unit test.
Change-Id: I591312a2c48f0cbbb03b2787e4b365e9c932afff
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62573
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cb_err_t was meant to be used in place of `enum cb_err` in all
situations, but the choice to use a typedef here seems to be
controversial. We should not be arbitrarily using two different
identifiers for the same thing across the codebase, so since there are
no use cases for serializing enum cb_err at the moment (which would be
the primary reason to typedef a fixed-width integer instead), remove
cb_err_t again for now.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaec36210d129db26d51f0a105d3de070c03b686b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62600
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
In order to provide the same loglevel prefixes and highlighting that
were recently introduced for "interactive" consoles (e.g. UART) to
"stored" consoles (e.g. CBMEM) but minimize the amont of extra storage
space wasted on this info, this patch will write a 1-byte control
character marker indicating the loglevel to the start of every line
logged in those consoles. The `cbmem` utility will then interpret those
markers and translate them back into loglevel prefixes and escape
sequences as needed.
Since coreboot and userspace log readers aren't always in sync,
occasionally an older reader may come across these markers and not know
how to interpret them... but that should usually be fine, as the range
chosen contains non-printable ASCII characters that normally have no
effect on the terminal. At worst the outdated reader would display one
garbled character at the start of every line which isn't that bad.
(Older versions of the `cbmem` utility will translate non-printable
characters into `?` question marks.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I86073f48aaf1e0a58e97676fb80e2475ec418ffc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch adds ANSI escape sequences to highlight a log line based on
its loglevel to the output of "interactive" consoles that are meant to
be displayed on a terminal (e.g. UART). This should help make errors and
warnings stand out better among the usual spew of debug messages. For
users whose terminal or use case doesn't support these sequences for
some reason (or who simply don't like them), they can be disabled with a
Kconfig.
While ANSI escape sequences can be used to add color, minicom (the
presumably most common terminal emulator for UART endpoints?) doesn't
support color output unless explicitly enabled (via -c command line
flag), and other terminal emulators may have similar restrictions, so in
an effort to make this as widely useful by default as possible I have
chosen not to use color codes and implement this highlighting via
bolding, underlining and inverting alone (which seem to go through in
all cases). If desired, support for separate color highlighting could be
added via Kconfig later.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I868f4026918bc0e967c32e14bcf3ac05816415e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61307
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
In an attempt to make loglevels more visible (and therefore useful,
hopefully), this patch adds a prefix indicating the log level to every
line sent to an "interactive" console (such as a UART). If the code
contains a `printk(BIOS_DEBUG, "This is a debug message!\n"), it will
now show up as
[DEBUG] This is a debug message!
on the UART output.
"Stored" consoles (such as in CBMEM) will get a similar but more
space-efficient feature in a later CL.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic83413475400821f8097ef1819a293ee8926bb0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Change timestamp_add to accept negative values for events that took
place before coreboot started executing.
TEST=Boot to OS, check cbmem -t
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I90afc13a8e92693d86e3358f05e0a0cb7cdbca9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59554
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
macOS has never defined the usual endian(3)/byteorder(9) byte-swapping
functions. This change implements these byte-swapping functions using
the OSSwap functions, which provide identical functionality. This was
tested on macOS 10.15.7.
Change-Id: I44d59869a4420030f3ce26118175304c680d57a1
Signed-off-by: Alex James <theracermaster@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Implement __fls() as an alias for log2(), and remove the duplicate
definitions in commonlib/storage/sdhci.c.
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: Ib458abfec7e03b2979569a8440a6e69b0285ac32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59738
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch removes all remaining pieces of the old CBFS API, now that
the last straggling use cases of it have been ported to the new one
(meaning cbfs_map()/cbfs_load()/etc... see CB:39304 and CB:38421).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1cec0ca2d9d311626a087318d1d78163243bfc3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The 'at' part of the name refers to starting to read from a specific
offset, so it doesn't make sense for the 'full' version of the function.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I60d595f0cbd161df171eaa4a76c7a00b6377e2b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59820
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Libpayload requires cbmem_id.h file to support extracting values from
CBMEM IMD entries of coreboot tables. Libpayload use BSD-3-Clause
license, and all of its files used to compile a static library have to
use it too.
Change-Id: I97c080e34ebdbcdf14fe3a3c9515b1dea8ede179
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
