The script was failing when origin/main doesn't exist. Instead of
trying to detect or use a main branch, simply save the current HEAD
hash and restore it when done. This works regardless of branch names
or remote configuration.
Also improve the clean check to use git diff-files instead of
comparing to a specific branch.
Change-Id: I237de4b1e8a06fd4e1e3ef08286208c130e7a6bd
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90502
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is the MCH Strap Length, and FMSBA is the corresponding
Flash MCH Strap Base Address. See ICH8 datasheet, FLMAP2.
Change-Id: I322c13d9228800a2736b0288377495287521712c
Signed-off-by: Daniel Maslowski <info@orangecms.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89614
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As of commit 31fc5b06a6 ("device: Introduce reworked azalia verb
table"), all boards using the old azalia verb table format must select
CONFIG_AZALIA_USE_LEGACY_VERB_TABLE. The generated output of autoport
uses the old format, so select the config.
This is only meant to be a temporary measure as opposed to reworking
autoport to produce the new format, as I would rather incorporate
hda-decoder's functionality to generate hda-verb.c instead of
duplicating efforts. Support for the new format in hda-decoder is
currently WIP on CB:84357.
Change-Id: I54c6a92a69039eb747ee8cc6d5186dc3a3c6acc8
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90055
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add register tables and device IDs for Phoenix AM5 desktop CPUs.
TEST=Dump all data with amdtool on MSI PRO B650M-A.
Change-Id: Ia7af9194fb7516e98b7cddee2bfc65af12d56dc0
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90009
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an utility similar to inteltool, which dumps useful information
for porting a board to coreboot.
TEST=Use amdtool on Gigabyte MZ33-AR1 with vendor BIOS and coreboot.
Change-Id: I34405897d0f5670038e7923f3680a28090d92821
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89492
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Allows ifittool to add FIT entries for files that are located in a
different FMAP region than the FIT table.
The region from where to source the file can be specified with -R.
If not given it defaults to using the value of the mandatory -r,
for full backwards compatibility.
Example: Tested with a custom binary with the bootblock and
corresponding FIT table in a separate region, and the microcode still
in the COREBOOT region:
λ ./ifittool -f test_ts.rom -a -n cpu_microcode_blob.bin -t 1 \
-r BOOTBLOCK \
-R COREBOOT \
-s 4
Change-Id: I7e49247f280ec118e09cf173795d7602a4c0d7f6
Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89608
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
LZMA checks at util/cbfstool/lzma/lzma.c:Write() for the output
buffer/stream size and does not write beyond it.
LZ4 checks at src/commonlib/bsd/lz4.c.inc:LZ4_decompress_generic() for
the buffer/stream size and does not write beyond it.
Change-Id: I41298b509b3f5e775bb4000c82c539eefa80c885
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
It was accidently added and is just dead code.
It doesn't change any functionality.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I868b8c8725fc2240543fb1e9e379ecb5e1471ef4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89898
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Switch to using `objdump -f`, which consistently prints the line
"file format <format>" across modern binutils versions, and extract
the architecture format from that output. This restores correct
toolchain detection on Ubuntu 25.10 and other systems with binutils
≥ 2.43, without breakng older versions.
Before:
DEBUG: obj_type:
/tmp/temp.rrDQ8i.o: file format elf64-x86-64
DEBUG: obj_arch:
After:
DEBUG: obj_type:
/tmp/temp.8GsK08.o: file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000000:
start address 0x0000000000000000
DEBUG: obj_arch: elf64-x86-64
Change-Id: Ic09304f9e81580bbe1c0bb4910c0cc534d3d2816
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89643
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
A .gitkeep file is an unofficial convention used in Git to keep and
track empty directories, as Git does not track empty folders by default.
This could be needed when one mainboard variant has an include directory
but another doesn't. If the directory is added to the include, it could
be easier to just create an empty include directory with a .gitkeep file
in it to keep things from failing.
Change-Id: I34b2ffa4d748d82e26867ecd5b9149301300e6a1
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
The amdfw.rom will be divided into 3 parts:
PSP Level 1, PSP Level 2A, PSP Level 2B.
The two ISHs are close to L1 and can be combined as a CBFS module.
To do that, move the new_psp_dir for L1 and L2 to separated branches.
The final sequence is EFS, PSP L1, ISH A, ISH B, PSP L2A, BIOS L2A,
PSP L2B, BIOS L2B.
TEST=Google/Skyrim
Change-Id: Id69268619893d78d9b5330052a4fd5b501263f75
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
coreboot does not use the nds32le-elf toolchain at all, but it causes
build issues in the CI. So drop it from the default builds. It can
still be built by using buildgcc.
Change-Id: I5e5e5b6914265d6aff14c011062db268db4acf6b
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89317
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MAINTAINERS file is used to automatically assign reviewers on
Gerrit, however as the paths are not checked they can become out of
sync with the codebase. This is detrimental to both the uploader
and the maintainers, as the change may not get the appropriate
attention.
Fix this problem by adding a simple check for 'F' and 'X' entries.
Change-Id: I7755f6317edda0d8d976e138cfafcc3ef5850ead
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add PCI IDs and descriptor strings of the integrated GPU
for the Twin Lake CPU.
Reference document: #759603 Rev 002
---
CPU: ID 0xb06e0, Processor Type 0x0, Family 0x6, Model 0xbe, Stepping 0x0
Northbridge: 8086:4617 (12th generation (Alder Lake N family) Intel Processor)
Southbridge: 8086:5481 (Alder Lake-N)
IGD: 8086:46d3 (Intel(R) UHD Graphics)
---
TEST=build and run inteltool on N355 mini pc, verify GPU ID is not unknown.
Change-Id: I8921bd1e22690acbb71547590905f739485126fb
Signed-off-by: Dmytro Aleksandrov <alkersan@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89529
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for taking the ifdtool platform parameter via the cmd
line, as well as the output directory. Add double quotes around
variables as needed. Add help output describing new parameter options.
TEST=run script against images from skl, adl, and mtl platforms.
Verify no warning from ifdtool that platform is unknown.
Change-Id: I4a27c9876bf639579b791c894b2cbfdae7ab63c1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Because the name NINJA has 2 occurrences inside remote recovery.conf:
https://dl.google.com/dl/edgedl/chromeos/recovery/recovery.conf
Running 'crosfirmware.sh ninja' will list both NINJA and VORTININJA
"file= & url=" with a total of 4 lines instead of 2. Since the script
by default uses the last 2 lines it will prefer VORTININJA and download
the Octopus MEEP recovery image instead while NINJA was requested.
By adjusting 'grep' its matching control by adding '-w' restores the
correct behaviour of only showing 2 lines for the requested image.
Both NINJA, VORTININJA and a third recovery image TIDUS still download
and extract correctly when applying this fix.
TEST=crosfirmware.sh ninja #downloads and extract correct image
Change-Id: I9b55c5a2626339e70f0ada9b80c9488a5580d371
Signed-off-by: Walter Sonius <walterav1984@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
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>
