The QT based xconfig util is broken for several reasons.
1. On systems with qt6 (which is a majority on modern distros),
the qconf-cfg.sh script appends a c++17 flag to the output file,
which makes the value of $(HOSTCXXFLAGS_qconf.o) - a multiline string.
This causes problem during compiler invocation, thus we can observe:
'g++: fatal error: no input files'
Flattening the HOSTCXXFLAGS_ with $strip function resolves the problem
2. The missing Qt's Meta-Object file "qconf-moc.cc",
which should be autogenerated during build by invoking "moc" tool.
The current set of recipes in Makefile.mk aren't triggering
the moc generation. Explicitly adding "qconf-moc.o" target,
with dependency on "qconf-moc.cc" resolves the problem.
3. "$(call if_changed,moc)" used to invoke "moc" tool isn't working,
due to missing "if_changed" macro.
Replace it with direct call to "cmd_moc" in "Makefile.real".
Bringing the full implementation of "if_changed" seem to be impractical,
as it uses too many dependent functions and macros.
BUG=https://ticket.coreboot.org/issues/518
Change-Id: I7eb1e71aeb6a92b8d3c194a369bd3bd6dc708863
Signed-off-by: Dmytro Aleksandrov <alkersan@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89006
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit introduces a new constant, ELOG_WAKE_SOURCE_PME_BLUETOOTH,
with the value 0x31 to represent Bluetooth as a wake source in the ELOG
event data structure. This change facilitates diagnostics and
event logging related to Bluetooth activity.
The cbfstool eventlog has been updated to include "PME - BLUETOOTH" in
the wake source types for event data printing.
Change-Id: Ib628502ddcccb4a781394a39b2aee6efa05ecf84
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
`src/mainboard/*/common` doesn't need a Kconfig.name, so don't check
for one.
Change-Id: I6c69c174287f7f068e28ed9c33b9b5542c87ca60
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89051
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Adjust the linter to skip `common` directories, as a board_info.txt
serves no purpose there.
This also changes `sort | uniq` to `sort -u` for efficiency.
Change-Id: I29639d8b620bcd4f2f7032802f375d79ac391535
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89050
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Trying to read a firmware binary for Turin platform results in
"Invalid address(41400) or mode(0)" error. The utility does not
respect the address mode set by the directory header. The address
mode of th entries is valid only if the address mode of the directory
is equal to 2 or 3.
Check the address mode of the directory and use it for entries only
when its value is less than 2.
TEST=Successfuly parse vendor BIOS for Gigabyte MZ33-AR1.
Change-Id: I479bc846bfb334231fdc707274a8ac44b6c384d4
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
According to AMD documentation, starting from Family 17h Models
00h-0Fh, the PSP on-chip boot loader reads the PSP directory pointer
from offset 0x14 in the Embedded Firmware structure, replacing the
previous offset 0x10.
The docs do not specify any special value indicating a change of
offset. Some AMI binaries use a zero address in this directory field,
which caused incorrect offset handling.
Change-Id: I67ab763d070a9580a8269b525b203c932c5b1b95
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Intel ifdtool can dump the Intel Firmware Descriptor, which is helpful
for debugging and inspecting firmware binaries. This utility lacked
similar functionality, so this patch introduces a `--dump` CLI option
to display decoded information from the embedded firmware header.
Currently, the output includes SPI frequency and read mode for various
AMD family models.
Change-Id: Ideb1076f1d580496dac293882007cfa4672d188b
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
smmstoretool is effectively a UEFI variable store writing tool, with
a specific emphasis on the SMMSTORE backend implementation.
However, it could also support other backends. Since it's typical for
the variable store to be `n / 2 - 1` blocks, but not typical how large
each block should be, allow this to be overridden on the command line.
This is necessary because in EDK2, the module producing the firmware
volume block protocol, the backend, will initialise a HOB or set PCDs to
indicate the size of the store to the rest of the stack, and an
assertion will be hit if the store has been preseeded by smmstoretool
using differently-sized blocks.
For example, `make CFLAGS=-DSMM_BLOCK_SIZE=8192` builds this for a
firmware volume block protocol implementation with 8K blocks.
Change-Id: I08b78cfb0b591641f09fcf86f40dd31e6b6c9b30
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Call to abort() in die() causes many tools to assume that the cbmem util
crashed even in case of just incorrect parameters. Changing it to
exit(1) allows for easier error handling by just getting the exit code
instead of having to handle SIGABRT.
Change-Id: Ic59e3479dcbe090a43878bf773409781729146c8
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88981
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This script will warn and suggest fixes when a CB:<change-id> of an
already merged change is found in the commit message. This should
enforce the clarification that was added to the documentation in
CB:88776.
This script requires a JSON parser (i.e. jq) to parse Gerrit's
REST API[1]. While it may be possible to grep the values, we chose to
use a proper parser to ensure there would be no false-positives.
TEST=
Prepare a commit with the following commit message:
Here are some open changes: CB:88614 CB:88717 CB:87282
Here are some abandoned changes: CB:88413 CB:84504 CB:82136
Here are some merged changes: CB:88566 CB:88598 CB:88697
Here are some old merged commits: CB:1 CB:50 CB:950
Here are some wrong stuff: CL:100 CB:TEST CB:99999
The script produces the following result (may change in the future when
open changes are merged etc):
Using a change ID (CB:88566) for an already merged commit; please replace it with:
commit 21639c3771 ("mb/getac/p470: Use common gpio functions")
Using a change ID (CB:88598) for an already merged commit; please replace it with:
commit 05a38e2af3 ("mb/google/fatcat: Disable memory training progress bar")
Using a change ID (CB:88697) for an already merged commit; please replace it with:
commit 1da2f46db8 ("soc/intel/alderlake: Restore mem_init_override_channel_mask()")
Using a change ID (CB:1) for an already merged commit; please replace it with:
commit 140a990a61 ("Teach abuild to emit JUnit formatted build reports")
Using a change ID (CB:50) for an already merged commit; please replace it with:
commit 7c634ae8c1 ("msrtool: added support for Intel CPUs")
Using a change ID (CB:950) for an already merged commit; please replace it with:
commit c31384e62c ("Fix up Sandybridge C state generation code")
CB:99999 does not exist
[1] https://gerrit-review.googlesource.com/Documentation/rest-api.html
Change-Id: I1c72f739b1f47b1227ef1e158b1553aa56945d7e
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Move the NULL pointer check to the beginning of the fill_dir_header function
before any dereference of the directory pointer. This prevents the potential
segmentation fault that could occur if directory is NULL.
This fixes CID 1540835 - Dereference before null check (REVERSE_NULL).
Change-Id: I12bb146d59839381478034f974b7d408f92ae677
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88617
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Perl 5.42.0 added a new warning for possible precedence problems between
the `!` logical negation operator and various other operators [1]. In
particular, the kconfig_lint script uses `!` and `=~` (binding operator)
to check that a filename does not match a regex, but was written in a
way that would be parsed as negating the filename and then comparing it
to the regex. The resulting warning from the newer version of Perl
caused lint-stable to fail on the lint-stable-008-kconfig test due to
the non empty output, causing the pre-commit hook to fail.
Fix this by using the negated binding operator `!~` instead as
recommended by the Perl documentation [2].
[1] https://perldoc.perl.org/perl5420delta#New-Warnings
[2] https://perldoc.perl.org/perldiag#Possible-precedence-problem-between-!-and-%25s
Change-Id: I3631b8b0be92bf85a1510be1f1d4221a010be1ba
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88619
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Finalise the new support for adding secure boot variables by adding this
alias. db and dbx have this GUID, all others (PKDefault, KEKDefault,
dbDefault, dbxDefault, PK, and KEK) have the "global" GUID.
Change-Id: I58a825498d57c0bc04516fe41fe94924bdff2181
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88426
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This commit adds support for CBMEM in sysfs. Useful for systems without
access to /dev/mem e.g. Android.
Linux kernel driver: drivers/firmware/google/cbmem.c
Linux driver Kconfig: CONFIG_GOOGLE_CBMEM
BUG=b:391874512
TEST=(devmem) cbmem -l; cbmem -x; cbmem -r 434f4e53; cbmem -t;
cbmem -a 1200
TEST=modprobe cbmem; cbmem -l; cbmem -x; cbmem -r 434f4e53; cbmem -t;
cbmem -a 1200
Change-Id: I527889509ffc84203be42d0160e5363c60eafd02
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86606
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Ensure that only one PT_LOAD segment is inside the input ELF as
the tool only expects and support one PT_LOAD segment. Instead of silently
discarding all other PT_LOAD segments than the first throw an error.
Change-Id: I90cfc8b9dd0b5e8060880790e5ff0ce73843943b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87315
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If fit_table_entries() fails, it returns zero, but the sort loop
subtracts 1 from that value before comparing for the loop termination.
Since the value is unsigned, this results in wraparound overflow,
effectively causing an infinite loop. To mitigate this, store the
number of FIT entries as an int, and use that for the loop exit
condition check. Use int type for the loop counters as well to
avoid the compiler complaining about an signed/unsigned comparison.
BUG=CID 1612099
Change-Id: Id0a16bdb86d075ec6c322b44fd782f81d15ca6a7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88324
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Extract devmem-specific code to a separate file providing unified API.
Move hexdump() and cbmem_print_entry() to common.c.
Create common function for getting coreboot table entries. This can be
adjusted later to use higher-level API that selects appropriate backend.
BUG=b:391874512
TEST=cbmem -l; cbmem -x; cbmem -r 434f4e53; cbmem -t
Change-Id: Ic11f0659833e03324f6909fa3c1d62c36988b7b7
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This adds parsing for some more possible firmware blobs on AMD.
These binaries are used on a mainboard based on glinda SOC.
Tested: Boot birman_plus mainboard
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I78d7a9dba71de557e0a9a885d8561eea1f4191ef
Original-signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84373
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MonotonicCount is required, or UEFITool fails to parse the store.
TimeStamp is required for variables with authenticated attributes.
Change-Id: Iea933c9943ec18ea773700cdf1e3bede0e8ef292
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88424
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This helps with initialising UEFI secure boot variables for the first
boot, for example, by setting PKDefault, KEKDefault, dbDefault and
dbxDefault to the desired certificates.
Tested, and the get subcommand returns the same data that the set
command added. However, EDK2's variable driver (from approximately
edk2-stable202505) asserts that the variable store isn't the expected
size, and UEFITool can't decode it correctly. This is also the case for
other types supported before this patch, suggesting that the bug is in
general variable-handling code in this utility. Will be debugged and
addressed in a follow-up.
Change-Id: If36394bb56388a35882702c93e26e63124fe0a63
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88377
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the header size is equal to fv.length, then `fv_parse()` will go
out-of-bounds when obtaining the variable store data, and obviously,
there is no data if the header takes up all available space.
Change-Id: I0ac46e098a14b51f936cb99f5e6bf83411570bc5
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
We want to distinguish between a variable store that's marked as capable
of storing authenticated variables (basically, checking their signatures
and promising that there's no TOCTOU possible), and a variable with the
authentication-checking enabled.
Change-Id: Ibf6ffbe279961ff54b0988d98a912a8421598e3b
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88423
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
ec_usb_pd_fw is a board specific utility to generate pointers to
firmware images found in the SPI flash. On some AMD boards the
x86 SPI flash is shared with the EC. The EC can also update the
USB Power Delivery controllers firmware, but it needs to know where
to load the firmware from. It uses pointers stored in the first
128 bytes of the x86 SPI flash.
Add a small utility to generate pointers to the USB PD firmware,
located somewhere in the ROM identified by the FMAP region.
There can be up to 12 USB PD firmwares, depending on the used
vendor or model.
Change-Id: I98717e849592f83eb7bacbfed33a8d4b811a5e18
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87430
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Microchip EC can share the SPI flash with the x86 host. Since
it boots first and does power sequencing, there's no problem with
concurrent access happening. Due to various vendor specific flash
layouts used on x86, the EC needs a pointer to it's own firmware.
The pointer resides at flash offset 0 and is read by MEC152x and
MEC1701 and MEC172x ECs, probably others as well.
The introduced tool generates the EC FW PTR at flash offset 0.
Allows to get rid of hand-crafted binary files (EC_SIG) being used
on AMD mainboards that hardcode the offset and must manually being
checked if those match the FMAP.
When there'll be additional firmware regions added it becomes
unconvienient to maintain those by hand.
Usage output:
Usage: ./util/mec152x/mec152xtool <rom-file> <command>
-h|--help
-f|--fmap_region_name
Command:
GEN_ECFW_PTR - Writes the ECFW PTR
Based on https://chromium.googlesource.com/chromiumos/platform/ec/+/08f5a1e6fc2c9467230444ac9b582dcf4d9f0068/chip/mchp/util/pack_ec_mec172x.py
Change-Id: I3b74c9f65643ad4437de29d4aed307b1a2b33286
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
By default, when building all boards, we use a single thread for each
board and build a number of boards in parallel. The --sequential-boards
flag will change that to use all specified cores to build each board
in sequence.
This can give better performance in some cases where multiple builds
are conflicting for a given resource.
Change-Id: I35ae7a5df5de48b8ce3373b6659be0df5104ed39
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88239
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When parsing the string, if it doesn't end with 0 or \n, get_line_as_int
returns -1, but wasn't freeing the buffer. Also if we got an empty
string with just null termination, that byte would also cause a leak, so
move the second free() to the bottom. It's always fine to free a null
pointer if the allocation failed.
BUG=CID 1419489
Change-Id: Ibb3a7544ec8c46820b6e47b6fd4bbe5cabafe1a8
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88335
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 712dfb3761.
printf formats fixed to use PRI* macros instead of raw values.
BUG=b:391874512
TEST=cbmem -l; cbmem -x; cbmem -r 434f4e53; cbmem -t; cbmem -c \
On both x86 (Brya) and ARM64 (Corsola)
Change-Id: Iba6e3af080fe10c4a55adfcaee9c373a2cce1378
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88292
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When compression fails (usually due to larger result), we could retry
with memcpy() as in cbfs-mkpayload.c, instead of stopping immediately.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: Id8b2cffef3832c4bad49bd722c9a5133735f61b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87934
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Builds using SBOM were failing in the release because we don't have a
git tree to get information from. We can't assume that the coreboot
source will always be in a git tree, so it needs to be updated. This
updates build.h to contain all the data that the SBOM wants and changes
the SBOM makefile to get its information from build.h which can generate
the required data in a number of different ways.
Change-Id: I59fba349d95cb0dcff7a31d335f4acb4f11c89c7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88236
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Due to a recent acpica version upgrade, the acpica tool is now
failing to download due to an incorrect url. This commit aims to
fix the issue by updating the iasl base url to match the upgraded
version.
Change-Id: I7eddff2d17587f5d90295928800c10068c8cf281
Signed-off-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88278
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The QCOM X1P42100 SoC requires images loaded by PBL in MBN v7
format. This script is updated to support MBN v7 format which will
be used to generate the Bootblock binary.
Starting with the Qualcomm x1p42100 SoC, the bootblock ELF header
expects MBN version 7 instead of version 6 with the SC7280 SoC. This
patch adds the necessary adjustment to ensure compatibility with older
SoC platforms and also adds incremental support for newer SoC
generations. If Qualcomm SoCs in the future demands a more advanced
version of MBN (version > 7), additional logic will be added to the
newly added section as `self.flash_parti_ver == 8`.
BUG=b:420542130, b:404985109
TEST=Create image.serial.bin with bootblock in MBN v7 format and
ensure it boots on X1P42100. Please refer to the steps mentioned
below to create final AP FW image for QC SoC X1P42100.
Step 1: Create Bootblock MBN image using createxbl.py script where the
newly added MBN v7 support will be used.
Step 2: Call create_multielf.py to create the concatenated multi ELF
( TME SEQ + TME FW + QC_SEC + BOOTBLOCK from step 1)
Step 3: Call nqgpt.py to create final GPT image.
Change-Id: I484df537ac7d1e51ec86dcae74a74dc211710616
Signed-off-by: Sasirekaa Madhesu <smadhesu@qualcomm.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88240
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
compiler-rt is not a variable used by the LLVM_ENABLE_PROJECTS config,
but has a separate configuration option.
Change-Id: Iacd9b5f1fc1444b3dd1a785b91510f346e7a2f51
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80737
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The old test code used outdated function declarations that break with
C23 in GCC 15. Instead of forcing C17 standard:
1. Add full prototype for g() function
2. Use 'void' for empty parameters
3. Clean up messy formatting
This keeps C23 compatibility while fixing the build.
Tested with GCC 15.1.0
The -std=gnu17 workaround is no longer needed.
Change-Id: I718a5ed5c11742b1c3448abf7198c96ac78bc98a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
"--parallel" is not a valid option for CMake.
Change-Id: Idba76ce6a29e5d582ce49aa91ce4013aebc6d835
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The mb/adlink directory no longer exists, so remove it from the list of
checked directories.
Add a check to make sure that the directory exists before trying to lint
it in the future.
Change-Id: I59874cb7356c2e8eeb8fc216f2930b3d8ef513c7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88237
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Change .inc to .mk. This was missed when renaming the makefiles.
- Verify that dirs/files exist before checking.
- Use $FINDOPTS to control search when not in a git repo.
Change-Id: If0d80403a3e799b8103164cc075601a50c33a8d9
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The Kconfig linter was browsing into the openSIL tree and reporting
issues for the release because it can't use git grep there. This change
explicitly tells the Kconfig linter to ignore the openSIL submodule.
Change-Id: Ia0399225cced9f199a6d2a90bc6c2af905ff4e99
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The binary files were not being correctly filtered. This tells grep to
just ignore binary files. This isn't particularly important inside the
git tree, but for releases where we can't use git grep, it becomes an
issue.
Change-Id: I2852ea1e8b0f337aa5c78daa5e9dbd0c3d6768a9
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
