In the unlikely but possible event where the name of the CBFS file is
longer than 232 characters, `cbfs_create_file_header()' would overflow
the buffer it allocated when it copies the CBFS filename.
Change-Id: If1825b5af21f7a20ce2a7ccb2d45b195c2fb67b0
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The flag activates some Win32 compatibility quirks and on
clang/openbsd it enables so many of them that the code doesn't compile
anymore. Therefore move it into the "Win32 area" in that Makefile.
Change-Id: Ic77c04941e40a568f1d74cec09eb3d22a66e69b0
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78724
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The linker can make relocation entries of a symbol which has a value
of zero point to the undefined symbol entry. It is permitted since
when the symbol value is zero as the documentation of the relocation
entry `r_info' field states:
"If the index is STN_UNDEF, the undefined symbol index, the relocation
uses 0 as the symbol value."
The ELF binary does not really have any missing symbols. It is an
optimization as the symbol points to the undefined symbol because its
value is zero.
A typical way to hit this cbfstool limitation is to define an empty
region using the REGION macro in the linker script. Here is an
example if we assume `CONFIG_MY_REGION' is set to 0:
.car.data {
[...]
REGION(my_region, CONFIG_MY_REGION_SIZE)
[...]
}
A region is defined as follow:
#define REGION_SIZE(name) ((size_t)_##name##_size)
#define DECLARE_REGION(name) \
extern u8 _##name[]; \
extern u8 _e##name[]; \
extern u8 _##name##_size[];
So the size of the region is actually the address of the
`_##name##_size' symbol. Therefore, the `_my_region_size' symbol
address is zero and the linker can make the relocation entry of this
symbol point to the undefined symbol index.
In such a situation, cbfstool hits a segmentation fault when it
attempts to relocate the symbol in `parse_elf_to_xip_stage()'
function. We resolves this issue by making cbfstool skips relocation
entries pointing to the undefined symbol similarly to the way it skips
relocation relative to absolute symbols. A symbol which value is zero
can be considered an absolute symbol and therefore should not be
relocated.
Of course, we could argue that we could just prevent the declaration
of an empty region as illustrated in the following example:
.car.data {
[...]
#if CONFIG_MY_REGION_SIZE > 0
REGION(my_region, CONFIG_MY_REGION_SIZE)
#endif
[...]
}
However, this is not a satisfying solution because:
1. It requires to add unnecessary code in the linker script as an empty
region is a valid declaration. Such a workaround requires the code
using it to mark the region symbols as weak symbols to handle the
situation where the region is not defined.
2. There could be other situations which have yet to be uncovered which
would lead the same cbfstool crash.
3. A binary with an empty region is a valid ELF file and cbfstool
should not crash when it is asked to create an eXecute-In-Place stage
out of it.
Change-Id: I2803fd3e96e7ff7a0b22d72d50bfbce7acaeb941
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Revise the Makefile.inc rules for generating FMD parser files.
- lex: If --header-file is supported then the lex (usually flex) should
also support '-o' so we don't need to do redirection (-t).
- yacc: Bison is already required by bincfg and sconfig so we
can change the default parser compiler to Bison. That also
allows us to use -o and --defines to override the output files.
- both: Line directives are only helpful when debugging the scanner and
the parser, so we should remove them to get better git diff
results (-L for lex, -l for bison).
Also regenerated the shipped files with latest version of flex (2.6.4)
and bison (3.8.2).
Change-Id: I15b58ff65dcd9f3f3a6095aa004091ff733ffec3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
There is a technical debt in ChromeOS flashrom, `cros_alias.c`, which
is to work around ChromeOS calling flashrom with `-p host` instead of
`-p internal`.
Replace all `-p host` occurrences with `-p internal`.
BUG=b:296978620
TEST=none
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: I81674213b9a21598002f349ced1130f0844841ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
For x86 eXecute-In-Place (XIP) pre-memory `.data` section support, we
have to use an extra segment as the VMA/LMA of the data is different
than the VMA/LMA of the code.
To support this requirement, this patch makes cbfstool:
1. Allow the load of an ELF with an extra segment
2. Makes add-stage for XIP (cf. parse_elf_to_xip_stage()) write its
content to the output binary.
To prevent the creation of unsuitable binaries, cbfstool verifies that
the LMA addresses of the segments are consecutives.
TEST=XIP pre-memory stages with a `.data` section have the `.data`
section covered by a second segment properly included right after
the code.
Change-Id: I480b4b047546c8aa4e12dfb688e0299f80283234
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77584
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For x86 eXecute-In-Place (XIP) .data section support, cbfstool need to
to skip relocation of the .data section symbols in addition to
.car.data section symbols.
To support this requirement, this patch makes the `-S` option take a
multiple section names separated by commas.
TEST=With `-S ".car.data .data"`, XIP pre-memory stages with
a `.data` section do not have any of the `.car.data` or `.data`
section symbols relocated.
Change-Id: Icf09ee5a318e37c5da94bba6c0a0f39485963d3a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds support for logging the firmware splash screen event
to the event log. There could be two possible scenarios for this
event: enabled and disabled.
BUG=b:284799726
TEST=Verify that the event shows up in the event log when the user
selects the HAVE_FSP_LOGO_SUPPORT and BMP_LOGO configs to display
the firmware splash screen.
Change-Id: I1e224903df21159d6eef2849a7d6fb05de09f543
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
In order to support logging of events for PSR data backup command
status during CSE firmware downgrade, add support for
ELOG_TYPE_PSR_DATA_BACKUP and ELOG_TYPE_PSR_DATA_LOST types.
BRANCH=None
BUG=b:273207144
TEST=Verify event shows in eventlog after CSE firmware downgrade
Change-Id: Ibb78ac8d420bb7a64328ce009ddcb99030519ec6
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77005
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
To support full 64-bit addresses, there is a new field `ext_lfb_base`
since Linux 4.1. It is unclear, however, how a loader is supposed to
know if the kernel is compatible with this. Filling these previously
reserved bits doesn't hurt, but an old kernel would probably ignore
them and not know that it's handling a clipped, invalid address. So
we play safe, and only allow 64-bit addresses for kernels after the
2.15 version bump of the boot protocol.
Change-Id: Ib20184cf207f092062a91ac3e6aa819b956efd33
Signed-off-by: Nico Huber <nico.h@gmx.de>
Co-authored-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76479
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Translate the coreboot framebuffer info from coreboot tables to
the Linux zero page.
Tested in QEMU/Q35 with a kernel w/ efifb enabled.
Change-Id: I2447b2366df8dd8ffe741c943de544d8b4d02dff
Signed-off-by: Nico Huber <nico.h@gmx.de>
Co-authored-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76431
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I6b87680ec9f501945ae266ae4e4927efd2399d56
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76815
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The patch adds a possibility to cache the PCIe 5.0 HSPHY firmware in
the SPI flash. New flashmap region is created for that purpose. The
goal of caching is to reduce the dependency on CSME and the HECI IP
LOAD command which may fail when the CSME is disabled, e.g. soft
disabled by HECI command or HAP disabled. This change allows to
keep PCIe 5.0 root ports functioning even if CSME/HECI is not
functional.
TEST=Boot Ubuntu 22.04 on MSI PRO Z690-A and notice PCIe 5.0 port
is functional after loading the HSPHY from cache.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5a37f5b06706ff30d92f60f1bf5dc900edbde96f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68987
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove duplicated definitions of ARRAY_SIZE macro across util/ dir.
Instead of duplicates, use the one from commonlib/bsd/helpers.h file.
BUG=b:231765496
TEST=make -C util/cbfstool; make -C util/cbmem;
make -C util/intelmetool; make -C util/superiotool
Change-Id: I29b776586b4f0548d4026b2ac77095791fc9f3a3
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74474
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Grzegorz Bernacki
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to accord with grub (see include/grub/i386/linux.h) and
comments for offsets of members of struct linux_params,
struct e820entry should be defined as __packed, otherwise,
sizeof(struct linux_params) will become 4224 (0x1080).
Fortunately, the affected area is usually not occupied.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I09955c90e4eec337adca383e628a8821075381d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
In CB:41119, I sort of made up a mechanism on the fly for how to make
the machine-parseable cbfstool print output extensible without breaking
backwards compatibility for older scripts. But I only explained it in
the commit message which is not very visible. This patch adds a comment
to the function that generates that output so that people who want to
change it can understand the intent.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0d18d59e7fe407eb34710d6a583cfae667723eb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This reverts commit 89b4f69746.
SI_BIOS is mostly used to indicate the BIOS region in Intel IFD. Not all
platforms are Intel platforms with an IFD, so revert this change. Also
tooling often depends on names not changing so renaming things should
not be done lightly. The default region should also be in sync with
non-x86 and made systematic across the tree.
Change-Id: I46f52494498295ba5e2a23d0b66b56f266293050
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74290
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Currently ifdtool --validate will not correctly validate the FMAP
against the IFD regions, since it will compare the IFD bios region with
an FMAP region called SI_BIOS.
It's probably a good idea to define default name for the BIOS FMAP
region like we have for 'COREBOOT' or 'FMAP' FMAP region.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I55eddfb5641b3011d4525893604ccf87fa05a1e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Add a new flag "--utc" to allow the user to choose if
elogtool should print timestamps in Local Time or in UTC.
It is useful for generating automated crash reports
including all system logs when users are located in
various regions (timezones).
Add information about timezone to timestamps printed
on the console.
Signed-off-by: Wojciech Macek <wmacek@google.com>
Change-Id: I30ba0e17c67ab4078e3a7137ece69009a63d68fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
In order to support logging events for when we show early signs
of life to the user during CSE FW syncs and MRC trainings add
support for the ELOG_TYPE_FW_EARLY_SOL type.
BUG=b:266113626
TEST=verify event shows in eventlog CSE sync/MRC training
Change-Id: I3913cb8501de9a2605266cf9988a7195576cb91d
Signed-off-by: Tarun Tuli <tarun.tuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71296
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=b:239110778
TEST=Make sure that the output of elogtool is unaffected by this change.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Ia1a6341abd834dd9ad5f12c9f2eefb0489364a08
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72099
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With commit 34a7e66faa ("util/cbfstool: Add a new mechanism to
provide a memory map"), builds are failing on 32-bit platforms with:
../cbfstool/cbfstool.c:397:30: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
printf("Image SIZE %lu\n", image_size);
~~~ ^~~~~~~~~~
%zu
Change the format specifier from %lu to %zu.
TEST=`emerge-cherry coreboot-utils` now succeeds
Change-Id: I3602f57cf91c330122019bfa921faef6deb2b4ce
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70848
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Clang -Wshadow is more rigorous than GCC and picks a shadowing of the
optarg global variable in /usr/include/bits/getopt_core.h .
TESTED: builds with both gcc and clang.
Change-Id: Ifc362c84511abb6a000671f03498e841d7747074
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70508
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This replaces the mechanism with --ext-win-base --ext-win-size with a
more generic mechanism where cbfstool can be provided with an arbitrary
memory map.
This will be useful for AMD platforms with flash sizes larger than 16M
where only the lower 16M half gets memory mapped below 4G. Also on Intel
system the IFD allows for a memory map where the "top of flash" !=
"below 4G". This is for instance the case by default on Intel APL.
TEST: google/brya build for chromeos which used --ext-win-base remains
the same after this change with BUILD_TIMELESS=1.
Change-Id: I38ab4c369704497f711e14ecda3ff3a8cdc0d089
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The functions create_bpdt_hdr and create_cse_layout
in bpdt_1_6.c are defined to return pointers but
not integers as was previouly implemented.
Reported-by: Coverity(CID:1469323)
Reported-by: Coverity(CID:1469353)
Signed-off-by: Solomon Alan-Dei <alandei.solomon@gmail.com>
Change-Id: Idb78d94be7a75a25ad954f062e9e52b1f0b921dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Correct the capitalization of ELOG_CROS_DIAG_TYPE_STORAGE_HEALTH from
"Storage Health Info" to "Storage health info", which is already widely
used in depthcharge diagnostics tools.
BUG=b:254405481
TEST=none
Change-Id: Ia6c1df9e8d2ee6f8ae11b962e76b52f3c6663c42
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
free the memory allocated in lz4_compress
function before returning from it.
Reported-by: Coverity (CID:1469433)
Signed-off-by: Solomon Alan-Dei <alandei.solomon@gmail.com>
Change-Id: I8698090d519964348e51fc3b6f2023d06d81fcd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Metadata Hash is usually present inside the first segment of BIOS. On
board where vboot starts in bootblock, it is present in bootblock. On
boards where vboot starts before bootblock, it is present in file
containing verstage. Update cbfstool to check for metadata hash in file
containing verstage besides bootblock.
Add a new CBFS file type for the concerned file and exclude it from CBFS
verification.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled using
x86 and PSP verstages.
Change-Id: Ib4dfba6a9cdbda0ef367b812f671c90e5f90caf8
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66942
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the "_DEPRECATED_" tag from ChromeOS diagnostics event and add a
subtype: "ELOG_CROS_DIAGNOSTICS_LOGS" under it.
The data of "ELOG_CROS_DIAGNOSTICS_LOGS" (0x02) contains:
* An uint8_t of subtype code
* Any number of "ChromeOS diagnostics logs" events
Each "ChromeOS diagnostics log" represents the result of one ChromeOS
diagnostics test run. It is stored within an uint8_t raw[3]:
* [23:19] = ELOG_CROS_DIAG_TYPE_*
* [18:16] = ELOG_CROS_DIAG_RESULT_*
* [15:0] = Running time in seconds
Also add support for parsing this event. The parser will first calculate
the number of runs it contains, and try to parse the result one by one.
BUG=b:226551117
TEST=Build and boot google/tomato to OS,
localhost ~ # elogtool list
0 | 2022-09-26 04:25:32 | Log area cleared | 186
1 | 2022-09-26 04:25:50 | System boot | 0
2 | 2022-09-26 04:25:50 | Firmware vboot info | boot_mode=Manual recovery
| recovery_reason=0x2/0 (Recovery button pressed)
| fw_tried=A | fw_try_count=0 | fw_prev_tried=A
| fw_prev_result=Unknown
3 | 2022-09-26 04:25:50 | EC Event | Keyboard Recovery
4 | 2022-09-26 04:26:01 | Memory Cache Update | Normal | Success
5 | 2022-09-26 04:26:06 | System boot | 0
6 | 2022-09-26 04:26:07 | Firmware vboot info | boot_mode=Diagnostic
| fw_tried=A | fw_try_count=0 | fw_prev_tried=A
| fw_prev_result=Unknown
7 | 2022-09-26 04:26:07 | Diagnostics Mode | Diagnostics Logs
| type=Memory check (quick), result=Aborted, time=0m0s
| type=Memory check (full), result=Aborted, time=0m0s
| type=Storage self-test (extended), result=Aborted, time=0m1s
Change-Id: I02428cd21be2ed797eb7aab45f1ef1d782a9c047
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Wrap the console logging macros with do { ... } while (0) so they act
more like functions.
Add missing semicolons to calls of these macros.
TEST=compile only
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I721a4a93636201fa2394ec62cbe4e743cd3ad9d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68336
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
parse_microcode_blob() returns success when it reaches max_fit_entries
microcode. It makes the FIT table size verification in
fit_add_microcode_file() useless. This patch makes
parse_microcode_blob() error out if max_fit_entries is reached.
Note that this size verification is critical as a FIT table only
partially listing the microcode patches can lead to boot failures as
recently observed on Raptor Lake-P.
BRANCH=firmware-brya-14505.B
BUG=b:245380705
TEST=compilation errors out when trying to stitch more than
CONFIG_CPU_INTEL_NUM_FIT_ENTRIES microcode patches.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Id9c5fb6c1e264f3f5137d29201b9021c72d78fde
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67454
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Some microcode patches are padded with zeros, which make
parse_microcode_blob() read beyond the end of the buffer.
BRANCH=firmware-brya-14505.B
BUG=b:245380705
TEST=No segmentation fault with a padded microcode patch
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Id9c5fb6c1e264f3f5137d29201b9021c72d78fdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67460
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
CL:3825558 changes all vb2_digest and vb2_hash functions to take a new
hwcrypto_allowed argument, to potentially let them try to call the
vb2ex_hwcrypto API for hash calculation. This change will open hardware
crypto acceleration up to all hash calculations in coreboot (most
notably CBFS verification). As part of this change, the
vb2_digest_buffer() function has been removed, so replace existing
instances in coreboot with the newer vb2_hash_calculate() API.
Due to the circular dependency of these changes with vboot, this patch
also needs to update the vboot submodule:
Updating from commit id 18cb85b5:
2load_kernel.c: Expose load kernel as vb2_api
to commit id b827ddb9:
tests: Ensure auxfw sync runs after EC sync
This brings in 15 new commits.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I287d8dac3c49ad7ea3e18a015874ce8d610ec67e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
This 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>
Check return value of cbfs_truncate_space() in cbfs_truncate().
Remove return from cbfs_image_from_buffer() to inform about invalid
image region when incorrect offset header was provided.
Also change header offset provided to mentioned function in
cbfs_expand_to_region() and cbfs_truncate_space() from zero
to HEADER_OFFSET_UNKNOWN, as they do not support images with cbfs master
header.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ib009212692fb3594a826436df765860f54837154
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.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>
Currently elogtool sub-proccesses flashrom as calling libflashrom
requires a missing function from the previous flashrom release.
Pending a new release of flashrom we must continue to use subprocess.
However the current subprocess wrapper implementation lives in
vboot_reference which is a git sub-module of coreboot. This causes
all sorts of grief keeping a subprocess ABI stable from vboot_reference
when the rest of vboot_reference builds of HEAD of the flashrom tree
(i.e., using unreleased libflashrom functions). In order to not keep
finding ourseleves in a bind between the two separately moving trees
with different build environments, decouple elogtool with its own
mini copy of flashrom subprocess wrapping logic.
Squash in,
util/cbfstool/elogtool.c: Convert args into struct in flashrom helper
vboot signatures for flashrom r/w helpers changed in the upstream
commit bd2971326ee94fc5. Reflect the change here to allow vboot ref
and coreboot to realign.
BUG=b:207808292,b:231152447
TEST=builds with vboot_ref uprev.
Change-Id: I04925e4d9a44b52e4a6fb6f9cec332cab2c7c725
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds a new line to `cbfstool print -v` output that records
the overall CBFS verification health of the image. While this info was
already visible from individual fields before, it's nice to have a
one-stop location to see "this is a good image" without having to
carefully parse a lot of output manually.
Also add a few lines to the Makefile that check whether this field is
valid for the final image (it always should be, but hopefully this check
will allow us to catch regressions like the one fixed by CB:64547 sooner
in the future).
BUG=b:233263447
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1b74b01a55b22294556007aaee835d0fdb9e1c63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.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>
Jeremy Compostella