The current QCOM fixup function qualcomm_find_hash() assumes only one
ELF will be loaded by the primary boot loader and the bootblock is one
of the segments of that ELF.
However, the primary boot loader for QCOM X1P42100 SoC loads multiple
ELFs for QC_SEC, TME Sequencer, TME FW and bootblock. This change
updates the fixup functionality to handle bootblock being a separate
ELF.
If the bootblock offset does not fit within the first ELF, then the
fixup function understands that it is a multi ELF.
Additionally, it ensures the bootblock ELF uses MBN v7 format.
BUG=b:420542130
TEST=1. Create a image.serial.bin and ensure it boots on X1P42100
2. Used the following script to verify the hash
#! /bin/bash
image=/build/bluey/firmware/image-bluey.serial.bin
bin=/tmp/bb.bin
seg=/tmp/bb.seg
hash=/tmp/bb.hash
#
# Bootblock is the final ELF of the multi ELF. Hopefully
# there is no other ELF in ${image}. Get the offset of the
# final ELF in ${image} and get it out
#
bb_offset=`od -Ad -w4 -tx4 ${image} | grep 464c457f | tail -1 | cut -f1 -d ' '`
dd if=${image} of=${bin} skip=1 bs=${bb_offset} &> /dev/null
#
# The last two segments of the bootblock ELF have the actual
# executable and the hash. 'LOAD' is the executable segment and
# the other is the hash segment. Get their offsets and convert
# to decimal.
#
offs=`readelf -lW ${bin} | tail -2 | awk '{print $1" "$2" "$5}'`
offs=(`printf "%s %u %u %s %u %u" ${offs}`)
#
# Get the executable and hash segments
#
if [ ${offs[0]} = "LOAD" ]; then
first=${seg}
second=${hash}
else
first=${hash}
second=${seg}
fi
dd if=${bin} skip=${offs[1]} bs=1 count=${offs[2]} of=${first} &> /dev/null
dd if=${bin} skip=${offs[4]} bs=1 count=${offs[5]} of=${second} &> /dev/null
#
# Find the SHA384 hash for the executable segment
#
sha=`sha384sum ${seg} | cut -f1 -d ' ' | sed 's/../& /g'`
echo ===================================================
echo Expected hash:
echo
echo ${sha} | fold -w48
echo ===================================================
echo
hexdump -C ${hash} | grep -A4 "`echo ${sha} | cut -f1-4 -d ' '`"
Change-Id: If57ba0cc9a4f08b69d7712f27c215339307e73d4
Signed-off-by: Varadarajan Narayanan <vnarayan@qualcomm.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88148
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GCC 15 added a new `unterminated-string-initialization` warning. Even
though crossgcc is still using GCC 14, some Linux distributions (e.g.
Arch Linux) already started shipping GCC 15. Given that coreboot uses
`-Werror` (warnings are errors), this new warning causes build errors
for things built using the host toolchain, such as utilities. In this
case, cbfstool is affected, which prevents building coreboot images.
The nonstring attribute is used to tell the compiler whether or not a
string is intentionally not null terminated. Since the attribute is
only included in GCC 15 for multidimensional character arrays (and even
later for clang) we need to check the GCC version before using the
attribute.
On GCC version prior to GCC 15 the nonstring attribute will not be used,
but that is not a problem since the unterminated-string-initialization
warning only exists since GCC 15. So you can still build on all GCC
versions as before. This way it also works if your host toolchain is GCC
15 (which builds commonlib code for cbfstool) and your coreboot cross
toolchain is GCC 14 (which builds commonlib code for coreboot).
Clang is a diffent matter. According to the documentation, the nonstring
attribute only exists in version 21 which is not yet released by LLVM.
TEST=Build qemu/Q35 successfully
Change-Id: I919d71cb2811e91869ba1ff493a0719ddcc86c36
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87825
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To allow adding more scripts to the util/mtkheader folder, rename it to
util/mediatek. Also update description.md and regenerate
Documentation/util.md and util/README.md by util_readme.sh.
Change-Id: Ibc6ef9dddc541d2dd471898af431cadde231edca
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
FMAP should not contain information about the memory map.
Done with the following command:
"find -name \*.fmd -exec sed -i 's/\(FLASH\).* \(.*\) /\1 \2 /' {} \;"
for AMD:
All addresses that amdfwtool expects as command line parameter have the
ADDR_REL_BIOS (flash address) address_mode setting. One exception is
the *_FW_A_POSITION and *_FW_B_POSITION addresses. But amdfwtool checks
if memory or flash addresses are passed and converts accordingly. So
changing the address from memory -> flash doesn't matter for the
resulting binary.
Since commit 41a162b7a8 ("soc/amd/phoenix/Makefile.inc: Pass APOB_NV
address as offset") and therefore since phoenix SOC, APOB_NV is passed
as flash offset. But before that the memory ABL always assumed a MMIO
address (no matter the address_mode) so we need to add a little quirk
for that.
tested: boot glinda based mainboard and also check that memory training
is still cached successfully in APOB_NV.
Change-Id: Iac86ef9be6b14817a65bf3a7ccb624d205ca3f99
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The help text of cbfstool's memory map window assignment option
needs to be corrected to [--mmap flash-base:mmio-base:size] from
[--mmio flash-base:mmio-base:size].
P.S. The option --mmap was initially introduced by
commit 34a7e66faa ("util/cbfstool: Add a new mechanism to
provide a memory map").
Change-Id: I5f8224c8789e642fc68f6ae2242e8e7a7228c8de
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
For adding missing \n, find all potential missings by below script
and apply manual checks and fixes.
grep -nE "(DEBUG|ERROR)\(\".+[^\\n]\"" util/cbfstool/ -r
For using __func__ in debug message, below script is used with
manual checks and fixes.
grep -nE "DEBUG\(.+:" util/cbfstool/ -r
Change-Id: I3e2c225dc16a65470f9f94db89d8ec3711e781c8
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86567
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Since add-int is intended for manipulating options stored as integers in
CBFS (such as SeaBIOS runtime config options), removing the file so that
it can be re-added with a new value is a common action. Attempt to
remove the existing integer automatically if it already exists to remove
the need for the extra step.
Change-Id: I5a0ac409fc9b91a4f7c0c35650875d6211ac2b25
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86009
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As suggested by the linter:
> Prefer 'unsigned long' over 'unsigned long int' as the int is
> unnecessary
In fmap_bsearch(), removed needless assignment of offset; it is already
set to 0 in the search loop.
fmap_find() uses the return value of fmap_bsearch(); and is declared as
'long int'. Per the linter warnings, replaced 'long int' by 'long'.
> Prefer 'long' over 'long int' as the int is unnecessary
Link: https://qa.coreboot.org/job/coreboot-untested-files/lastSuccessfulBuild/artifact/lint.txt
Change-Id: If94e70778d0302552f151c31d3073524162faf9e
Signed-off-by: Ariel Otilibili <otilibil@eurecom.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85786
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Since commit 34a7e66faa ("util/cbfstool: Add a new mechanism to
provide a memory map") the ext-win-base and ext-win-size option has been
replaced with the "--mmap" option.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I33cfb59d9dbe88c4f618301ac1506e3281b1a483
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85619
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.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>
This patch introduces logging for the ELOG_TYPE_FW_CSE_SYNC event. This
event logs data related to CSE synchronization, along with the relevant
boot stage information.
BUG=b:305898363
TEST=boot verified on google/rex0 and google/rex64
Change-Id: I4d6d3c4e07ab8677feb6a8acf8d4c6604ab704b8
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85218
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
LLD deals with loadable segments in a different manner than BFD. The
MemSiz of the .text loadable section is padded till the virtaddr of the
.car.data section. Since .text is not loaded in ENV_CAR this does not
matter.
Change-Id: I1a0541c8ea3dfbebfba83d505d84b6db12000723
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84043
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`cbfstool add-stage' crashes with a segmentation fault when generating
the program binary out of a romstage ELF containing relocation within
the data segment.
This commit makes `parse_elf_to_xip_stage()' look for the segment to
which the current relocation applies and compute the appropriate
location within the program binary.
This issue can be reproduced by defining a global variable with a
pointer to constant data. This variable is defined within the .data
section and contains a pointer to a constant which resides in the
.text section. As a result, a relocation entry is generated in the ELF
file.
struct my_struct {
const char *name;
};
struct my_struct my_global = { .name = "EXAMPLE" };
void fun(void)
{
printk(BIOS_DEBUG, "my_global.name=%s\n", my_global.name);
}
TEST=global data structure with a pointer to a constant does not make
cbfstool crash
Change-Id: I480b4b047546c8aa4e12dfb688e0299f80283235
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Intel platform boot policy setting blob is linked into FIT table
as an FIT4 entry. It is required for server executing CBnT and/or
PFR without a PCH.
Please refer to chapter 4.6 of the document in below link:
https://www.intel.com/content/dam/www/public/us/en/documents/
guides/fit-bios-specification.pdf
Tool usage:
./util/cbfstool/ifittool -f <binary> -a -n <cbfs name> -t 4 \
-r COREBOOT -s <max table size>
Change-Id: I0f9fc61341430b1a35a44d50b108dcfaf31cd11c
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Signed-off-by: Li, Jincheng <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84305
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When parsing XIP stages only compare PT_LOAD phdrs. Currently coreboot
stages only use PT_LOAD phdrs.
Change-Id: I305b25032a3c4a9fdefc76cad77fafdb862a604c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Currently, cbfstool prints the following error message when the added
file doesn't fit in the region:
E: Could not add [file, 1024 bytes (1 KB)@0x0]; too big?
It requires manual inspection to know the space left in the region. To
make that easier, also print the maximum empty CBFS entry size in the
error message:
E: Could not add file [header 76 + content 1024 bytes (1 KB)] @0x0;
Largest empty slot: 512 bytes
Change-Id: I00bcc83abe8b0a33dcd7b75521e6cfccd8953661
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84204
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.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>
This adds some error handling to the code that adds the input segments
(e.g. kernel, cmdline, initrd...) to the output file.
Currently the compress function can fail and coreboot will still
build "successfully" leaving whoever build coreboot puzzled.
Change-Id: Ie36ad469c73cb3ff9360acc9bbe66c245e8b4a1e
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83617
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Compressing the already compressed bzImage does not yield any
fruit. If you are lucky it actually makes the image a little bit
smaller. If you are unlucky the image actually gets bigger and since the
compressing function is not checked for any errors, coreboot just builds
successfully even though the payload is broken through compression.
Before this patch you could possibly get this error during compilation:
```
E: LZMA: LzmaEnc_Encode failed 9.
```
and your linux payload would end up something like this in CBFS:
```
FMAP REGION: COREBOOT
Name Offset Type Size Comp
....
fallback/payload 0x1c9c0 simple elf 511 none
....
```
That doesn't stop coreboot from finishing the build though, since we
currently don't check for errors from the compression. That is an issue
for another patch though.
Tested:
Build and run QEMU-Q35 with Linux bzImage as payload.
Change-Id: I022982667515ce721d98af534414d9e336b5f35a
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83615
Reviewed-by: coreboot org <coreboot.org@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
The compressing and decompressing functions return 0 on success and not
the other way around.
Change-Id: I9f8653aa805c62eb4bfc3560d7880921830c2c59
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83616
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to support logging events for when we show early signs
of life to the user during CSE FW syncs add support for the
ELOG_TYPE_FW_LATE_SOL type.
BUG=b:305898363
TEST=verify event shows in eventlog CSE sync.
Change-Id: I862db946f6ff622ac83072e6bf27832732c0c318
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
On x86_64 romstage can contain page tables and a page table pointer
which have an larger alignment requirement of 4096. Instead of
hardcoding it, read if from the ELF phdrs.
Change-Id: I94e4a4209b7441ecb2966a1342c3d46625771bb8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82102
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The SPDX parsers can find the SPDX identifiers in the scripts and
makefiles if they aren't broken up. This unnecessarily confuses things
when we're doing license parsing.
Change-Id: I215ed047397f342c912f1a969315fa184a124f6a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80585
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
linux_trampoline.c generation is broken with latest crossgcc-i386
toolchain. Fix the issue to enable the building.
../cbfstool/linux_trampoline.S: Assembler messages:
../cbfstool/linux_trampoline.S💯 Error: no instruction mnemonic
suffix given and no register operands; can't size
instruction
<builtin>: recipe for target '../cbfstool/linux_trampoline.o'
failed
TEST=Build and boot on intel/archercity CRB
cd util/cbfstool/
rm linux_trampoline.c
make linux_trampoline.c
Change-Id: I7faca296f946bb4e9fd510661357925e5dcf9a6b
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82704
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
<stdio.h> header is used for input/output operations (such as printf,
scanf, fopen, etc.). Although some input/output functions can manipulate
strings, they do not need to directly include <string.h> because they
are declared independently.
Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is useful for listing older images.
Change-Id: I588028d4327f59538f7c9920b671458fc631cb4c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81504
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>
SELF has the fields wired up for 64bit, but adding flat images cuts the
upper half.
Change-Id: I3b48b8face921e942fb0e01eace791ad3e1669a0
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80576
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since linux commit f9ba70535dc12d9eb57d466a2ecd749e16eca866
"[PATCH] Increase number of e820 entries hard limit from 32 to 128"
made in 2005 the number of e820 entries passed from the bootloader
is 128. Use the boot protocol version to check for support of
128 entries and use them if necessary.
Tested on IBM/SBP1:
Fixes booting a Linux payload when more than 32 entries are present
in the memory table, which can easily happen on a 4 socket platform.
Change-Id: Iec0a832fff091b6c3ae7050ef63e743a30618f25
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marvin Drees <marvin.drees@9elements.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I434940ebb46853980596f7ad55d27a62c90280fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Always use the high-level API region_offset() and region_sz()
functions. This excludes the internal `region.c` code as well
as unit tests. FIT payload support was also skipped, as it
seems it never tried to use the API and would need a bigger
overhaul.
Change-Id: Iaae116a1ab2da3b2ea2a5ebcd0c300b238582834
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79904
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Use same indent levels for switch/case in order to comply with the
linter.
Change-Id: I2dd0c2ccc4f4ae7af7dd815723adf757244d2005
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Eric Lai <ericllai@google.com>
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>
