Generate a signed UEFI capsule from the final coreboot ROM image using
EDK2 BaseTools.
When using an EDK2 payload and enabling DRIVERS_EFI_UPDATE_CAPSULES and
DRIVERS_EFI_GENERATE_CAPSULE, the build produces build/coreboot.cap once
the ROM is finalised (after all files were added to CBFS). The capsule
can also be generated explicitly with `make capsule`.
Move the capsule generation and certificate preparation into
payloads/external/edk2/Makefile, including generating the trusted root
certificate PCD include via BinToPcd.
Support capsule flows with an embedded FmpDxe driver by optionally
embedding FmpDxe.efi into generated capsules, and wiring the
embedded-driver Kconfig options through to the EDK2 payload build and
capsule generation.
Always set PersistAcrossReset on the capsule. Make InitiateReset
configurable (default off) because Linux rejects capsules with
InitiateReset when writing via /dev/efi_capsule_loader.
Use CONFIG_DRIVERS_EFI_MAIN_FW_VERSION for GenerateCapsule
--fw-version, but fall back to parsing a leading <major>.<minor> from
CONFIG_LOCALVERSION when it is left at 0. If
CONFIG_DRIVERS_EFI_MAIN_FW_LSV is 0, use the resolved firmware version.
Document capsule generation and embedded driver configuration.
Corresponding edk2 patches can be found at:
https://github.com/tianocore/edk2/pull/12053
Change-Id: I5f56b894d40ddb49f3158bb72f0143d0ebe9c34c
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90862
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Moves the variables to more appropriate locations to save some lines and
make it more readable. For x86 it now also adds the intermediate, but
since x86 doesn't define any regions (e.g. ramstage) to check against,
the intermediate is effectively skipped.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I28371ae3416040243f238271ba45238ceccfcf0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90816
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For both x86 and non-x86 its the same anyway, so factor it out.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I30e6d1da8a663cd79d59d55446eda2b70269f118
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Its actually the size FMAP flash region so the name is more appropriate.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I152b66abedb68f1ab809d918502efe096e9dde59
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90811
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Also removes some dead code below which uses a dongle.py binary.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ia9b31a79f7637d31bbd824a8f6ad9137df429711
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90818
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The issue has been fixed since binutils version 2.43
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I9d8802aa0908dd2838199399e739b13c345702f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90815
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Separating the bootblock into two copies (in BOOTBLOCK and TOPSWAP fmap
regions) breaks the CBFS verification as TSPI CRTM knows nothing about
the new regions and looks for bootblock in a hard-coded COREBOOT fmap
region.
Introduce and use cbfs_unverified_area_type_alloc() which is an
extension of cbfs_unverified_area_alloc(), very similar to how
cbfs_ro_type_map() is an extension of cbfs_ro_map(). This allows to
specify a region of the bootblock file and skip verification because
bootblock serves as a container of hashes and is not verified itself.
The branching is done on the state of RTC BUC to always use the current
bootblock. Somewhat confusingly, the measurement always uses BOOTBLOCK
region because with active Top Swap that's the way to access a
memory-mapped TOPSWAP region.
Makefile.mk now verifies both COREBOOT and COREBOOT_TS regions.
cbfstool needed a few updates as well:
- recognize both "BOOTBLOCK" and "TOPSWAP" regions
- recognize both "COREBOOT" and "COREBOOT_TS" regions
- reset metadata cache before processing each region as cache may now
be invalid
SMM doesn't link with vboot functions, so cbfs_file_hash_mismatch() has
to skip verification in SMM due to the use of CMOS options backend.
This is a part of the bootblock redundancy feature proposed
on the mailing list:
https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
Tested by successfully booting into Protectli VP6670 with Top Swap and
CBFS Verification features enabled and Top Swap state being toggled.
Change-Id: Ia75e714ae84d8c0ae09b27495e3056313b109999
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89691
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a correction of CB:89570 (commit 04ea4724e2 ("Makefile.mk:
separate bootblocks into BOOTBLOCK and TOPSWAP")). It wasn't obvious
that CBFS verification depends on bootblock being added first (otherwise
cbfstool considers CBFS verification to be disabled because anchor is
part of a bootblock). Correct this and add a comment for anyone else
who might edit this code in the future.
The issue manifested itself in build failing to perform CBFS
verification via cbfstool when the firmware was built with
CBFS_VERIFICATION enabled.
Change-Id: If775480394270fc05206cde0707c511b126265d3
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90436
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Take advantage of cbfstool's ability to operate on multiple regions and
introduce a variable with a list of main CBFS regions: it's just
"COREBOOT" in most cases, but becomes "COREBOOT,COREBOOT_TS" when Top
Swap update mechanism is enabled (see [0]).
This is meant to simplify Makefiles by avoiding extra branches in
existing and future changes.
[0]: https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
Change-Id: If537d0d21a2867fafc2241ea9a0b4c0c6ca290a8
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90435
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-by: Filip Gołaś <filip.golas@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
This adds the option to compress ramstage and payloads with zstd.
zstd compressed ramstages are typically +5% bigger than lzma compressed
ramstages. The decompressor .text section grows by 20KiB and the
decompressor needs 16KiB more heap than the lzma decompressor.
To use less heap inside the zstd decompressor the build time define
ZSTD_DECODER_INTERNAL_BUFFER is used.
Quote:
The build macro `ZSTD_DECODER_INTERNAL_BUFFER` can be set to control
the amount of extra memory used during decompression to store
literals. This defaults to 64kB. Reducing this value reduces the
memory footprint of `ZSTD_DCtx` decompression contexts, but might
also result in a small decompression speed cost
TEST=Booted on Lenovo X220 with zstd ramstage showed no disadvantage
over a bigger internal buffer used.
TEST=Booted on Lenovo X220. The zstd decompressor is twice as fast
as the lzma decompressor.
cbmem -t shows:
- finished ZSTD decompress (ignore for x86) 79,444 (24,494)
- finished LZMA decompress (ignore for x86) 94,971 (45,545)
TEST=Booted on QEMU Q35, QEMU aarch64 virt, QEMU riscv RV64 with
zstd compressed ramstage.
Change-Id: Ic1b1f53327c598d07bd83d4391e8012d41696a16
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69893
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the Top Swap mechanism is enabled, after running the bootblock from
the TOP_SWAP region, boot from an updatable COREBOOT_TS FMAP region.
Having flashed the TOP_SWAP bootblock and COREBOOT_TS, this allows the
user to boot a newer version of the firmware with the ability to
revert to the previous known-good version by performing a CMOS reset.
Requires having a read-write COREBOOT_TS region in the FMAP file.
This is part of an ongoing implementation of a redundancy feature
proposed on the mailing list:
https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
TEST=Boot Protectli VP6650, setting the attempt_slot_b flag to
different values, observing the "Booting from COREBOOT/COREBOOT_TS
region" prints correspondingly.
Change-Id: Ieadc9bfbe940cbec79eb84f16a5d622bfbb82ede
Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90147
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Add Kconfig INTEL_TOP_SWAP_SEPARATE_REGIONS. When enabled, place the
regular bootblock in BOOTBLOCK and the Top Swap bootblock in TOPSWAP
to simplify A B updates. This lays groundwork for redundancy where one
bootblock remains a read only golden copy and the other is replaceable.
No swap control logic is added in this change. The option depends on
INTEL_ADD_TOP_SWAP_BOOTBLOCK and defaults to n so existing builds are
unchanged. A custom .fmd is required with BOOTBLOCK and TOPSWAP added
at the end of the image.
Background and update flow are described here:
Link: https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5Y
V35/
TEST=Build and run Protectli VP6650 (ADL-P), boots successfully with
correct microcode
Change-Id: I489406dd8d08ad85bb46324d3d009acb49b6c52a
Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Ensure FMAP_CBFS_BASE is aligned to 4k (0x1000) to match typical flash
sector boundaries. This allows flashrom to read/write only the COREBOOT
region using the --fmap layout option without extending the boundaries.
Previously, the COREBOOT region would start immediately after the FMAP
region (at FMAP_BASE + 0x200), which is not sector-aligned. Most flash
chips support a minimum 4k sector size, so flashrom would automatically
extend the region boundaries and emit a warning.
This eliminates warnings from flashrom such as:
Region [0x00c54000 - 0x00c541ff] is not sector aligned!
Extending end boundaries by 0x00000e00 bytes,
from 0x00c541ff -> 0x00c54fff
TEST=build/boot google/gladios, update using --fmap and verify no
warnings regarding region alignment.
Change-Id: Ie4963bbef546aa23364bb9c1c347c5eb5bfeaf8e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The generated build/fmap.fmd file was displaying region sizes and
offsets in a mix of decimal and hexadecimal formats, making it harder
to read and compare values. This change ensures all numeric values are
consistently printed in hexadecimal.
The conversion to hex is done in two places:
1. For conditional FMAP entries (MRC_CACHE, SMMSTORE, SPD_CACHE, VPD,
HSPHY_FW, CONSOLE), the _tohex conversion is applied at entry
definition time. This is necessary because these entries may be
empty when their respective CONFIG options are disabled, and the
conditional logic happens before the sed substitution.
2. For unconditional values (ROM_SIZE, BIOS_BASE, BIOS_SIZE,
FMAP_BASE, CBFS_BASE, CBFS_SIZE), the _tohex conversion is applied
directly in the sed command when generating fmap.fmd. This keeps
the base variables in decimal form for continued use in arithmetic
operations.
All internal calculations continue to use decimal values. Only the
final output strings that are written to fmap.fmd are converted to hex
format.
Before:
SI_BIOS@29032448 4521984 {
SMMSTORE@65536 0x40000
RW_SPD_CACHE@327680 4096
After:
SI_BIOS@0x1bb0000 0x450000 {
SMMSTORE@0x10000 0x40000
RW_SPD_CACHE@0x50000 0x1000
Change-Id: I48cc39b430943cb4923955b5e3d64ad6dd24a6cf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89836
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Allow mainboard vendors to have common code, controlled by a new
Kconfig option MB_COMMON_CODE.
Change-Id: I5b97b26a70fbbe2e3f659f01aa00b16b76167f88
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89531
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 6b446b991b.
Reason for revert: This effort was apparently given up on since 4 years.
So remove the function, since it is not used at the moment. If someone
wants to bring that effort back to live, said person can feel free to do
so.
Change-Id: Ifa1ca58c8bf6aabb5b291d3244b1a1a0a7aec6c7
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87065
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit a7eb390796 ("mb/*/*/*.fmd: Start flash at 0")
caused a build failure for all mainboards that generate their FMAP
from the IFD (so intel only) instead of providing one themselves.
Jenkins didn't catch that, because apparently all mainboards that have
the IFD in the 3rdparty/blobs repository provide a custom FMAP.
So there was no defconfig that jenkins tested that would come across
this issue.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ia9852e8ef48148264d2d3f73eb667f3eb8b85005
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87288
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.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>
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>
The generated static.c file output by sconfig is currently added as a
prerequisite for all objects to ensure that static.h exists before
compiling anything that might need it. However, this forces every single
object out of date when the compiled devicetree is updated, even though
not every file actually needs static.h.
Only static.h actually needs to exist before compilation of other
objects, since static.c is an independent compilation unit that doesn't
need to exist before other objects can be built. Thus, change the
prerequisite from static.c to static.h, and add a rule for static.h that
depends on static.c. The recipe is a simple `true` since sconfig
generates static.c and static.h at the same time. To prevent unnecessary
recompiles, make static.h an order-only prerequisite [1] using the new
generated files argument for create_cc_template to ensure that the
header exists before any object might need it, but without forcing a
recompile of all objects by default whenever it is updated.
On a clean build, all objects will be compiled since they do not exist,
and these will occur after static.h is generated due to the default
order-only prerequisite. On subsequent incremental compiles, sources
that do need static.h will be appropriately marked out of date due to
the generated .d dependency files from the compiler, which list static.h
as a normal prerequisite for each objects that do include it, which
overrides the default order-only prerequisite. The dependency files
generated for all other objects will not include static.h, and thus the
objects will not be updated since the default order-only dependency does
not force them out of date.
After updating the devicetree of qemu-i440fx after a clean build,
comparing the build log with `make --debug=why` with the generated
dependency files indicates that only objects that actually depend on
static.h were rebuilt, instead of every object. Running a timeless
incremental build after making a change in the devicetree yielded
identical roms when performed with this patch and main, with the only
difference being the number of objects that needed to be rebuilt. Also
tested with the E6430.
[1] https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html
Change-Id: I34efc162760ae703285f3982fa16cc23a86b37f6
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84387
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Signing is performed with test keys by default, set
CONFIG_SIGNING_KEYS_DIR to a non-empty value to use other keys.
Depending on the version of the Talos II firmware this alone might not
allow booting because coreboot replaces only part of the stock firmware
and its newer versions enable secure boot by default (not to be confused
with SecureBoot in EFI). The signing performed in this commit is still
a prerequisite and might as well be done on its own. Fixing operation
with newer stock firmware will be done in a follow-up change.
Change-Id: Id88baef5ecb1f8ffd74a7f464bbbaaaea0ca643d
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
This will not succeed in compiling on all target and compiler
combinations but at least gets the ball rolling. The change is not
invasive.
Some notes:
- GCC has issues with LTO on ARM
- Clang uses LLD automatically on some arch
- Clang with LTO fails on x86 as it forwards the linking to GCC for some
reason
- SMM building succeeds but the binary is empty
Change-Id: Ieb9204777fd349542744a8946e2207731c37969c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
A few differences with the original link targets:
- 'libs' is now supported on all arch even though only x86 uses it
- compiler_rt is included on arch that previously did not (arm). This
however has no impact as there compiler_rt is not defined for those
arch in xcompile
- LIBGCC_FILE_NAME_bootblock is not included, but this was not defined
anywhere so this is a noop
Change-Id: I64f7686894c99732d06972e7ba327061db6d7c44
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83574
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The parameter is not available for binutils older than 2.39. So move it
to xcompile to provide backwards compatibility for a bit.
Change-Id: I02982769ae2c356f037a747e85d155368bfcb730
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Suppress the warning:
missing .note.GNU-stack section implies executable stack
NOTE: This behaviour is deprecated and will be removed in a
future version of the linker
Since we don't need an executable stack this is fine. Some newer
linkers like LLD even default to this.
Change-Id: Ib787cc464e0924ab57575cec9fbfd1d59bdd3481
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Silence a linker warnings about segments with RWX. Having one segment
for all sections is a good design choice as it makes parsing the elf
into a loadable binary simpler.
Change-Id: I1e0f51c69dabaea314ac45924474d446a9ab68f4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
commit 4a8d73d6a4 ("Makefile.mk: Remove bc dependency") broke the left
shift, since the expr tool does not support shifting operations.
This patch uses the left shift operator inside arithmetic expansion.
Every posix shell should support this.
Tested:
Build amd/birman mainboard and check that the soft-fuse parameter
doesn't change.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If3b29dae727875b0788100a2cb02c86736ffaf8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83377
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
bc was added as dependency in commit 229e021110 ("Makefile.inc: Add left shift macro")
bc is not stated as dependency in our docs (e.g. package installation).
If you don't have bc installed you can easily get false positives on
coreboot builds. For example you build a mainboard and coreboot tells
you the build succeeded, even though you don't have bc installed.
This patch is from julius comment on CB:21601.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I6ab4bc2bd7a45e84b923d4fe7ec473e6c7db2146
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83313
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This reverts commit 6ab188ee6c.
This breaks the build using a slightly older toolchain that doesn't know
this option yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0bdc909c0e53b5353743dca521c963bbec792f7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83311
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>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
This double-colon target doesn't do anything unless it's implemented by
another makefile. It's intended to be used only by the site-local
makefile to allow it to run any necessary steps before the actual
coreboot build begins.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I01f98c9cf8375bca21ab87f9becf66a25402c758
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83198
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use one line per *_common flag like it's done elsewhere in the tree.
It makes the list of options more readable.
Change-Id: I33c500e6eb74daf1e66c2b5e07b50f81c0f4587d
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
In commit 854dd9a5d1
(Makefile.mk: Put site-local path first) the inclusion of
site-local/Makefile.inc was moved to the first place. Unfortunately,
the very next line where subdirs-y is modified resets the variable
instead of extending it which overwrites the inclusion of
site-local/Makefile.inc. This breaks setups where
site-local/Makefile.inc is required.
This patch fixes it.
Change-Id: I36ad1aca5742869c84e2fb556f898f896c6f037a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83190
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
"site-local" Makfile(s) may need to override some of the macros/paths
used elsewhere in src/* Makefiles. If we include it last src/*
Makefile.mk will have already been processed. MAINBOARD_BLOBS_DIR is
an example where the path needs to be overwritten in site-local
requiring it to be included first before src/mainboard/* Makefile.mk
is processed.
Change-Id: I8ea865cd73aba5092a628b0422e5c4121b32fb4d
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
This reverts commit f4acef92.
Reason for revert: '-Wflex-array-member-not-at-end' is new command
option came with GCC-14. older versions will not support it.
Change-Id: I179d0bc0db3e863645ae4c87e1534c5c20025dfb
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82758
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit b3db3abd63.
Reason for revert: `Wcalloc-transposed-args` is new command option came with GCC-14. older versions will not support it.
Change-Id: I74ef8de1f7d38e1e0519c3b41e79fd9b11d8e16f
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82759
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GCC-14 documentation says "The first argument to calloc is documented to
be number of elements in array, while the second argument is size of
each element, so calloc(n, sizeof (int)) is preferred over
calloc(sizeof(int), n)."
Change-Id: I77b6f4d2eda487b087ba5665b588999633c33e8d
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82658
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Starting with version 18 LLVM puts code and data generated with
-ffunction-section -mcmodel=large inside sections with an 'l' prefix.
This would now also pick up const data in .rodata.
Change-Id: Ie07779ef548337772183ffe2d642f971d8cceae7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Currently, if something is overlapped, you get this:
ERROR: Ramstage region _ramstage overlapped by: fallback/payload fallback/opensbi
This change prints out the start and end of the sections.
Change-Id: Ica8c05b63ed9bbd28e2d3daa4dc7c2f9d8da3f55
Signed-off-by: Ronald G Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81544
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Instead of including the generated dependency file during the evaluation
of asl_template, add it to the DEPENDENCIES variable so that it is
included at the same time as the rest of the .d files in the top level
Makefile. This makes the handling of .d files cleaner as all of them are
processed in the same way. Tracking all of them in a single variable
also prevents any from being missed if any post-processing is performed
on them, such as running them through the fixdep utility from the Linux
kernel project to replace the config.h dependency with only the configs
that are used.
This should be safe since asl_template is evaluated while calling
includemakefiles, which is occurs before the files in DEPENDENCIES are
included.
TEST:
1. Build dell/e6400
2. Run `touch src/mainboard/dell/e6400/dsdt.asl` (defined as a
prerequisite of build/dsdt.aml in build/dsdt.d)
3. Run `make --debug=b`
4. Verify that dsdt.aml was rebuilt due dsdt.asl being newer than target
Change-Id: Ie8271d1e172395917f2859c8bbfd2041ddc572ca
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80383
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
