GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/Makefile.inc

1385 lines
54 KiB
PHP
Raw Normal View History

treewide: more SPDX header work Change-Id: Ib78c322730ec6dfa9dcaafa16e5741cd3d351b8d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41174 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-08 18:32:38 +02:00
# SPDX-License-Identifier: GPL-2.0-only
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
build system: don't run xcompile or git for %clean/%config targets It takes a long time for no gain: We don't need to update the submodules, we don't need to fetch the revision, we don't need to find the compilers, when all we want to do is to manipulate the .config file or clean the build directory. Change-Id: Ie1bd446a0d49a81e3cccdb56fe2c43ffd83b6c98 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/18182 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-19 23:20:14 +01:00
ifneq ($(NOCOMPILE),1)
Makefile.inc: Improve git worktree check `Makefile.inc` checks for `.git` to be present under $(top) to define the value of $GIT. This check is rather weak and doesn't handle many edge cases like that of a broken gitfile. Add a proper `git rev-parse` call to check the condition. Change-Id: Ifd6da19f13d9f2a9fddb6afd7cb5f16daba2401e Signed-off-by: Alex Thiessen <alex.thiessen.de+coreboot@gmail.com> Reviewed-on: https://review.coreboot.org/23254 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-14 11:38:30 +01:00
GIT:=$(shell git -C "$(top)" rev-parse --git-dir 1>/dev/null 2>&1 \
&& command -v git)
build system: don't run xcompile or git for %clean/%config targets It takes a long time for no gain: We don't need to update the submodules, we don't need to fetch the revision, we don't need to find the compilers, when all we want to do is to manipulate the .config file or clean the build directory. Change-Id: Ie1bd446a0d49a81e3cccdb56fe2c43ffd83b6c98 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/18182 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-19 23:20:14 +01:00
else
GIT:=
endif
build system: Only test for git once And then use the variable to decide what to do. Change-Id: I48a801ecdbf774c4a8b64d7efaf9cf0ef2c2d438 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/8600 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-04 15:02:03 +01:00
build system: strip quotes from CONFIG_CBFS_PREFIX in a single location Instead of having to remember to strip the quotes everywhere so that string comparisons (of which there are a few) match up, do it right at the beginning. Fixes building the image with a .config where CONFIG_CBFS_PREFIX contains quotes. Change-Id: I4d63341cd9f0bc5e313883ef7b5ca6486190c124 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12578 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-11-30 22:44:53 +01:00
#######################################################################
# normalize Kconfig variables in a central place
CONFIG_CBFS_PREFIX:=$(call strip_quotes,$(CONFIG_CBFS_PREFIX))
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
CONFIG_FMDFILE:=$(call strip_quotes,$(CONFIG_FMDFILE))
Makefile.inc: Strip CONFIG_DEVICETREE quotes at top of makefile Minor change - Instead of stripping the quotes from CONFIG_DEVICETREE inline, add it to the location where we normalize all the other Kconfig variables. Change-Id: Idbc58179c7b45160afef7d7e44f9b3b334f8c4a7 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/16116 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-08 23:12:11 +02:00
CONFIG_DEVICETREE:=$(call strip_quotes, $(CONFIG_DEVICETREE))
Kconfig: Add new config for OVERRIDE_DEVICETREE This change adds a new config option OVERRIDE_DEVICETREE that allows variants to provide an override devicetree file to override the registers and/or add new devices on top of the ones provided by baseboard devicetree using CONFIG_DEVICETREE. BUG=b:80081934 Change-Id: Ica046b7e0d70d0f1e8d94da714d1e62032277916 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/26691 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-22 03:50:48 +02:00
CONFIG_OVERRIDE_DEVICETREE:=$(call strip_quotes, $(CONFIG_OVERRIDE_DEVICETREE))
sconfig: Allow chipset to provide a base devicetree This change extends the devicetree override one more layer and allows the chipset to provide the base devicetree. This allows the chipset to assign alias names to devices as well as set default register values. This works for both the baseboard devicetree.cb as well as variant overridetree.cb. chipset.cb: device pci 15.0 alias i2c0 off end devicetree.cb: device ref i2c0 on end BUG=b:156957424 Change-Id: Ia7500a62f6211243b519424ef3834b9e7615e2fd Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44037 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-07-30 01:28:43 +02:00
CONFIG_CHIPSET_DEVICETREE:=$(call strip_quotes, $(CONFIG_CHIPSET_DEVICETREE))
treewide: Add Kconfig variable MEMLAYOUT_LD_FILE This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows SoC/mainboard to provide a linker file for the platform. x86 already provides a default memlayout.ld under src/arch/x86. With this new Kconfig variable, it is possible for the SoC/mainboard code for x86 to provide a custom linker file as well. Makefile.inc is updated for all architectures to use this new Kconfig variable instead of assuming memlayout.ld files under a certain path. All non-x86 boards used memlayout.ld under mainboard directory. However, a lot of these boards were simply including the memlayout from SoC. So, this change also updates these mainboards and SoCs to define the Kconfig as required. BUG=b:155322763 TEST=Verified that abuild with --timeless option results in the same coreboot.rom image for all boards. Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-11 20:59:07 +02:00
CONFIG_MEMLAYOUT_LD_FILE:=$(call strip_quotes, $(CONFIG_MEMLAYOUT_LD_FILE))
build system: strip quotes from CONFIG_CBFS_PREFIX in a single location Instead of having to remember to strip the quotes everywhere so that string comparisons (of which there are a few) match up, do it right at the beginning. Fixes building the image with a .config where CONFIG_CBFS_PREFIX contains quotes. Change-Id: I4d63341cd9f0bc5e313883ef7b5ca6486190c124 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12578 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-11-30 22:44:53 +01:00
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# misleadingly named, this is the coreboot version
Makefile.inc: Stop running git repeatedly for each build Currently, the coreboot makefiles repeatedly run git to try to set the KERNELVERSION variable and to fetch the submodules. This happens three times for every build. By exporting a variable, we can catch this on recursive makes and not run each of these steps again. Change-Id: I85ab867b40e80c36bd94d48510ffe3252c6cf93f Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14392 Tested-by: build bot (Jenkins) Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2016-04-20 04:15:16 +02:00
ifeq ($(KERNELVERSION),)
Add option for "timeless" builds Builds with BUILD_TIMELESS=1 shall always give a bit identical output for stable inputs. This should help verifying that resulting rom files stay the same across commits that shouldn't change the outcome. To be useful for builds that rely on 3rdparty/arm-trusted-firmware, this needs a similar change there. Change-Id: Ia0a22e3e79fbd0abbd2a9071ecbeef6541787a08 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13412 Tested-by: build bot (Jenkins) Reviewed-by: Damien Zammit <damien@zamaudio.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-24 16:00:50 +01:00
ifeq ($(BUILD_TIMELESS),1)
Makefile.inc: Extend version string for timeless builds With the version string "TIMELESS", binaries are slightly smaller than for a regular build. This may lead to false positive build tests if the space is limited (e.g. bootblock). So let's make the string a little longer. Change-Id: I3bbf6f71d5bcd74728a3fe39734312690901d0ec Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32986 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-05-24 13:03:43 +02:00
KERNELVERSION := -TIMELESS--LESSTIME-
Add option for "timeless" builds Builds with BUILD_TIMELESS=1 shall always give a bit identical output for stable inputs. This should help verifying that resulting rom files stay the same across commits that shouldn't change the outcome. To be useful for builds that rely on 3rdparty/arm-trusted-firmware, this needs a similar change there. Change-Id: Ia0a22e3e79fbd0abbd2a9071ecbeef6541787a08 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13412 Tested-by: build bot (Jenkins) Reviewed-by: Damien Zammit <damien@zamaudio.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-24 16:00:50 +01:00
else
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
KERNELVERSION := $(strip $(if $(GIT),\
Makefile,genbuild: Provide length for abbreviated commit hashes The original default, minimum abbreviated hash length was 7. It dif- fers on newer systems, however. This breaks reproducibility, so set an explicit length. 12 hex digits should be good enough. Note: This sets only a minimum. With a high enough number of commit objects in the repository, Git could still decide to use a longer hash, again breaking reproducibility. 12 digits will hopefully pro- vide enough margin. Change-Id: Ia86e9cc41e27a0a57d498dcb13aec954c4ea0f04 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76560 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-07-16 00:59:55 +02:00
$(shell git describe --abbrev=12 --dirty --always || git describe),\
version: allow stating the coreboot revision in .coreboot-version If .git doesn't exist, try to fetch the coreboot version from a file, before falling back to a hard-code. Change-Id: Idee8019c9a2b766fe69535367614c5254498335a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10908 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-07-13 20:43:28 +02:00
$(if $(wildcard $(top)/.coreboot-version),\
$(shell cat $(top)/.coreboot-version),\
coreboot-unknown$(KERNELREVISION))))
Add option for "timeless" builds Builds with BUILD_TIMELESS=1 shall always give a bit identical output for stable inputs. This should help verifying that resulting rom files stay the same across commits that shouldn't change the outcome. To be useful for builds that rely on 3rdparty/arm-trusted-firmware, this needs a similar change there. Change-Id: Ia0a22e3e79fbd0abbd2a9071ecbeef6541787a08 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13412 Tested-by: build bot (Jenkins) Reviewed-by: Damien Zammit <damien@zamaudio.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-24 16:00:50 +01:00
endif
Makefile.inc: Stop running git repeatedly for each build Currently, the coreboot makefiles repeatedly run git to try to set the KERNELVERSION variable and to fetch the submodules. This happens three times for every build. By exporting a variable, we can catch this on recursive makes and not run each of these steps again. Change-Id: I85ab867b40e80c36bd94d48510ffe3252c6cf93f Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14392 Tested-by: build bot (Jenkins) Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2016-04-20 04:15:16 +02:00
endif
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
COREBOOT_EXPORTS += KERNELVERSION
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# Basic component discovery
MAINBOARDDIR=$(call strip_quotes,$(CONFIG_MAINBOARD_DIR))
Makefile.inc: export VARIANT_DIR as top-level variable export VARIANT_DIR at the top level, rather than doing so multiple times at the SoC / board level Change-Id: If825701450c78289cb8cca731d589e12aafced11 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/17451 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-16 22:03:43 +01:00
VARIANT_DIR:=$(call strip_quotes,$(CONFIG_VARIANT_DIR))
Makefile.inc: Add CARRIER_DIR to component discovery The idea is to split the “mainboard” category into “variants” and “carrierboards”, in the case when we use the COMe module together with the Carrier Board instead of a single monolithic motherboard. Previously, the “variants” category defined the type of motherboard, which has a number of differences from the base one, for example, it differed in the size or type of memory, and in the configuration of the interfaces. Thus, there is no need to create a separate directory in src/mainboard for a board that is similar in configuration to the base board. But for a COMe module, “variants” contains different variants of only this module, and the entire Carrier Board configuration is allocated to a separate category - “carrierboards”, and each of the variants can be used with one of the many boards in “carrierboards”. For example, in the case of the Kontron mAL10 COMe module, variant refers to the COMe-mAL10 or COMe-m4AL10 module type. They differ in the type of memory (DDR3L or DDR4), and maybe they differ in some chips (see more in https://www.kontron.com/products). However, all variants contain the same type of processor/SoC. The "carrierboards" directory can be able contain both the Kontron's Evalution carrier boards (such as Eval Carrier2 T10 and COMe Ref.Carrier-i T10 TNI) and third party vendor backplanes that are compatible with the COMe modules from “variants”. Thus, the src/mainboard/<module-name> directory contains the common configuration code for all variants from src/mainboard/<module-name>/ variants, which can be supplemented/redefined with a configuration from src/mainboard/<module-name>/carrierboard/<vendor-carrierboard-name>. This architectural solution will be able to systematize and simplify understanding of the code structure for COMe modules and will allow vendors to add/maintain their code in a separate directory. This work is also the first step towards to union of all carrierboards into the global category in src/carrierboard on a par with all boards from src/mainboard. The patch takes this into account in the build system and adds CARRIER_DIR component to use the “carrierboards” category, as it has done for VARIANT_DIR. TEST = Build ROM image for Kontron mAL10 COMe module together with T10 TNI carrier board (https://review.coreboot.org/c/coreboot/+/39133). Change-Id: Ic6b2f8994b1293ae6f5bda8c9cc95128ba0abf7a Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42609 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-20 16:26:21 +02:00
CARRIER_DIR:=$(call strip_quotes,$(CONFIG_CARRIER_DIR))
COREBOOT_EXPORTS += MAINBOARDDIR VARIANT_DIR CARRIER_DIR
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
Makefile: define build result directories Final build results (.elf, .debug, .map) are to be placed under directory $(objcbfs), the default is: $(obj)/cbfs/$(CONFIG_CBFS_PREFIX)/ Intermediate build results (.o, .s, .S, .inc, .ld) that do not have a clear one-to-one relation to a file under src/ are to be placed under directory $(objgenerated), the default is: $(obj)/generated Also defines implicit rules for final build results: .debug -> .elf and .map .elf -> .bin Change-Id: I448c6b7c9a952e54170df42091d7db438025a795 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/858 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-04-19 11:00:06 +02:00
## Final build results, which CBFSTOOL uses to create the final
## rom image file, are placed under $(objcbfs).
## These typically have suffixes .debug .elf .bin and .map
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
objcbfs := $(obj)/cbfs/$(CONFIG_CBFS_PREFIX)
Makefile.inc: Use `additional-dirs` for $(objcbfs), $(objgenerated) We use `additional-dirs` for a single `mkdir -p` invocation for all directiories. I don't see why these two, $(objcbfs) and $(objgenerated), should be an exception. Fixes clean builds for targets that don't include the phony `coreboot` target, e.g. `make qemu`. Change-Id: I85abaa74cddefd2bd669e2b5c8934352775070fe Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51318 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-03-06 13:12:34 +01:00
additional-dirs += $(objcbfs)
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
COREBOOT_EXPORTS += objcbfs
Makefile: define build result directories Final build results (.elf, .debug, .map) are to be placed under directory $(objcbfs), the default is: $(obj)/cbfs/$(CONFIG_CBFS_PREFIX)/ Intermediate build results (.o, .s, .S, .inc, .ld) that do not have a clear one-to-one relation to a file under src/ are to be placed under directory $(objgenerated), the default is: $(obj)/generated Also defines implicit rules for final build results: .debug -> .elf and .map .elf -> .bin Change-Id: I448c6b7c9a952e54170df42091d7db438025a795 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/858 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-04-19 11:00:06 +02:00
## Based on the active configuration, Makefile conditionally collects
## the required assembly includes and saves them in a file.
## Such files that do not have a clear one-to-one relation to a source
## file under src/ are placed and built under $(objgenerated)
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
objgenerated := $(obj)/generated
Makefile.inc: Use `additional-dirs` for $(objcbfs), $(objgenerated) We use `additional-dirs` for a single `mkdir -p` invocation for all directiories. I don't see why these two, $(objcbfs) and $(objgenerated), should be an exception. Fixes clean builds for targets that don't include the phony `coreboot` target, e.g. `make qemu`. Change-Id: I85abaa74cddefd2bd669e2b5c8934352775070fe Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51318 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-03-06 13:12:34 +01:00
additional-dirs += $(objgenerated)
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
COREBOOT_EXPORTS += objgenerated
Makefile: define build result directories Final build results (.elf, .debug, .map) are to be placed under directory $(objcbfs), the default is: $(obj)/cbfs/$(CONFIG_CBFS_PREFIX)/ Intermediate build results (.o, .s, .S, .inc, .ld) that do not have a clear one-to-one relation to a file under src/ are to be placed under directory $(objgenerated), the default is: $(obj)/generated Also defines implicit rules for final build results: .debug -> .elf and .map .elf -> .bin Change-Id: I448c6b7c9a952e54170df42091d7db438025a795 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/858 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-04-19 11:00:06 +02:00
Makefile.inc: Export CCACHE_EXTRAFILES and add __BUILD_DIR__ definition This patch adds the CCACHE_EXTRAFILES variable to the list of exported environment variables, which can be useful as a target-specific variable to make ccache aware of extra dependencies that it cannot figure out on its own. It also adds a CPPFLAGS parameter to define the __BUILD_DIR__ constant for the preprocessor so that the current output build directory can be referenced in C code if necessary. Change-Id: I4fdd08842972cfed8ef5e5a61ebf859c0571bcfb Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26451 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-21 22:04:04 +02:00
## CCACHE_EXTRAFILES can be set by individual rules to help CCACHE
## discover dependencies it might not notice on its own (e.g. asm (".incbin")).
COREBOOT_EXPORTS += CCACHE_EXTRAFILES
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# root rule to resolve if in build mode (ie. configuration exists)
build system: Add another post-processing step files_added is for rules that need to run after all CBFS processing is finished, such as SoC-specific postprocessing of the image, or for vboot, to sign the RW regions (that contain CBFS that shouldn't change afterwards.) Change-Id: I830aa0c93429f4971cd68e4358faba5c206c0038 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-02-02 17:38:45 +01:00
real-target: $(obj)/config.h coreboot files_added
util/cse_serger: Add a new tool for stitching CSE components This change adds a new tool `cse_serger` which can be used to print, dump and stitch together different components for the CSE region. BUG=b:189177186 Change-Id: I90dd809b47fd16afdc80e66431312721082496aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55503 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-09-17 07:04:11 +02:00
coreboot: $(obj)/coreboot.rom $(obj)/cbfstool $(obj)/rmodtool $(obj)/ifwitool $(obj)/cse_fpt $(obj)/cse_serger
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
build_system: Extend site-local - Add a target at the end of the build that can be used to run additional scripts or additional targets after coreboot.rom is built. - Source a site-local Kconfig file to allow site-specific configuration. This eliminates the need to add a hook for a script at the end of the build because you can add one yourself in site-local. Example site-local/Makefile.inc: build_complete:: ifeq ($(CONFIG_SITE_LOCAL),y) echo "Running additional steps in site-local" # run some script here to make my build unreproducible. endif .phony: build_complete Example site-local/Kconfig: menu "site-local" config SITE_LOCAL bool "site-local enabled" help Enable my site-local configuration to do stuff. endmenu Change-Id: Id4d1e727c69b5cdb05e7d52731bbb1d1e201864a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13413 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2016-01-25 03:38:33 +01:00
# This target can be used in site local to run scripts or additional
# targets after the build completes by creating a Makefile.inc in the
# site-local directory with a target named 'build_complete::'
build_complete:: coreboot
Append per-board ccache statistics in log Starting with ccache 4.4 it is possible to collect statistics about cache miss/hit rates in a separate file. Add the info of the build at end of created make.log file or on stdout. Change-Id: I1bab712712f4d6379ec6733fdc55b234e3845da7 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75087 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-14 16:26:35 +01:00
printf "\nBuilt %s (%s)\n" $(MAINBOARDDIR) $(CONFIG_MAINBOARD_PART_NUMBER)
if [ -f "$(CCACHE_STATSLOG)" ]; then \
printf "\nccache statistics\n"; \
$(CCACHE) --show-log-stats -v; \
fi
build_system: Extend site-local - Add a target at the end of the build that can be used to run additional scripts or additional targets after coreboot.rom is built. - Source a site-local Kconfig file to allow site-specific configuration. This eliminates the need to add a hook for a script at the end of the build because you can add one yourself in site-local. Example site-local/Makefile.inc: build_complete:: ifeq ($(CONFIG_SITE_LOCAL),y) echo "Running additional steps in site-local" # run some script here to make my build unreproducible. endif .phony: build_complete Example site-local/Kconfig: menu "site-local" config SITE_LOCAL bool "site-local enabled" help Enable my site-local configuration to do stuff. endmenu Change-Id: Id4d1e727c69b5cdb05e7d52731bbb1d1e201864a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13413 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2016-01-25 03:38:33 +01:00
build system: Add another post-processing step files_added is for rules that need to run after all CBFS processing is finished, such as SoC-specific postprocessing of the image, or for vboot, to sign the RW regions (that contain CBFS that shouldn't change afterwards.) Change-Id: I830aa0c93429f4971cd68e4358faba5c206c0038 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-02-02 17:38:45 +01:00
# This target can be used to run rules after all files were added to CBFS,
# for example to process FMAP regions or the entire image.
files_added:: build_complete
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# our phony targets
Makefile.inc: Use `additional-dirs` for $(objcbfs), $(objgenerated) We use `additional-dirs` for a single `mkdir -p` invocation for all directiories. I don't see why these two, $(objcbfs) and $(objgenerated), should be an exception. Fixes clean builds for targets that don't include the phony `coreboot` target, e.g. `make qemu`. Change-Id: I85abaa74cddefd2bd669e2b5c8934352775070fe Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51318 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-03-06 13:12:34 +01:00
PHONY+= clean-abuild coreboot check-style build_complete
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# root source directories of coreboot
src/superio: trim and move Makefile.inc, instead use wildcard matches Signed-off-by: Idwer Vollering <vidwer@gmail.com> Change-Id: If77d59485451c77dcea752bc4fe0dfadba8fec45 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48900 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-24 15:33:20 +01:00
subdirs-y := src/lib src/commonlib/ src/console src/device src/acpi src/superio/common
src/ec/intel: Create common code for board_id implementation This patch creates initial common code structure for board_id implementation for intel rvp platforms. Board_id helps in identifying the platform with respect to CHROME_EC and INTEL_EC (Windows_EC). Changes include 1. Create initial board_id.c and board_id.h 2. Modify the Makefile to include src/ec/intel directory BUG=b:260654043 TEST=Able to build with the patch and boot the mtlrvp platform with the subsequent patches in the train Signed-off-by: Harsha B R <harsha.b.r@intel.com> Change-Id: If133f6a72b8c3e1d8811a11f91e4556beb8c16e0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/70227 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Usha P <usha.p@intel.com> Reviewed-by: Subrata Banik <subratabanik@google.com>
2022-12-01 16:53:53 +01:00
subdirs-$(CONFIG_EC_ACPI) += src/ec/intel
kbuild: automatically include ECs This change switches all ECs and the generic EC ACPI code to be autoincluded by Makefile.inc, rather than having to be mentioned explicitly in ec/Makefile.inc or in ec/<vendor>/Makefile.inc. This means, vendor and ec directories are now "drop in", e.g. be placed in the coreboot directory hierarchy without having to modify any higher level coreboot files. The long term plan is to enable out of tree components to be built with a given coreboot version (given that the API did not change). Change-Id: I29d757d1f8c10a1d0167a76fd0d0f97bac576f6d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9798 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-27 23:03:47 +02:00
subdirs-y += src/ec/acpi $(wildcard src/ec/*/*) $(wildcard src/southbridge/*/*)
$top/Makefile.inc: Move common folder before other sibling ones Putting src/soc/*/common before src/soc/*/*, and src/superio/common before src/superio/*,(which is already moved but with duplicated folder "common") can make the variables in common Makefile get the expected value before they are used in other subdirs. The later "*" also contains "common", which needs to be eliminated by "filter-out". Then we can put some common variables from all the subdir Makefile.inc to the common Makefile.inc to reduce code redundancy. Change-Id: I99597af22cac6d12aaef348789664cd7db02ba06 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/62750 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-03-11 07:47:07 +01:00
subdirs-y += $(wildcard src/soc/*) $(wildcard src/soc/*/common) $(filter-out $(wildcard src/soc/*/common),$(wildcard src/soc/*/*))
subdirs-y += $(wildcard src/northbridge/*/*)
subdirs-y += $(filter-out src/superio/common,$(wildcard src/superio/*)) $(wildcard src/superio/*/*)
drivers/intel/usb4: Add driver for USB4 retimer device The USB4 retimer device needs to declare a _DSM with specific functions that allow for GPIO control to turn off the power when an external device is not connected. This driver allows the mainboard to provide the GPIO that is connected to the power control. BUG=b:156957424 Change-Id: Icfb85dc3c0885d828aba3855a66109043250ab86 Signed-off-by: Duncan Laurie <dlaurie@google.com> Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44918 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-28 21:46:35 +02:00
subdirs-y += $(wildcard src/drivers/*) $(wildcard src/drivers/*/*) $(wildcard src/drivers/*/*/*)
kbuild: Allow drivers to fit src/drivers/[X]/[Y]/ scheme Reorder drivers to fit src/drivers/[X]/[Y]/ scheme to make them pluggable. Also, fix up the following driver subdirectories by switching to the src/drivers/[X]/[Y]/ scheme as these are hard requirements for the main change: * drivers/intel * drivers/pc80 * drivers/dec Change-Id: I455d3089a317181d5b99bf658df759ec728a5f6b Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/14047 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-03-12 05:22:28 +01:00
subdirs-y += src/cpu src/vendorcode
amdfwtool: Clean up the Makefile of amdfwtool Add Makefile.inc to compliant with other tools. Makefile is kept for building amdfwtool by typing make in the folder. Change-Id: I3688d93de4459f5f838955892086b4b9bf30a9b8 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45286 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-09-29 11:32:36 +02:00
subdirs-y += util/cbfstool util/sconfig util/nvramtool util/pgtblgen util/amdfwtool
util/qemu: Add `qemu` make target Add some mechanics to automatically have a `qemu` make target for supported configurations. So with a QEMU target selected in Kconfig, one would ideally only have to run `make qemu` to test things. There are some notable variables that can be set or adapted in `Makefile.inc` files, the make command line or the environment. Primarily for `Makefile.inc` use: QEMU-y the QEMU executable QEMU_CFG-y a QEMU config that sets the available default devices, used to run more comprehensive tests by default, e.g. many more PCI devices For general use: QEMU_ARGS additional command line arguments (default: -serial stdio) QEMU_EXTRA_CFGS additional config files that can add devices QEMU_CFG_ARGS gathers config file related arguments, can be used to override a default config (QEMU_CFG-y) Examples: $ # Run coreboot's default config with additional command line args $ make qemu QEMU_ARGS="-cdrom site-local/grml64-small_2018.12.iso" $ # Force QEMU's built-in config $ make qemu QEMU_CFG_ARGS= Change-Id: I658f86e05df416ae09be6d432f9a80f7f71f9f75 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46767 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2020-10-25 12:37:21 +01:00
subdirs-y += util/futility util/marvell util/bincfg util/supermicro util/qemu
util/ifdtool: Add coreboot build system support When building as part of the coreboot build system, use the same mechanism as other tools (cbfstool, amdfwtool, ...) so that abuild builds ifdtool once into sharedutils instead of once per board (while avoiding other race conditions, too). Change-Id: I42c7b43cc0859916174d59cba6b62630e70287fd Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49312 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-01-11 15:17:59 +01:00
subdirs-y += util/ifdtool
kbuild: automatically include southbridges This change switches all southbridge vendors and southbridges to be autoincluded by Makefile.inc, rather than having to be mentioned explicitly in southbridge/Makefile.inc or in southbridge/<vendor>/Makefile.inc. In order to be able to drop southbridge/amd/Makefile.inc, some scattered source files had to be moved to a southbridge/amd/common directory, in accordance to what we are doing on other architectures already. This means, vendor and southbridge directories are now "drop in", e.g. be placed in the coreboot directory hierarchy without having to modify any higher level coreboot files. The long term plan is to enable out of tree components to be built with a given coreboot version (given that the API did not change). Change-Id: I79bd644a0a3c4e8320c80f8cc7a7f8ffd65d32f2 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9796 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-04-27 23:02:36 +02:00
subdirs-y += $(wildcard src/arch/*)
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
subdirs-y += src/mainboard/$(MAINBOARDDIR)
security/vboot: Move vboot2 to security kconfig section This commit just moves the vboot sources into the security directory and fixes kconfig/makefile paths. Fix vboot2 headers Change-Id: Icd87f95640186f7a625242a3937e1dd13347eb60 Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/22074 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-10-17 17:02:29 +02:00
subdirs-y += src/security
payloads: Load coreinfo as a secondary payload This allows coreinfo to be added to CBFS as a 'secondary' payload on x86 systems, to be loaded by the main payload if desired. Selecting this option, which defaults to no, builds the coreinfo payload and adds it to CBFS as `img/coreinfo` which can then be loaded by for example SeaBIOS or GRUB. Change-Id: I52661d486823bc4bb215ce92dca118c9d2c2a309 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13728 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-02-17 03:40:47 +01:00
subdirs-y += payloads payloads/external
Add SBOM (Software Bill of Materials) Generation Firmware is typically delivered as one large binary image that gets flashed. Since this final image consists of binaries and data from a vast number of different people and companies, it's hard to determine what all the small parts included in it are. The goal of the software bill of materials (SBOM) is to take a firmware image and make it easy to find out what it consists of and where those pieces came from. Basically, this answers the question, who supplied the code that's running on my system right now? For example, buyers of a system can use an SBOM to perform an automated vulnerability check or license analysis, both of which can be used to evaluate risk in a product. Furthermore, one can quickly check to see if the firmware is subject to a new vulnerability included in one of the software parts (with the specified version) of the firmware. Further reference: https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/ - Add Makefile.inc to generate and build coswid tags - Add templates for most payloads, coreboot, intel-microcode, amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM, intel ME and compiler (gcc,clang,other) - Add Kconfig entries to optionally supply a path to CoSWID tags instead of using the default CoSWID tags - Add CBFS entry called SBOM to each build via Makefile.inc - Add goswid utility tool to generate SBOM data Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-04-14 14:54:16 +02:00
subdirs-$(CONFIG_SBOM) += src/sbom
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
Provide mechanism to local additions to the build site-local/ is an optional directory for local additions to the build. If site-local/Makefile.inc exists it will be parsed and used. Use it to define VGA option roms, splash screens, extra rules to the tree... Change-Id: I0c6ee43ffa40e6c3f193db081ab551ab75bc7478 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/212 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-09-02 09:57:01 +02:00
subdirs-y += site-local
Make: Move testing into a subdirectory In preparation for expanding the testing, move the test targets out of the top level Makefile.inc and into a separate subdirectory. Change-Id: Ie252c7555223f9ce76b54e6f7b66d03f3cf60500 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/20873 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Chris Ching <chingcodes@google.com>
2017-07-31 19:52:58 +02:00
subdirs-y += util/checklist util/testing
Provide mechanism to local additions to the build site-local/ is an optional directory for local additions to the build. If site-local/Makefile.inc exists it will be parsed and used. Use it to define VGA option roms, splash screens, extra rules to the tree... Change-Id: I0c6ee43ffa40e6c3f193db081ab551ab75bc7478 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/212 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-09-02 09:57:01 +02:00
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# Add source classes and their build options
Introduce bootblock self-decompression Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-16 23:14:04 +02:00
classes-y := ramstage romstage bootblock decompressor postcar smm smmstub cpu_microcode verstage
coreboot classes: Add dynamic classes to coreboot Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-07-31 18:28:55 +02:00
Makefile.inc: Add a class 'all' to link files in all stage except SMM Change-Id: I955dd2dc22cb3cfc4fdf1198cfd32f56475f97c9 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33198 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-06-04 13:16:28 +02:00
# Add a special 'all' class to add sources to all stages
$(call add-special-class,all)
all-handler = $(foreach class,bootblock verstage romstage postcar ramstage,$(eval $(class)-y += $(2)))
Makefile.inc: introduce all_x86 target For compilation units that should be built for all stages that run on the x86 cores in a newer AMD SoC, but can't be built for verstage on PSP which is an ARM core, the 'all' target can't be used, since that would result in the compilation unit also being added to the verstage target in the verstage on PSP case. In order to not need to add a compilation unit to the 'bootblock', 'verstage_x86', 'romstage', and 'ramstage' targets in separate lines in the Makefile, introduce the 'all_x86' target that adds a file to 'bootblock', 'verstage_x86', 'romstage', 'postcar', and 'ramstage'. The compilation units also need to be added to the 'postcar' stage which is only present on the pre-Zen SoCs to be able to also use the 'all_x86' target in common AMD code that is also used in those pre-Zen SoCs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9d0184182b931185990094d0874b49c0b5cb9f7e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74150 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-01 01:26:39 +02:00
$(call add-special-class,all_x86)
all_x86-handler = $(foreach class,bootblock verstage_x86 romstage postcar ramstage,$(eval $(class)-y += $(2)))
src/*: Update makefiles to exclude x86 code from psp-verstage The assumption up to this point was that if the system had an x86 processor, verstage would be running on the x86 processor. With running verstage on the PSP, that assumption no longer holds true, so exclude pieces of code that cause problems for verstage on the PSP. This change will add these files to verstage only if the verstage architecture is X86 - either 32 or 64 bit. BUG=b:158124527 TEST=Build and boot on Trembyle Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I797b67394825172bd44ad1ee693a0c509289486b Reviewed-on: https://review.coreboot.org/c/coreboot/+/42062 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Eric Peers <epeers@google.com> Reviewed-by: Rob Barnes <robbarnes@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-04 03:24:11 +02:00
$(call add-special-class,verstage_x86)
ifeq ($(CONFIG_ARCH_VERSTAGE_X86_32)$(CONFIG_ARCH_VERSTAGE_X86_64),y)
verstage_x86-handler = $(eval verstage-y += $(2))
else
verstage_x86-handler =
endif
coreboot classes: Add dynamic classes to coreboot Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-07-31 18:28:55 +02:00
# Add dynamic classes for rmodules
$(foreach supported_arch,$(ARCH_SUPPORTED), \
$(eval $(call define_class,rmodules_$(supported_arch),$(supported_arch))))
rmodule: use program.ld for linking Bring rmodule linking into the common linking method. The __rmodule_entry symbol was removed while using a more common _start symbol. The rmodtool will honor the entry point found within the ELF header. Add ENV_RMODULE so that one can distinguish the environment when generating linker scripts for rmodules. Lastly, directly use program.ld for the rmodule.ld linker script. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage, sipi_vector, and smm rmodules. Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11517 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-05 19:59:26 +02:00
# Provide a macro to determine environment for free standing rmodules.
$(foreach supported_arch,$(ARCH_SUPPORTED), \
$(eval rmodules_$(supported_arch)-generic-ccopts += -D__RMODULE__))
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
build system: improve portability There are too many differences, and calculating relatively large integer using floats might not be the brightest idea anyway. Also avoid relying on ls(1) output format to determine file sizes. Change-Id: I5f96c036737b74e20f525c3dc9edc011ad403662 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7447 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-12 19:11:50 +01:00
#######################################################################
Makefile.inc: Add toupper, tolower, and ws_to_under macros Add a few additional macros that can be used throughout the coreboot makefiles. tolower: returns the value in all lowercase toupper: returns the value in all uppercase ws_to_under: returns the value with any whitespace changed to underscores Change-Id: Icd0e6586481d8f229af0e899e0c94ef7c5c672c3 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14093 Tested-by: build bot (Jenkins) Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-03-14 22:07:14 +01:00
# Helper functions for math, strings, and various file placement matters.
Makefile.inc: Add math macros Add macros to standardize math done in the Makefiles in a posix compliant manner. int-multiply takes an arbitrary list of values to multiply, the same as the int-addition macro. The other macros only work on two values at a time. Change-Id: I3b754b9bcde26f33edc4f945d5af3d5444f383c7 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10874 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-03 20:54:14 +02:00
# macros work on all formats understood by printf(1)
# values are space separated if using more than one value
build system: improve portability There are too many differences, and calculating relatively large integer using floats might not be the brightest idea anyway. Also avoid relying on ls(1) output format to determine file sizes. Change-Id: I5f96c036737b74e20f525c3dc9edc011ad403662 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7447 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-12 19:11:50 +01:00
#
Makefile.inc: Add left shift macro Add a macro to shift a value to the left by a specified number of bits. Change-Id: Ib3fb43b620f31fee2a41f00ddf7294edc81a60f6 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/21601 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
2017-09-19 21:25:11 +02:00
# int-add: adds an arbitrary length list of integers
Fix typos involving "the the" Change-Id: I179264ee6681a7ba4488b9f1c6bce1a19b4e1772 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/c/30160 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2018-12-11 17:53:07 +01:00
# int-subtract: subtracts the second of two integers from the first
Makefile.inc: Add left shift macro Add a macro to shift a value to the left by a specified number of bits. Change-Id: Ib3fb43b620f31fee2a41f00ddf7294edc81a60f6 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/21601 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
2017-09-19 21:25:11 +02:00
# int-multiply: multiplies an arbitrary length list of integers
# int-divide: divides the first integer by the second
# int-remainder: arithmetic remainder of the first number divided by the second
# int-shift-left: Shift $1 left by $2 bits
# int-lt: 1 if the first value is less than the second. 0 otherwise
# int-gt: 1 if the first values is greater than the second. 0 otherwise
# int-eq: 1 if the two values are equal. 0 otherwise
# int-align: align $1 to $2 units
# file-size: returns the filesize of the given file
# tolower: returns the value in all lowercase
# toupper: returns the value in all uppercase
# ws_to_under: returns the value with any whitespace changed to underscores
Makefile.inc: relocate get_fmap_value() here from soc/intel/common/block/cse Move this function to the root Makefile.inc since other Makefiles use the exact same function call. Will allow for deduplication in AMD SoC Makefiles in a follow-on commit. Change-Id: I56a50e21b27a4cd6ce1a08a3aea338c63322a6b2 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76167 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-29 23:39:53 +02:00
# get_fmap_value returns the value of a given FMAP field from fmap_config.h
build system: improve portability There are too many differences, and calculating relatively large integer using floats might not be the brightest idea anyway. Also avoid relying on ls(1) output format to determine file sizes. Change-Id: I5f96c036737b74e20f525c3dc9edc011ad403662 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7447 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-12 19:11:50 +01:00
_toint=$(shell printf "%d" $1)
top/Makefile.inc: add _tohex Get string of hex value of a given number. Change-Id: I6d3525db19089938897b9d19ad9875bb07e0eecf Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72953 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-02-11 09:28:16 +01:00
_tohex=$(shell printf 0x"%x" $1)
build system: improve portability There are too many differences, and calculating relatively large integer using floats might not be the brightest idea anyway. Also avoid relying on ls(1) output format to determine file sizes. Change-Id: I5f96c036737b74e20f525c3dc9edc011ad403662 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7447 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-12 19:11:50 +01:00
_int-add2=$(shell expr $(call _toint,$1) + $(call _toint,$2))
int-add=$(if $(filter 1,$(words $1)),$(strip $1),$(call int-add,$(call _int-add2,$(word 1,$1),$(word 2,$1)) $(wordlist 3,$(words $1),$1)))
Makefile.inc: Add math macros Add macros to standardize math done in the Makefiles in a posix compliant manner. int-multiply takes an arbitrary list of values to multiply, the same as the int-addition macro. The other macros only work on two values at a time. Change-Id: I3b754b9bcde26f33edc4f945d5af3d5444f383c7 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10874 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-03 20:54:14 +02:00
int-subtract=$(if $(filter 1,$(words $1)),$(strip $1),$(shell expr $(call _toint,$(word 1,$1)) - $(call _toint,$(word 2,$1))))
_int-multiply2=$(shell expr $(call _toint,$1) \* $(call _toint,$2))
int-multiply=$(if $(filter 1,$(words $1)),$(strip $1),$(call int-multiply,$(call _int-multiply2,$(word 1,$1),$(word 2,$1)) $(wordlist 3,$(words $1),$1)))
int-divide=$(if $(filter 1,$(words $1)),$(strip $1),$(shell expr $(call _toint,$(word 1,$1)) / $(call _toint,$(word 2,$1))))
int-remainder=$(if $(filter 1,$(words $1)),$(strip $1),$(shell expr $(call _toint,$(word 1,$1)) % $(call _toint,$(word 2,$1))))
Makefile.inc: Add left shift macro Add a macro to shift a value to the left by a specified number of bits. Change-Id: Ib3fb43b620f31fee2a41f00ddf7294edc81a60f6 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/21601 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
2017-09-19 21:25:11 +02:00
int-shift-left=$(shell echo "$(call _toint,$(word 1, $1)) * (2 ^ $(call _toint,$(word 2, $1)))" | bc)
Makefile.inc: Add math macros Add macros to standardize math done in the Makefiles in a posix compliant manner. int-multiply takes an arbitrary list of values to multiply, the same as the int-addition macro. The other macros only work on two values at a time. Change-Id: I3b754b9bcde26f33edc4f945d5af3d5444f383c7 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10874 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-03 20:54:14 +02:00
int-lt=$(if $(filter 1,$(words $1)),$(strip $1),$(shell expr $(call _toint,$(word 1,$1)) \< $(call _toint,$(word 2,$1))))
int-gt=$(if $(filter 1,$(words $1)),$(strip $1),$(shell expr $(call _toint,$(word 1,$1)) \> $(call _toint,$(word 2,$1))))
int-eq=$(if $(filter 1,$(words $1)),$(strip $1),$(shell expr $(call _toint,$(word 1,$1)) = $(call _toint,$(word 2,$1))))
build system: fix alignment function It seriously miscomputed alignment values, always off-by-one, and off-by-an-alignment for aligned values. Change-Id: Ide3477d09d34d7728cb0666bb30dd9f7a3f1056d Reported-by: Dave Frodin <dave.frodin@se-eng.com> Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7635 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
2014-12-03 11:20:51 +01:00
int-align=$(shell A=$(call _toint,$1) B=$(call _toint,$2); expr $$A + \( \( $$B - \( $$A % $$B \) \) % $$B \) )
Makefile.inc: Make sure the BIOS region is 64K aligned If a non aligned CONFIG_CBFS_SIZE is used the region RW_MRC_CACHE and CONSOLE could end up non aligned. Currently this is only possible if the user messes with CONFIG_CBFS_SIZE in menuconfig, but better be safe than sorry. Change-Id: Ieb7e3c7112bd4b3f9733c36af21b1d59b3836811 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30420 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-12-25 02:52:52 +01:00
int-align-down=$(shell A=$(call _toint,$1) B=$(call _toint,$2); expr $$A - \( $$A % $$B \) )
Makefile.inc: Fix build hang if file-size is run on empty string Currently, if for some reason, the file-size command is called on an empty string, the build will hang waiting for stdin input to cat. Since wc accepts a file, this cat was unnecessary anyway. Put the file name in quotes so an empty string will result in calling wc on an actual null file instead of just leaving the filename blank. This results in an error, and will probably halt the build. BUG=214790407 TEST=Build default build. Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Change-Id: I3dacf1968ed897a8ebd00f95583c2f254a7fb55a Reviewed-on: https://review.coreboot.org/c/coreboot/+/67263 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-09-01 04:42:50 +02:00
file-size=$(strip $(shell wc -c "$1" | cut -f 1 -d ' '))
Makefile.inc: Add toupper, tolower, and ws_to_under macros Add a few additional macros that can be used throughout the coreboot makefiles. tolower: returns the value in all lowercase toupper: returns the value in all uppercase ws_to_under: returns the value with any whitespace changed to underscores Change-Id: Icd0e6586481d8f229af0e899e0c94ef7c5c672c3 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14093 Tested-by: build bot (Jenkins) Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-03-14 22:07:14 +01:00
tolower=$(shell echo '$1' | tr '[:upper:]' '[:lower:]')
toupper=$(shell echo '$1' | tr '[:lower:]' '[:upper:]')
ws_to_under=$(shell echo '$1' | tr ' \t' '_')
Makefile.inc: relocate get_fmap_value() here from soc/intel/common/block/cse Move this function to the root Makefile.inc since other Makefiles use the exact same function call. Will allow for deduplication in AMD SoC Makefiles in a follow-on commit. Change-Id: I56a50e21b27a4cd6ce1a08a3aea338c63322a6b2 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76167 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-29 23:39:53 +02:00
get_fmap_value=$(shell awk '$$2 == "$1" {print $$3}' $(obj)/fmap_config.h)
build system: improve portability There are too many differences, and calculating relatively large integer using floats might not be the brightest idea anyway. Also avoid relying on ls(1) output format to determine file sizes. Change-Id: I5f96c036737b74e20f525c3dc9edc011ad403662 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7447 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-12 19:11:50 +01:00
build system: Split linking into multiple steps After collecting dependencies for ramstage, add an intermediate step in which object files are linked per directory. The results are then linked into the final binary. This reduces the maximum command line length and might also help with future use of LTO linking. Also adapt the lint test for build dir handling, since printall doesn't provide individual object files for ramstage anymore. Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-25 17:10:47 +01:00
#######################################################################
# Helper functions for ramstage postprocess
spc :=
Makefile.inc: Adapt $(spc) definition GNU Make 4.3 is more picky about the $(spc) definition. It seems, the variable ends up empty. The old definition worked for nearly 8 years, RIP. Tested with GNU Make 4.2.1 and 4.3. Change-Id: I7981e0066b550251ae4a98d7b50e83049fc5586a Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38790 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-02-09 11:24:32 +01:00
spc := $(spc) $(spc)
vboot: Install files into FW_MAIN_A and FW_MAIN_B unless they're for RO Setup an initial rule to make use of the updatable CBFS regions in fmap. Change-Id: I1fe1c6e7574854b735760c85590da6e297f6e687 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13060 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-20 15:54:31 +01:00
comma := ,
build system: Split linking into multiple steps After collecting dependencies for ramstage, add an intermediate step in which object files are linked per directory. The results are then linked into the final binary. This reduces the maximum command line length and might also help with future use of LTO linking. Also adapt the lint test for build dir handling, since printall doesn't provide individual object files for ramstage anymore. Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-25 17:10:47 +01:00
Makefile.inc: Rewrite $(files-in-dir) The `files-in-dir` macro is supposed to return all files (out of a given set) that reside directly (non-recursive) in a given directory. While the current solution worked splendidly, we can achieve the same without recursive macros that look at each parent dir individually. Beside providing better readability, this also fixes a future make error, as make doesn't like the variable name ` ` anymore ;) Change-Id: Iac0eacdf91b8b5098592ad301c1f3fdb632454e9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/27324 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-07-02 18:19:40 +02:00
# Returns all files and dirs below `dir` (recursively).
# files-below-dir,dir,files
files-below-dir=$(filter $(1)%,$(2))
build system: Split linking into multiple steps After collecting dependencies for ramstage, add an intermediate step in which object files are linked per directory. The results are then linked into the final binary. This reduces the maximum command line length and might also help with future use of LTO linking. Also adapt the lint test for build dir handling, since printall doesn't provide individual object files for ramstage anymore. Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-25 17:10:47 +01:00
Makefile.inc: Rewrite $(files-in-dir) The `files-in-dir` macro is supposed to return all files (out of a given set) that reside directly (non-recursive) in a given directory. While the current solution worked splendidly, we can achieve the same without recursive macros that look at each parent dir individually. Beside providing better readability, this also fixes a future make error, as make doesn't like the variable name ` ` anymore ;) Change-Id: Iac0eacdf91b8b5098592ad301c1f3fdb632454e9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/27324 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-07-02 18:19:40 +02:00
# Returns all dirs below `dir` (recursively).
# dirs-below-dir,dir,files
dirs-below-dir=$(filter-out $(1),$(sort $(dir $(call files-below-dir,$(1),$(2)))))
build system: Split linking into multiple steps After collecting dependencies for ramstage, add an intermediate step in which object files are linked per directory. The results are then linked into the final binary. This reduces the maximum command line length and might also help with future use of LTO linking. Also adapt the lint test for build dir handling, since printall doesn't provide individual object files for ramstage anymore. Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-25 17:10:47 +01:00
Makefile.inc: Rewrite $(files-in-dir) The `files-in-dir` macro is supposed to return all files (out of a given set) that reside directly (non-recursive) in a given directory. While the current solution worked splendidly, we can achieve the same without recursive macros that look at each parent dir individually. Beside providing better readability, this also fixes a future make error, as make doesn't like the variable name ` ` anymore ;) Change-Id: Iac0eacdf91b8b5098592ad301c1f3fdb632454e9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/27324 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-07-02 18:19:40 +02:00
# Returns all files directly in `dir` (non-recursively).
build system: Split linking into multiple steps After collecting dependencies for ramstage, add an intermediate step in which object files are linked per directory. The results are then linked into the final binary. This reduces the maximum command line length and might also help with future use of LTO linking. Also adapt the lint test for build dir handling, since printall doesn't provide individual object files for ramstage anymore. Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-25 17:10:47 +01:00
# files-in-dir,dir,files
Makefile.inc: Rewrite $(files-in-dir) The `files-in-dir` macro is supposed to return all files (out of a given set) that reside directly (non-recursive) in a given directory. While the current solution worked splendidly, we can achieve the same without recursive macros that look at each parent dir individually. Beside providing better readability, this also fixes a future make error, as make doesn't like the variable name ` ` anymore ;) Change-Id: Iac0eacdf91b8b5098592ad301c1f3fdb632454e9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/27324 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-07-02 18:19:40 +02:00
files-in-dir=$(filter-out $(addsuffix %,$(call dirs-below-dir,$(1),$(2))),$(call files-below-dir,$(1),$(2)))
build system: Split linking into multiple steps After collecting dependencies for ramstage, add an intermediate step in which object files are linked per directory. The results are then linked into the final binary. This reduces the maximum command line length and might also help with future use of LTO linking. Also adapt the lint test for build dir handling, since printall doesn't provide individual object files for ramstage anymore. Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-25 17:10:47 +01:00
#######################################################################
# reduce command line length by linking the objects of each
# directory into an intermediate file
Makefile: Fix dependency tracking for ramstage objects Dependency tracking in incremental builds is currently broken for the ramstage, due to the intermediate linking step into one ramstage.o file per directory. The original xxx.ramstage.o files are removed from ramstage-objs, so they don't end up in allobjs and won't get translated into DEPENDENCIES. This patch explicitly adds them to DEPENDENCIES beforehand to resolve the issue. BRANCH=None BUG=None TEST=Built, ran 'touch src/include/cbmem.h' and built again incrementally. Confirmed that objects dependent on the modified header such as timestamp.ramstage.o get rebuilt correctly. Change-Id: I3ba411e4073b38e038445aadceeccfe6c09670c8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9c57d6a8421a109ee3e87567c9add579f9ae761e Original-Change-Id: Ife529ad8f5c011456c1e0c380356f1b1bb5047cb Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/233571 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9745 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-05 21:32:09 +01:00
ramstage-postprocess=$$(eval DEPENDENCIES+=$$(addsuffix .d,$$(basename $(1)))) \
$(foreach d,$(sort $(dir $(filter-out %.ld,$(1)))), \
build system: use archives, not linker action to shorten command lines Intermediate linking may distort linker behavior (in particular related to weak symbols). The idea is that archives are closer to 'just a list of object files', and ideally makes the linker more predictable. Using --whole-archive, the linker doesn't optimize out object files just because their symbols were already provided by weak versions. However it shouldn't be used for libgcc, because that one has some unexpected side-effects. Change-Id: Ie226c198a93bcdca2d82c02431c72108a1c6ea60 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10139 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-05-07 22:24:41 +02:00
$(eval $(d)ramstage.a: $(call files-in-dir,$(d),$(filter-out %.ld,$(1))); rm -f $$@ && $(AR_ramstage) rcsT $$@ $$^ ) \
$(eval ramstage-objs:=$(d)ramstage.a $(filter-out $(filter-out %.ld, $(call files-in-dir,$(d),$(1))),$(ramstage-objs))))
build system: Split linking into multiple steps After collecting dependencies for ramstage, add an intermediate step in which object files are linked per directory. The results are then linked into the final binary. This reduces the maximum command line length and might also help with future use of LTO linking. Also adapt the lint test for build dir handling, since printall doesn't provide individual object files for ramstage anymore. Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1911 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-25 17:10:47 +01:00
Makefiles: Remove -D__PRE_RAM__ All cases of testing for __PRE_RAM__ have been converted to equivalent ENV_xxx definitions from <rules.h>. Change-Id: Ib6cd598f17109cc1072818cebe4791f7410c3428 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37075 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-11-21 07:09:34 +01:00
decompressor-generic-ccopts += -D__DECOMPRESSOR__
bootblock-generic-ccopts += -D__BOOTBLOCK__
romstage-generic-ccopts += -D__ROMSTAGE__
Add predefined __ROMSTAGE__ and __RAMSTAGE__ macros This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get predefined in their respective stages by make, so that we have one specific macro for every stage. It also renames __BOOT_BLOCK__ and __VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency. This change is intended to provide finer control and clearer communication of intent after we added a new (optional) stage that falls under __PRE_RAM__, and will hopefully provide some robustness for the future (we don't want to end up always checking for romstage with #if defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) && !defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The __PRE_RAM__ macro stays as it is since many features do in fact need to differentiate on whether RAM is available. (Some also depend on whether RAM is available at the end of a stage, in which case #if !defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be authoritative.) It's unfeasable to change all existing occurences of __PRE_RAM__ that would be better described with __ROMSTAGE__, so this patch only demonstratively changes a few obvious ones in core code. BUG=None TEST=None (tested together with dependent patch). Change-Id: I6a06d0f42c27a2feeb778a4acd35dd14bb53f744 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a4ad042746c1d3a7a3bfda422d26e0d3b9f9ae42 Original-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219172 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9304 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-09-16 07:10:33 +02:00
ramstage-generic-ccopts += -D__RAMSTAGE__
Implement GCC code coverage analysis In order to provide some insight on what code is executed during coreboot's run time and how well our test scenarios work, this adds code coverage support to coreboot's ram stage. This should be easily adaptable for payloads, and maybe even romstage. See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for more information. To instrument coreboot, select CONFIG_COVERAGE ("Code coverage support") in Kconfig, and recompile coreboot. coreboot will then store its code coverage information into CBMEM, if possible. Then, run "cbmem -CV" as root on the target system running the instrumented coreboot binary. This will create a whole bunch of .gcda files that contain coverage information. Tar them up, copy them to your build system machine, and untar them. Then you can use your favorite coverage utility (gcov, lcov, ...) to visualize code coverage. For a sneak peak of what will expect you, please take a look at http://www.coreboot.org/~stepan/coreboot-coverage/ Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2052 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Martin Roth <martin@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-19 01:23:28 +01:00
ifeq ($(CONFIG_COVERAGE),y)
Add predefined __ROMSTAGE__ and __RAMSTAGE__ macros This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get predefined in their respective stages by make, so that we have one specific macro for every stage. It also renames __BOOT_BLOCK__ and __VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency. This change is intended to provide finer control and clearer communication of intent after we added a new (optional) stage that falls under __PRE_RAM__, and will hopefully provide some robustness for the future (we don't want to end up always checking for romstage with #if defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) && !defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The __PRE_RAM__ macro stays as it is since many features do in fact need to differentiate on whether RAM is available. (Some also depend on whether RAM is available at the end of a stage, in which case #if !defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be authoritative.) It's unfeasable to change all existing occurences of __PRE_RAM__ that would be better described with __ROMSTAGE__, so this patch only demonstratively changes a few obvious ones in core code. BUG=None TEST=None (tested together with dependent patch). Change-Id: I6a06d0f42c27a2feeb778a4acd35dd14bb53f744 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a4ad042746c1d3a7a3bfda422d26e0d3b9f9ae42 Original-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219172 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9304 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-09-16 07:10:33 +02:00
ramstage-c-ccopts += -fprofile-arcs -ftest-coverage
Implement GCC code coverage analysis In order to provide some insight on what code is executed during coreboot's run time and how well our test scenarios work, this adds code coverage support to coreboot's ram stage. This should be easily adaptable for payloads, and maybe even romstage. See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for more information. To instrument coreboot, select CONFIG_COVERAGE ("Code coverage support") in Kconfig, and recompile coreboot. coreboot will then store its code coverage information into CBMEM, if possible. Then, run "cbmem -CV" as root on the target system running the instrumented coreboot binary. This will create a whole bunch of .gcda files that contain coverage information. Tar them up, copy them to your build system machine, and untar them. Then you can use your favorite coverage utility (gcov, lcov, ...) to visualize code coverage. For a sneak peak of what will expect you, please take a look at http://www.coreboot.org/~stepan/coreboot-coverage/ Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2052 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Martin Roth <martin@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-19 01:23:28 +01:00
endif
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
ifneq ($(GIT),)
Makefile.inc: Stop running git repeatedly for each build Currently, the coreboot makefiles repeatedly run git to try to set the KERNELVERSION variable and to fetch the submodules. This happens three times for every build. By exporting a variable, we can catch this on recursive makes and not run each of these steps again. Change-Id: I85ab867b40e80c36bd94d48510ffe3252c6cf93f Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14392 Tested-by: build bot (Jenkins) Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2016-04-20 04:15:16 +02:00
ifneq ($(UPDATED_SUBMODULES),1)
Makefile.inc: Notify about updating submodules There is no longer any information printed when updating submodules, so on the initial build, this can lead to a long delay without explaining what's going on. Just add an information line that the submodules are being updated so that the user can see what's happening. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I987e50b99e39b976bc8367525549153e1eba69cd Reviewed-on: https://review.coreboot.org/c/coreboot/+/65322 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:35:58 +02:00
$(info Updating git submodules.)
Only update submodules if the source is in a git repo This change just adds a check to verify that the build is happening inside a git repo and that git is a valid command before trying to update the submodules. Use 'command -v' instead of 'which' to stay portable. Change-Id: Idfa27645c3dbfd684f90002ecb01626d71eacc8f Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/8427 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-02-13 03:34:11 +01:00
# try to fetch non-optional submodules if the source is under git
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
forgetthis:=$(shell git submodule update --init $(quiet_errors))
Makefile,tests: Move cmocka checkout into top level Makefile cmocka is currently ignoring the UPDATED_SUBMODULES flag. Move the cmocka checkout with the other submodule checkouts. BUG=none TEST=Make sure cmocka is not checked out if UPDATED_SUBMODULES=1 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I2a1db809368a77d2c0f9c9a796d62555ec476dc7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/52578 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
2021-04-21 23:09:04 +02:00
# Checkout Cmocka repository
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/cmocka $(quiet_errors))
Add Kconfig options to handle the blobs repository One option to allow using the repo (defaults to no), one to let boards state that they require it in the current configuration. The build system checks out the repo if allowed, and fails if the repo is requested by the configuration but not desired by the user. Change-Id: If71d80b329cf528aa467fcb0b4d9d7c7434aab27 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/957 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2012-04-30 21:06:10 +02:00
ifeq ($(CONFIG_USE_BLOBS),y)
Makefile.inc: Consolidate submodule comments Reduce duplicated comments explaining that submodules' settings in .gitmodules are update=none, and that --checkout is required. This prepares for another submodule, and makes adding a third set of comments unnecessary. Change-Id: I7721333a61122284ed9975ecd2adc3271a879728 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36440 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-10-29 18:44:16 +01:00
# These items are necessary because each has update=none in .gitmodules. They are ignored
# until expressly requested and enabled with --checkout
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/blobs $(quiet_errors))
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/intel-microcode $(quiet_errors))
Makefile.inc: Simplify fsp submodule check TEST=Building Asrock H110M using FSP from repo updates the submodule. Change-Id: I25023af88d878353a04db456009249da67e41521 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42778 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-06-24 18:49:41 +02:00
ifeq ($(CONFIG_FSP_USE_REPO),y)
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/fsp $(quiet_errors))
vendorcode/intel/fsp1_0/broadwell_de: Use FSP from 3rdparty/fsp Default to FSP binary and headers shiped in 3rdparty/fsp. * Drop headers and code from vendorcode/intel/fsp1_0/broadwell_de * Select HAVE_FSP_BIN to build test the platform * Fetch FSP repo as submodule * Make FSP_HEADER_PATH known from FSP2.0 useable on FSP1.0 * Introduce FSP_SRC_PATH for FSP source file * Add sane defaults for FSP_FILE Tested on wedge100s. Change-Id: I46f201218d19cf34c43a04f57458f474d8c3340d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/30742 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
2019-01-08 11:37:18 +01:00
endif
Makefile, Kconfig: Add AMD dependency for amd_blobs repo Add a Kconfig option for indicating agreement to use the contents of amd_blobs. Users should only download the repo after implicitely agreeing to AMD's License text. No formal documented agreement is required. Update Makfile.inc, similar to other submodules, to initialize and checkout the submodule once the Kconfig option is selected. Change-Id: I4ae807659db16756453dc3db2c51848291c681b8 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36416 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-10-28 22:55:03 +01:00
ifeq ($(CONFIG_USE_AMD_BLOBS),y)
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/amd_blobs $(quiet_errors))
Makefile, Kconfig: Add AMD dependency for amd_blobs repo Add a Kconfig option for indicating agreement to use the contents of amd_blobs. Users should only download the repo after implicitely agreeing to AMD's License text. No formal documented agreement is required. Update Makfile.inc, similar to other submodules, to initialize and checkout the submodule once the Kconfig option is selected. Change-Id: I4ae807659db16756453dc3db2c51848291c681b8 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36416 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-10-28 22:55:03 +01:00
endif
Add qc_blobs repository This patch adds a separate blobs repository for Qualcomm blobs, analogous to the existing AMD blobs. Qualcomm's binary licenses allow files to be redistributed and used by anyone, but they explicitly require the user to agree to the license terms when just *downloading* the binary (even if they're not using them to build any firmware). Some community members do not like to have to agree to licenses for files they're not actually using, so we are keeping these files separate from the main blobs repository and adding an extra Kconfig to make sure the user is aware of and must explicitly agree to this before downloading these files. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I247746c1b633343064c9f32ef1556000475d6c4a Reviewed-on: https://review.coreboot.org/c/coreboot/+/42548 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-06-19 00:03:22 +02:00
ifeq ($(CONFIG_USE_QC_BLOBS),y)
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/qc_blobs $(quiet_errors))
Add qc_blobs repository This patch adds a separate blobs repository for Qualcomm blobs, analogous to the existing AMD blobs. Qualcomm's binary licenses allow files to be redistributed and used by anyone, but they explicitly require the user to agree to the license terms when just *downloading* the binary (even if they're not using them to build any firmware). Some community members do not like to have to agree to licenses for files they're not actually using, so we are keeping these files separate from the main blobs repository and adding an extra Kconfig to make sure the user is aware of and must explicitly agree to this before downloading these files. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I247746c1b633343064c9f32ef1556000475d6c4a Reviewed-on: https://review.coreboot.org/c/coreboot/+/42548 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-06-19 00:03:22 +02:00
endif
vendorcode/intel/fsp1_0/broadwell_de: Use FSP from 3rdparty/fsp Default to FSP binary and headers shiped in 3rdparty/fsp. * Drop headers and code from vendorcode/intel/fsp1_0/broadwell_de * Select HAVE_FSP_BIN to build test the platform * Fetch FSP repo as submodule * Make FSP_HEADER_PATH known from FSP2.0 useable on FSP1.0 * Introduce FSP_SRC_PATH for FSP source file * Add sane defaults for FSP_FILE Tested on wedge100s. Change-Id: I46f201218d19cf34c43a04f57458f474d8c3340d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/30742 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
2019-01-08 11:37:18 +01:00
endif
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
UPDATED_SUBMODULES:=1
COREBOOT_EXPORTS += UPDATED_SUBMODULES
Makefiles: Hide skipping submodule info unless V=1 Currently, git prints out the submodules that are being skipped twice on many builds. This patch hides that output unless the build is set to show it with `make V=1`. This is the normal way of showing the extra information during the build. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I7b5c7f1f79dcc88793a9a21f2e92e7accc5de1e0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59511 Reviewed-by: Patrick Georgi <patrick@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-11-21 16:42:04 +01:00
Makefile.inc: Stop running git repeatedly for each build Currently, the coreboot makefiles repeatedly run git to try to set the KERNELVERSION variable and to fetch the submodules. This happens three times for every build. By exporting a variable, we can catch this on recursive makes and not run each of these steps again. Change-Id: I85ab867b40e80c36bd94d48510ffe3252c6cf93f Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/14392 Tested-by: build bot (Jenkins) Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2016-04-20 04:15:16 +02:00
endif
Makefile.inc: Update submodules only when git is present Instead of trying to update the submodules, then skipping each update if git is not present, just don't try to update the submodules at all. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2022-06-23 02:33:43 +02:00
endif # GIT != ""
Add Kconfig options to handle the blobs repository One option to allow using the repo (defaults to no), one to let boards state that they require it in the current configuration. The build system checks out the repo if allowed, and fails if the repo is requested by the configuration but not desired by the user. Change-Id: If71d80b329cf528aa467fcb0b4d9d7c7434aab27 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/957 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2012-04-30 21:06:10 +02:00
drivers/pc80/rtc: Build for bootblock and postcar stages too Fixes builds with BOOTBLOCK_CONSOLE && USE_OPTION_TABLE. Change-Id: I1c7e9baa60f33c2c3651e2def0335454f7e20451 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/20767 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-07-25 15:55:08 +02:00
postcar-c-deps:=$$(OPTION_TABLE_H)
Add option_table.h as dependency for all C based object files if option tables are used. This is to make sure that the file exists when it is needed. While this isn't the case for every C source file, it doesn't hurt either to create the file a bit sooner than strictly necessary. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Jonathan Kollasch <jakllsch@kollasch.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6438 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-03-08 21:49:18 +01:00
ramstage-c-deps:=$$(OPTION_TABLE_H)
romstage-c-deps:=$$(OPTION_TABLE_H)
vboot2: add verstage This reverts the revert commit 5780d6f3876723b94fbe3653c9d87dad6330862e and fixes the build issue that cuased it to be reverted. Verstage will host vboot2 for firmware verification. It's a stage in the sense that it has its own set of toolchains, compiler flags, and includes. This allows us to easily add object files as needed. But it's directly linked to bootblock. This allows us to avoid code duplication for stage loading and jumping (e.g. cbfs driver) for the boards where bootblock has to run in a different architecture (e.g. Tegra124). To avoid name space conflict, verstage symbols are prefixed with verstage_. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac Original-Reviewed-on: https://chromium-review.googlesource.com/204376 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf Reviewed-on: http://review.coreboot.org/8224 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-14 19:51:47 +01:00
verstage-c-deps:=$$(OPTION_TABLE_H)
armv7: Add 'bootblock' build class. For ARM platform, the bootblock may need more C source files to initialize UART / SPI for loading romstage. To preventing making complex and implicit dependency by using #include inside bootblock.c, we should add a new build class "bootblock". Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled for boot block. For x86, the bootblock is limited to fewer assembly files so it's not using this class. (Some files shared by x86 and arm in top level or lib are also changed but nothing should be changed in x86 build process.) Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2252 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-01-31 18:09:24 +01:00
bootblock-c-deps:=$$(OPTION_TABLE_H)
Add minimal GNAT run time system (RTS) Add a stripped-down version of libgnat. This is somehow comparable to libgcc but for Ada programs. It's licensed under GPLv3 but with the runtime library exception. So it's totally fine to link it with our GPLv2 code and keep it under GPLv2. Change-Id: Ie6522abf093f0a516b9ae18ddc69131bd721dc0c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/11836 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-09-29 16:41:19 +02:00
$(foreach type,ads adb, \
$(foreach stage,$(COREBOOT_STANDARD_STAGES), \
Hook up Kconfig Ada spec file We generate a $(obj)/cb-config.ads once and copy it per stage that uses it to $(obj)/<stage>/cb-config.ads (to simplify the gnat-bind step). The Ada package is called `CB.Config`. As there was no `CB` package yet, add that too. Change-Id: I963a6517ef4bcf84f2c8e9ae8d24a0d6b971d2b0 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/30584 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-01-01 22:06:01 +01:00
$(eval $(stage)-$(type)-deps := \
$(obj)/$(stage)/$(notdir $(KCONFIG_AUTOADS)) \
$(obj)/libgnat-$(ARCH-$(stage)-y)/libgnat.a)))
Add option_table.h as dependency for all C based object files if option tables are used. This is to make sure that the file exists when it is needed. While this isn't the case for every C source file, it doesn't hurt either to create the file a bit sooner than strictly necessary. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Jonathan Kollasch <jakllsch@kollasch.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6438 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-03-08 21:49:18 +01:00
build system x86: deprecate bootblock_lds and ldscripts variables Instead of keeping this separate variable around, add linker scripts to the $(class)-y source lists and let the build system sort things out. This is inspired by the commit listed below, but rewritten to match upstream, and split in smaller pieces to keep intent clear. Change-Id: I4af687becf2971e009cb077debc902d2f0722cfb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org> Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170 Reviewed-on: http://review.coreboot.org/9289 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-04-03 10:47:15 +02:00
# Add handler to copy linker scripts
define generic-objs_ld_template_gen
de$(EMPTY)fine $(1)-objs_ld_template
lib/fmap: Add optional pre-RAM cache This patch adds an optional pre-RAM cache for the FMAP which most platforms should be able to use, complementing the recently added post-RAM FMAP cache in CBMEM. vboot systems currently read the FMAP about half a dozen times from flash in verstage, which will all be coalesced into a single read with this patch. It will also help future vboot improvements since when FMAP reads become "free" vboot doesn't need to keep track of so much information separately. In order to make sure we have a single, well-defined point where the new cache is first initialized, eliminate the build-time hardcoding of the CBFS section offsets, so that all CBFS accesses explicitly read the FMAP. Add FMAP_CACHEs to all platforms that can afford it (other than the RISC-V things where I have no idea how they work), trying to take the space from things that look like they were oversized anyway (pre-RAM consoles and CBFS caches). Change-Id: I2820436776ef620bdc4481b5cd4b6957764248ea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Joel Kitching <kitching@google.com>
2019-11-07 04:29:44 +01:00
$$(call src-to-obj,$1,$$(1).ld): $$(1).ld $(obj)/config.h $(obj)/fmap_config.h
build system x86: deprecate bootblock_lds and ldscripts variables Instead of keeping this separate variable around, add linker scripts to the $(class)-y source lists and let the build system sort things out. This is inspired by the commit listed below, but rewritten to match upstream, and split in smaller pieces to keep intent clear. Change-Id: I4af687becf2971e009cb077debc902d2f0722cfb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org> Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170 Reviewed-on: http://review.coreboot.org/9289 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-04-03 10:47:15 +02:00
@printf " CP $$$$(subst $$$$(obj)/,,$$$$(@))\n"
Makefile: Fix dependency tracking for linker scripts When the memlayout framework was initially developed in the Chromium OS tree, the accompanying build system changes unified handling for all file types (including .ld and .asl) in a single template. This had the advantage that compiler invocation options pertaining to the build system itself could be centralized in a single place. On upstreaming this was reverted for some reason, keeping the old special handling for ASL files and writing a custom template for LD. The duplicated compiler invocation code for the latter was missing the -MMD flag required for dependency tracking. It was also missing at least one $-sign which causes the $(<class>-ld-ccopts) variable to be evaluated at the time it's parsing the template generator (before the subdirectory pass). This should not cause any issues with current code, but all the ccopts variables were meant to be evaluated after the subdirectory pass (so things like archs and SoCs can manipulate them if needed), so this patch fixes both issues. BRANCH=None BUG=None TEST='make; touch src/soc/.../memlayout.ld; make' re-links all stages and includes the changed symbol addresses from the new address map. Change-Id: I4be458112908380268229b3220cfa0062add5c5d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e8a36f994ef6a819ded7bf6b39b1e0fce8e52279 Original-Change-Id: If2310b46b53d888975cb2113edce20a896be39ef Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/303054 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/12139 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-09-30 01:41:11 +02:00
$$(CC_$(1)) -MMD $$(CPPFLAGS_$(1)) $$($(1)-ld-ccopts) $(PREPROCESS_ONLY) -include $(obj)/config.h -MT $$$$@ -o $$$$@ $$$$<
build system x86: deprecate bootblock_lds and ldscripts variables Instead of keeping this separate variable around, add linker scripts to the $(class)-y source lists and let the build system sort things out. This is inspired by the commit listed below, but rewritten to match upstream, and split in smaller pieces to keep intent clear. Change-Id: I4af687becf2971e009cb077debc902d2f0722cfb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org> Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170 Reviewed-on: http://review.coreboot.org/9289 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-04-03 10:47:15 +02:00
en$(EMPTY)def
endef
build system: Allow using .a archives as source Change-Id: I1d61971f1458ca7e4257abb6a9c2aa15ac08e1d0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10001 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-27 18:01:12 +02:00
# Add handler to deal with archives
define generic-objs_a_template_gen
de$(EMPTY)fine $(1)-objs_a_template
$$(call src-to-obj,$1,$$(1).a): $$(1).a
Makefile: Don't copy thin archives around We can't just copy archives around as they may be thin archives which contain relative paths. Using ar to create another thin archive should result in the same archive with fixed paths. Tested by verifying that the resulting coreboot.rom files didn't change for all of Jenkins' abuild configurations. Change-Id: Ic5743da2f4b5eb246fafd02181d66c5d40e7f00c Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13179 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-23 03:23:23 +01:00
@printf " AR $$$$(subst $$$$(obj)/,,$$$$(@))\n"
$$$$(AR_$(1)) rcsT $$$$@.tmp $$$$<
build system: Allow using .a archives as source Change-Id: I1d61971f1458ca7e4257abb6a9c2aa15ac08e1d0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10001 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-27 18:01:12 +02:00
mv $$$$@.tmp $$$$@
en$(EMPTY)def
endef
build system: Introduce manual file type It's used for files with custom build rules, eg. the objcopy stuff surrounding smm and sipi_vector. Change-Id: Ie9ab4c9c6008ca42f82f768c5f33f90c7f5f4db5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9287 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-03 10:39:05 +02:00
# Add handler to add no rules for manual files
define generic-objs_manual_template_gen
# do nothing
endef
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# Add handler to compile ACPI's ASL
x86: parameterize asl_template for CBFS inclusion The asl_template previously unconditionally included dsdt.aml. However, COMPILE_IN_DSDT=y results in the dsdt.aml being linked directly into ramstage. Thus the information is duplicated. The inclusion of this file unconditionally throws some errors as certain assets need to be included in CBFS. However, as there isn't fine-grained ordering control in how files are added fixed resource requirements for other assets collide result in failure to build. To remedy both things, provide a 2nd argument to asl_template which defaults to 'y' for CBFS addition. In the COMPILE_IN_DSDT=y case pass 'n' so that dsdt.aml is no longer added. BUG=chrome-os-partner:43419 BRANCH=None TEST=For glados: Built with COMPILE_IN_DSDT=y. dsdt.aml not included. Built with COMPILE_IN_DSDT=n. dsdt.aml was included. Original-Change-Id: I4767e5be2915c1732251fe415017f30314c5efc9 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/289840 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Change-Id: Id1828627ba0a034eb05b2fe23be76e19f3040444 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11166 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-07-30 19:44:58 +02:00
# arg1: base file name
# arg2: y or n for including in cbfs. defaults to y
Makefile.inc: Ignore IASL empty resource template warnings As I mention in the comment, this is valid ASL, which was added as a warning with the comment "This would appear to be worthless in real-world ASL code." While code using empty resource templates could probably be rewritten, this seems like an arbitrary choice to generate this as a warning, since it's valid. This gets rid of warnings such as this one: dsdt.aml 2975: Return (ResourceTemplate() {}) Warning 3150 - Empty Resource Template (END_TAG only) Which is generated by this code in google/rambi/acpi/mainboard.asl: Method (_CRS) { /* Only return interrupt if I2C1 is PCI mode */ If (LEqual (\S1EN, 0)) { Return (^RBUF) } /* Return empty resource template otherwise */ Return (ResourceTemplate() {}) } Change-Id: I9cfe9069c738a284aa85feada9d58e1aee97e433 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/26352 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-17 18:18:01 +02:00
# Empty resource templates were marked as a warning in IASL with the comment
# "This would appear to be worthless in real-world ASL code.", which is
# possibly true in many cases. In other cases it seems that an empty
# ResourceTemplate is the correct code.
# As it's valid ASL, disable the warning.
EMPTY_RESOURCE_TEMPLATE_WARNING = 3150
Makefile.inc: Ignore _HID & _ADR conflicts in Broadwell & Lynxpoint We haven't been able to update IASL in 8 months because of this conflict. Ignoring it doesn't make things any worse than they are now. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Iced2e55e9f2aa7a262a5c1ffeff32af78acfa35e Reviewed-on: https://review.coreboot.org/c/coreboot/+/38810 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-02-09 22:30:26 +01:00
Makefile.inc: Remove leftover Commit 9a8d0a03db (crossgcc: Upgrade IASL from 20211217 to 20220331) removed this parameter. Change-Id: Iba062efcabac88edc1f7937b75ea9d5d884b448b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64217 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-05-09 15:18:56 +02:00
IASL_WARNINGS_LIST = $(EMPTY_RESOURCE_TEMPLATE_WARNING)
Makefile.inc: Print warning type ignored by IASL - Use a new variable to store the list of warning types; - print this list when building an image. TEST = build image on Kontron mAL-10 COMe module: IASL 3150 2158 3133 warning types were ignored! IASL build/dsdt.aml disassembled correctly. Change-Id: I46f761612254b400563f8567be9bd61601f23467 Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44864 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-08-27 15:41:53 +02:00
IGNORED_IASL_WARNINGS = $(addprefix -vw , $(IASL_WARNINGS_LIST))
Make DSDT a file in CBFS rather than embedding it into ramstage. Makes it cleaner by putting AML into separate file rather than having an array in C code. Change-Id: Ia5d6b50ad9dabdb97ed05c837dc3ccc48b8f490f Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10385 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-31 12:31:59 +02:00
define asl_template
build system: strip quotes from CONFIG_CBFS_PREFIX in a single location Instead of having to remember to strip the quotes everywhere so that string comparisons (of which there are a few) match up, do it right at the beginning. Fixes building the image with a .config where CONFIG_CBFS_PREFIX contains quotes. Change-Id: I4d63341cd9f0bc5e313883ef7b5ca6486190c124 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12578 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-11-30 22:44:53 +01:00
$(CONFIG_CBFS_PREFIX)/$(1).aml-file = $(obj)/$(1).aml
$(CONFIG_CBFS_PREFIX)/$(1).aml-type = raw
$(CONFIG_CBFS_PREFIX)/$(1).aml-compression = none
acpi,Makefile: Add preload_acpi_dsdt This will allow us to preload the dsdt.aml file. BUG=b:179699789 TEST=Build guybrush | 80 - write tables | 1.564 | 1.08 Δ( -0.48, -0.03%) | | 85 - finalize chips | 15.483 | 13.543 Δ( -1.94, -0.14%) | Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ibf69ecb947811a2eec861018e3ba5f858155f1c3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59504 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-11-19 19:38:35 +01:00
ifeq ($(CONFIG_SOC_AMD_COMMON_BLOCK_LPC_SPI_DMA),y)
$(CONFIG_CBFS_PREFIX)/$(1).aml-align = 64
endif
build system: strip quotes from CONFIG_CBFS_PREFIX in a single location Instead of having to remember to strip the quotes everywhere so that string comparisons (of which there are a few) match up, do it right at the beginning. Fixes building the image with a .config where CONFIG_CBFS_PREFIX contains quotes. Change-Id: I4d63341cd9f0bc5e313883ef7b5ca6486190c124 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12578 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-11-30 22:44:53 +01:00
cbfs-files-$(if $(2),$(2),y) += $(CONFIG_CBFS_PREFIX)/$(1).aml
Makefile.inc: Include build/dsdt.d if it exists The dsdt dependency file is created, but wasn't being used to determine whether or not to update the dsdt file. If it's present, include it into the makefile so dsdt.aml gets rebuilt if any of the depencencies change. Change-Id: I76bc22541c6b9740841bda891a5b88030cb949cd Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12699 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-09 21:05:00 +01:00
-include $(obj)/$(1).d
Make DSDT a file in CBFS rather than embedding it into ramstage. Makes it cleaner by putting AML into separate file rather than having an array in C code. Change-Id: Ia5d6b50ad9dabdb97ed05c837dc3ccc48b8f490f Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10385 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-31 12:31:59 +02:00
$(obj)/$(1).aml: $(src)/mainboard/$(MAINBOARDDIR)/$(1).asl $(obj)/config.h
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
@printf " IASL $$(subst $(top)/,,$$(@))\n"
Makefile.inc: Keep .asl intermediates We used .aml as the file extension for preprocessed ASL code. That file gets overwritten with the compilation results, fix that. Change-Id: I11a03dfbcebb0fd762da7b27862a7bdb9a581b92 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/31523 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-02-20 17:03:52 +01:00
$(CC_ramstage) -x assembler-with-cpp -E -MMD -MT $$(@) $$(CPPFLAGS_ramstage) -D__ACPI__ -P -include $(src)/include/kconfig.h -I$(obj) -I$(src) -I$(src)/include -I$(src)/arch/$(ARCHDIR-$(ARCH-ramstage-y))/include -I$(src)/mainboard/$(MAINBOARDDIR) $$< -o $(obj)/$(1).asl
cd $$(dir $$@); $(IASL) $(IGNORED_IASL_WARNINGS) -we -p $$(notdir $$@) $(1).asl
Makefile.inc: Print warning type ignored by IASL - Use a new variable to store the list of warning types; - print this list when building an image. TEST = build image on Kontron mAL-10 COMe module: IASL 3150 2158 3133 warning types were ignored! IASL build/dsdt.aml disassembled correctly. Change-Id: I46f761612254b400563f8567be9bd61601f23467 Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44864 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-08-27 15:41:53 +02:00
echo " IASL "$(IASL_WARNINGS_LIST)" warning types were ignored!"
Makefile: Check for errors in ACPI decompilation, too We only grep'ed for "ACPI Warning" resulting in an actual more severe "ACPI Error" being ignored. Change-Id: I9cec8a388f5558b1ffc383cc2fc69405252cbb37 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32469 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-04-26 15:11:42 +02:00
if ! $(IASL) -d $$@ 2>&1 | grep -Eq 'ACPI (Warning|Error)'; then \
echo " IASL $$@ disassembled correctly."; \
true; \
else \
echo "Error: Could not correctly disassemble $$@"; \
$(IASL) -d $$@; \
false; \
fi
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
endef
Add preprocessing capabilities to the cbfs-files mechanism It's now possible to generate files that are about to be added to CBFS by specifying "sourcefile:method" as real file name. This makes the build system use the cbfs-files-preprocessor-$(method) function to create a file from sourcefile. That generated file is then added to CBFS. The first method to be defined is "nvramtool". It expects a plain text specification of the CMOS configuration and emits the binary format suitable for cmos.default. Change-Id: I33a142718fc7238eaf5317b0ed62b4726d9b48f2 Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com> Reviewed-on: http://review.coreboot.org/847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-09 12:30:07 +01:00
#######################################################################
treewide: Capitalize 'CMOS' Change-Id: I1d36e554618498d70f33f6c425b0abc91d4fb952 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38928 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Peter Lemenkov <lemenkov@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-02-16 10:01:33 +01:00
# Parse plaintext CMOS defaults into binary format
Add preprocessing capabilities to the cbfs-files mechanism It's now possible to generate files that are about to be added to CBFS by specifying "sourcefile:method" as real file name. This makes the build system use the cbfs-files-preprocessor-$(method) function to create a file from sourcefile. That generated file is then added to CBFS. The first method to be defined is "nvramtool". It expects a plain text specification of the CMOS configuration and emits the binary format suitable for cmos.default. Change-Id: I33a142718fc7238eaf5317b0ed62b4726d9b48f2 Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com> Reviewed-on: http://review.coreboot.org/847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-09 12:30:07 +01:00
# arg1: source file
# arg2: binary file name
cbfs-files-processor-nvramtool= \
option: Introduce `CMOS_LAYOUT_FILE` Kconfig symbol Mainboards with variants may not always use the same cmos.layout file. Turn the hardcoded path into a Kconfig symbol to allow changing it. Tested with BUILD_TIMELESS=1: Without including the config file in the coreboot.rom and with `USE_OPTION_TABLE` selected, building for the Asus P8H61-M PRO produces an identical coreboot image. Change-Id: I4cc622dcb70855c06cb8a816c34406f8421180df Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54366 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-05-17 12:12:39 +02:00
$(eval $(2): $(1) $(top)/$(call strip_quotes,$(CONFIG_CMOS_LAYOUT_FILE)) | $(objutil)/nvramtool/nvramtool ; \
build system: break overly long lines into logical units Change-Id: I37b716acb305a79614cea184f57b8488111eab7a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12540 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 19:17:42 +01:00
printf " CREATE $(2) (from $(1))\n"; \
option: Introduce `CMOS_LAYOUT_FILE` Kconfig symbol Mainboards with variants may not always use the same cmos.layout file. Turn the hardcoded path into a Kconfig symbol to allow changing it. Tested with BUILD_TIMELESS=1: Without including the config file in the coreboot.rom and with `USE_OPTION_TABLE` selected, building for the Asus P8H61-M PRO produces an identical coreboot image. Change-Id: I4cc622dcb70855c06cb8a816c34406f8421180df Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54366 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-05-17 12:12:39 +02:00
$(objutil)/nvramtool/nvramtool -y $(top)/$(call strip_quotes,$(CONFIG_CMOS_LAYOUT_FILE)) -D $(2).tmp -p $(1) && \
build system: break overly long lines into logical units Change-Id: I37b716acb305a79614cea184f57b8488111eab7a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12540 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 19:17:42 +01:00
mv $(2).tmp $(2))
Add preprocessing capabilities to the cbfs-files mechanism It's now possible to generate files that are about to be added to CBFS by specifying "sourcefile:method" as real file name. This makes the build system use the cbfs-files-preprocessor-$(method) function to create a file from sourcefile. That generated file is then added to CBFS. The first method to be defined is "nvramtool". It expects a plain text specification of the CMOS configuration and emits the binary format suitable for cmos.default. Change-Id: I33a142718fc7238eaf5317b0ed62b4726d9b48f2 Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com> Reviewed-on: http://review.coreboot.org/847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-09 12:30:07 +01:00
build system: move defconfig creation into a cbfs-files filter That allows this special case to become a normal cbfs-files instance, too. Change-Id: I896ffebe4cec64c9c11605b4f09c7790e5419928 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12539 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:47:56 +01:00
#######################################################################
build: Combine "savedefconfig" and "stripped config" in CBFS `config` The intention of CB:69710 was that the expanded config file introduced there would be a strict superset of the old version and could be used in all the same cases. This is generally true except for a small oversight: if a boolean Kconfig is `default y`, but was manually set to `n` by the user, the new `config` file does not include a line for it. Running `make olddefconfig` on such a file will again introduce the option as `y`. It turns out that `make olddefconfig` actually parses those "load-bearing comments" in that case. This patch fixes the problem by also generating the minimal defconfig (like before CB:69710), and then just appending the non-comment lines from the full config that don't appear in it already. This ensures that any "load-bearing comments" in the defconfig remain in the file and the result of Kconfig utilities regenerating a full config from there will again be the same as before CB:69710. In addition, it clearly separates the "minimal defconfig" part of the file from the rest, making it easy for people to extract that if they need it; while also keeping all the config values in one file to make it easy to grep for a certain value. Also eliminate that random backslash in the recipe that doesn't seem to have any good reason to exist and was probably a typo to begin with. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I52ba5d20d3536498fae79d529acf7135f97ef1a8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69955 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-11-24 03:20:32 +01:00
# Reduce a .config file by removing lines about default unset booleans
build system: move defconfig creation into a cbfs-files filter That allows this special case to become a normal cbfs-files instance, too. Change-Id: I896ffebe4cec64c9c11605b4f09c7790e5419928 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12539 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:47:56 +01:00
# arg1: input
# arg2: output
build: List all Kconfigs in CBFS `config` file, compress it The coreboot build system automatically adds a `config` file to CBFS that lists the exact Kconfig configuration that this image was built with. This is useful to reproduce a build after the fact or to check whether support for a specific feature is enabled in the image. However, the file is currently generated using the `savedefconfig` command to Kconfig, which generates the minimal .config file that is needed to produce the required config in a coreboot build. This is fine for reproduction, but bad when you want to check if a certain config was enabled, since many configs get enabled by default or pulled in through another config's `select` statement and thus don't show up in the defconfig. This patch tries to fix that second use case by instead including the full .config instead. In order to save some space, we can remove all comments (e.g. `# CONFIG_XXX is not set`) from the file, which still makes it easy to test for a specific config (if it's in the file you can extract the right value, if not you can assume it was set to `n`). We can also LZMA compress it since this file is never read by firmware itself and only intended for later re-extraction via cbfstool, which always has LZMA support included. On a sample Trogdor device the existing (uncompressed) `config` file takes up 519 bytes in CBFS, whereas the new (compressed) file after this patch will take up 1832 bytes -- still a small amount that should hopefully not break the bank for anyone. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I5259ec6f932cdc5780b8843f46dd476da9d19728 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-11-17 02:48:46 +01:00
define cbfs-files-processor-config
makefile: Add $(objutil)/kconfig/conf as make dependency This patch fixes the build failure with 'make -j' where the build fails at "$(MAKE)... savedefconfig" as that rule doesn't have the dependency on kconfig/conf. Normally make takes care of all dependencies, so parallel builds work well. However if you have recursive make calls, i.e. make calling make like in these recipes, there is no single make with a global view of the dependencies anymore, and then multiple "makes" can try to build the same file concurrently. Adding that explicit dependency on build/util/kconfig/conf makes sure the recursive make is only called later when the top-level make already finished building build/util/kconfig/conf. Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com> Change-Id: Id44ab44618b0ddfb3c2472c469499429118bf76d Reviewed-on: https://review.coreboot.org/c/coreboot/+/72070 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Patrick Georgi <patrick@coreboot.org>
2023-01-18 12:28:08 +01:00
$(eval $(2): $(1) $(obj)/build.h $(objutil)/kconfig/conf; \
build system: mark sub-make invocations as parallelizable We rely on gnu make, so we can expect the jobserver to be around in parallel builds, too. Avoids some make warnings and slightly speeds up the build if those sub-makes are executed (eg for arm-trusted-firmware and vboot). Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/18263 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-30 15:29:34 +01:00
+printf " CREATE $(2) (from $(1))\n"; \
Makefile.inc: Use `define` for cbfs-files-processor-defconfig The body contains a `#` and GNU make 4.3 disagrees with earlier versions if it should be treated as a comment. Turn it into a `define` which has clearer semantics regarding comments (interpretation is supposed to be deferred until the variable is expanded). Change-Id: I589542abbd14082c3ecc4a2456ebd809fb6911ea Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38793 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-02-09 11:44:27 +01:00
printf "# This image was built using coreboot " > $(2).tmp && \
build system: actually provide revision information in defconfig The config file added to CBFS is the short version created by defconfig. The build system tried to add a header describing the version for quite a while now, but failed because it wrote to the file, then had kconfig overwrite it with the config data. While at it, rely on build.h and its version information instead of calling git manually. Change-Id: I5e4d6c857594a55432c05bf1480973fc950f4d4a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12558 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-27 12:36:28 +01:00
grep "\<COREBOOT_VERSION\>" $(obj)/build.h |cut -d\" -f2 >> $(2).tmp && \
build: Combine "savedefconfig" and "stripped config" in CBFS `config` The intention of CB:69710 was that the expanded config file introduced there would be a strict superset of the old version and could be used in all the same cases. This is generally true except for a small oversight: if a boolean Kconfig is `default y`, but was manually set to `n` by the user, the new `config` file does not include a line for it. Running `make olddefconfig` on such a file will again introduce the option as `y`. It turns out that `make olddefconfig` actually parses those "load-bearing comments" in that case. This patch fixes the problem by also generating the minimal defconfig (like before CB:69710), and then just appending the non-comment lines from the full config that don't appear in it already. This ensures that any "load-bearing comments" in the defconfig remain in the file and the result of Kconfig utilities regenerating a full config from there will again be the same as before CB:69710. In addition, it clearly separates the "minimal defconfig" part of the file from the rest, making it easy for people to extract that if they need it; while also keeping all the config values in one file to make it easy to grep for a certain value. Also eliminate that random backslash in the recipe that doesn't seem to have any good reason to exist and was probably a typo to begin with. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I52ba5d20d3536498fae79d529acf7135f97ef1a8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69955 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-11-24 03:20:32 +01:00
$(MAKE) DOTCONFIG=$(1) DEFCONFIG=$(2).tmp2 savedefconfig && \
cat $(2).tmp2 >> $(2).tmp && \
printf "# End of defconfig. Derivable values start here.\n" >> $(2).tmp && \
grep "^CONFIG" $(1) | grep -F -v -f $(2).tmp2 >> $(2).tmp && \
rm -f $(2).tmp2 && \
mv -f $(2).tmp $(2))
Makefile.inc: Use `define` for cbfs-files-processor-defconfig The body contains a `#` and GNU make 4.3 disagrees with earlier versions if it should be treated as a comment. Turn it into a `define` which has clearer semantics regarding comments (interpretation is supposed to be deferred until the variable is expanded). Change-Id: I589542abbd14082c3ecc4a2456ebd809fb6911ea Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38793 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-02-09 11:44:27 +01:00
endef
build system: move defconfig creation into a cbfs-files filter That allows this special case to become a normal cbfs-files instance, too. Change-Id: I896ffebe4cec64c9c11605b4f09c7790e5419928 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12539 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:47:56 +01:00
Makefile.inc: Create function to add a file to CBFS This function can be called to more easily add a file to CBFS. Additional file attributes can be added later: cbfs-files-y += pagetables pagetables-file := $(objcbfs)/pt pagetables-type := raw pagetables-compression := none pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC) becomes $(call add-cbfs-file-simple, pagetables, $(objcbfs)/pt, raw, none ) pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC) This is especially useful inside macros where you may want to add an unknown number of entries. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I72bb2f21fb22f650b7970c7a37a48c10a4af0ed5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75108 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-05-10 20:43:24 +02:00
#######################################################################
# Add a file to CBFS with just type and compression values
# arg1: name in CBFS
# arg2: filename and path
# arg3: type in CBFS
# arg4: compression type
define add-cbfs-file-simple
$(eval cbfs-files-y += $(1))
$(eval $(1)-file := $(2))
$(eval $(1)-type := $(3))
$(eval $(1)-compression := $(4))
endef
cbfs: Add "struct" file type and associated helpers This patch adds functionality to compile a C data structure into a raw binary file, add it to CBFS and allow coreboot to load it at runtime. This is useful in all cases where we need to be able to have several larger data sets available in an image, but will only require a small subset of them at boot (a classic example would be DRAM parameters) or only require it in certain boot modes. This allows us to load less data from flash and increase boot speed compared to solutions that compile all data sets into a stage. Each structure has to be defined in a separate .c file which contains no functions and only a single global variable. The data type must be serialization safe (composed of only fixed-width types, paying attention to padding). It must be added to CBFS in a Makefile with the 'struct' file processor. Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16272 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-20 00:43:06 +02:00
#######################################################################
# Compile a C file with a bare struct definition into binary
# arg1: C source file
# arg2: binary file
cbfs-files-processor-struct= \
Makefile.inc: Add fmap_config.h as a dependency to cbfs-struct generation There is no easy way to add dependencies to cbfs-structs objects and fmap_config.h is a generated file. Follow-up commits depend on it being available so add it in the cbfs-struct makefile function. Change-Id: I7067ff144d38c1ff058825819419b2a2e7801e17 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63350 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-04-04 14:02:19 +02:00
$(eval $(2): $(1) $(obj)/build.h $(obj)/fmap_config.h $(KCONFIG_AUTOHEADER); \
Makefile.inc: Fix empty output when processing C struct files in CBFS When passing $(@) to eval command, $(@) is replaced by empty string, Also, the $(@) in cbfs-files-processor-struct is a temporary file name, so we should quote it by an extra '$' or use the arg ($1 or $2) directly. For example: cbfs-files-processor-struct= \ $(eval $(2): $(1) $(obj)/build.h $(KCONFIG_AUTOHEADER); \ # ** $(@) is empty string instead of $(2) ** printf " CC+STRIP $(@) \n"; \ # ** $(1) contains the name of source file ** printf " CC+STRIP $(1) \n"; \ ......) Signed-off-by: Xi Chen <xixi.chen@mediatek.com> Change-Id: Id6a66e25d7dfe8fe6410e517593ed22a438d2f82 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48201 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-12-01 09:17:24 +01:00
printf " CC+STRIP $(1)\n"; \
Makefile.inc: Don't compile bare structs with asan-global=1 This messes up the bare structs. Change-Id: I5a13bd9f4b11530a6dd5f572059fed851db44757 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51436 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-03-12 10:24:44 +01:00
$(CC_ramstage) -MMD $(CPPFLAGS_ramstage) $(CFLAGS_ramstage) --param asan-globals=0 $$(ramstage-c-ccopts) -include $(KCONFIG_AUTOHEADER) -MT $(2) -o $(2).tmp -c $(1) && \
Makefile.inc: objcopy extracts a wrong section of cbfs_master_header Commit 75226bb879837 ("Makefile.inc: Generate master header and pointer as C structs") may cause objcopy to copy a wrong section of object file resulting in miscompiled image with missing CBFS master header. This makes the usage of secondary payloads impossible. For example a wrong section for CONFIG_ANY_TOOLCHAIN + objcopy 2.38-slack151 will copy ".note.gnu.property". This patch constraints the sections to .data and .bss only. Signed-off-by: Petr Cvek <petrcvekcz@gmail.com> Change-Id: I1b9a73ece7067c9c5100cb294775078f838e263b Reviewed-on: https://review.coreboot.org/c/coreboot/+/65808 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2022-07-13 05:23:15 +02:00
$(OBJCOPY_ramstage) -O binary --only-section='.data*' --only-section='.bss*' --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \
cbfs: Add "struct" file type and associated helpers This patch adds functionality to compile a C data structure into a raw binary file, add it to CBFS and allow coreboot to load it at runtime. This is useful in all cases where we need to be able to have several larger data sets available in an image, but will only require a small subset of them at boot (a classic example would be DRAM parameters) or only require it in certain boot modes. This allows us to load less data from flash and increase boot speed compared to solutions that compile all data sets into a stage. Each structure has to be defined in a separate .c file which contains no functions and only a single global variable. The data type must be serialization safe (composed of only fixed-width types, paying attention to padding). It must be added to CBFS in a Makefile with the 'struct' file processor. Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16272 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-20 00:43:06 +02:00
rm -f $(2).tmp) \
$(eval DEPENDENCIES += $(2).d)
bootsplash: Add ImageMagick voodoo The JPEG decoder, that was added many years ago to display a boot- splash in coreboot, has a few quirks. People used to do some voodoo with GIMP to convert images to the right format, but we can also achieve the same with ImageMagick's `convert`. The currently known constraints are: * The framebuffer's color format is ignored, * only YCC 4:2:0 color sampling is supported, and * width and height have to be a multiple of 16 pixels. Beside that, we can only display the bootsplash if it completely fits into the framebuffer. As the latter's size is often decided at runtime, we can't do much more than offering an option to set a specific size. Change-Id: I564e0d89fb46503ff4c11e095726616700009968 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76564 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-07-16 19:24:13 +02:00
#######################################################################
# Convert image to YCC 4:2:0 JPEG
#
# In two steps:
# 1. Convert to RGB colors, optionally resize and store as BMP.
# 2. Round final size to multiples of 16, optionally swap colors,
# convert (back) to sRGB and store as JPEG.
# The split is necessary because we don't know the exact, scaled
# size due to aspect-ratio. Note: IM v7 would allow us to do the
# calculations in one command using %[fx:...] syntax.
#
# arg1: image input file
# arg2: output jpg
cbfs-files-processor-jpg420= \
$(eval $(2): $(1) $(KCONFIG_AUTOCONFIG); \
printf " CONVERT $$<\n"; \
res=$(CONFIG_BOOTSPLASH_CONVERT_RESOLUTION); \
res=$$$$(convert $$< \
-colorspace RGB \
$$(BOOTSPLASH_RESIZE-y) \
-format '%wx%h' -write info: \
bmp:$$@); \
convert $$@ \
$$(BOOTSPLASH_ROUND16) \
$$(BOOTSPLASH_COLORSWAP-y) \
-colorspace sRGB \
-quality $$(CONFIG_BOOTSPLASH_CONVERT_QUALITY)% \
-interlace none -colorspace YCC -sampling-factor 4:2:0 \
jpg:$$@)
BOOTSPLASH_FLOOR = $$(($${res%%x*} & ~15))x$$(($${res\#\#*x} & ~15))
BOOTSPLASH_RESIZE-$(CONFIG_BOOTSPLASH_CONVERT_RESIZE) = -resize $(BOOTSPLASH_FLOOR)
BOOTSPLASH_CEIL = $$((($${res%%x*} + 15) & ~15))x$$((($${res\#\#*x} + 15) & ~15))
BOOTSPLASH_ROUND16 = -background black -gravity center -extent $(BOOTSPLASH_CEIL)
BOOTSPLASH_COLORSWAP-$(CONFIG_BOOTSPLASH_CONVERT_COLORSWAP) := -channel-fx 'red<=>blue'
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# Add handler for arbitrary files in CBFS
$(call add-special-class,cbfs-files)
cbfs-files-handler= \
Add preprocessing capabilities to the cbfs-files mechanism It's now possible to generate files that are about to be added to CBFS by specifying "sourcefile:method" as real file name. This makes the build system use the cbfs-files-preprocessor-$(method) function to create a file from sourcefile. That generated file is then added to CBFS. The first method to be defined is "nvramtool". It expects a plain text specification of the CMOS configuration and emits the binary format suitable for cmos.default. Change-Id: I33a142718fc7238eaf5317b0ed62b4726d9b48f2 Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com> Reviewed-on: http://review.coreboot.org/847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-09 12:30:07 +01:00
$(eval tmp-cbfs-method:=$(word 2, $(subst :, ,$($(2)-file)))) \
build system: use strip_quotes on cbfs-files If they come from the build system, file names might be guarded in quotes, which confuses make. Drop them here. Change-Id: Ice0d3c4bc2c45a3f121a85e1b9f5f6420c5761d5 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/1866 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-15 14:51:54 +01:00
$(eval $(2)-file:=$(call strip_quotes,$(word 1, $(subst :, ,$($(2)-file))))) \
build system: don't try to add cbfs-files with no backing file Change-Id: Idd05a552762be92d0d93b357b96442b25a614757 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12537 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:59:54 +01:00
$(eval tmp-cbfs-file:= ) \
$(if $($(2)-file), \
$(if $(wildcard $(1)$($(2)-file)), \
$(eval tmp-cbfs-file:= $(wildcard $(1)$($(2)-file))), \
$(eval tmp-cbfs-file:= $($(2)-file)))) \
build system: Retire REQUIRES_BLOB REQUIRES_BLOB assumes that all blob files come from the 3rdparty directory, builds failed when all files were configured to point to other sources. This change modifies the blob mechanism so that cbfs-files can be tagged as "required" with some specification what is missing. If the configured files can't be found (wrong path, missing file), the build system returns a list of descriptions, then aborts. Change-Id: Icc128e3afcee8acf49bff9409b93af7769db3517 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2418 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marcj303@gmail.com>
2013-02-16 01:06:57 +01:00
$(if $(strip $($(2)-required)), \
$(if $(wildcard $(tmp-cbfs-file)),, \
$(info This build configuration requires $($(2)-required)) \
$(eval FAILBUILD:=1) \
)) \
build system: allow defining alignment for cbfs-files Just set $(filename)-align to the desired alignment, and the build system will figure it out using cbfstool locate. Change-Id: I44369d947888041c21ff51ae49f9aacf510918a0 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7728 Tested-by: build bot (Jenkins) Reviewed-by: Werner Zeh <werner.zeh@gmx.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-12-09 12:49:21 +01:00
$(if $(strip $($(2)-align)), \
$(if $(strip $($(2)-position)), \
$(info ERROR: It is not allowed to specify both alignment and position for $($(2)-file)) \
$(eval FAILBUILD:=1) \
)) \
Add preprocessing capabilities to the cbfs-files mechanism It's now possible to generate files that are about to be added to CBFS by specifying "sourcefile:method" as real file name. This makes the build system use the cbfs-files-preprocessor-$(method) function to create a file from sourcefile. That generated file is then added to CBFS. The first method to be defined is "nvramtool". It expects a plain text specification of the CMOS configuration and emits the binary format suitable for cmos.default. Change-Id: I33a142718fc7238eaf5317b0ed62b4726d9b48f2 Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com> Reviewed-on: http://review.coreboot.org/847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-09 12:30:07 +01:00
$(if $(tmp-cbfs-method), \
$(eval tmp-old-cbfs-file:=$(tmp-cbfs-file)) \
buildsystem: ensure directory exists before use In some cases we request mktemp to create a temporary file in $(obj)/mainboard/... before it exists. Let's make sure the directory exists Change-Id: I51f0065c30b1f25eb501a6fd5edefb3f4c15d0ab Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/1532 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marcj303@gmail.com>
2012-09-21 18:11:59 +02:00
$(eval tmp-cbfs-file:=$(shell mkdir -p $(obj)/mainboard/$(MAINBOARDDIR); mktemp $(obj)/mainboard/$(MAINBOARDDIR)/cbfs-file.XXXXXX).out) \
Add preprocessing capabilities to the cbfs-files mechanism It's now possible to generate files that are about to be added to CBFS by specifying "sourcefile:method" as real file name. This makes the build system use the cbfs-files-preprocessor-$(method) function to create a file from sourcefile. That generated file is then added to CBFS. The first method to be defined is "nvramtool". It expects a plain text specification of the CMOS configuration and emits the binary format suitable for cmos.default. Change-Id: I33a142718fc7238eaf5317b0ed62b4726d9b48f2 Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com> Reviewed-on: http://review.coreboot.org/847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-09 12:30:07 +01:00
$(call cbfs-files-processor-$(tmp-cbfs-method),$(tmp-old-cbfs-file),$(tmp-cbfs-file))) \
build system: don't try to add cbfs-files with no backing file Change-Id: Idd05a552762be92d0d93b357b96442b25a614757 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12537 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:59:54 +01:00
$(if $(tmp-cbfs-file), \
build system: remove early stage cbfs-file sorting They're now sorted later in the process after the per-region file lists are determined. Change-Id: I0bba381d09dc4b99e2fe5cae16ff7ffcb5b3aa82 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16138 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-10 13:29:03 +02:00
$(eval cbfs-files += $(subst $(spc),*,$(tmp-cbfs-file)|$(2)|$($(2)-type)|$($(2)-compression)|$(strip $($(2)-position))|$($(2)-align)|$($(2)-options)))) \
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
$(eval $(2)-name:=) \
$(eval $(2)-type:=) \
Support use of the compression option when adding payloads to cbfs. Change-Id: Ie77e8e1628d34f1a9e7a57e994bf2882c5e55e25 Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/1452 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-08-14 19:01:53 +02:00
$(eval $(2)-compression:=) \
build system: Retire REQUIRES_BLOB REQUIRES_BLOB assumes that all blob files come from the 3rdparty directory, builds failed when all files were configured to point to other sources. This change modifies the blob mechanism so that cbfs-files can be tagged as "required" with some specification what is missing. If the configured files can't be found (wrong path, missing file), the build system returns a list of descriptions, then aborts. Change-Id: Icc128e3afcee8acf49bff9409b93af7769db3517 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2418 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marcj303@gmail.com>
2013-02-16 01:06:57 +01:00
$(eval $(2)-position:=) \
build system: allow defining alignment for cbfs-files Just set $(filename)-align to the desired alignment, and the build system will figure it out using cbfstool locate. Change-Id: I44369d947888041c21ff51ae49f9aacf510918a0 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7728 Tested-by: build bot (Jenkins) Reviewed-by: Werner Zeh <werner.zeh@gmx.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-12-09 12:49:21 +01:00
$(eval $(2)-required:=) \
build system: Allow giving additional cbfstool options to cbfs-files-y This enables adding romstage, verstage, and payload, that may need additional options (eg. for XIP or for linux initrd arguments) to be added with the build system infrastructure instead of manual rules. Change-Id: Ifde4ec3ca4ab436aca9b51a3c2cc478ed493fbfb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12547 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-26 16:37:45 +01:00
$(eval $(2)-options:=) \
build system: allow defining alignment for cbfs-files Just set $(filename)-align to the desired alignment, and the build system will figure it out using cbfstool locate. Change-Id: I44369d947888041c21ff51ae49f9aacf510918a0 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7728 Tested-by: build bot (Jenkins) Reviewed-by: Werner Zeh <werner.zeh@gmx.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-12-09 12:49:21 +01:00
$(eval $(2)-align:=)
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# a variety of flags for our build
cbfstool: Rework to use getopt style parameters - Adding more and more optional and non-optional parameters bloated cbfstool and made the code hard to read with a lot of parsing in the actual cbfs handling functions. This change switches over to use getopt style options for everything but command and cbfs file name. - This allows us to simplify the coreboot Makefiles a bit - Also, add guards to include files - Fix some 80+ character lines - Add more detailed error reporting - Free memory we're allocating Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7 Reviewed-on: http://review.coreboot.org/1800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-10-30 00:52:36 +01:00
CBFS_COMPRESS_FLAG:=none
Kconfig: Add option to compress ramstage with LZ4 When ramstage is loaded asynchronously, as on the skyrim boards, the faster decompression of LZ4 allows for faster boot times than the tighter compression of LZMA. To make this change, the name of the existing ramstage_compression option needs to be updated. BUG=b:264409477 TEST=Boot skyrim, look at boot speed Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Change-Id: I27dd1a8def024e0efd466cef9ffd9ca71717486a Reviewed-on: https://review.coreboot.org/c/coreboot/+/71673 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-05 01:26:21 +01:00
ifeq ($(CONFIG_COMPRESS_RAMSTAGE_LZMA),y)
cbfstool: Rework to use getopt style parameters - Adding more and more optional and non-optional parameters bloated cbfstool and made the code hard to read with a lot of parsing in the actual cbfs handling functions. This change switches over to use getopt style options for everything but command and cbfs file name. - This allows us to simplify the coreboot Makefiles a bit - Also, add guards to include files - Fix some 80+ character lines - Add more detailed error reporting - Free memory we're allocating Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7 Reviewed-on: http://review.coreboot.org/1800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-10-30 00:52:36 +01:00
CBFS_COMPRESS_FLAG:=LZMA
Add option 'compress ramstage' Add an option to make compression of ramstage configurable. Right now it is always compressed. On my Thinkpad, the complete boot to grub takes 4s, with around 1s required for decompressing ramstage. This is probably caused by the fact the decompression does a lot of single byte/word/qword accesses, which are really slow on SPI buses. So give the user the option to store ramstage uncompressed, if he has enough memory. Signed-off-by: Sven Schnelle <svens@stackframe.org> Acked-by: Patrick Georgi <patrick@georgi-clan.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6552 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-05-02 21:53:04 +02:00
endif
Kconfig: Add option to compress ramstage with LZ4 When ramstage is loaded asynchronously, as on the skyrim boards, the faster decompression of LZ4 allows for faster boot times than the tighter compression of LZMA. To make this change, the name of the existing ramstage_compression option needs to be updated. BUG=b:264409477 TEST=Boot skyrim, look at boot speed Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Change-Id: I27dd1a8def024e0efd466cef9ffd9ca71717486a Reviewed-on: https://review.coreboot.org/c/coreboot/+/71673 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-05 01:26:21 +01:00
ifeq ($(CONFIG_COMPRESS_RAMSTAGE_LZ4),y)
CBFS_COMPRESS_FLAG:=LZ4
endif
Add option 'compress ramstage' Add an option to make compression of ramstage configurable. Right now it is always compressed. On my Thinkpad, the complete boot to grub takes 4s, with around 1s required for decompressing ramstage. This is probably caused by the fact the decompression does a lot of single byte/word/qword accesses, which are really slow on SPI buses. So give the user the option to store ramstage uncompressed, if he has enough memory. Signed-off-by: Sven Schnelle <svens@stackframe.org> Acked-by: Patrick Georgi <patrick@georgi-clan.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6552 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-05-02 21:53:04 +02:00
cbfstool: Rework to use getopt style parameters - Adding more and more optional and non-optional parameters bloated cbfstool and made the code hard to read with a lot of parsing in the actual cbfs handling functions. This change switches over to use getopt style options for everything but command and cbfs file name. - This allows us to simplify the coreboot Makefiles a bit - Also, add guards to include files - Fix some 80+ character lines - Add more detailed error reporting - Free memory we're allocating Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7 Reviewed-on: http://review.coreboot.org/1800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-10-30 00:52:36 +01:00
CBFS_PAYLOAD_COMPRESS_FLAG:=none
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
ifeq ($(CONFIG_COMPRESSED_PAYLOAD_LZMA),y)
cbfstool: Rework to use getopt style parameters - Adding more and more optional and non-optional parameters bloated cbfstool and made the code hard to read with a lot of parsing in the actual cbfs handling functions. This change switches over to use getopt style options for everything but command and cbfs file name. - This allows us to simplify the coreboot Makefiles a bit - Also, add guards to include files - Fix some 80+ character lines - Add more detailed error reporting - Free memory we're allocating Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7 Reviewed-on: http://review.coreboot.org/1800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-10-30 00:52:36 +01:00
CBFS_PAYLOAD_COMPRESS_FLAG:=LZMA
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
endif
payloads: add support lz4 compression Add the option to use the lz4 compression method to compress payloads. Also sets LZ4 as the default compression method. Change-Id: Ic712f984f791d268440c8463eaea0d246aa31d99 Signed-off-by: Antonello Dettori <dev@dettori.io> Reviewed-on: https://review.coreboot.org/15817 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-07-23 17:11:44 +02:00
ifeq ($(CONFIG_COMPRESSED_PAYLOAD_LZ4),y)
CBFS_PAYLOAD_COMPRESS_FLAG:=LZ4
endif
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
payloads: Add an option to compress secondary payloads Both GRUB and SeaBIOS can chainload lzma compressed payloads. Therefore it is beneficial to compress secondary payloads like Memtest86+, coreinfo, nvramcui,... for both size reasons and often also speed reasons since the limiting factor is generally the IO of the boot device. Tested with SeaBIOS and memtest86+ master on Thinkpad X220. Change-Id: Iddfd6fcf4112d255cc7b2b49b99bf5ea4d6f8db4 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23639 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2018-02-07 13:01:43 +01:00
CBFS_SECONDARY_PAYLOAD_COMPRESS_FLAG:=none
ifeq ($(CONFIG_COMPRESS_SECONDARY_PAYLOAD),y)
CBFS_SECONDARY_PAYLOAD_COMPRESS_FLAG:=LZMA
endif
cbfs: Add LZ4 in-place decompression support for pre-RAM stages This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-29 22:51:35 +02:00
CBFS_PRERAM_COMPRESS_FLAG:=none
ifeq ($(CONFIG_COMPRESS_PRERAM_STAGES),y)
CBFS_PRERAM_COMPRESS_FLAG:=LZ4
endif
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
ifneq ($(CONFIG_LOCALVERSION),"")
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
COREBOOT_EXTRA_VERSION := -$(call strip_quotes,$(CONFIG_LOCALVERSION))
COREBOOT_EXPORTS += COREBOOT_EXTRA_VERSION
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
endif
commonlib: Add commonlib/bsd This patch creates a new commonlib/bsd subdirectory with a similar purpose to the existing commonlib, with the difference that all files under this subdirectory shall be licensed under the BSD-3-Clause license (or compatible permissive license). The goal is to allow more code to be shared with libpayload in the future. Initially, I'm going to move a few files there that have already been BSD-licensed in the existing commonlib. I am also exracting most contents of the often-needed <commonlib/helpers.h> as long as they have either been written by me (and are hereby relicensed) or have an existing equivalent in BSD-licensed libpayload code. I am also relicensing <commonlib/compression.h> (written by me) and <commonlib/compiler.h> (same stuff exists in libpayload). Finally, I am extracting the cb_err error code definitions from <types.h> into a new BSD-licensed header so that future commonlib/bsd code can build upon a common set of error values. I am making the assumption here that the enum constants and the half-sentence fragments of documentation next to them by themselves do not meet the threshold of copyrightability. Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2019-12-12 00:47:42 +01:00
CPPFLAGS_common := -Isrc -Isrc/include -Isrc/commonlib/include -Isrc/commonlib/bsd/include -I$(obj)
Revert "tests: Allow specifying vboot source directory" This reverts commit 7713a2f295d9ed9a7023a78e085ce190ee1203fe. Reason for revert: breaks main branch Change-Id: I2749bea9369c222e510b838e278c7797d5dce56e Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78852 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Patrick Georgi <patrick@coreboot.org>
2023-11-16 14:50:50 +01:00
VBOOT_SOURCE ?= 3rdparty/vboot
Rename VB_SOURCE to VBOOT_SOURCE for increased clarity This renames the VB_SOURCE variable to VBOOT_SOURCE in the build system, providing increased clarity about what it represents. Since the submodule itself is called "vboot", it makes sense to use that name in full instead of a very shortened (and confusing) version of it. Change-Id: Ib343b6642363665ec1205134832498a59b7c4a26 Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-on: https://review.coreboot.org/15824 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-07-24 12:10:38 +02:00
CPPFLAGS_common += -I$(VBOOT_SOURCE)/firmware/include
build: separate CPPFLAGS from CFLAGS There are a couple of places where CPPFLAGS are pasted into CFLAGS, eliminate them. Change-Id: Ic7f568cf87a7d9c5c52e2942032a867161036bd7 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5765 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 14:00:12 +02:00
CPPFLAGS_common += -include $(src)/include/kconfig.h
buildsystem: Promote rules.h to default include Does not fix 3rdparty/, *.S or *.ld or yet. Change-Id: I66b48013dd89540b35ab219d2b64bc13f5f19cda Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/17656 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2016-11-30 13:53:24 +01:00
CPPFLAGS_common += -include $(src)/include/rules.h
commonlib: Add commonlib/bsd This patch creates a new commonlib/bsd subdirectory with a similar purpose to the existing commonlib, with the difference that all files under this subdirectory shall be licensed under the BSD-3-Clause license (or compatible permissive license). The goal is to allow more code to be shared with libpayload in the future. Initially, I'm going to move a few files there that have already been BSD-licensed in the existing commonlib. I am also exracting most contents of the often-needed <commonlib/helpers.h> as long as they have either been written by me (and are hereby relicensed) or have an existing equivalent in BSD-licensed libpayload code. I am also relicensing <commonlib/compression.h> (written by me) and <commonlib/compiler.h> (same stuff exists in libpayload). Finally, I am extracting the cb_err error code definitions from <types.h> into a new BSD-licensed header so that future commonlib/bsd code can build upon a common set of error values. I am making the assumption here that the enum constants and the half-sentence fragments of documentation next to them by themselves do not meet the threshold of copyrightability. Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2019-12-12 00:47:42 +01:00
CPPFLAGS_common += -include $(src)/commonlib/bsd/include/commonlib/bsd/compiler.h
Makefile: Add 3rdparty to CPPFLAGS_common In some occasions, Coreboot may need to include the header file from 3rdparty directory. By adding 3rdparty directory to Coreboot include path, we can include 3rdparty header file directly. BRANCH=none BUG=none TEST=build pass Change-Id: I8ed68bd330eae1211736a91b213c5dc0af2f7fa9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d6a86b3488ebbc9d8f5f46e922106b71034e7127 Original-Change-Id: Ib8e9f059f88a8c6767f872af8760e91186ae5ec3 Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/315021 Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12929 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de>
2015-11-30 11:16:42 +01:00
CPPFLAGS_common += -I3rdparty
Makefile.inc: Export CCACHE_EXTRAFILES and add __BUILD_DIR__ definition This patch adds the CCACHE_EXTRAFILES variable to the list of exported environment variables, which can be useful as a target-specific variable to make ccache aware of extra dependencies that it cannot figure out on its own. It also adds a CPPFLAGS parameter to define the __BUILD_DIR__ constant for the preprocessor so that the current output build directory can be referenced in C code if necessary. Change-Id: I4fdd08842972cfed8ef5e5a61ebf859c0571bcfb Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26451 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-21 22:04:04 +02:00
CPPFLAGS_common += -D__BUILD_DIR__=\"$(obj)\"
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
assert.h: Do not use __FILE__ nor __LINE__ on timeless builds When refactoring, one can move code around quite a bit while preserving reproducibility, unless there is an assert-style macro somewhere... As these macros use __FILE__ and __LINE__, just moving them is enough to change the resulting binary, making timeless builds rather useless. To improve reproducibility, do not use __FILE__ nor __LINE__ inside the assert-style macros. Instead, use hardcoded values. Plus, mention that timeless builds lack such information in place of the file name, so that grepping for the printed string directs one towards this commit. And for the immutable line number, we can use 404: line number not found :-) Change-Id: Id42d7121b6864759c042f8e4e438ee77a8ac0b41 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42196 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2020-06-08 15:52:03 +02:00
ifeq ($(BUILD_TIMELESS),1)
CPPFLAGS_common += -D__TIMELESS__
endif
Makefile: Reduce scope of oprom include paths Change-Id: Ibaa5428df1832d3f18946d456fb0b6d2fff65c32 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31694 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-02 18:33:26 +01:00
ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_YABEL)$(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y)
CPPFLAGS_ramstage += -Isrc/device/oprom/include
endif
Makefile.inc: Explicitly set GNU11 as C language standard Different compiler versions use a different C language standard by default. GCC 4.9 uses GNU89 by default [1], while GCC 5.x uses GNU11 [2]. The discussion on the mailing list in thread *[RFC] Setting C99 by default* [3] resulted in the preference of C11, which results in build errors. So explicitly set it to GNU11, which is also what the current coreboot toolchain with GCC 5.3 is using. [1] https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/C-Dialect-Options.html [2] https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Standards.html [3] https://www.coreboot.org/pipermail/coreboot/2016-November/082541.html Change-Id: If1569618f8044925ff72dcf3543480b34d4f90d6 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/17636 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2016-11-29 10:30:44 +01:00
CFLAGS_common += -pipe -g -nostdinc -std=gnu11
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
CFLAGS_common += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
Makefile.inc: Enable -Wimplicit-fallthrough Change-Id: Ic81ed9eb2ed5255a221082326b81c375456a6499 Signed-off-by: Jacob Garber <jgarber1@ualberta.ca> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34300 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-07-13 02:43:07 +02:00
CFLAGS_common += -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough
Makefile.inc: Use 'Wold-style-definition' Warn when a definition is using '()' instead of '(void)'. Use of ‘()’ is considered an old-style definition in C1x standards, but probably not in C2x. Change-Id: I734cfffe3e89996ab13e846cc08e13753f24f742 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70205 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-12-01 12:12:49 +01:00
CFLAGS_common += -Wshadow -Wdate-time -Wtype-limits -Wvla -Wold-style-definition
Makefile.inc: Use 'Wmissing-include-dirs' command option This is to warn if a user add to Makefile a path to nonexistent directory. Change-Id: I5a30c3830f30509deaaadc6eaeab0e17bc08565c Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70251 Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-05 19:06:56 +01:00
CFLAGS_common += -Wdangling-else -Wmissing-include-dirs
Move function/data sections to common CFLAGS Instead of adding -ffunction-sections and -fdata-sections to every architecture, just add it to CFLAGS_common, thus making sure that new architectures will pick it up automatically. Change-Id: I38e878851226565b7791d05e222cb4e502e0c8a3 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/11105 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-31 22:50:03 +02:00
CFLAGS_common += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer
Makefile.inc: Remove redundant warning flag '-Wstrict-aliasing' is turned on by '-Wall'. '-Wstrict-aliasing' is only active when -fstrict-aliasing is active, so add it. 'BUILD_TIMELESS=1' on gigabyte/ga-945gcm-s2l gives the same binary. Change-Id: I51eb8241389f13d2659aef0a3b4b376ce9c651cf Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44216 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-08-05 15:24:47 +02:00
CFLAGS_common += -fstrict-aliasing -ffunction-sections -fdata-sections -fno-pie
Fix build with CLANG, avoid GCC only CFLAGS Commit 7c8d331fbb "Fine-tune compiler flags" added CFLAGS that are not existing on CLANG hence breaking building coreboot with clang. Fixes: https://ticket.coreboot.org/issues/134 Change-Id: Ie0250e285b0c5a9f8ee2eb99401aeca875d2789a Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/21202 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Damien Zammit <damien@zamaudio.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-08-25 15:39:10 +02:00
ifeq ($(CONFIG_COMPILER_GCC),y)
Makefile.inc: Skip -fconserve-stack flag if running scan-build Scan-build refuses to run if the -fconserve-stack flag is added to cflags. It fails with the cryptic message "could not find clang line". Change-Id: Ib1b56ef7d217138a1a195fe993d8e8dd965bd855 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/26878 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-06-06 05:41:19 +02:00
# Don't add these GCC specific flags when running scan-build
ifeq ($(CCC_ANALYZER_OUTPUT_FORMAT),)
Build system: Add fixes for scanbuild - Exclude build flags that generate warnings when scanbuild is running - Add the SCANBUILD_ARGS variable to abuild so we can pass in arguments to scanbuild. - Set the default scanbuild argument to -k (--keep-going) so that even if an error occurs it continues with the scan. This is similar to what we do with coverity runs. Change-Id: I82e7c13d7fd7432b43c17a31834ec82fca158a07 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/27595 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-07-22 18:11:26 +02:00
CFLAGS_common += -Wno-packed-not-aligned
Makefile.inc: Skip -fconserve-stack flag if running scan-build Scan-build refuses to run if the -fconserve-stack flag is added to cflags. It fails with the cryptic message "could not find clang line". Change-Id: Ib1b56ef7d217138a1a195fe993d8e8dd965bd855 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/26878 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-06-06 05:41:19 +02:00
CFLAGS_common += -fconserve-stack
Makefile.inc: Remove duplicated -Wreturn-type option "-Wall" turns on "-Wreturn-type". Change-Id: Iad4d8465112e3ca89d7d78e391d52c2b2d5f37cd Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72436 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-05-28 07:42:33 +02:00
CFLAGS_common += -Wnull-dereference
Makefile.inc: Disable compiler warning array-compare for GCC gcc 12 fails the build with the warning below: CC romstage/lib/cbfs.o src/lib/cbfs.c: In function 'switch_to_postram_cache': src/lib/cbfs.c:31:32: error: comparison between two arrays [-Werror=array-compare] 31 | if (_preram_cbfs_cache != _postram_cbfs_cache) | ^~ src/lib/cbfs.c:31:32: note: use '&_preram_cbfs_cache[0] != &_postram_cbfs_cache[0]' to compare the addresses Instead of following gcc’s suggestion, disable the warning for gcc as requested by Julius [1]: > Can we just set -Wno-array-compare instead? There's nothing illegal > about that expression and as we can see in this case, there are > perfectly reasonable cases where you might want to do something like > that. On the other hand, I don't really see a realistic scenario where > this warning could prevent a real problem (anyone who doesn't know > that array1 == array2 doesn't compare the array elements in C > shouldn't have any business submitting code to coreboot). [1]: https://review.coreboot.org/c/coreboot/+/62827/1 Found-by: gcc-12 (Debian 12-20220313-1) 12.0.1 20220314 (experimental) [master r12-7638-g823b3b79cd2] Found-by: gcc (Debian 12.1.0-7) 12.1.0 Change-Id: I322f7cc57dcca713141bddaaaed9ec034898754d Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66105 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-07-23 10:25:34 +02:00
CFLAGS_common += -Wlogical-op -Wduplicated-cond -Wno-array-compare
Makefile.inc: Skip -fconserve-stack flag if running scan-build Scan-build refuses to run if the -fconserve-stack flag is added to cflags. It fails with the cryptic message "could not find clang line". Change-Id: Ib1b56ef7d217138a1a195fe993d8e8dd965bd855 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/26878 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-06-06 05:41:19 +02:00
endif
Fix build with CLANG, avoid GCC only CFLAGS Commit 7c8d331fbb "Fine-tune compiler flags" added CFLAGS that are not existing on CLANG hence breaking building coreboot with clang. Fixes: https://ticket.coreboot.org/issues/134 Change-Id: Ie0250e285b0c5a9f8ee2eb99401aeca875d2789a Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/21202 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Damien Zammit <damien@zamaudio.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-08-25 15:39:10 +02:00
endif
Makefile.inc: Only add `-Wno-unused-but-set-variable` for GCC Clang (3.5) does not know that option. error: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option] Fix up commit f69a99db (coreboot: x86: enable gc-sections) to only add that option, when GCC is used. Change-Id: I65b41133a806df1803ccc445e27184c579a718a0 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/9377 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-04-08 10:53:39 +02:00
Makefile.inc: Remove -gnatg from ADAFLAGS_common It was only set by accident. `-gnatg` is a special mode for GNAT internals and libgnat (we already set it explicitly for the latter). TEST=Gave libgfxinit a shot on lenovo/t420. Change-Id: Ie56a95da2dafd014bd6152cb419a2d315e7c78c4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21365 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-12-30 15:40:20 +01:00
ADAFLAGS_common += -gnatp
Make Ada a first class citizen Some remarks on the make process: o We usually leave Ada specs (.ads files which are like c headers) together with the bodies (implementations in .adb files) in one directory. So we have to know, where they live. o If there is no matching .adb an .ads is a valid source file and we'll generate an object file from it. o Object files need to have the same basename as their source files :-/ That's why we put them in build/<class>/ dirs now. o We track dependencies by looking at the compiler output (.ali files which accompany every .o). This way we don't need any gnatmake magic, or even more complex, less portable tools. For ADAFLAGS_common, I simply copied the CFLAGS_common whilst dropping everything unsupported and adding sane warning options. The set of language features is highly restricted (see gnat.adc). This should suit the embedded nature of coreboot and helps proving absence of runtime errors with SPARK. Change-Id: I70df9adbd467ecd2dc7c5c1cf418b7765aca4e93 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13044 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2016-01-14 01:13:33 +01:00
ADAFLAGS_common += -Wuninitialized -Wall -Werror
ADAFLAGS_common += -pipe -g -nostdinc
ADAFLAGS_common += -Wstrict-aliasing -Wshadow
ADAFLAGS_common += -fno-common -fomit-frame-pointer
ADAFLAGS_common += -ffunction-sections -fdata-sections
Makefile.inc: Add `-fno-pie` to `ADAFLAGS_common` Building libgfxinit with Debian’s toolchain – latest test with *gnat-11* 11.2.0-13 from Debian sid/unstable – the build fails with the error below. E: Invalid reloc type: 10 E: Unable to create rmodule from 'build/cbfs/fallback/ramstage.debug'. Debian’s toolchain is built without enabling PIE by default. So, explicitly pass `-fno-pie` to `ADAFLAGS_common` to be independent from how the toolchain was built. TEST=*gnat* 11.2.0-13 successfully. builds purism/librem_cnl/variants/librem_mini with libgfxint. With the coreboot toolchain `make BUILD_TIMELESS=1` produces the same `build/coreboot.rom` for `BOARD_PURISM_LIBREM_MINI_V2=y` on top of commit 50251400d2 (sb/intel/common/firmware: Reword me_cleaner warning) with and without the change. Change-Id: I6661937906d95c130c6099f598d61b21e958fd85 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43759 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-03-07 19:20:49 +01:00
ADAFLAGS_common += -fno-pie
Make Ada a first class citizen Some remarks on the make process: o We usually leave Ada specs (.ads files which are like c headers) together with the bodies (implementations in .adb files) in one directory. So we have to know, where they live. o If there is no matching .adb an .ads is a valid source file and we'll generate an object file from it. o Object files need to have the same basename as their source files :-/ That's why we put them in build/<class>/ dirs now. o We track dependencies by looking at the compiler output (.ali files which accompany every .o). This way we don't need any gnatmake magic, or even more complex, less portable tools. For ADAFLAGS_common, I simply copied the CFLAGS_common whilst dropping everything unsupported and adding sane warning options. The set of language features is highly restricted (see gnat.adc). This should suit the embedded nature of coreboot and helps proving absence of runtime errors with SPARK. Change-Id: I70df9adbd467ecd2dc7c5c1cf418b7765aca4e93 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13044 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2016-01-14 01:13:33 +01:00
# Ada warning options:
#
# a Activate most optional warnings.
# .e Activate every optional warnings.
# e Treat warnings and style checks as errors.
#
# D Suppress warnings on implicit dereferences:
# As SPARK does not accept access types we have to map the
# dynamically chosen register locations to a static SPARK
# variable.
#
# .H Suppress warnings on holes/gaps in records:
# We are modelling hardware here!
#
# H Suppress warnings on hiding:
# It's too annoying, you run out of ideas for identifiers fast.
#
# T Suppress warnings for tracking of deleted conditional code:
# We use static options to select code paths at compile time.
#
# U Suppress warnings on unused entities:
# Would have lots of warnings for unused register definitions,
# `withs` for debugging etc.
#
# .U Deactivate warnings on unordered enumeration types:
# As SPARK doesn't support `pragma Ordered` by now, we don't
# use that, yet.
#
# .W Suppress warnings on unnecessary Warnings Off pragmas:
# Things get really messy when you use different compiler
# versions, otherwise.
# .Y Disable information messages for why package spec needs body:
# Those messages are annoying. But don't forget to enable those,
# if you need the information.
ADAFLAGS_common += -gnatwa.eeD.HHTU.U.W.Y
# Disable style checks for now
ADAFLAGS_common += -gnatyN
Makefile.inc: Replace linker flag -nostartfiles with --nmagic While the gcc(1) driver has the `-nostartfiles` option, ld(1), the program the coreboot toolchain uses to link the object files, doesn't have it. In binutils before 2.36, this option is interpreted as `-n -o startfiles`, in which the `-o` option is overridden by a later `-o` option, so only the `-n` option has effect, which is the `--nmagic` long option of ld(1). So the correct linker option in this place is `--nmagic`. It is tested that without `--nmagic`, ld can generate a much bigger x86_64 romstage, so this option is still needed. This error is found when trying to update binutils to 2.36 and later versions, where ld(1) is unable to disambiguate options and reports an error. Change-Id: I27dc2209abdc6fec866716a252736c5cf236a347 Signed-off-by: Iru Cai <mytbk920423@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56490 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2021-07-21 17:14:35 +02:00
LDFLAGS_common := --gc-sections -nostdlib --nmagic -static
Makefile.inc: Avoid --emit-relocs on RISC-V There seems to be a bug[1] in the GNU linker for the RISC-V architecture triggered by symbols that are more than 2GB offset from the program counter. My next patch is introducing symbols like that and stuck on this problem. The code path that runs into the issue is only taken when passing the --emit-relocs flag, which is really only needed for building rmodules. Since RISC-V platforms don't use any rmodules at the moment, let's disable the flag on RISC-V until the issue can be fixed in the toolchain. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=27180 Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I784a506034325c0ba937589416acaafbf80080e2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/49449 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-14 04:13:21 +01:00
# Workaround for RISC-V linker bug, merge back into above line when fixed.
# https://sourceware.org/bugzilla/show_bug.cgi?id=27180
ifneq ($(CONFIG_ARCH_RISCV),y)
LDFLAGS_common += --emit-relocs
endif
linking: add and use LDFLAGS_common Add an LDFLAGS_common variable and use that for each stage during linking within all the architectures. All the architectures support gc-sections, and as such they should be linking in the same way. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage. Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11522 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-09-06 17:15:17 +02:00
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y)
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
CFLAGS_common += -Werror
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
endif
Provide a way to compile some files with -O0 option When preparing an image for source level debugging, it is convenient to be able to compile some modules with -O0, which makes it much easier to follow the execution flow. This patch allows to do it by defining GDB_DEBUG=1 in the environment before invoking make. Adding this feature as a common config flag is problematic, because we don't want to compile the entire image with -O0. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196359 (cherry picked from commit dde4928c045d12e502cb109015a710cd9fdf2a04) Changed from CFLAGS to CFLAGS_common. Change-Id: Ie0be653509509eeb64ea3a7229f54c0c812840a9 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/7005 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-23 02:06:43 +02:00
ifneq ($(GDB_DEBUG),)
Makefile.inc: Use -Og when compiling with GDB support From GCC's documentation: Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. Change-Id: I9a3dadbf8e894cb28e29d7b2f4e9add252e7bbb3 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8689 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 00:21:17 +01:00
CFLAGS_common += -Og
Make Ada a first class citizen Some remarks on the make process: o We usually leave Ada specs (.ads files which are like c headers) together with the bodies (implementations in .adb files) in one directory. So we have to know, where they live. o If there is no matching .adb an .ads is a valid source file and we'll generate an object file from it. o Object files need to have the same basename as their source files :-/ That's why we put them in build/<class>/ dirs now. o We track dependencies by looking at the compiler output (.ali files which accompany every .o). This way we don't need any gnatmake magic, or even more complex, less portable tools. For ADAFLAGS_common, I simply copied the CFLAGS_common whilst dropping everything unsupported and adding sane warning options. The set of language features is highly restricted (see gnat.adc). This should suit the embedded nature of coreboot and helps proving absence of runtime errors with SPARK. Change-Id: I70df9adbd467ecd2dc7c5c1cf418b7765aca4e93 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13044 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2016-01-14 01:13:33 +01:00
ADAFLAGS_common += -Og
Provide a way to compile some files with -O0 option When preparing an image for source level debugging, it is convenient to be able to compile some modules with -O0, which makes it much easier to follow the execution flow. This patch allows to do it by defining GDB_DEBUG=1 in the environment before invoking make. Adding this feature as a common config flag is problematic, because we don't want to compile the entire image with -O0. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196359 (cherry picked from commit dde4928c045d12e502cb109015a710cd9fdf2a04) Changed from CFLAGS to CFLAGS_common. Change-Id: Ie0be653509509eeb64ea3a7229f54c0c812840a9 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/7005 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-23 02:06:43 +02:00
else
CFLAGS_common += -Os
Make Ada a first class citizen Some remarks on the make process: o We usually leave Ada specs (.ads files which are like c headers) together with the bodies (implementations in .adb files) in one directory. So we have to know, where they live. o If there is no matching .adb an .ads is a valid source file and we'll generate an object file from it. o Object files need to have the same basename as their source files :-/ That's why we put them in build/<class>/ dirs now. o We track dependencies by looking at the compiler output (.ali files which accompany every .o). This way we don't need any gnatmake magic, or even more complex, less portable tools. For ADAFLAGS_common, I simply copied the CFLAGS_common whilst dropping everything unsupported and adding sane warning options. The set of language features is highly restricted (see gnat.adc). This should suit the embedded nature of coreboot and helps proving absence of runtime errors with SPARK. Change-Id: I70df9adbd467ecd2dc7c5c1cf418b7765aca4e93 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13044 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2016-01-14 01:13:33 +01:00
ADAFLAGS_common += -Os
Provide a way to compile some files with -O0 option When preparing an image for source level debugging, it is convenient to be able to compile some modules with -O0, which makes it much easier to follow the execution flow. This patch allows to do it by defining GDB_DEBUG=1 in the environment before invoking make. Adding this feature as a common config flag is problematic, because we don't want to compile the entire image with -O0. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196359 (cherry picked from commit dde4928c045d12e502cb109015a710cd9fdf2a04) Changed from CFLAGS to CFLAGS_common. Change-Id: Ie0be653509509eeb64ea3a7229f54c0c812840a9 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/7005 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-23 02:06:43 +02:00
endif
Add option to build Ada debugging code Ada knows a pragma `Debug` that is used to exclude procedure calls from a release build. The new option `DEBUG_ADA_CODE` enables those procedure calls. Change-Id: Id5298e5819606c3d1cf2a2a1cd4f1d5d1227aa4f Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/16943 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-05 17:43:56 +02:00
ifeq ($(CONFIG_DEBUG_ADA_CODE),y)
ADAFLAGS_common += -gnata
endif
Makefile.inc: Use `additional-dirs` for $(objcbfs), $(objgenerated) We use `additional-dirs` for a single `mkdir -p` invocation for all directiories. I don't see why these two, $(objcbfs) and $(objgenerated), should be an exception. Fixes clean builds for targets that don't include the phony `coreboot` target, e.g. `make qemu`. Change-Id: I85abaa74cddefd2bd669e2b5c8934352775070fe Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51318 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-03-06 13:12:34 +01:00
additional-dirs += $(objutil)/cbfstool $(objutil)/ifdtool \
Kconfig, Makefile.inc: Remove all traces of ifdfake Since ifdfake has been deprecated in favor of better alternatives, there is no need to support it any further. Remove it from the build system. Change-Id: Id62e95ba72004a1e15453e3eb75f09cb8194feb2 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/28233 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-08-20 16:32:22 +02:00
$(objutil)/options $(objutil)/amdfwtool \
Remove imgtec/pistachio SoC After removing urara no board still uses this SoC, and there are no plans to add any in the future (I'm not sure if the chip really exists tbh...). Change-Id: Ic4628fdfacc9fb19b6210394d96431fdb5f8e8f1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36491 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-10-31 00:12:24 +01:00
$(objutil)/cbootimage
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
Makefile: Keep list of exported variables This can be useful to unexport them later. Change-Id: I2ce9eff32d817ec190441550116376843abd1c11 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21162 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-23 23:48:13 +02:00
export $(COREBOOT_EXPORTS)
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# generate build support files
Makefile.inc: Ensure update of build.h There were so many pitfalls that I wrote my own version of this even- tually. This version is inspired by the procedure of Alex Thiessen[1]. Instead of generating a `build.h` on demand, we always generate a tem- porary version that, if it differs from the current one, is added as a dependency. As we use .SECONDEXPANSION on the prerequisites, special care is taken that we won't generate the file twice. As it would be too late to add the dependency if we'd run `genbuild_h.sh` inside a recipe, we have to run it through the `$(shell)` function. But that brings us to the next issue: The make variables used by `genbuild_h.sh` are not expor- ted to this shell like they would be in a recipe. So we export them manually. We could also make these variables explicit parameters of `genbuild_h.sh` instead. An alternative to always creating the temporary `build.h` would be to add a phony target as dependency instead, and finally calling `genbuild_h.sh` again in case we need an update. But, um, we create so many files anyway... [1] https://review.coreboot.org/25685 Change-Id: I311cf610eabae873c70f2985fc7a09acec8061f0 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/28197 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-08-17 17:29:14 +02:00
build_h := $(obj)/build.h
# We have to manually export variables that `genbuild_h.sh` uses
# when we call it through the `$(shell)` function. This is fragile
# but as variables newly added to `genbuild_h.sh` would just not
# work, we'd notice that instantly at least.
build_h_exports := BUILD_TIMELESS KERNELVERSION COREBOOT_EXTRA_VERSION
# Report new `build.ht` as dependency if `build.h` differs.
build_h_check := \
export $(foreach exp,$(build_h_exports),$(exp)="$($(exp))"); \
Makefile: Add $(xcompile) to specify where to write xcompile This file was being written to the root src directory. It is the only file being written to src during a normal build, while all others are being written to $(obj). I added a new variable to allow specifying the xcompile path. This allows generating a single file if building multiple boards. I also moved the default location into $(obj) so we don't pollute the src directory by default. I also cleaned up the generation of xcompile by removing the unnecessary eval and NOCOMPILE check. I also left .xcompile in distclean so it cleans up stale files. Since .xcompile is written into $(obj), `make clean` will now remove it. The tegra Makefiles are outside of the normal build process, so I just updated those Makefiles to point to the default xcompile location of a normal build. The what-jenkins-does target had to be updated to support these special targets. We generate an xcompile specifically for these targets and pass it into the Makefile. Ideally we should get these targets added to the main build. BUG=b:112267918 TEST=ran `emerge-grunt coreboot` and `make what-jenkins-does` Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ia83f234447b977efa824751c9674154b77d606b0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/28101 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-07-11 18:44:21 +02:00
util/genbuild_h/genbuild_h.sh $(xcompile) \
>$(build_h)t 2>/dev/null; \
Makefile.inc: Ensure update of build.h There were so many pitfalls that I wrote my own version of this even- tually. This version is inspired by the procedure of Alex Thiessen[1]. Instead of generating a `build.h` on demand, we always generate a tem- porary version that, if it differs from the current one, is added as a dependency. As we use .SECONDEXPANSION on the prerequisites, special care is taken that we won't generate the file twice. As it would be too late to add the dependency if we'd run `genbuild_h.sh` inside a recipe, we have to run it through the `$(shell)` function. But that brings us to the next issue: The make variables used by `genbuild_h.sh` are not expor- ted to this shell like they would be in a recipe. So we export them manually. We could also make these variables explicit parameters of `genbuild_h.sh` instead. An alternative to always creating the temporary `build.h` would be to add a phony target as dependency instead, and finally calling `genbuild_h.sh` again in case we need an update. But, um, we create so many files anyway... [1] https://review.coreboot.org/25685 Change-Id: I311cf610eabae873c70f2985fc7a09acec8061f0 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/28197 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-08-17 17:29:14 +02:00
cmp -s $(build_h)t $(build_h) >/dev/null 2>&1 || echo $(build_h)t
$(build_h): $$(shell $$(build_h_check))
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
@printf " GEN build.h\n"
Makefile.inc: Ensure update of build.h There were so many pitfalls that I wrote my own version of this even- tually. This version is inspired by the procedure of Alex Thiessen[1]. Instead of generating a `build.h` on demand, we always generate a tem- porary version that, if it differs from the current one, is added as a dependency. As we use .SECONDEXPANSION on the prerequisites, special care is taken that we won't generate the file twice. As it would be too late to add the dependency if we'd run `genbuild_h.sh` inside a recipe, we have to run it through the `$(shell)` function. But that brings us to the next issue: The make variables used by `genbuild_h.sh` are not expor- ted to this shell like they would be in a recipe. So we export them manually. We could also make these variables explicit parameters of `genbuild_h.sh` instead. An alternative to always creating the temporary `build.h` would be to add a phony target as dependency instead, and finally calling `genbuild_h.sh` again in case we need an update. But, um, we create so many files anyway... [1] https://review.coreboot.org/25685 Change-Id: I311cf610eabae873c70f2985fc7a09acec8061f0 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/28197 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-08-17 17:29:14 +02:00
mv $< $@
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
arch/arm: Replace .id section with build_info in CBFS For arch/arm[64], the offsets to board identification strings and CONFIG_ROM_SIZE inside .id were never really used; it was only a convenience to have the strings appear near the start of image. Add the same strings in an uncompressed file in CBFS. Change-Id: I35d3312336e9c66d657d2ca619cf30fd79e18fd4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47602 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-15 08:07:36 +01:00
$(obj)/build_info:
@echo 'COREBOOT_VERSION: $(call strip_quotes,$(KERNELVERSION))' > $@.tmp
@echo 'MAINBOARD_VENDOR: $(call strip_quotes,$(CONFIG_MAINBOARD_VENDOR))' >> $@.tmp
@echo 'MAINBOARD_PART_NUMBER: $(call strip_quotes,$(CONFIG_MAINBOARD_PART_NUMBER))' >> $@.tmp
mv $@.tmp $@
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# Build the tools
build system: avoid more race conditions In an abuild run, cbfstool is built in a shared directory using "make tools". Unfortunately the build system doesn't actually use that binary directly but creates a per-board copy (for convenience purposes when editing the image later) and uses that. With this change the build system uses the original file but still creates the copy for the user, avoiding the race while ensuring convenience. Change-Id: I38c603a7eca5ef859875ad3031bf7a850189645f Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/6242 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10 09:42:03 +02:00
CBFSTOOL:=$(objutil)/cbfstool/cbfstool
fmaptool: Introduce the fmd ("flashmap descriptor") language and compiler This adds a compiler for a language whose textual representation of flashmap regions will be used to describe the layout of flash chips that contain more than just a single CBFS. Direct integration with cbfstool (via a new command-line switch for the create action) is forthcoming but will be added separately. BUG=chromium:461875 TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for panther. Using the latter file as a reference, write a corresponding fmap.fmd file and feed it through fmaptool. Run both binary output files though the flashmap project's own flashmap_decode utility. Observe only the expected differences. BRANCH=None Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142 Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255031 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9942 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-02-26 20:47:19 +01:00
FMAPTOOL:=$(objutil)/cbfstool/fmaptool
build system: avoid more race conditions In an abuild run, cbfstool is built in a shared directory using "make tools". Unfortunately the build system doesn't actually use that binary directly but creates a per-board copy (for convenience purposes when editing the image later) and uses that. With this change the build system uses the original file but still creates the copy for the user, avoiding the race while ensuring convenience. Change-Id: I38c603a7eca5ef859875ad3031bf7a850189645f Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/6242 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10 09:42:03 +02:00
RMODTOOL:=$(objutil)/cbfstool/rmodtool
Makefile: Add ifwitool to list of tools to be built Add ifwitool to list of tools to be built so that it can be used by the build system. Change-Id: Ifcfbfd87ad9b7ba3ea11cfbcf40894f3e0dae694 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15013 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-31 08:03:58 +02:00
IFWITOOL:=$(objutil)/cbfstool/ifwitool
Makefile: Use ifittool to update FIT Depend on ifittool and use it to update FIT instead cbfstool FIT code. Move the TOPSWAP / microcode handling out of cbfstool and implement it in the Makefile. The new FIT looks like the old one and has been tested on Broadwell-DE. The TOPSWAP / microcode code path needs test on real hardware. Change-Id: I687469d62557f81e9d88398cfc93182164fdac95 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31495 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2019-02-18 13:33:16 +01:00
IFITTOOL:=$(objutil)/cbfstool/ifittool
util/cbfstool: Add AMD BIOS compression tool for PSP Add a utility to generate a compressed BIOS image for AMD Family 17h. If the input is an elf file, the utility extracts the program portion for compression. Otherwise the file is compressed as-is. In modern AMD systems, the PSP brings up DRAM then uncompresses the BIOS image into memory prior to x86 beginning execution. The PSP supports a zlib engine, and interprets the first 256 bytes as a header, where offset 0x14 containing the uncompressed size. For further details, see AMD Platform Security Processor BIOS Architecture Design Guide for AMD Family 17h Processors (NDA only, #55758). BUG=b:127766506 TEST=Use with WIP Picasso Change-Id: Id1c54e0a6dae9e4a0362c6635fe8b8aa48a369d8 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33401 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
2019-03-19 21:48:33 +01:00
AMDCOMPRESS:=$(objutil)/cbfstool/amdcompress
util/cse_fpt: Add a new tool for managing Intel CSE FPT binaries This change adds a new tool `cse_fpt` which can be used to print and dump CSE partitions in Flash Partition Table (FPT) format. BUG=b:189167923 Change-Id: I93c8d33e9baa327cbdab918a14f2f7a039953be6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-09-17 07:02:01 +02:00
CSE_FPT:=$(objutil)/cbfstool/cse_fpt
util/cse_serger: Add a new tool for stitching CSE components This change adds a new tool `cse_serger` which can be used to print, dump and stitch together different components for the CSE region. BUG=b:189177186 Change-Id: I90dd809b47fd16afdc80e66431312721082496aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55503 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-09-17 07:04:11 +02:00
CSE_SERGER:=$(objutil)/cbfstool/cse_serger
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
build system: avoid more race conditions In an abuild run, cbfstool is built in a shared directory using "make tools". Unfortunately the build system doesn't actually use that binary directly but creates a per-board copy (for convenience purposes when editing the image later) and uses that. With this change the build system uses the original file but still creates the copy for the user, avoiding the race while ensuring convenience. Change-Id: I38c603a7eca5ef859875ad3031bf7a850189645f Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/6242 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10 09:42:03 +02:00
$(obj)/cbfstool: $(CBFSTOOL)
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
cp $< $@
fmaptool: Introduce the fmd ("flashmap descriptor") language and compiler This adds a compiler for a language whose textual representation of flashmap regions will be used to describe the layout of flash chips that contain more than just a single CBFS. Direct integration with cbfstool (via a new command-line switch for the create action) is forthcoming but will be added separately. BUG=chromium:461875 TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for panther. Using the latter file as a reference, write a corresponding fmap.fmd file and feed it through fmaptool. Run both binary output files though the flashmap project's own flashmap_decode utility. Observe only the expected differences. BRANCH=None Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142 Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255031 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9942 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-02-26 20:47:19 +01:00
$(obj)/fmaptool: $(FMAPTOOL)
cp $< $@
build system: avoid more race conditions In an abuild run, cbfstool is built in a shared directory using "make tools". Unfortunately the build system doesn't actually use that binary directly but creates a per-board copy (for convenience purposes when editing the image later) and uses that. With this change the build system uses the original file but still creates the copy for the user, avoiding the race while ensuring convenience. Change-Id: I38c603a7eca5ef859875ad3031bf7a850189645f Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/6242 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10 09:42:03 +02:00
$(obj)/rmodtool: $(RMODTOOL)
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-10 22:13:58 +01:00
cp $< $@
Makefile: Add ifwitool to list of tools to be built Add ifwitool to list of tools to be built so that it can be used by the build system. Change-Id: Ifcfbfd87ad9b7ba3ea11cfbcf40894f3e0dae694 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15013 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-31 08:03:58 +02:00
$(obj)/ifwitool: $(IFWITOOL)
cp $< $@
Makefile: Use ifittool to update FIT Depend on ifittool and use it to update FIT instead cbfstool FIT code. Move the TOPSWAP / microcode handling out of cbfstool and implement it in the Makefile. The new FIT looks like the old one and has been tested on Broadwell-DE. The TOPSWAP / microcode code path needs test on real hardware. Change-Id: I687469d62557f81e9d88398cfc93182164fdac95 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31495 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2019-02-18 13:33:16 +01:00
$(obj)/ifittool: $(IFITTOOL)
cp $< $@
util/cbfstool: Add AMD BIOS compression tool for PSP Add a utility to generate a compressed BIOS image for AMD Family 17h. If the input is an elf file, the utility extracts the program portion for compression. Otherwise the file is compressed as-is. In modern AMD systems, the PSP brings up DRAM then uncompresses the BIOS image into memory prior to x86 beginning execution. The PSP supports a zlib engine, and interprets the first 256 bytes as a header, where offset 0x14 containing the uncompressed size. For further details, see AMD Platform Security Processor BIOS Architecture Design Guide for AMD Family 17h Processors (NDA only, #55758). BUG=b:127766506 TEST=Use with WIP Picasso Change-Id: Id1c54e0a6dae9e4a0362c6635fe8b8aa48a369d8 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33401 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
2019-03-19 21:48:33 +01:00
$(obj)/amdcompress: $(AMDCOMPRESS)
cp $< $@
util/cse_fpt: Add a new tool for managing Intel CSE FPT binaries This change adds a new tool `cse_fpt` which can be used to print and dump CSE partitions in Flash Partition Table (FPT) format. BUG=b:189167923 Change-Id: I93c8d33e9baa327cbdab918a14f2f7a039953be6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-09-17 07:02:01 +02:00
$(obj)/cse_fpt: $(CSE_FPT)
cp $< $@
util/cse_serger: Add a new tool for stitching CSE components This change adds a new tool `cse_serger` which can be used to print, dump and stitch together different components for the CSE region. BUG=b:189177186 Change-Id: I90dd809b47fd16afdc80e66431312721082496aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55503 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-09-17 07:04:11 +02:00
$(obj)/cse_serger: $(CSE_SERGER)
cp $< $@
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
_WINCHECK=$(shell uname -o 2> /dev/null)
STACK=
ifeq ($(_WINCHECK),Msys)
STACK=-Wl,--stack,16384000
endif
ifeq ($(_WINCHECK),Cygwin)
STACK=-Wl,--stack,16384000
endif
util/blobtool: rename to bincfg The name blobtool is confusing as 'blob' is also used to describe nonfree software in binary form. Since this utility deals with binary configurations it makes more sense to call it bincfg. Change-Id: I3339274f1c42df4bb4a6b30b9538d91c3c03d7d0 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: https://review.coreboot.org/23239 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-10 14:35:55 +01:00
BINCFG:=$(objutil)/bincfg/bincfg
Makefile.inc: Cosmetics: Format blobtool commands similar to other tools Change-Id: Iddb09d0838da119bfccd5443652ca7a6baa95c7b Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: https://review.coreboot.org/22126 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-10-20 22:09:12 +02:00
SandyBridge/IvyBridge: Add IFD and ME firmware automatically Right now coreboot's build process produces images that are not booting on actual hardware because they are smaller than the actual flash device and also don't have an IFD nor an ME firmware in them. In order to produce bootable images, you needed a wrapper script / extra step until now. With this change, the resulting coreboot.rom is actually bootable. Change-Id: I82714069fb004d4badc41698747a704bd9fed4da Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1771 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-08-16 23:05:42 +02:00
IFDTOOL:=$(objutil)/ifdtool/ifdtool
southbridge/amd: update for amdfwtool size on command line amdfwtool was getting the ROM size as a #define when it was built. It has been updated to pass it in as a command line parameter, so now it can be built just once for abuild as a shared tool. Update the calls to amdfwtool to pass the ROM size. All platforms using amdfwtool had the output verified using a binary compare. This reverts commit 0529236ed22f1a28d29f2054674004c4f7a056e7 (Makefile.inc: Don't share amdfwtool between platforms) Change-Id: I188b34e08249f2d00bd48957ced750b21f1ec348 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/17327 Tested-by: build bot (Jenkins) Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2016-11-08 19:49:58 +01:00
AMDFWTOOL:=$(objutil)/amdfwtool/amdfwtool
util/amdfwtool: Add build rules for amdfwread Add build rules to build amdfwread tool. Also mark this as a dependency either while building tools or amdfw.rom. BUG=None TEST=Build and boot to OS in Skyrim with CBFS verification enabled. Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Change-Id: I3fee4e4c77f62bb2840270b3eaaa58b894780d75 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66939 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-17 01:30:06 +02:00
AMDFWREAD:=$(objutil)/amdfwtool/amdfwread
AMD Steppe Eagle: New integrated southbridge (Avalon) 00730F01 contains the Avalon southbridge and a Platform Security Processor (PSP). Supporting the PSP requires specific binaries to be included in the ROM. The fletcher utility is used to sign PSP binaries. The IMC access routines are not accessible for newer AMD parts that use pre-compiled AGESA. Change the Hudson code such that the IMC code is not compiled if IMC is not selected in Kconfig. Disable compilation of resume.c if HAVE_ACPI_RESUME is disabled. The newer AMD mainboards will initially be released without ACPI resume support (S3) due to the use of AGESA internals in the existing Hudson routines. The Makefile change allows newer mainboards to avoid the API issues. Change Kconfig such that the FWM flag is always set for PSP-enabled parts. This has the side effect of forcing the generation of the FWM directory in the absence of GEC, IMC, and xHCI. Change-Id: I6d056f54b60a64300841599490b9fafd561c4a7d Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/6677 Tested-by: build bot (Jenkins) Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com> Reviewed-by: Zheng Bao <zheng.bao@amd.com>
2014-08-11 01:09:15 +02:00
Makefile: Add missing APCB_EDIT_TOOL variable Apparently I missed adding this variable definition. BUG=b:157140753 TEST=Build APCBs with clean tree :) Fixes: cbaa835f211 ("soc/amd/picasso/Makefile: Use apcb_tool to generate APCBs from SPDs") Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ia9055ed3507996cbf78687a97599aab3b0b39d6f Reviewed-on: https://review.coreboot.org/c/coreboot/+/41738 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-26 22:47:05 +02:00
APCB_EDIT_TOOL:=$(top)/util/apcb/apcb_edit.py
guybrush: Inject SPDs into APCB Inject SPDs into APCB at coreboot build time. BUG=b:209486191 BRANCH=None TEST=Boot guybrush and nipperkin with injected APCB Change-Id: Ib21085855324e0d473dd5e258f35a52bed326901 Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60775 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-12-23 16:03:14 +01:00
APCB_V3_EDIT_TOOL:=$(top)/util/apcb/apcb_v3_edit.py
util/apcb: Add apcb edit tool for phoenix Add a new apcb edit tool, apcb_v3a_edit.py, that injects SPDs into an APCB for phoenix platform. The tool makes several assumptions: * Each SPD only uses blocks 0, 1, 3 and 5. All other blocks are zero. * Each block is 64 bytes. * Dimm and socket are always 0 * Unused SPD entries are zero'd BUG=b:281983434 BRANCH=None TEST=build, flash, boot myst Change-Id: Ifb50287de77138170714a702ab87d56427aacfef Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76188 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-14 19:19:53 +02:00
APCB_V3A_EDIT_TOOL:=$(top)/util/apcb/apcb_v3a_edit.py
nvidia-cbootimage: integrate into coreboot make Add rules for building the nvidia-cbootimage utility and add dependencies to the tegra124 platform. Change-Id: Ia9f26981bccd217fe79e1b5dd432ee7da868d22a Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6851 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-08 23:28:17 +02:00
CBOOTIMAGE:=$(objutil)/cbootimage/cbootimage
build system: Allow overriding the path to the futility binary Change-Id: I84e68e8407149780769c3e6a1148c175e42d1025 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/14100 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-03-15 23:14:08 +01:00
FUTILITY?=$(objutil)/futility/futility
build system: add Chrome OS futility to tools Change-Id: I08925d110c6faa9e37107d63bfa75d0ab677d379 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13545 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de>
2016-02-01 12:03:04 +01:00
nvidia/cbootimage: avoid upstream's build system It brings in useless dependencies, a weird autotools configuration, and tons of pain everywhere. Instead just build things ourselves. Change-Id: I67f06e711cb9dcd594363bc1a4f99d3273074549 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/6986 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-09-27 11:37:46 +02:00
subdirs-y += util/nvidia
nvidia-cbootimage: integrate into coreboot make Add rules for building the nvidia-cbootimage utility and add dependencies to the tegra124 platform. Change-Id: Ia9f26981bccd217fe79e1b5dd432ee7da868d22a Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6851 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-08 23:28:17 +02:00
Makefile.inc: Add dependency on util/kconfig/conf for config.h This dependency wasn't called out before, and when building with enough threads, the build would fail due to a collision trying to build build/util/kconfig/conf. Fixes this failure: make[1]: execvp: build/util/kconfig/conf: Permission denied /home/martin/git/coreboot/util/kconfig/Makefile:40: recipe for target 'oldconfig' failed make[1]: *** [oldconfig] Error 127 Makefile:167: recipe for target 'build/config.h' failed Change-Id: Ib78d36bab0ba469796d89877bbe6a61e05196e87 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13859 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-02-29 05:04:15 +01:00
$(obj)/config.h: $(objutil)/kconfig/conf
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# needed objects that every mainboard uses
# Creation of these is architecture and mainboard independent
Makefile.inc: Strip CONFIG_DEVICETREE quotes at top of makefile Minor change - Instead of stripping the quotes from CONFIG_DEVICETREE inline, add it to the location where we normalize all the other Kconfig variables. Change-Id: Idbc58179c7b45160afef7d7e44f9b3b334f8c4a7 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/16116 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-08 23:12:11 +02:00
DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_DEVICETREE)
Kconfig: Add new config for OVERRIDE_DEVICETREE This change adds a new config option OVERRIDE_DEVICETREE that allows variants to provide an override devicetree file to override the registers and/or add new devices on top of the ones provided by baseboard devicetree using CONFIG_DEVICETREE. BUG=b:80081934 Change-Id: Ica046b7e0d70d0f1e8d94da714d1e62032277916 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/26691 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-22 03:50:48 +02:00
sconfig: Switch to getopt Instead of positional arguments switch sconfig to use getopt and pass the arguments as options in the build system. This will make it easier to add additional options. Change-Id: I431633781e80362e086c000b7108191b5b01aa9d Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44035 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-09 20:20:29 +02:00
SCONFIG_OPTIONS := --mainboard_devtree=$(DEVICETREE_FILE)
Kconfig: Add new config for OVERRIDE_DEVICETREE This change adds a new config option OVERRIDE_DEVICETREE that allows variants to provide an override devicetree file to override the registers and/or add new devices on top of the ones provided by baseboard devicetree using CONFIG_DEVICETREE. BUG=b:80081934 Change-Id: Ica046b7e0d70d0f1e8d94da714d1e62032277916 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/26691 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-22 03:50:48 +02:00
sconfig: Switch to getopt Instead of positional arguments switch sconfig to use getopt and pass the arguments as options in the build system. This will make it easier to add additional options. Change-Id: I431633781e80362e086c000b7108191b5b01aa9d Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44035 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-09 20:20:29 +02:00
ifneq ($(CONFIG_OVERRIDE_DEVICETREE),)
Kconfig: Add new config for OVERRIDE_DEVICETREE This change adds a new config option OVERRIDE_DEVICETREE that allows variants to provide an override devicetree file to override the registers and/or add new devices on top of the ones provided by baseboard devicetree using CONFIG_DEVICETREE. BUG=b:80081934 Change-Id: Ica046b7e0d70d0f1e8d94da714d1e62032277916 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/26691 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-22 03:50:48 +02:00
OVERRIDE_DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_OVERRIDE_DEVICETREE)
sconfig: Switch to getopt Instead of positional arguments switch sconfig to use getopt and pass the arguments as options in the build system. This will make it easier to add additional options. Change-Id: I431633781e80362e086c000b7108191b5b01aa9d Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44035 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-09 20:20:29 +02:00
SCONFIG_OPTIONS += --override_devtree=$(OVERRIDE_DEVICETREE_FILE)
Kconfig: Add new config for OVERRIDE_DEVICETREE This change adds a new config option OVERRIDE_DEVICETREE that allows variants to provide an override devicetree file to override the registers and/or add new devices on top of the ones provided by baseboard devicetree using CONFIG_DEVICETREE. BUG=b:80081934 Change-Id: Ica046b7e0d70d0f1e8d94da714d1e62032277916 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/26691 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-22 03:50:48 +02:00
endif
sconfig: Allow chipset to provide a base devicetree This change extends the devicetree override one more layer and allows the chipset to provide the base devicetree. This allows the chipset to assign alias names to devices as well as set default register values. This works for both the baseboard devicetree.cb as well as variant overridetree.cb. chipset.cb: device pci 15.0 alias i2c0 off end devicetree.cb: device ref i2c0 on end BUG=b:156957424 Change-Id: Ia7500a62f6211243b519424ef3834b9e7615e2fd Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44037 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-07-30 01:28:43 +02:00
ifneq ($(CONFIG_CHIPSET_DEVICETREE),)
CHIPSET_DEVICETREE_FILE := $(src)/$(CONFIG_CHIPSET_DEVICETREE)
SCONFIG_OPTIONS += --chipset_devtree=$(CHIPSET_DEVICETREE_FILE)
endif
sconfig: Update command line parameters Instead of having directories and file names hardcoded, pass in the full path and filename of both the input and output files. In the makefile, create variables for these values, and use them in places that previously had the names and paths written out. Change-Id: Icb6f536547ce3193980ec5d60c786a29755c2813 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16078 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-05 23:46:56 +02:00
DEVICETREE_STATIC_C := $(obj)/mainboard/$(MAINBOARDDIR)/static.c
sconfig: Switch to getopt Instead of positional arguments switch sconfig to use getopt and pass the arguments as options in the build system. This will make it easier to add additional options. Change-Id: I431633781e80362e086c000b7108191b5b01aa9d Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44035 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-09 20:20:29 +02:00
SCONFIG_OPTIONS += --output_c=$(DEVICETREE_STATIC_C)
util/sconfig: Issue header for exposed PCI and PNP names Let `sconfig` output a C header file with the symbol names that we generate since 5e2a2cd5e7 (util/sconfig: Expose usable PCI and PNP device names). We add another command line argument for the path to the header file. As the file is similar in nature to our `config.h` we simply put it in $(obj)/ too. Change-Id: I8f87288c82f2844b61eba6534797a42b978b47bb Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35488 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-09-20 12:05:51 +02:00
DEVICETREE_STATIC_H := $(obj)/static.h
sconfig: Switch to getopt Instead of positional arguments switch sconfig to use getopt and pass the arguments as options in the build system. This will make it easier to add additional options. Change-Id: I431633781e80362e086c000b7108191b5b01aa9d Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44035 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-09 20:20:29 +02:00
SCONFIG_OPTIONS += --output_h=$(DEVICETREE_STATIC_H)
sconfig: Update command line parameters Instead of having directories and file names hardcoded, pass in the full path and filename of both the input and output files. In the makefile, create variables for these values, and use them in places that previously had the names and paths written out. Change-Id: Icb6f536547ce3193980ec5d60c786a29755c2813 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16078 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-05 23:46:56 +02:00
sconfig: Split up sconfig-generated static.h Currently sconfig generates a `static.h` to accompany `static.c`. However, some payloads may decide they would like to consume the FW_CONFIG macros as well. The current state of `static.h` makes this impossible (relying on `device/device.h`). This patch splits up `static.h` into 3 files: `static.h, `static_devices.h`, and `static_fw_config.h`. `static.h` simply includes the other two `.h` files to ensure no changes are needed to other code. `static_devices.h` contains the extern'd definitions of the device names recently introduced to sconfig. `static_fw_config.h` contains the FW_CONFIG_FIELD_* macros only, which makes it easily consumable by a payload which wishes to use FW_CONFIG. Also refactor the generation of all these output files, as the code was getting messy. Change-Id: Ie0f4520ee055528c7be84d1d1e2dcea113ea8b5f Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45667 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
2020-09-23 23:36:30 +02:00
DEVICETREE_DEVICENAMES_H := $(obj)/static_devices.h
SCONFIG_OPTIONS += --output_d=$(DEVICETREE_DEVICENAMES_H)
DEVICETREE_FWCONFIG_H := $(obj)/static_fw_config.h
SCONFIG_OPTIONS += --output_f=$(DEVICETREE_FWCONFIG_H)
sconfig: Allow chipset to provide a base devicetree This change extends the devicetree override one more layer and allows the chipset to provide the base devicetree. This allows the chipset to assign alias names to devices as well as set default register values. This works for both the baseboard devicetree.cb as well as variant overridetree.cb. chipset.cb: device pci 15.0 alias i2c0 off end devicetree.cb: device ref i2c0 on end BUG=b:156957424 Change-Id: Ia7500a62f6211243b519424ef3834b9e7615e2fd Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44037 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-07-30 01:28:43 +02:00
$(DEVICETREE_STATIC_C): $(DEVICETREE_FILE) $(OVERRIDE_DEVICETREE_FILE) $(CHIPSET_DEVICETREE_FILE) $(objutil)/sconfig/sconfig
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
@printf " SCONFIG $(subst $(src)/,,$(<))\n"
sconfig: Update command line parameters Instead of having directories and file names hardcoded, pass in the full path and filename of both the input and output files. In the makefile, create variables for these values, and use them in places that previously had the names and paths written out. Change-Id: Icb6f536547ce3193980ec5d60c786a29755c2813 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16078 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-05 23:46:56 +02:00
mkdir -p $(dir $(DEVICETREE_STATIC_C))
sconfig: Switch to getopt Instead of positional arguments switch sconfig to use getopt and pass the arguments as options in the build system. This will make it easier to add additional options. Change-Id: I431633781e80362e086c000b7108191b5b01aa9d Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44035 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-09 20:20:29 +02:00
$(objutil)/sconfig/sconfig $(SCONFIG_OPTIONS)
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
sconfig: Update command line parameters Instead of having directories and file names hardcoded, pass in the full path and filename of both the input and output files. In the makefile, create variables for these values, and use them in places that previously had the names and paths written out. Change-Id: Icb6f536547ce3193980ec5d60c786a29755c2813 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16078 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-05 23:46:56 +02:00
ramstage-y+=$(DEVICETREE_STATIC_C)
romstage-y+=$(DEVICETREE_STATIC_C)
verstage-y+=$(DEVICETREE_STATIC_C)
bootblock-y+=$(DEVICETREE_STATIC_C)
device: allow devicetree accesses in postcar stage Change-Id: Ib6f8ee937c4f3d8e2c0ff3851a819077fa499ccc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/19334 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-04-17 05:13:39 +02:00
postcar-y+=$(DEVICETREE_STATIC_C)
device: Include devicetree in SMM stage Allow bootblock to get access to the entire static device tree as other stages can access independently. TEST=SMM code now can access devicetree.cb variables. Change-Id: I59537c16f0a459e48d8b1efb5c1b196302f13381 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/23823 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2018-02-20 06:07:42 +01:00
smm-y+=$(DEVICETREE_STATIC_C)
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
make: Add a target and dependency to parse the devicetree with sconfig This change adds a target to the top level Makefile that allows building sconfig and generating static.c/static.h without building the rest of coreboot. It also adds $(DEVICETREE_STATIC_C) to the c-deps for each stage so the files are generated before the build runs. Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I4320288422230d8913dfa7cc7b7512775a1a797b Reviewed-on: https://review.coreboot.org/c/coreboot/+/41439 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-16 00:37:07 +02:00
# Ensure static.c and static.h are created before any objects are compiled
ramstage-c-deps+=$(DEVICETREE_STATIC_C)
romstage-c-deps+=$(DEVICETREE_STATIC_C)
verstage-c-deps+=$(DEVICETREE_STATIC_C)
bootblock-c-deps+=$(DEVICETREE_STATIC_C)
postcar-c-deps+=$(DEVICETREE_STATIC_C)
smm-c-deps+=$(DEVICETREE_STATIC_C)
Makefile.inc: fix multiple jobs build issue Certain C source files for coreboot stages require fmap_config.h to be present. When building coreboot using multiple jobs the dependency is not always satisfied due to race condition and results in make error. Work around it by adding fmap_config.h to stage C deps. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Change-Id: I3a70beedf2eb1c018c5ff98163904253f9a87a61 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69819 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
2022-11-09 10:23:11 +01:00
# Ensure fmap_config.h are created before any objects are compiled
ramstage-c-deps+=$(obj)/fmap_config.h
romstage-c-deps+=$(obj)/fmap_config.h
verstage-c-deps+=$(obj)/fmap_config.h
bootblock-c-deps+=$(obj)/fmap_config.h
postcar-c-deps+=$(obj)/fmap_config.h
smm-c-deps+=$(obj)/fmap_config.h
make: Add a target and dependency to parse the devicetree with sconfig This change adds a target to the top level Makefile that allows building sconfig and generating static.c/static.h without building the rest of coreboot. It also adds $(DEVICETREE_STATIC_C) to the c-deps for each stage so the files are generated before the build runs. Signed-off-by: Duncan Laurie <dlaurie@google.com> Change-Id: I4320288422230d8913dfa7cc7b7512775a1a797b Reviewed-on: https://review.coreboot.org/c/coreboot/+/41439 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-16 00:37:07 +02:00
.PHONY: devicetree
devicetree: $(DEVICETREE_STATIC_C)
treewide: Add Kconfig variable MEMLAYOUT_LD_FILE This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows SoC/mainboard to provide a linker file for the platform. x86 already provides a default memlayout.ld under src/arch/x86. With this new Kconfig variable, it is possible for the SoC/mainboard code for x86 to provide a custom linker file as well. Makefile.inc is updated for all architectures to use this new Kconfig variable instead of assuming memlayout.ld files under a certain path. All non-x86 boards used memlayout.ld under mainboard directory. However, a lot of these boards were simply including the memlayout from SoC. So, this change also updates these mainboards and SoCs to define the Kconfig as required. BUG=b:155322763 TEST=Verified that abuild with --timeless option results in the same coreboot.rom image for all boards. Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-11 20:59:07 +02:00
ramstage-y += $(CONFIG_MEMLAYOUT_LD_FILE)
romstage-y += $(CONFIG_MEMLAYOUT_LD_FILE)
bootblock-y += $(CONFIG_MEMLAYOUT_LD_FILE)
verstage-y += $(CONFIG_MEMLAYOUT_LD_FILE)
postcar-y += $(CONFIG_MEMLAYOUT_LD_FILE)
decompressor-y += $(CONFIG_MEMLAYOUT_LD_FILE)
Move coreboot specific rules and setup to toplevel Makefile.inc KERNELVERSION issue found by Stefan is fixed. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6375 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-02-22 15:35:05 +01:00
#######################################################################
# Clean up rules
clean-abuild:
rm -rf coreboot-builds
#######################################################################
# Development utilities
printcrt0s:
@echo crt0s=$(crt0s)
@echo ldscripts=$(ldscripts)
update:
dongle.py -c /dev/term/1 $(obj)/coreboot.rom EOF
util/gitconfig/pre-commit: Use clang-format to sanitise commits Use the `git-format' tool to sanitise coreboot commits such that they conform to coreboot's coding style. This fancy piece of machinary allows one to have LibFormat from Clang to automatically check your commit conforms to coreboot's coding style, fix any issues automatically and provides you a diff you may review and apply at your convenience. N.B. When the `clang-format' binary is not found we issue a warning that the test was skipped and carry on as usual. Hence, this is strictly non-enforcing at this current time. You may use it at your leisure. Change-Id: If49017ea82f0707efd47cae5978a286a9af8f3b7 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: https://review.coreboot.org/c/8037 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2015-01-02 16:08:33 +01:00
check-style:
grep "^# DESCR:" util/lint/check-style | sed "s,.*DESCR: *,,"
echo "========"
util/lint/check-style
echo "========"
Add "gitconfig" make target to simplify gerrit configuration "make gitconfig" installs the gerrit commit-msg hook and validates that user.name and user.email are configured. No data will be overwritten. Change-Id: I49ec98538574866e7ad6238ff3d02b9c1beef1bb Reviewed-on: http://review.coreboot.org/2 Tested-by: build bot (Jenkins) Reviewed-by: Peter Stuge <peter@stuge.se>
2011-06-05 15:15:49 +02:00
gitconfig:
util/gitconfig: Use `make` in git hooks As the code was moved from the Makefile.inc to a separate file in commit 9ab8ae6a (util/gitconfig: Make gitconfig a bash script),`$(MAKE)` was replaced by `remake`, introducing dependency on this tool which is basically a `make` with debugging capabilities. Many developers don't have `remake` installed, leading to pre-commit hooks being not executed properly. Apparently this was an unintentional change. Furthermore, special treatment of `make` tool via the `%MAKE%` substitution performed during hooks' deployment is still desired. Use case is calling `remake gitconfig` to set `remake` as the `make` tool in the hooks. To accomplish this, add a parameter that is passed from the Makefile.inc to gitconfig.sh. Change-Id: Ia78e06567b904b342dc9b7778569201fe02e6897 Signed-off-by: Alex Thiessen <alex.thiessen.de+coreboot@gmail.com> Reviewed-on: https://review.coreboot.org/23096 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2018-01-04 16:16:23 +01:00
util/gitconfig/gitconfig.sh "$(MAKE)"
Add "gitconfig" make target to simplify gerrit configuration "make gitconfig" installs the gerrit commit-msg hook and validates that user.name and user.email are configured. No data will be overwritten. Change-Id: I49ec98538574866e7ad6238ff3d02b9c1beef1bb Reviewed-on: http://review.coreboot.org/2 Tested-by: build bot (Jenkins) Reviewed-by: Peter Stuge <peter@stuge.se>
2011-06-05 15:15:49 +02:00
make: add clang-format prepare-commit-msg hook To install this hook, run make install-git-commit-clangfmt This will install a pre-commit-msg hook that runs clang-format on all .c and .h files that are staged. It will add a clang-formatted-by: <git username> line to the commit message to indicate that clang-format was run on the files and that further processing of them is not needed. Change-Id: I1773f55b5b4677dad8f4bea017b6328fd93df20c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/27779 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-08-01 16:19:31 +02:00
install-git-commit-clangfmt:
cp util/scripts/prepare-commit-msg.clang-format .git/hooks/prepare-commit-msg
buildgcc: Move all toolchain build targets to util/crossgcc There is a lot of potential to completely get rid of Makefile and keep everything in Makefile.inc, but for now this declutters the main Makefile.inc. Change-Id: I653313c74207f955514c036c81efcbfd988827c9 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/13518 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-30 02:48:47 +01:00
include util/crossgcc/Makefile.inc
Move crossgcc rules to coreboot specific Makefile Toplevel Makefile should (as far as possible) be coreboot-agnostic, we have Makefile.inc for that. Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Acked-by: Patrick Georgi <patrick@georgi-clan.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6599 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-05-16 17:32:28 +02:00
buildgcc: Move all toolchain build targets to util/crossgcc There is a lot of potential to completely get rid of Makefile and keep everything in Makefile.inc, but for now this declutters the main Makefile.inc. Change-Id: I653313c74207f955514c036c81efcbfd988827c9 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/13518 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-30 02:48:47 +01:00
.PHONY: tools
util/amdfwtool: Add build rules for amdfwread Add build rules to build amdfwread tool. Also mark this as a dependency either while building tools or amdfw.rom. BUG=None TEST=Build and boot to OS in Skyrim with CBFS verification enabled. Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Change-Id: I3fee4e4c77f62bb2840270b3eaaa58b894780d75 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66939 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-17 01:30:06 +02:00
tools: $(objutil)/kconfig/conf $(objutil)/kconfig/toada $(CBFSTOOL) $(objutil)/cbfstool/cbfs-compression-tool $(FMAPTOOL) $(RMODTOOL) $(IFWITOOL) $(objutil)/nvramtool/nvramtool $(objutil)/sconfig/sconfig $(IFDTOOL) $(CBOOTIMAGE) $(AMDFWTOOL) $(AMDCOMPRESS) $(FUTILITY) $(BINCFG) $(IFITTOOL) $(objutil)/supermicro/smcbiosinfo $(CSE_FPT) $(CSE_SERGER) $(AMDFWREAD)
abuild: Build boards in parallel if possible Determine if xargs -P works. If yes, use that to build multiple boards in parallel, instead of relying on make -j X, when doing a full abuild run (instead of single boards). make -j X isn't able to make use of several cores at various serialization points in our build process, so this change results in a >25% speed up for a full abuild run in my tests. Change-Id: Id484a4211c84a3a24115278e0fbe92345f346596 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/409 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-11-05 14:44:41 +01:00
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
###########################################################################
# Common recipes for all stages
###########################################################################
New mechanism to define SRAM/memory map with automatic bounds checking This patch creates a new mechanism to define the static memory layout (primarily in SRAM) for a given board, superseding the brittle mass of Kconfigs that we were using before. The core part is a memlayout.ld file in the mainboard directory (although boards are expected to just include the SoC default in most cases), which is the primary linker script for all stages (though not rmodules for now). It uses preprocessor macros from <memlayout.h> to form a different valid linker script for all stages while looking like a declarative, boilerplate-free map of memory addresses to the programmer. Linker asserts will automatically guarantee that the defined regions cannot overlap. Stages are defined with a maximum size that will be enforced by the linker. The file serves to both define and document the memory layout, so that the documentation cannot go missing or out of date. The mechanism is implemented for all boards in the ARM, ARM64 and MIPS architectures, and should be extended onto all systems using SRAM in the future. The CAR/XIP environment on x86 has very different requirements and the layout is generally not as static, so it will stay like it is and be unaffected by this patch (save for aligning some symbol names for consistency and sharing the new common ramstage linker script include). BUG=None TEST=Booted normally and in recovery mode, checked suspend/resume and the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies with ToT and looked for red flags. Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614 Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/213370 Reviewed-on: http://review.coreboot.org/9283 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-08-21 00:29:56 +02:00
# loadaddr can determine the load address of a stage, which may be needed for
# platform-specific image headers (only works *after* the stage has been built)
loadaddr = $(shell $(OBJDUMP_$(1)) -p $(objcbfs)/$(1).debug | \
sed -ne '/LOAD/s/^.*vaddr 0x\([0-9a-fA-F]\{8\}\).*$$/0x\1/p')
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
# find-substr is required for stages like romstage_null and romstage_xip to
# eliminate the _* part of the string
find-substr = $(word 1,$(subst _, ,$(1)))
# find-class is used to identify the class from the name of the stage
# The input to this macro can be something like romstage.x or romstage.x.y
# find-class recursively strips off the suffixes to extract the exact class name
# e.g.: if romstage.x is provided to find-class, it will remove .x and return romstage
# if romstage.x.y is provided, it will first remove .y, call find-class with romstage.x
# and remove .x the next time and finally return romstage
find-class = $(if $(filter $(1),$(basename $(1))),$(if $(CC_$(1)), $(1), $(call find-substr,$(1))),$(call find-class,$(basename $(1))))
linking: link bootblock.elf with .data and .bss sections again Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-18 00:02:53 +02:00
# Bootblocks are not CBFS stages. coreboot is currently expecting the bss to
# be cleared by the loader of the stage. For ARM SoCs that means one needs to
# include the bss section in the binary so the BootROM clears the bss on
# loading of the bootblock stage. Achieve this by marking the bss section
# loadable,allocatable, and data. Do the same for the .data section in case
Makefile.inc: Add separate bootblock.raw.elf with allocatable BSS This patch moves the objcopy invocation that changes the bootblock's section flags to make sure .data and .bss are preserved in the binary image from the generation of bootblock.raw.bin into a separate bootblock.raw.elf file. Some SoCs (like SDM845) like to have an ELF rather than a raw binary as input to their masked ROM wrapper generation script. Also move those objcopy flags out into a variable because I'll need them again in a later patch. Change-Id: I9557b184df7f753a442c7e0ceb58e81c5e19f2c5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26338 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-16 02:36:59 +02:00
# the linker marked it NOBITS automatically because there are only zeroes in it.
preserve-bss-flags := --set-section-flags .bss=load,alloc,data --set-section-flags .data=load,alloc,data
build: Mark bootblock files on x86 as IBB * Add cbfsoption --ibb to mark files as IBB * Will be used by "Legacy FIT TXT" boot Change-Id: I83313f035e7fb7e1eb484b323862522e28cb73d4 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31497 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2019-02-19 10:57:16 +01:00
# For Intel TXT files in the CBFS needs to be marked as 'Initial Boot Block'.
# As CBFS attributes aren't cheap, only mark them if TXT is enabled.
ifeq ($(CONFIG_INTEL_TXT),y)
TXTIBB := --ibb
else
TXTIBB :=
endif
Introduce bootblock self-decompression Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-16 23:14:04 +02:00
ifeq ($(CONFIG_COMPRESS_BOOTBLOCK),y)
$(objcbfs)/bootblock.lz4: $(objcbfs)/bootblock.elf $(objutil)/cbfstool/cbfs-compression-tool
@printf " LZ4 $(subst $(obj)/,,$(@))\n"
$(OBJCOPY_bootblock) $(preserve-bss-flags) $< $@.tmp
$(OBJCOPY_bootblock) -O binary $@.tmp
$(objutil)/cbfstool/cbfs-compression-tool rawcompress $@.tmp $@.tmp2 lz4
rm -f $@.tmp
mv $@.tmp2 $@
# Put assembled decompressor+bootblock into bootblock.raw.elf so that SoC
# Makefiles wrapping the bootblock in a header can always key off the same file.
$(objcbfs)/bootblock.raw.elf: $(objcbfs)/decompressor.elf
@printf " OBJCOPY $(notdir $(@))\n"
$(OBJCOPY_bootblock) $(preserve-bss-flags) $< $@
else # CONFIG_COMPRESS_BOOTBLOCK
Makefile.inc: Add separate bootblock.raw.elf with allocatable BSS This patch moves the objcopy invocation that changes the bootblock's section flags to make sure .data and .bss are preserved in the binary image from the generation of bootblock.raw.bin into a separate bootblock.raw.elf file. Some SoCs (like SDM845) like to have an ELF rather than a raw binary as input to their masked ROM wrapper generation script. Also move those objcopy flags out into a variable because I'll need them again in a later patch. Change-Id: I9557b184df7f753a442c7e0ceb58e81c5e19f2c5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26338 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-16 02:36:59 +02:00
$(objcbfs)/bootblock.raw.elf: $(objcbfs)/bootblock.elf
@printf " OBJCOPY $(notdir $(@))\n"
$(OBJCOPY_bootblock) $(preserve-bss-flags) $< $@
Introduce bootblock self-decompression Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-16 23:14:04 +02:00
endif # CONFIG_COMPRESS_BOOTBLOCK
Makefile.inc: Add separate bootblock.raw.elf with allocatable BSS This patch moves the objcopy invocation that changes the bootblock's section flags to make sure .data and .bss are preserved in the binary image from the generation of bootblock.raw.bin into a separate bootblock.raw.elf file. Some SoCs (like SDM845) like to have an ELF rather than a raw binary as input to their masked ROM wrapper generation script. Also move those objcopy flags out into a variable because I'll need them again in a later patch. Change-Id: I9557b184df7f753a442c7e0ceb58e81c5e19f2c5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26338 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-16 02:36:59 +02:00
$(objcbfs)/bootblock.raw.bin: $(objcbfs)/bootblock.raw.elf
linking: link bootblock.elf with .data and .bss sections again Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-18 00:02:53 +02:00
@printf " OBJCOPY $(notdir $(@))\n"
Makefile.inc: Add separate bootblock.raw.elf with allocatable BSS This patch moves the objcopy invocation that changes the bootblock's section flags to make sure .data and .bss are preserved in the binary image from the generation of bootblock.raw.bin into a separate bootblock.raw.elf file. Some SoCs (like SDM845) like to have an ELF rather than a raw binary as input to their masked ROM wrapper generation script. Also move those objcopy flags out into a variable because I'll need them again in a later patch. Change-Id: I9557b184df7f753a442c7e0ceb58e81c5e19f2c5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26338 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-16 02:36:59 +02:00
$(OBJCOPY_bootblock) -O binary $< $@
linking: link bootblock.elf with .data and .bss sections again Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-18 00:02:53 +02:00
Makefile: Support HAVE_BOOTBLOCK=n case With HAVE_BOOTBLOCK=n build of bootblock-class is skipped. Inserts an empty 64-byte bootblock-region to coreboot.rom file, cbfstool will fill in the CBFS master header relative location at the end. Change-Id: Iaee9200f72f31175aca597865e3c74fc68bec8a6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34477 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2019-07-22 08:34:43 +02:00
ifneq ($(CONFIG_HAVE_BOOTBLOCK),y)
Makefile.inc: Use `additional-dirs` for $(objcbfs), $(objgenerated) We use `additional-dirs` for a single `mkdir -p` invocation for all directiories. I don't see why these two, $(objcbfs) and $(objgenerated), should be an exception. Fixes clean builds for targets that don't include the phony `coreboot` target, e.g. `make qemu`. Change-Id: I85abaa74cddefd2bd669e2b5c8934352775070fe Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51318 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-03-06 13:12:34 +01:00
$(objcbfs)/bootblock.bin:
Makefile: Support HAVE_BOOTBLOCK=n case With HAVE_BOOTBLOCK=n build of bootblock-class is skipped. Inserts an empty 64-byte bootblock-region to coreboot.rom file, cbfstool will fill in the CBFS master header relative location at the end. Change-Id: Iaee9200f72f31175aca597865e3c74fc68bec8a6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34477 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2019-07-22 08:34:43 +02:00
dd if=/dev/zero of=$@ bs=64 count=1
endif
linking: link bootblock.elf with .data and .bss sections again Currently coreboot expects the loader to clear the bss section for all stages. i.e. stages don't clear their own bss. On ARM SoCs the BootROM would be responsible for this. To do that one needs to include the bss section data (all zeros) in the bootblock.bin file. This was previously being attempted by keeping the .bss info in the .data section because objcopy happened zero out non-file allocated data section data. Instead go back to linking bootblock with the bss section but mark the bss section as loadable allocatable data. That way it will be included in the binary properly when objcopy -O binary is emplyed. Also do the same for the data section in the case of no non-zero object values are in the data section. Without this change the trick of including .bss in .data was not working when there wasn't a non-zero value object in the data section. BUG=None BRANCH=None TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains the cleared bss. Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11680 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-18 00:02:53 +02:00
$(objcbfs)/%.bin: $(objcbfs)/%.raw.bin
cp $< $@
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
Makefile: Add a build target for .map We don't currently have a build target defined for .map files. This means they can't be used as a dependency. This change splits the .map creation into its own rule. BUG=b:221231786 TEST=Build guybrush and verify .map still exists Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I1ce21902e97390aa9520670299ef08debf4458db Reviewed-on: https://review.coreboot.org/c/coreboot/+/62399 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Martin Roth <martinroth@google.com>
2022-02-26 00:22:27 +01:00
$(objcbfs)/%.map: $(objcbfs)/%.debug
$(eval class := $(call find-class,$(@F)))
$(NM_$(class)) -n $< | sort > $(basename $@).map
$(objcbfs)/%.elf: $(objcbfs)/%.debug $(objcbfs)/%.map
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
$(eval class := $(call find-class,$(@F)))
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
@printf " OBJCOPY $(subst $(obj)/,,$(@))\n"
cp $< $@.tmp
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
$(OBJCOPY_$(class)) --strip-debug $@.tmp
$(OBJCOPY_$(class)) --add-gnu-debuglink=$< $@.tmp
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
mv $@.tmp $@
Introduce bootblock self-decompression Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-16 23:14:04 +02:00
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
###########################################################################
# Build the final rom image
###########################################################################
Makefile.inc: Document extract_nth and the fields it extracts Change-Id: I0b5cffff95aca0ea0d6302b436797dada1850ba0 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12713 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-11 19:40:06 +01:00
# extract_nth - Return a subsection of the $file string
#
# the input string looks like this:
# ./build/cbfs/fallback/romstage.elf|fallback/romstage|stage|none||64|--xip*-S*.car.data*-P*0x10000
#
# Sections:
# 1 - Path and name of file [FILENAME: Added to cbfs-files-y list variable]
# 2 - Name of file in cbfs [$(FILENAME)-file]
# 3 - File type: [$(FILENAME)-type]
# bootblock, cbfs header, stage, payload, optionrom, bootsplash, raw, vsa,
# mbi, microcode, fsp, mrc, cmos_default, cmos_layout, spd, mrc_cache,
# mma, efi, deleted, null
# 4 - Compression type [$(FILENAME)-compression]
# none, LZMA
Makefile.inc: Fix typo in comment Replace FILANAME with FILENAME. Change-Id: I96388245df406e6b4cb1cd3418f6a32d5b23499f Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76890 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com> Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-02 21:35:34 +02:00
# 5 - Base address [$(FILENAME)-position]
Makefile.inc: Document extract_nth and the fields it extracts Change-Id: I0b5cffff95aca0ea0d6302b436797dada1850ba0 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12713 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-11 19:40:06 +01:00
# 6 - Alignment [$(FILENAME)-align]
# 7 - cbfstool flags [$(FILENAME)-options]
#
# Input:
# $(1) = Section to extract
# $(2) = Input string
#
# Steps:
# 1) replace all '|' characters with the sequence '- -' within the full string, prepended and appended with the character '-'
# 2) extract the specified section from the string - this gets us the section surrounded by '-' characters
# 3) remove the leading and trailing '-' characters
# 4) replace all '*' characters with spaces
build system: make cbfs-files mechanism spaces-safe Space is commonly used as separator in make variables, so escape them as * (which should be reasonably uncommon in file names and cbfstool options alike to not be a problem). Change-Id: Ia77b5559841b5eae3aa1c0c0027f2e7fb882ea2f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12548 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-26 17:17:28 +01:00
extract_nth=$(subst *,$(spc),$(patsubst -%-,%,$(word $(1), $(subst |,- -,-$(2)-))))
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
build system: allow assigning files to regions Using the regions-for-file function, the build system can now declare which (CBFS formatted) fmap region(s) a file should end up in. The default is to put them in the regular COREBOOT region, but more complex boot schemes (eg. vboot or fallback/normal) can use the function to implement suitable policies. Change-Id: I5e2e6b8e8759fda2cfb0144d5b998ba3e05650c8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13039 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-01-18 16:24:10 +01:00
# regions-for-file - Returns a cbfstool regions parameter
# $(call regions-for-file,$(filename))
# returns "REGION1,REGION2,..."
#
# This is the default implementation. When using a boot strategy employing
# multiple CBFSes in fmap regions, override it.
top/Makefile.inc: Define regions-for-file with a flexibility If we need to put a CBFS chunk into a specific region, add a line in any Makefile.inc regions-for-file-xxx=region_name TODO:Do a complete binary identical test for all the mainboards. Change-Id: Ie37a8a9230dc8b8e5664be8806f047afb94fba69 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70313 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-12-04 10:38:04 +01:00
regions-for-file ?= $(if $(value regions-for-file-$(1)), $(regions-for-file-$(1)), COREBOOT)
build system: allow assigning files to regions Using the regions-for-file function, the build system can now declare which (CBFS formatted) fmap region(s) a file should end up in. The default is to put them in the regular COREBOOT region, but more complex boot schemes (eg. vboot or fallback/normal) can use the function to implement suitable policies. Change-Id: I5e2e6b8e8759fda2cfb0144d5b998ba3e05650c8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13039 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-01-18 16:24:10 +01:00
build system: Add option for auto generated cbfs attributes Add a new Kconfig variable to enable the generation of position and alignment attributes for cbfs files which has constraints on this parameters. In addition, modify Makefile.inc to support that option. Change-Id: Ibd725fe69a4de35964bdb2dde106d9a7c37ffb47 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/12968 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-14 15:08:36 +01:00
ifeq ($(CONFIG_CBFS_AUTOGEN_ATTRIBUTES),y)
cbfs-autogen-attributes=-g
endif
build system: Unwind multi-region cbfstool add commands Add files to fmap regions one-by-one, so we can modify options per-file-per-region. Change-Id: Ic3ff5a4e563796c9fdd5705236aef37c883abf5e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13504 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 22:22:38 +01:00
# cbfs-add-cmd-for-region
# $(call cbfs-add-cmd-for-region,file in extract_nth format,region name)
Makefile: Allow platform to provide additional params for add cmd This change adds optional CBFSTOOL_ADD_CMD_OPTIONS that can be used by arch/SoC/mainboard Makefiles to supply any additional arguments that need to be passed into cbfstool when using cbfstool add command. This is useful when platform wants to add these parameters depending upon some arch/SoC/mainboard specific configs. Immediate use case is the fast SPI controller on Intel platforms adding arguments for extended window base and size. BUG=b:171534504 Change-Id: I2f48bc3f494d9a5da7e99b530a39d6078b4a881c Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47884 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-22 07:21:42 +01:00
#
# CBFSTOOL_ADD_CMD_OPTIONS can be used by arch/SoC/mainboard to supply
# add commands with any additional arguments for cbfstool.
# Example: --ext-win-base <base> --ext-win-size <size>
build system: Unwind multi-region cbfstool add commands Add files to fmap regions one-by-one, so we can modify options per-file-per-region. Change-Id: Ic3ff5a4e563796c9fdd5705236aef37c883abf5e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13504 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 22:22:38 +01:00
define cbfs-add-cmd-for-region
build system: reformat cbfs-add-cmd Change-Id: Iccf2c0ac62d410fd541d7aa244b9989b92584c13 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13498 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 21:32:33 +01:00
$(CBFSTOOL) $@.tmp \
Payloads: Add U-Boot as a coreboot-payload - Add Kconfig and Makefile options to use U-Boot as a payload. - Add Kconfig option for extra cbfstool command line arguments. - Add Kconfig & Makefile option to load the payload as a flat binary. - Add u-boot directory to .gitignore. This is currently working for X-86 only. Graphics worked in U-Boot correctly by initializing the VBIOS and setting up a console mode. Tested in QEMU and on Minnowboard Max. Got into U-Boot, have not booted an OS yet. Change-Id: Ia122a4ad7cd7d96107c1552b0376c8106ca8fb92 Signed-off-by: Martin Roth <martinroth@google.com> Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/12714 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-11 20:24:33 +01:00
add$(if $(filter stage,$(call extract_nth,3,$(1))),-stage)$(if \
$(filter payload,$(call extract_nth,3,$(1))),-payload)$(if \
$(filter flat-binary,$(call extract_nth,3,$(1))),-flat-binary) \
build system: pass $(file) explicitly And not in the global context. Change-Id: Ife7394b1343663456c24316df6a07d883adb9ee9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13500 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 21:47:31 +01:00
-f $(call extract_nth,1,$(1)) \
-n $(call extract_nth,2,$(1)) \
Makefile.inc: Drop spurious `-t` from `cbfstool add-payload` The `-t` argument was never required for `add-payload` and results in a warning now because the type was renamed. TEST=Built with BUILD_TIMELESS=1 and compared binaries with and without this patch. Change-Id: I6ccb70acc6e88a602b90c625040d4f05d8e3630a Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/26323 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-16 13:12:35 +02:00
$(if $(filter-out flat-binary payload stage,$(call \
extract_nth,3,$(1))),-t $(call extract_nth,3,$(1))) \
build system: deduplicate use of cbfs-autogen-attributes Also drop the second argument to cbfs-add-cmd because it's not needed anymore. Change-Id: Ie01d73f6b2aff09caccc397f72d6d8065624aebe Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13502 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 21:51:55 +01:00
$(if $(call extract_nth,4,$(1)),-c $(call extract_nth,4,$(1))) \
$(cbfs-autogen-attributes) \
build system: Unwind multi-region cbfstool add commands Add files to fmap regions one-by-one, so we can modify options per-file-per-region. Change-Id: Ic3ff5a4e563796c9fdd5705236aef37c883abf5e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13504 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 22:22:38 +01:00
-r $(2) \
build system: add easier targetting of cbfstool options per region The first attempt of providing a options-for-region function to call to determining a file's cbfstool options would work, but it means there can only be one instance which has to handle all of the files that may need an override. That logic can be problematic in impelementation. Instead, provide a mechanism to target cbfstool options for a given CBFS region where the implementation is tightly coupled in the build system to where the file as requested to be added to cbfs. This allows there to be a base set of cbfstool options while more easily extending arguments on specific regions. Example which adds '-b 0x10000' only for the COREBOOT CBFS region: cbfs-files-y += file.bin file.bin-COREBOOT-cbfstool-opts := -b 0x10000 Change-Id: Idfafb0205be42768adb04bb0a30fe46a9ca1bd57 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14640 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2016-05-06 23:01:25 +02:00
$(if $(call extract_nth,6,$(1)),-a $(call extract_nth,6,$(file)), \
$(if $(call extract_nth,5,$(file)),-b $(call extract_nth,5,$(file)))) \
Makefile: Allow platform to provide additional params for add cmd This change adds optional CBFSTOOL_ADD_CMD_OPTIONS that can be used by arch/SoC/mainboard Makefiles to supply any additional arguments that need to be passed into cbfstool when using cbfstool add command. This is useful when platform wants to add these parameters depending upon some arch/SoC/mainboard specific configs. Immediate use case is the fast SPI controller on Intel platforms adding arguments for extended window base and size. BUG=b:171534504 Change-Id: I2f48bc3f494d9a5da7e99b530a39d6078b4a881c Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47884 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-22 07:21:42 +01:00
$(call extract_nth,7,$(1)) \
$(CBFSTOOL_ADD_CMD_OPTIONS)
build system: Unwind multi-region cbfstool add commands Add files to fmap regions one-by-one, so we can modify options per-file-per-region. Change-Id: Ic3ff5a4e563796c9fdd5705236aef37c883abf5e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13504 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 22:22:38 +01:00
endef
# Empty line before endef is necessary so cbfs-add-cmd-for-region ends in a
# newline
# cbfs-add-cmd
build system: change addition order of files to go by region Instead of adding each file in all requested regions, sort by region, then by file. This is in preparation of per-region file options (eg. position, alignment) Change-Id: Ide09a1c8840279380294a059bbd5d2f9f0cba780 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16130 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-09 20:19:19 +02:00
# $(call cbfs-add-cmd,
# file in extract_nth format,
# region name,
# non-empty if file removal requested)
build system: Unwind multi-region cbfstool add commands Add files to fmap regions one-by-one, so we can modify options per-file-per-region. Change-Id: Ic3ff5a4e563796c9fdd5705236aef37c883abf5e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13504 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 22:22:38 +01:00
define cbfs-add-cmd
printf " CBFS $(call extract_nth,2,$(1))\n"
build system: change addition order of files to go by region Instead of adding each file in all requested regions, sort by region, then by file. This is in preparation of per-region file options (eg. position, alignment) Change-Id: Ide09a1c8840279380294a059bbd5d2f9f0cba780 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16130 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-09 20:19:19 +02:00
$(if $(3),-$(CBFSTOOL) $@.tmp remove -n $(call extract_nth,2,$(file)) 2>/dev/null)
$(call cbfs-add-cmd-for-region,$(1),$(2))
build system: separate cbfstool add invocations into separate commands They used to be chained into a single make shell invocation but now they're individual commands, which makes them easier to manage. Change-Id: I22394fd31989d5180790818153f466c0e7ebbedd Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13499 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-28 21:37:16 +01:00
endef
build system: allow defining alignment for cbfs-files Just set $(filename)-align to the desired alignment, and the build system will figure it out using cbfstool locate. Change-Id: I44369d947888041c21ff51ae49f9aacf510918a0 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7728 Tested-by: build bot (Jenkins) Reviewed-by: Werner Zeh <werner.zeh@gmx.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-12-09 12:49:21 +01:00
build system: change addition order of files to go by region Instead of adding each file in all requested regions, sort by region, then by file. This is in preparation of per-region file options (eg. position, alignment) Change-Id: Ide09a1c8840279380294a059bbd5d2f9f0cba780 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16130 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-09 20:19:19 +02:00
# list of files to add (using their file system names, not CBFS names),
# for dependencies etc.
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
prebuilt-files = $(foreach file,$(cbfs-files), $(call extract_nth,1,$(file)))
build system: change addition order of files to go by region Instead of adding each file in all requested regions, sort by region, then by file. This is in preparation of per-region file options (eg. position, alignment) Change-Id: Ide09a1c8840279380294a059bbd5d2f9f0cba780 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16130 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-09 20:19:19 +02:00
# $(all-regions)
# returns full list of fmap regions that we add files to
all-regions = $(sort $(subst $(comma),$(spc), \
$(foreach file,$(cbfs-files), \
$(call regions-for-file,$(call extract_nth,2,$(file))))))
# $(call all-files-in-region,region name)
# returns elements in $(cbfs-files) that end up in that region, in the order
# they appear in $(cbfs-files)
all-files-in-region = $(foreach file,$(cbfs-files), \
$(if $(filter $(1), \
$(subst $(comma),$(spc),$(call regions-for-file,$(call extract_nth,2,$(file))))), \
$(file)))
build system: allow overriding file position and alignment per region To override fallback/foo's position or alignment in region BAR, use fallback/foo-BAR-{position,align} = 0x1234 Like for the global settings, specifying both isn't allowed because that's rather pointless. Change-Id: I94f41ebc9f35108267265df4164f23b70e3d0bf6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16140 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-10 17:02:58 +02:00
# $(call update-file-for-region,file string from $(cbfs-files),region name)
# Update position and alignment according to overrides for region
# Doesn't check for invalid configurations (eg. resetting neither or both
# position and align)
# Returns the updated file string
update-file-for-region = \
$(subst $(spc),*,$(call extract_nth,1,$(1))|$(call extract_nth,2,$(1))|$(call extract_nth,3,$(1))|$(call extract_nth,4,$(1))|$($(call extract_nth,2,$(1))-$(2)-position)|$($(call extract_nth,2,$(1))-$(2)-align)|$(call extract_nth,7,$(1)))
# $(call placed-files-in-region,region name)
# like all-files-in-region, but updates the files to contain region overrides
# to position or alignment.
placed-files-in-region = $(foreach file,$(call all-files-in-region,$(1)), \
$(if $($(call extract_nth,2,$(file))-$(1)-position), \
$(if $($(call extract_nth,2,$(file))-$(1)-align), \
$(error It is not allowed to specify both alignment and position for $(call extract_nth,2,$(file))-$(1))) \
$(call update-file-for-region,$(file),$(1)), \
$(if $($(call extract_nth,2,$(file))-$(1)-align), \
$(call update-file-for-region,$(file),$(1)), \
$(file))))
build system: order per-region files to optimize placement success Make sure that files with a fixed position are placed first (whose order doesn't matter: either they collide or they don't), then all aligned files (where we just hope that the right thing happens) and finally the files with no further requirements (again, hope). It's still a pretty good heuristic given a typical coreboot image. The global sorting that happens earlier in the build flow will be removed in the future to make room for per-region requirements. Change-Id: I269c00b2ece262c95d310b76a6651c9574badb58 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16137 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-10 13:25:02 +02:00
# $(call sort-files,subset of $(cbfs-files))
# reorders the files in the given set to list files at fixed positions first,
# followed by aligned files and finally those with no constraints.
sort-files = \
$(eval _tmp_fixed:=) \
$(eval _tmp_aligned:=) \
$(eval _tmp_regular:=) \
$(foreach file,$(1), \
$(if $(call extract_nth,5,$(file)),\
$(eval _tmp_fixed += $(file)), \
$(if $(call extract_nth,6,$(file)), \
$(eval _tmp_aligned += $(file)), \
$(eval _tmp_regular += $(file))))) \
$(_tmp_fixed) $(_tmp_aligned) $(_tmp_regular)
build system: change addition order of files to go by region Instead of adding each file in all requested regions, sort by region, then by file. This is in preparation of per-region file options (eg. position, alignment) Change-Id: Ide09a1c8840279380294a059bbd5d2f9f0cba780 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16130 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-09 20:19:19 +02:00
# command list to add files to CBFS
prebuild-files = $(foreach region,$(all-regions), \
build system: order per-region files to optimize placement success Make sure that files with a fixed position are placed first (whose order doesn't matter: either they collide or they don't), then all aligned files (where we just hope that the right thing happens) and finally the files with no further requirements (again, hope). It's still a pretty good heuristic given a typical coreboot image. The global sorting that happens earlier in the build flow will be removed in the future to make room for per-region requirements. Change-Id: I269c00b2ece262c95d310b76a6651c9574badb58 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16137 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-10 13:25:02 +02:00
$(foreach file, \
build system: allow overriding file position and alignment per region To override fallback/foo's position or alignment in region BAR, use fallback/foo-BAR-{position,align} = 0x1234 Like for the global settings, specifying both isn't allowed because that's rather pointless. Change-Id: I94f41ebc9f35108267265df4164f23b70e3d0bf6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16140 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-10 17:02:58 +02:00
$(call sort-files,$(call placed-files-in-region,$(region))), \
build system: change addition order of files to go by region Instead of adding each file in all requested regions, sort by region, then by file. This is in preparation of per-region file options (eg. position, alignment) Change-Id: Ide09a1c8840279380294a059bbd5d2f9f0cba780 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16130 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-09 20:19:19 +02:00
$(call cbfs-add-cmd,$(file),$(region),$(CONFIG_UPDATE_IMAGE))))
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
util/ifdtool: Add option to create FMAP template On systems that do not provide their own *.fmd (Flashmap) file, we fall back to a default flashmap file. That file however does not contain the blobs (ME, GBE ...), that are usually placed below the BIOS Flashmap. It can therefore easily happen that the placement of the blobs collides with the placement of the BIOS region (e.g. if CBFS_SIZE is big enough). The fmaptool can't catch that, since it does not know of the blobs placement. This patch basically maps the regions described in the IFD (Intel Firmware Descriptor) to the default Flashmap. Test: Build and see that build/fmap.fmd contains all blobs now (on intel systems that are supported by the ifdtool) Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I82cb252fff456773af69943e188480a4998736fd Reviewed-on: https://review.coreboot.org/c/coreboot/+/73487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-03-05 20:55:32 +01:00
# If no FMD file (Flashmap) is supplied by mainboard, fall back to a default
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
ifeq ($(CONFIG_FMDFILE),)
util/ifdtool: Add option to create FMAP template On systems that do not provide their own *.fmd (Flashmap) file, we fall back to a default flashmap file. That file however does not contain the blobs (ME, GBE ...), that are usually placed below the BIOS Flashmap. It can therefore easily happen that the placement of the blobs collides with the placement of the BIOS region (e.g. if CBFS_SIZE is big enough). The fmaptool can't catch that, since it does not know of the blobs placement. This patch basically maps the regions described in the IFD (Intel Firmware Descriptor) to the default Flashmap. Test: Build and see that build/fmap.fmd contains all blobs now (on intel systems that are supported by the ifdtool) Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I82cb252fff456773af69943e188480a4998736fd Reviewed-on: https://review.coreboot.org/c/coreboot/+/73487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-03-05 20:55:32 +01:00
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
ifeq ($(CONFIG_ARCH_X86),y)
util/ifdtool: Add option to create FMAP template On systems that do not provide their own *.fmd (Flashmap) file, we fall back to a default flashmap file. That file however does not contain the blobs (ME, GBE ...), that are usually placed below the BIOS Flashmap. It can therefore easily happen that the placement of the blobs collides with the placement of the BIOS region (e.g. if CBFS_SIZE is big enough). The fmaptool can't catch that, since it does not know of the blobs placement. This patch basically maps the regions described in the IFD (Intel Firmware Descriptor) to the default Flashmap. Test: Build and see that build/fmap.fmd contains all blobs now (on intel systems that are supported by the ifdtool) Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I82cb252fff456773af69943e188480a4998736fd Reviewed-on: https://review.coreboot.org/c/coreboot/+/73487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-03-05 20:55:32 +01:00
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
DEFAULT_FLASHMAP:=$(top)/util/cbfstool/default-x86.fmd
util/ifdtool: Add option to create FMAP template On systems that do not provide their own *.fmd (Flashmap) file, we fall back to a default flashmap file. That file however does not contain the blobs (ME, GBE ...), that are usually placed below the BIOS Flashmap. It can therefore easily happen that the placement of the blobs collides with the placement of the BIOS region (e.g. if CBFS_SIZE is big enough). The fmaptool can't catch that, since it does not know of the blobs placement. This patch basically maps the regions described in the IFD (Intel Firmware Descriptor) to the default Flashmap. Test: Build and see that build/fmap.fmd contains all blobs now (on intel systems that are supported by the ifdtool) Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I82cb252fff456773af69943e188480a4998736fd Reviewed-on: https://review.coreboot.org/c/coreboot/+/73487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-03-05 20:55:32 +01:00
# check if IFD_CHIPSET is set and if yes generate a FMAP template from IFD descriptor
ifneq ($(CONFIG_IFD_CHIPSET),)
ifeq ($(CONFIG_HAVE_IFD_BIN),y)
DEFAULT_FLASHMAP:=$(obj)/fmap-template.fmd
$(DEFAULT_FLASHMAP): $(call strip_quotes,$(CONFIG_IFD_BIN_PATH)) $(IFDTOOL)
echo " IFDTOOL -p $(CONFIG_IFD_CHIPSET) -F $@ $<"
$(IFDTOOL) -p $(CONFIG_IFD_CHIPSET) -F $@ $<
endif # ifeq($(CONFIG_HAVE_IFD_BIN),y)
endif # ifneq($(CONFIG_IFD_CHIPSET),)
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
# entire flash
FMAP_ROM_ADDR := $(call int-subtract, 0x100000000 $(CONFIG_ROM_SIZE))
FMAP_ROM_SIZE := $(CONFIG_ROM_SIZE)
# entire "BIOS" region (everything directly of concern to the host system)
# relative to ROM_BASE
Makefile.inc: Make sure the BIOS region is 64K aligned If a non aligned CONFIG_CBFS_SIZE is used the region RW_MRC_CACHE and CONSOLE could end up non aligned. Currently this is only possible if the user messes with CONFIG_CBFS_SIZE in menuconfig, but better be safe than sorry. Change-Id: Ieb7e3c7112bd4b3f9733c36af21b1d59b3836811 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30420 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-12-25 02:52:52 +01:00
FMAP_BIOS_BASE := $(call int-align, $(call int-subtract, $(CONFIG_ROM_SIZE) $(CONFIG_CBFS_SIZE)), 0x10000)
FMAP_BIOS_SIZE := $(call int-align-down, $(shell echo $(CONFIG_CBFS_SIZE) | tr A-F a-f), 0x10000)
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
# position and size of flashmap, relative to BIOS_BASE
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
#
# X86 CONSOLE FMAP region
#
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
# position, size and entry line of CONSOLE relative to BIOS_BASE, if enabled
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CURRENT_BASE := 0
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CONSOLE_BASE := $(FMAP_CURRENT_BASE)
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
FMAP_CONSOLE_SIZE := $(CONFIG_CONSOLE_SPI_FLASH_BUFFER_SIZE)
FMAP_CONSOLE_ENTRY := CONSOLE@$(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE))
else
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
FMAP_CONSOLE_ENTRY :=
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
endif
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_MRC_CACHE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
FMAP_MRC_CACHE_SIZE := $(CONFIG_MRC_SETTINGS_CACHE_SIZE)
FMAP_MRC_CACHE_ENTRY := RW_MRC_CACHE@$(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE))
else
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
FMAP_MRC_CACHE_ENTRY :=
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
endif
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
Makefile.inc: Create a default SMMSTORE region Change-Id: I7b7b75050e0139ea9a0a4f2ad3c0d69a482fb38b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30421 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-12-25 03:00:34 +01:00
ifeq ($(CONFIG_SMMSTORE),y)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_SMMSTORE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
Makefile.inc: Create a default SMMSTORE region Change-Id: I7b7b75050e0139ea9a0a4f2ad3c0d69a482fb38b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30421 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-12-25 03:00:34 +01:00
FMAP_SMMSTORE_SIZE := $(CONFIG_SMMSTORE_SIZE)
FMAP_SMMSTORE_ENTRY := SMMSTORE@$(FMAP_SMMSTORE_BASE) $(FMAP_SMMSTORE_SIZE)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_SMMSTORE_BASE) $(FMAP_SMMSTORE_SIZE))
else
Makefile.inc: Create a default SMMSTORE region Change-Id: I7b7b75050e0139ea9a0a4f2ad3c0d69a482fb38b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30421 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-12-25 03:00:34 +01:00
FMAP_SMMSTORE_ENTRY :=
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
endif
Makefile.inc: Create a default SMMSTORE region Change-Id: I7b7b75050e0139ea9a0a4f2ad3c0d69a482fb38b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30421 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-12-25 03:00:34 +01:00
src/lib: Add Kconfig option for SPD cache in FMAP Currently, the option to cache DIMM SPD data in an FMAP region is closely coupled to a single board (google/hatch) and requires a custom FMAP to utilize. Loosen this coupling by introducing a Kconfig option which adds a correctly sized and aligned RW_SPD_CACHE region to the default FMAP. Add a Kconfig option for the region name, replacing the existing hard- coded instance in spd_cache.h. Change the inclusion of spd_cache.c to use this new Kconfig, rather than the board-specific one currently used. Lastly, have google/hatch select the new Kconfig when appropriate to ensure no change in current functionality. Test: build/boot WYVERN google/hatch variant with default FMAP, verify FMAP contains RW_SPD_CACHE, verify SPD cache used via cbmem log. Also tested on an out-of-tree Purism board. Change-Id: Iee0e7acb01e238d7ed354e3dbab1207903e3a4fc Signed-off-by: Matt DeVillier <matt.devillier@puri.sm> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48520 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-30 21:30:15 +01:00
ifeq ($(CONFIG_SPD_CACHE_IN_FMAP),y)
FMAP_SPD_CACHE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x4000)
FMAP_SPD_CACHE_SIZE := $(call int-multiply, $(CONFIG_DIMM_MAX) $(CONFIG_DIMM_SPD_SIZE))
FMAP_SPD_CACHE_SIZE := $(call int-align, $(FMAP_SPD_CACHE_SIZE), 0x1000)
FMAP_SPD_CACHE_ENTRY := $(CONFIG_SPD_CACHE_FMAP_NAME)@$(FMAP_SPD_CACHE_BASE) $(FMAP_SPD_CACHE_SIZE)
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_SPD_CACHE_BASE) $(FMAP_SPD_CACHE_SIZE))
else
FMAP_SPD_CACHE_ENTRY :=
endif
drivers/vpd: Add VPD region to default FMAP when selected Currently, use of the VPD driver to read VPD tables from flash requires the use of a custom FMAP with one or more VPD regions. Extend this funtionality to boards using the default FMAP by creating a dedicated VPD region when the driver is selected. Test: build qemu target with CONFIG_VPD selected, verify entry added to build/fmap.fmd. Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-01 21:08:29 +01:00
ifeq ($(CONFIG_VPD),y)
FMAP_VPD_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x4000)
FMAP_VPD_SIZE := $(CONFIG_VPD_FMAP_SIZE)
FMAP_VPD_ENTRY := $(CONFIG_VPD_FMAP_NAME)@$(FMAP_VPD_BASE) $(FMAP_VPD_SIZE)
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_VPD_BASE) $(FMAP_VPD_SIZE))
else
FMAP_VPD_ENTRY :=
endif
soc/intel/alderlake/hsphy: Add possibility to cache HSPHY in flash The patch adds a possibility to cache the PCIe 5.0 HSPHY firmware in the SPI flash. New flashmap region is created for that purpose. The goal of caching is to reduce the dependency on CSME and the HECI IP LOAD command which may fail when the CSME is disabled, e.g. soft disabled by HECI command or HAP disabled. This change allows to keep PCIe 5.0 root ports functioning even if CSME/HECI is not functional. TEST=Boot Ubuntu 22.04 on MSI PRO Z690-A and notice PCIe 5.0 port is functional after loading the HSPHY from cache. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Change-Id: I5a37f5b06706ff30d92f60f1bf5dc900edbde96f Reviewed-on: https://review.coreboot.org/c/coreboot/+/68987 Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-29 21:32:54 +02:00
ifeq ($(CONFIG_INCLUDE_HSPHY_IN_FMAP),y)
FMAP_HSPHY_FW_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x1000)
FMAP_HSPHY_FW_SIZE := $(CONFIG_HSPHY_FW_MAX_SIZE)
FMAP_HSPHY_FW_ENTRY := HSPHY_FW@$(FMAP_HSPHY_FW_BASE) $(FMAP_HSPHY_FW_SIZE)
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_HSPHY_FW_BASE) $(FMAP_HSPHY_FW_SIZE))
else
FMAP_HSPHY_FW_ENTRY :=
endif
Makefile.inc: Optimize generating the default x86 fmap Put the FMAP FMAP region right above the coreboot CBFS region. The other regions like RW_MRC_CACHE and CONSOLE often have alignment requirements so it makes sense to put those on top. This also simplifies the code the generate the default fmap a little. Change-Id: I24fa6c89ecf85fb9002c0357f14aa970ee51b1df Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30419 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-12-25 02:31:48 +01:00
#
# X86 FMAP region
#
#
# position, size
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_FMAP_BASE := $(FMAP_CURRENT_BASE)
Makefile.inc: Optimize generating the default x86 fmap Put the FMAP FMAP region right above the coreboot CBFS region. The other regions like RW_MRC_CACHE and CONSOLE often have alignment requirements so it makes sense to put those on top. This also simplifies the code the generate the default fmap a little. Change-Id: I24fa6c89ecf85fb9002c0357f14aa970ee51b1df Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30419 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-12-25 02:31:48 +01:00
FMAP_FMAP_SIZE := 0x200
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
#
# X86 COREBOOT default cbfs FMAP region
#
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
# position and size of CBFS, relative to BIOS_BASE
Makefile.inc: Optimize generating the default x86 fmap Put the FMAP FMAP region right above the coreboot CBFS region. The other regions like RW_MRC_CACHE and CONSOLE often have alignment requirements so it makes sense to put those on top. This also simplifies the code the generate the default fmap a little. Change-Id: I24fa6c89ecf85fb9002c0357f14aa970ee51b1df Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30419 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-12-25 02:31:48 +01:00
FMAP_CBFS_BASE := $(call int-add, $(FMAP_FMAP_BASE) $(FMAP_FMAP_SIZE))
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
FMAP_CBFS_SIZE := $(call int-subtract, $(FMAP_BIOS_SIZE) $(FMAP_CBFS_BASE))
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
Makefile.inc: Comment some 'else' and 'endif' statements Help figure out which 'else' or 'endif' is attached to which 'if'. Change-Id: I5ad068eb7c69f2dae57856f0e886f786563f7783 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13064 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2016-01-20 22:52:08 +01:00
else # ifeq ($(CONFIG_ARCH_X86),y)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
DEFAULT_FLASHMAP:=$(top)/util/cbfstool/default.fmd
# entire flash
FMAP_ROM_ADDR := 0
FMAP_ROM_SIZE := $(CONFIG_ROM_SIZE)
# entire "BIOS" region (everything directly of concern to the host system)
# relative to ROM_BASE
FMAP_BIOS_BASE := 0
FMAP_BIOS_SIZE := $(CONFIG_CBFS_SIZE)
# position and size of flashmap, relative to BIOS_BASE
FMAP_FMAP_BASE := 0x20000
Makefile: Set FMAP size to 0x200 for non-x86 boards with default fmd This change updates FMAP_FMAP_SIZE for non-x86 boards using default fmd file to be 0x200 just like for x86 boards. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I3f58696b26fbb5363d67bec4056653da83485776 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40374 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:57:08 +02:00
FMAP_FMAP_SIZE := 0x200
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_FMAP_BASE) $(FMAP_FMAP_SIZE))
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
#
# NON-X86 CONSOLE FMAP region
#
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
# position, size and entry line of CONSOLE relative to BIOS_BASE, if enabled
ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CONSOLE_BASE := $(FMAP_CURRENT_BASE)
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
FMAP_CONSOLE_SIZE := $(CONFIG_CONSOLE_SPI_FLASH_BUFFER_SIZE)
FMAP_CONSOLE_ENTRY := CONSOLE@$(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE))
else
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
FMAP_CONSOLE_ENTRY :=
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
endif
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
#
# NON-X86 RW_MRC_CACHE FMAP region
#
# position, size and entry line of MRC_CACHE relative to BIOS_BASE, if enabled
ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_MRC_CACHE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
FMAP_MRC_CACHE_SIZE := $(CONFIG_MRC_SETTINGS_CACHE_SIZE)
FMAP_MRC_CACHE_ENTRY := RW_MRC_CACHE@$(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE)
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE))
else
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
FMAP_MRC_CACHE_ENTRY :=
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
endif
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
#
# NON-X86 COREBOOT default cbfs FMAP region
#
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
# position and size of CBFS, relative to BIOS_BASE
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
FMAP_CBFS_BASE := $(FMAP_CURRENT_BASE)
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
FMAP_CBFS_SIZE := $(call int-subtract,$(FMAP_BIOS_SIZE) $(FMAP_CBFS_BASE))
Makefile: Simplify calculation of region base with default fmd files When using default fmd files, base of the fmap region is currently calculated based on the size and base of previous fmap regions. Since the existence of any fmap region is dependent on the selection of certain CONFIG_* parameters, these calculations get complicated. Every time base is calculated for a region, there need to be checks to see which of the previous regions really exist. As the regions in default fmd file are increased, these calculations and the conditional checks get even more complicated. This change introduces a Makefile variable FMAP_CURRENT_BASE which is updated every time a new region is allocated space. This allows using the same steps for determining the base of any fmap region irrespective of the state of previous regions. The way the code is organized it should be possible in the future to also add a macro to perform the same steps (in case that is possible). TEST=Verified that coreboot image generated remains unchanged for x86 and ARM boards using the default fmd files. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-04-14 08:39:44 +02:00
Makefile.inc: Comment some 'else' and 'endif' statements Help figure out which 'else' or 'endif' is attached to which 'if'. Change-Id: I5ad068eb7c69f2dae57856f0e886f786563f7783 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13064 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2016-01-20 22:52:08 +01:00
endif # ifeq ($(CONFIG_ARCH_X86),y)
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
Makefile.inc: Fmaptool build fixes - make sure CONFIG_CBFS_SIZE is lowercase for fmaptool. - Regenerate the fmap.fmd file when config.h changes. - Print the fmaptool step when doing the build. Change-Id: Ib518ed469d9e39eb41c81f7b19480c7789067d2d Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/12806 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-12-27 01:02:41 +01:00
$(obj)/fmap.fmd: $(top)/Makefile.inc $(DEFAULT_FLASHMAP) $(obj)/config.h
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
sed -e "s,##ROM_BASE##,$(FMAP_ROM_ADDR)," \
-e "s,##ROM_SIZE##,$(FMAP_ROM_SIZE)," \
-e "s,##BIOS_BASE##,$(FMAP_BIOS_BASE)," \
-e "s,##BIOS_SIZE##,$(FMAP_BIOS_SIZE)," \
-e "s,##FMAP_BASE##,$(FMAP_FMAP_BASE)," \
-e "s,##FMAP_SIZE##,$(FMAP_FMAP_SIZE)," \
console/flashsconsole: Add spi flash console for debugging If CONSOLE_SPI_FLASH config is enabled, we write the cbmem messages to the 'CONSOLE' area in FMAP which allows us to grab the log when we read the flash. This is useful when you don't have usb debugging, and UART lines are hard to find. Since a failure to boot would require a hardware flasher anyways, we can get the log at the same time. This feature should only be used when no alternative is found and only when we can't boot the system, because excessive writes to the flash is not recommended. This has been tested on purism/librem13 v2 and librem 15 v3 which run Intel Skylake hardware. It has not been tested on other archs or with a driver other than the fast_spi. Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3 Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm> Reviewed-on: https://review.coreboot.org/19849 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-11 16:36:29 +02:00
-e "s,##CONSOLE_ENTRY##,$(FMAP_CONSOLE_ENTRY)," \
drivers/mrc_cache: Always generate an FMAP region This automatically generates an FMAP region for the MRC_CACHE driver which is easier to handle than a cbfsfile. Adds some spaces and more comments to Makefile.inc to improve readability. Tested on Thinkpad x200 with some proof of concept patches. Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23150 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-07 23:12:49 +01:00
-e "s,##MRC_CACHE_ENTRY##,$(FMAP_MRC_CACHE_ENTRY)," \
Makefile.inc: Create a default SMMSTORE region Change-Id: I7b7b75050e0139ea9a0a4f2ad3c0d69a482fb38b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/30421 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-12-25 03:00:34 +01:00
-e "s,##SMMSTORE_ENTRY##,$(FMAP_SMMSTORE_ENTRY)," \
src/lib: Add Kconfig option for SPD cache in FMAP Currently, the option to cache DIMM SPD data in an FMAP region is closely coupled to a single board (google/hatch) and requires a custom FMAP to utilize. Loosen this coupling by introducing a Kconfig option which adds a correctly sized and aligned RW_SPD_CACHE region to the default FMAP. Add a Kconfig option for the region name, replacing the existing hard- coded instance in spd_cache.h. Change the inclusion of spd_cache.c to use this new Kconfig, rather than the board-specific one currently used. Lastly, have google/hatch select the new Kconfig when appropriate to ensure no change in current functionality. Test: build/boot WYVERN google/hatch variant with default FMAP, verify FMAP contains RW_SPD_CACHE, verify SPD cache used via cbmem log. Also tested on an out-of-tree Purism board. Change-Id: Iee0e7acb01e238d7ed354e3dbab1207903e3a4fc Signed-off-by: Matt DeVillier <matt.devillier@puri.sm> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48520 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-30 21:30:15 +01:00
-e "s,##SPD_CACHE_ENTRY##,$(FMAP_SPD_CACHE_ENTRY)," \
drivers/vpd: Add VPD region to default FMAP when selected Currently, use of the VPD driver to read VPD tables from flash requires the use of a custom FMAP with one or more VPD regions. Extend this funtionality to boards using the default FMAP by creating a dedicated VPD region when the driver is selected. Test: build qemu target with CONFIG_VPD selected, verify entry added to build/fmap.fmd. Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-01 21:08:29 +01:00
-e "s,##VPD_ENTRY##,$(FMAP_VPD_ENTRY)," \
soc/intel/alderlake/hsphy: Add possibility to cache HSPHY in flash The patch adds a possibility to cache the PCIe 5.0 HSPHY firmware in the SPI flash. New flashmap region is created for that purpose. The goal of caching is to reduce the dependency on CSME and the HECI IP LOAD command which may fail when the CSME is disabled, e.g. soft disabled by HECI command or HAP disabled. This change allows to keep PCIe 5.0 root ports functioning even if CSME/HECI is not functional. TEST=Boot Ubuntu 22.04 on MSI PRO Z690-A and notice PCIe 5.0 port is functional after loading the HSPHY from cache. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Change-Id: I5a37f5b06706ff30d92f60f1bf5dc900edbde96f Reviewed-on: https://review.coreboot.org/c/coreboot/+/68987 Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-29 21:32:54 +02:00
-e "s,##HSPHY_FW_ENTRY##,$(FMAP_HSPHY_FW_ENTRY)," \
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
-e "s,##CBFS_BASE##,$(FMAP_CBFS_BASE)," \
-e "s,##CBFS_SIZE##,$(FMAP_CBFS_SIZE)," \
$(DEFAULT_FLASHMAP) > $@.tmp
mv $@.tmp $@
Makefile.inc: Comment some 'else' and 'endif' statements Help figure out which 'else' or 'endif' is attached to which 'if'. Change-Id: I5ad068eb7c69f2dae57856f0e886f786563f7783 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13064 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2016-01-20 22:52:08 +01:00
else # ifeq ($(CONFIG_FMDFILE),)
Makefile.inc: Fmaptool build fixes - make sure CONFIG_CBFS_SIZE is lowercase for fmaptool. - Regenerate the fmap.fmd file when config.h changes. - Print the fmaptool step when doing the build. Change-Id: Ib518ed469d9e39eb41c81f7b19480c7789067d2d Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/12806 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-12-27 01:02:41 +01:00
$(obj)/fmap.fmd: $(CONFIG_FMDFILE) $(obj)/config.h
flashmap: Use CONFIG_ROM_SIZE as flash size in flashmap Currently there are two sources for the final size of the flash image. One is defined as a Kconfig variable (ROM_SIZE) and the other can be provided in a user defined flashmap.fmd. This patch will enable the usage of CONFIG_ROM_SIZE in flashmap.fmd to define the flash size. In this way, the Kconfig variable is the only source of information for the flash image size. This way is optional. Change-Id: Id5298e06d360aaa6d94f2b5a2ffa65e45919853e Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/15219 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-17 01:48:44 +02:00
$(HOSTCC) $(PREPROCESS_ONLY) -include $(obj)/config.h $< -o $@.pre
mv $@.pre $@
Makefile.inc: Comment some 'else' and 'endif' statements Help figure out which 'else' or 'endif' is attached to which 'if'. Change-Id: I5ad068eb7c69f2dae57856f0e886f786563f7783 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13064 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2016-01-20 22:52:08 +01:00
endif # ifeq ($(CONFIG_FMDFILE),)
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
# generated at the same time as fmap.fmap
build system: rename fmap.h to fmap_config.h There's an in-tree fmap.h, and the file generated by fmaptool is likely used in tandem with it. To avoid problems, rename the generated file (which so far isn't used). Change-Id: I95dfde513a7f78677cf18ecd7ce8745e40af316b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14570 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-02 10:50:31 +02:00
$(obj)/fmap_config.h: $(obj)/fmap.fmap
Makefile.inc: Fix dependency tracking of fmap{_config.h,.desc} GNU make is too smart (or too stupid?) for empty recipes. In the case of empty recipes, GNU make doesn't consider the target as updated even if its prerequisites are. So if we told make to rebuild `build/romstage/ lib/cbfs.o` for instance, and the FMAP changed, it rerun the fmaptool recipe (as a prerequisite) but only considered `cbfs.o` to be updated by chance. Just not leaving the recipes empty seems to help here. I seeemed to remember that it wasn't that easy, but it fixes the issue for me... Change-Id: Ic7ecb88cf7df7f2488defd47ea02255fc10a67e9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/28198 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-08-17 20:05:53 +02:00
true
build system: Initialize all CBFS regions Regions marked "(CBFS)" in the fmd weren't actually initialized with a CBFS structure, just the default CBFS region (COREBOOT). This made cbfstool add (etc) fail on those regions, so explicitly initialize all those regions. Change-Id: Ib321fa73cd2ecc8057b52408521fd214d6df7f2e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13059 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-20 15:32:03 +01:00
$(obj)/fmap.desc: $(obj)/fmap.fmap
Makefile.inc: Fix dependency tracking of fmap{_config.h,.desc} GNU make is too smart (or too stupid?) for empty recipes. In the case of empty recipes, GNU make doesn't consider the target as updated even if its prerequisites are. So if we told make to rebuild `build/romstage/ lib/cbfs.o` for instance, and the FMAP changed, it rerun the fmaptool recipe (as a prerequisite) but only considered `cbfs.o` to be updated by chance. Just not leaving the recipes empty seems to help here. I seeemed to remember that it wasn't that easy, but it fixes the issue for me... Change-Id: Ic7ecb88cf7df7f2488defd47ea02255fc10a67e9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/28198 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-08-17 20:05:53 +02:00
true
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
$(obj)/fmap.fmap: $(obj)/fmap.fmd $(FMAPTOOL)
build system: rename fmap.h to fmap_config.h There's an in-tree fmap.h, and the file generated by fmaptool is likely used in tandem with it. To avoid problems, rename the generated file (which so far isn't used). Change-Id: I95dfde513a7f78677cf18ecd7ce8745e40af316b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14570 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-02 10:50:31 +02:00
echo " FMAP $(FMAPTOOL) -h $(obj)/fmap_config.h $< $@"
$(FMAPTOOL) -h $(obj)/fmap_config.h -R $(obj)/fmap.desc $< $@
build system: Switch to fmap based firmware layout We still add a master header for compatibility purposes, and the default layouts don't cover anything non-coreboot (eg. IFD regions) yet. The default layouts can be overridden by specifying an fmd file, from which the fmap is generated. Future work: - map IFD regions to fmap regions - non-x86: build minimalistic trampolines that jump into the first cbfs file, so the bootblock can be part of CBFS instead of reserving a whole 64K for it. - teach coreboot's cbfs code to work without the master header - teach coreboot's cbfs code to work on different fmap regions Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/11692 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-16 18:10:52 +02:00
Kconfig: Add config for creating a second bootblock Intel PCH/Southbridges have feature that it is possible to have the southbridge/PCH look for the bootblock at a 64K or 128K/256K/512K/1MB (in case of newer SoCs) offset instead of the usual top of flash. Add configs to create a second bootblock and configure its size. Change-Id: I4bbd19c35871891b762a0673f840858d972e129e Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Signed-off-by: Aamir Bohra <aamir.bohra@intel.com> Reviewed-on: https://review.coreboot.org/22533 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-11-16 09:02:29 +01:00
ifeq ($(CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK),y)
TS_OPTIONS := -j $(CONFIG_INTEL_TOP_SWAP_BOOTBLOCK_SIZE)
endif
sec/intel/cbnt: Stitch in ACMs in the coreboot image Actual support CBnT will be added later on. Change-Id: Icc35c5e6c74d002efee43cc05ecc8023e00631e0 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46456 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-15 13:57:52 +02:00
Makefile.inc: Add bootblock to CBFS before others With CBFS verification, cbfstool (CB:41121) needs bootblock to be present in coreboot.pre in order to locate the metadata hash stored in it. Therefore we have to ensure that bootblock is added to CBFS before other CBFS files are added. To solve the problem, create the 'add_bootblock' function, and call it in the coreboot.pre recipe. Because bootblock.bin is now a prerequisite of coreboot.pre, it will get built even if CONFIG_BOOTBLOCK_IN_CBFS=n. BUG=b:233263447 TEST=emerge-guybrush coreboot TEST=emerge-corsola coreboot chromeos-bootimage TEST=cbfstool image-kingler.bin print -v TEST=Kingler booted successfully BRANCH=none Change-Id: I385deb8231e44310ee139c3f69f449e75b92b2be Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64547 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-05-20 11:36:46 +02:00
ifneq ($(CONFIG_ARCH_X86),y)
add_bootblock = $(CBFSTOOL) $(1) write -u -r BOOTBLOCK -f $(2)
endif
Makefile.inc: Explicitly delete coreboot.pre coreboot.pre doesn't follow the standard Make conventions. It gets modified by multiple rules, and thus we can't compute the dependencies correctly. This means we need to manually delete it before starting the dependency calculations. i.e., Building firmware with the seabios payload now works correctly. Fixes: dd6efce934f ("Makefile: Add .SECONDARY") Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: If5fa3f0b8d314369a044658e452bd75bc7709397 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62922 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2022-03-18 16:54:19 +01:00
# coreboot.pre doesn't follow the standard Make conventions. It gets modified
# by multiple rules, and thus we can't compute the dependencies correctly.
$(shell rm -f $(obj)/coreboot.pre)
build system: create fmap for UPDATE_IMAGE configurations, too This fixes UPDATE_IMAGE builds, assuming that the fmap configuration in the tree didn't change, at least as far as the CBFS regions are concerned. Another option would be to synthesize the fmap related files from the existing image, but that comes with other issues (eg. what about updating images old enough that there is no fmap?) and is more complex, so keep it simple, stupid for now. Change-Id: I036dab9f81f524f7d70bc0029b1ef835e6180a53 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14601 Tested-by: build bot (Jenkins) Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2016-05-04 01:37:50 +02:00
ifneq ($(CONFIG_UPDATE_IMAGE),y)
Makefile.inc: Add bootblock to CBFS before others With CBFS verification, cbfstool (CB:41121) needs bootblock to be present in coreboot.pre in order to locate the metadata hash stored in it. Therefore we have to ensure that bootblock is added to CBFS before other CBFS files are added. To solve the problem, create the 'add_bootblock' function, and call it in the coreboot.pre recipe. Because bootblock.bin is now a prerequisite of coreboot.pre, it will get built even if CONFIG_BOOTBLOCK_IN_CBFS=n. BUG=b:233263447 TEST=emerge-guybrush coreboot TEST=emerge-corsola coreboot chromeos-bootimage TEST=cbfstool image-kingler.bin print -v TEST=Kingler booted successfully BRANCH=none Change-Id: I385deb8231e44310ee139c3f69f449e75b92b2be Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64547 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-05-20 11:36:46 +02:00
$(obj)/coreboot.pre: $$(prebuilt-files) $(CBFSTOOL) $(obj)/fmap.fmap $(obj)/fmap.desc $(objcbfs)/bootblock.bin
build system: Initialize all CBFS regions Regions marked "(CBFS)" in the fmd weren't actually initialized with a CBFS structure, just the default CBFS region (COREBOOT). This made cbfstool add (etc) fail on those regions, so explicitly initialize all those regions. Change-Id: Ib321fa73cd2ecc8057b52408521fd214d6df7f2e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13059 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-20 15:32:03 +01:00
$(CBFSTOOL) $@.tmp create -M $(obj)/fmap.fmap -r $(shell cat $(obj)/fmap.desc)
Makefile.inc: Add bootblock to CBFS before others With CBFS verification, cbfstool (CB:41121) needs bootblock to be present in coreboot.pre in order to locate the metadata hash stored in it. Therefore we have to ensure that bootblock is added to CBFS before other CBFS files are added. To solve the problem, create the 'add_bootblock' function, and call it in the coreboot.pre recipe. Because bootblock.bin is now a prerequisite of coreboot.pre, it will get built even if CONFIG_BOOTBLOCK_IN_CBFS=n. BUG=b:233263447 TEST=emerge-guybrush coreboot TEST=emerge-corsola coreboot chromeos-bootimage TEST=cbfstool image-kingler.bin print -v TEST=Kingler booted successfully BRANCH=none Change-Id: I385deb8231e44310ee139c3f69f449e75b92b2be Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64547 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-05-20 11:36:46 +02:00
printf " BOOTBLOCK\n"
$(call add_bootblock,$@.tmp,$(objcbfs)/bootblock.bin)
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
$(prebuild-files) true
mv $@.tmp $@
Makefile.inc: Comment some 'else' and 'endif' statements Help figure out which 'else' or 'endif' is attached to which 'if'. Change-Id: I5ad068eb7c69f2dae57856f0e886f786563f7783 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13064 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2016-01-20 22:52:08 +01:00
else # ifneq ($(CONFIG_UPDATE_IMAGE),y)
build system: drop one level of indirection coreboot.pre1 was generated then copied into coreboot.pre, now without any additional manipulation. Get rid of that extra step. Change-Id: I138567cadbc2fa1a6b6c988e34bdaae0e92d5554 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12550 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-26 17:22:38 +01:00
.PHONY: $(obj)/coreboot.pre
$(obj)/coreboot.pre: $$(prebuilt-files) $(CBFSTOOL)
Makefile.inc: error if UPDATE_IMAGE is enabled with no coreboot.rom Instead of just failing with the statement: 'mv: cannot stat ‘coreboot.rom’: No such file or directory', fail with an error that helps the user understand the issue. Change-Id: Ie693d45710f599991514e0803a7c444636e473c9 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13065 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de>
2016-01-20 22:54:27 +01:00
mv $(obj)/coreboot.rom $@.tmp || \
(echo "Error: You have UPDATE_IMAGE set in Kconfig, but have no existing image to update." && \
build system: Fix UPDATE_IMAGE A quote was missing in a command. Change-Id: I04148538007e5c450c6be113aab8a7fbb534db26 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reported-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: https://review.coreboot.org/13474 Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2016-01-26 22:25:40 +01:00
echo "Exiting." && \
Makefile.inc: error if UPDATE_IMAGE is enabled with no coreboot.rom Instead of just failing with the statement: 'mv: cannot stat ‘coreboot.rom’: No such file or directory', fail with an error that helps the user understand the issue. Change-Id: Ie693d45710f599991514e0803a7c444636e473c9 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13065 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de>
2016-01-20 22:54:27 +01:00
false)
update_image: add all CBFS_PREFIX files to cbfs In order to accomodate objects not directly linked into ramstage anymore those files need to be added to the image when UPDATE_IMAGE is selected. Otherwise many required pieces are missing from booting correctly. Change-Id: Ic0b24387d24d0af3b75f5fd6fa1795fd381c4d58 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10410 Tested-by: build bot (Jenkins) Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-06-03 18:54:59 +02:00
$(prebuild-files) true
mv $@.tmp $@
Makefile.inc: Comment some 'else' and 'endif' statements Help figure out which 'else' or 'endif' is attached to which 'if'. Change-Id: I5ad068eb7c69f2dae57856f0e886f786563f7783 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13064 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2016-01-20 22:52:08 +01:00
endif # ifneq ($(CONFIG_UPDATE_IMAGE),y)
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
ifeq ($(CONFIG_HAVE_REFCODE_BLOB),y)
REFCODE_BLOB=$(obj)/refcode.rmod
$(REFCODE_BLOB): $(RMODTOOL)
$(RMODTOOL) -i $(CONFIG_REFCODE_BLOB_FILE) -o $@
endif
Rampayload: Able to build coreboot without ramstage This patch removes all possible dependencies in order to build platform with CONFIG_RAMPAYLOAD enable(without ramstage). A. Create coreboot separate stage kconfigs This patch creates seperate stage configs as below 1. HAVE_BOOTBLOCK 2. HAVE_VERSTAGE 3. HAVE_ROMSTAGE 4. HAVE_POSTCAR 5. HAVE_RAMSTAGE B. Also ensures below kconfigs are aligned with correct stage configs 1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if CONFIG_HAVE_RAMSTAGE is selected. 2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set 3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE || CONFIG_HAVE_ROMSTAGE is selected. C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE On x86 platform: Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32 Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_ This patch fixes Case 2 usecase where platform doesn't select CONFIG_HAVE_RAMSTAGE. Also add option to create sipi_vector.manual based on $(TARGET_STAGE) variable. $(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE $(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-06-08 08:59:02 +02:00
ifeq ($(CONFIG_HAVE_RAMSTAGE),y)
RAMSTAGE=$(objcbfs)/ramstage.elf
else
RAMSTAGE=
endif
build system: Structure and serialize INTERMEDIATE Target added to INTERMEDIATE all operate on coreboot.pre, each modifying the file in some way. When running them in parallel, coreboot.pre can be read from and written to in parallel which can corrupt the result. Add a function to create those rules that also adds existing INTERMEDIATE targets to enforce an order (as established by evaluation order of Makefile.inc files). While at it, also add the addition to the PHONY target so we don't forget it. BUG=chromium:1154313, b:174585424 TEST=Built a configuration with SeaBIOS + SeaBIOS config files (ps2 timeout and sercon) and saw that they were executed. Change-Id: Ia5803806e6c33083dfe5dec8904a65c46436e756 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49358 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-12 15:09:57 +01:00
add_intermediate = \
build system: Always add coreboot.pre dependency to intermediates They all operate on that file, so just add it globally. Change-Id: I953975a4078d0f4a5ec0b6248f0dcedada69afb2 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49380 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-01-13 09:15:07 +01:00
$(1): $(obj)/coreboot.pre $(2) | $(INTERMEDIATE) \
build system: Structure and serialize INTERMEDIATE Target added to INTERMEDIATE all operate on coreboot.pre, each modifying the file in some way. When running them in parallel, coreboot.pre can be read from and written to in parallel which can corrupt the result. Add a function to create those rules that also adds existing INTERMEDIATE targets to enforce an order (as established by evaluation order of Makefile.inc files). While at it, also add the addition to the PHONY target so we don't forget it. BUG=chromium:1154313, b:174585424 TEST=Built a configuration with SeaBIOS + SeaBIOS config files (ps2 timeout and sercon) and saw that they were executed. Change-Id: Ia5803806e6c33083dfe5dec8904a65c46436e756 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49358 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-01-12 15:09:57 +01:00
$(eval INTERMEDIATE+=$(1)) $(eval PHONY+=$(1))
Makefile.inc: Fix IFITTOOL dependencies Add IFITTOOL as a dependency where needed and remove where it is unneeded. Change-Id: I88c9fc19cca0c72e80d3218dbcc76b89b04feacf Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56112 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2021-07-06 12:26:41 +02:00
$(obj)/coreboot.rom: $(obj)/coreboot.pre $(CBFSTOOL) $(IFITTOOL) $$(INTERMEDIATE)
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
@printf " CBFS $(subst $(obj)/,,$(@))\n"
CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE for cbfstool Some projects (like ChromeOS) put more content than described by CBFS onto their image. For top-aligned images (read: x86), this has traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the area actually managed by CBFS, as opposed to ROM_SIZE) that is used to calculate the CBFS entry start offset. On bottom-aligned boards, many define a fake (smaller) ROM_SIZE for only the CBFS part, which is not consistently done and can be an issue because ROM_SIZE is expected to be a power of two. This patch changes all non-x86 boards to describe their actual (physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a mainboard Kconfig select (which is the correct place to declare unchangeable physical properties of the board). It also changes the cbfstool create invocation to use CBFS_SIZE as the -s parameter for those architectures, which defaults to ROM_SIZE but gets overridden for special use cases like ChromeOS. This has the advantage that cbfstool has a consistent idea of where the area it is responsible for ends, which offers better bounds-checking and is needed for a subsequent fix. Also change the FMAP offset to default to right behind the (now consistently known) CBFS region for non-x86 boards, which has emerged as a de-facto standard on those architectures and allows us to reduce the amount of custom configuration. In the future, the nightmare that is ChromeOS's image build system could be redesigned to enforce this automatically, and also confirm that it doesn't overwrite any space used by CBFS (which is now consistently defined as the file size of coreboot.rom on non-x86). CQ-DEPEND=CL:231576,CL:231475 BRANCH=None BUG=chromium:422501 TEST=Built and booted on Veyron_Pinky. Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71 Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229974 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9619 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-11-10 22:11:50 +01:00
# The full ROM may be larger than the CBFS part, so create an empty
# file (filled with \377 = 0xff) and copy the CBFS image over it.
Build system: Fix "dd: invalid number `0x800000'" dd doesn't recognise hex number. the commit introducing this: f21b657 build system: improve portability by not relying on extraordinary dd options Change-Id: Ie0df3eb00fa2ba5d7bbb8218e24b864cbdd07c3a Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com> Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/9944 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-22 09:22:00 +02:00
dd if=/dev/zero bs=$(call _toint,$(CONFIG_ROM_SIZE)) count=1 2> /dev/null | tr '\000' '\377' > $@.tmp
CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE for cbfstool Some projects (like ChromeOS) put more content than described by CBFS onto their image. For top-aligned images (read: x86), this has traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the area actually managed by CBFS, as opposed to ROM_SIZE) that is used to calculate the CBFS entry start offset. On bottom-aligned boards, many define a fake (smaller) ROM_SIZE for only the CBFS part, which is not consistently done and can be an issue because ROM_SIZE is expected to be a power of two. This patch changes all non-x86 boards to describe their actual (physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a mainboard Kconfig select (which is the correct place to declare unchangeable physical properties of the board). It also changes the cbfstool create invocation to use CBFS_SIZE as the -s parameter for those architectures, which defaults to ROM_SIZE but gets overridden for special use cases like ChromeOS. This has the advantage that cbfstool has a consistent idea of where the area it is responsible for ends, which offers better bounds-checking and is needed for a subsequent fix. Also change the FMAP offset to default to right behind the (now consistently known) CBFS region for non-x86 boards, which has emerged as a de-facto standard on those architectures and allows us to reduce the amount of custom configuration. In the future, the nightmare that is ChromeOS's image build system could be redesigned to enforce this automatically, and also confirm that it doesn't overwrite any space used by CBFS (which is now consistently defined as the file size of coreboot.rom on non-x86). CQ-DEPEND=CL:231576,CL:231475 BRANCH=None BUG=chromium:422501 TEST=Built and booted on Veyron_Pinky. Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71 Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229974 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9619 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-11-10 22:11:50 +01:00
dd if=$(obj)/coreboot.pre of=$@.tmp bs=8192 conv=notrunc 2> /dev/null
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
ifeq ($(CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE),y)
Makefile.inc: Move adding mcu FIT entries This can be done using in the INTERMEDIATE target in the proper place. Change-Id: I28a7764205e0510be89c131058ec56861a479699 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46453 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-14 16:35:11 +02:00
# Print final FIT table
Makefile: Use ifittool to update FIT Depend on ifittool and use it to update FIT instead cbfstool FIT code. Move the TOPSWAP / microcode handling out of cbfstool and implement it in the Makefile. The new FIT looks like the old one and has been tested on Broadwell-DE. The TOPSWAP / microcode code path needs test on real hardware. Change-Id: I687469d62557f81e9d88398cfc93182164fdac95 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31495 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2019-02-18 13:33:16 +01:00
$(IFITTOOL) -f $@.tmp -D -r COREBOOT
Makefile.inc: Move adding mcu FIT entries This can be done using in the INTERMEDIATE target in the proper place. Change-Id: I28a7764205e0510be89c131058ec56861a479699 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46453 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-14 16:35:11 +02:00
# Print final TS BOOTBLOCK FIT table
Makefile: Use ifittool to update FIT Depend on ifittool and use it to update FIT instead cbfstool FIT code. Move the TOPSWAP / microcode handling out of cbfstool and implement it in the Makefile. The new FIT looks like the old one and has been tested on Broadwell-DE. The TOPSWAP / microcode code path needs test on real hardware. Change-Id: I687469d62557f81e9d88398cfc93182164fdac95 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31495 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2019-02-18 13:33:16 +01:00
ifeq ($(CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK),y)
Makefile.inc: Move adding mcu FIT entries This can be done using in the INTERMEDIATE target in the proper place. Change-Id: I28a7764205e0510be89c131058ec56861a479699 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46453 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-14 16:35:11 +02:00
@printf " TOP SWAP FIT table\n"
Makefile: Use ifittool to update FIT Depend on ifittool and use it to update FIT instead cbfstool FIT code. Move the TOPSWAP / microcode handling out of cbfstool and implement it in the Makefile. The new FIT looks like the old one and has been tested on Broadwell-DE. The TOPSWAP / microcode code path needs test on real hardware. Change-Id: I687469d62557f81e9d88398cfc93182164fdac95 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31495 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
2019-02-18 13:33:16 +01:00
$(IFITTOOL) -f $@.tmp -D $(TS_OPTIONS) -r COREBOOT
Makefile.inc: Move adding mcu FIT entries This can be done using in the INTERMEDIATE target in the proper place. Change-Id: I28a7764205e0510be89c131058ec56861a479699 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46453 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Christian Walter <christian.walter@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-14 16:35:11 +02:00
endif # CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK
Makefile.inc: Don't run `ifittool` with CONFIG_UPDATE_IMAGE The dependency for `ifittool` was missing in the CONFIG_UPDATE_IMAGE case. Which led us to the question: Why run `ifittool` in this case? The idea of CONFIG_UPDATE_IMAGE is to update everything _but_ the bootblock. Change-Id: I7fd3bd1b56f495b16beb1e1f4b35b8cfcf25b2ba Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39803 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Singer <felixsinger@posteo.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-24 13:51:26 +01:00
endif # CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
mv $@.tmp $@
Makefile.inc: Also print layout at end of build Currently, at the end of a build `CBFSPRINT` prints the content of all CBFS regions. This is confusing, as they are identical. To avoid confusion print the layout beforehand. > layout [-w] – List mutable (or, with -w, readable) image regions Change-Id: Ibf03b125ef6dae41c58b8ae867430047778cfff3 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/22143 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-10-23 19:20:57 +02:00
@printf " CBFSLAYOUT $(subst $(obj)/,,$(@))\n\n"
$(CBFSTOOL) $@ layout
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
@printf " CBFSPRINT $(subst $(obj)/,,$(@))\n\n"
build system: Print the content of all regions we add files to That's more useful than just COREBOOT for more complex scenarios Change-Id: I93cd686d698799a3331ca2ea487cd6efb304caa0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/16143 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-10 17:13:00 +02:00
$(CBFSTOOL) $@ print -r $(subst $(spc),$(comma),$(all-regions))
cbfstool: Expand CBFS verification validity check This patch adds a new line to `cbfstool print -v` output that records the overall CBFS verification health of the image. While this info was already visible from individual fields before, it's nice to have a one-stop location to see "this is a good image" without having to carefully parse a lot of output manually. Also add a few lines to the Makefile that check whether this field is valid for the final image (it always should be, but hopefully this check will allow us to catch regressions like the one fixed by CB:64547 sooner in the future). BUG=b:233263447 Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I1b74b01a55b22294556007aaee835d0fdb9e1c63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/64657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-05-25 03:18:46 +02:00
ifeq ($(CONFIG_CBFS_VERIFICATION),y)
line=$$($(CBFSTOOL) $@ print -kv 2>/dev/null | grep -F '[CBFS VERIFICATION (COREBOOT)]') ;\
if ! printf "$$line" | grep -q 'fully valid'; then \
echo "CBFS verification error: $$line" ;\
exit 1 ;\
fi
endif # CONFIG_CBFS_VERIFICATION
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
Allow to build romstage sources inside the bootblock Having a separate romstage is only desirable: - with advanced setups like vboot or normal/fallback - boot medium is slow at startup (some ARM SOCs) - bootblock is limited in size (Intel APL 32K) When this is not the case there is no need for the extra complexity that romstage brings. Including the romstage sources inside the bootblock substantially reduces the total code footprint. Often the resulting code is 10-20k smaller. This is controlled via a Kconfig option. TESTED: works on qemu x86, arm and aarch64 with and without VBOOT. Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-05-29 08:10:49 +02:00
ifeq ($(CONFIG_SEPARATE_ROMSTAGE),y)
build system: Add more files through cbfs-files instead of manual rules verstage, romstage, and payload can be added through infrastructure now. Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12549 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-26 16:39:23 +01:00
cbfs-files-y += $(CONFIG_CBFS_PREFIX)/romstage
$(CONFIG_CBFS_PREFIX)/romstage-file := $(objcbfs)/romstage.elf
$(CONFIG_CBFS_PREFIX)/romstage-type := stage
cbfs: Add LZ4 in-place decompression support for pre-RAM stages This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-29 22:51:35 +02:00
$(CONFIG_CBFS_PREFIX)/romstage-compression := $(CBFS_PRERAM_COMPRESS_FLAG)
build system: Add more files through cbfs-files instead of manual rules verstage, romstage, and payload can be added through infrastructure now. Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12549 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-26 16:39:23 +01:00
ifeq ($(CONFIG_ARCH_ROMSTAGE_ARM),y)
$(CONFIG_CBFS_PREFIX)/romstage-options := -b 0
endif
ifeq ($(CONFIG_ARCH_ROMSTAGE_X86_32)$(CONFIG_ARCH_ROMSTAGE_X86_64),y)
# Use a 64 byte alignment to provide a minimum alignment
# requirement for the overall romstage. While the first object within
# romstage could have a 4 byte minimum alignment that doesn't mean the linker
# won't decide the entire section should be aligned to a larger value. In the
# future cbfstool should add XIP files proper and honor the alignment
# requirements of the program segment.
#
# Make sure that segment for .car.data is ignored while adding romstage.
$(CONFIG_CBFS_PREFIX)/romstage-align := 64
x86: Add .data section support for pre-memory stages x86 pre-memory stages do not support the `.data` section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of `.data` section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage for Raptor Lake has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some `.data` symbols in the `_bss` region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Other platforms do not have that limitation. Hence, resolving it would help to align code and reduce compilation based restriction (cf. the use of `ENV_HAS_DATA_SECTION` compilation flag in various places of coreboot code). We identified three cases to consider: 1. eXecute-In-Place pre-memory stages - code is in SPINOR - data is also stored in SPINOR but must be linked in Cache-As-RAM and copied there at runtime 2. `bootblock` stage is a bit different as it uses Cache-As-Ram but the memory mapping and its entry code different 3. pre-memory stages loaded in and executed from Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`). eXecute-In-Place pre-memory stages (#1) require the creation of a new ELF segment as the code segment Virtual Memory Address and Load Memory Address are identical but the data needs to be linked in cache-As-RAM (VMA) but to be stored right after the code (LMA). Here is the output `readelf --segments` on a `romstage.debug` ELF binary. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20 LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4 Section to Segment mapping: Segment Sections... 00 .text 01 .data Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they are totally different for the Segment 1 holding the `.data` section. Since we need the data section `VirtAddr` to be in the Cache-As-Ram and its `PhysAddr` right after the `.text` section, the use of a new segment is mandatory. `bootblock` (#2) also uses this new segment to store the data right after the code and load it to Cache-As-RAM at runtime. However, the code involved is different. Not eXecute-In-Place pre-memory stages (#3) do not really need any special work other than enabling a data section as the code and data VMA / LMA translation vector is the same. TEST=#1 and #2 verified on rex and qemu 32 and 64 bits: - The `bootblock.debug`, `romstage.debug` and `verstage.debug` all have data stored at the end of the `.text` section and code to copy the data content to the Cache-As-RAM. - The CBFS stages included in the final image has not improperly relocated any of the `.data` section symbol. - Test purposes global data symbols we added in bootblock, romstage and verstage are properly accessible at runtime #3: for "Intel Apollolake DDR3 RVP1" board, we verified that the generated romstage ELF includes a .data section similarly to a regular memory enabled stage. Change-Id: I030407fcc72776e59def476daa5b86ad0495debe Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-08-31 00:42:09 +02:00
ifeq ($(CONFIG_NO_XIP_EARLY_STAGES),y)
xip: Do not pass --xip for early stages if CAR supports code execution On modern x86 platforms like apollolake, pre-RAM stages verstage and romstage run within the cache-as-ram region. Thus, we do not need to pass in the --xip parameter to cbfstool while adding these stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is default false for all x86 platforms. Apollolake selects this option since it supports code execution with CAR. Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14623 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-05-05 08:25:16 +02:00
$(CONFIG_CBFS_PREFIX)/romstage-options := -S ".car.data"
x86: Add .data section support for pre-memory stages x86 pre-memory stages do not support the `.data` section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of `.data` section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage for Raptor Lake has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some `.data` symbols in the `_bss` region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Other platforms do not have that limitation. Hence, resolving it would help to align code and reduce compilation based restriction (cf. the use of `ENV_HAS_DATA_SECTION` compilation flag in various places of coreboot code). We identified three cases to consider: 1. eXecute-In-Place pre-memory stages - code is in SPINOR - data is also stored in SPINOR but must be linked in Cache-As-RAM and copied there at runtime 2. `bootblock` stage is a bit different as it uses Cache-As-Ram but the memory mapping and its entry code different 3. pre-memory stages loaded in and executed from Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`). eXecute-In-Place pre-memory stages (#1) require the creation of a new ELF segment as the code segment Virtual Memory Address and Load Memory Address are identical but the data needs to be linked in cache-As-RAM (VMA) but to be stored right after the code (LMA). Here is the output `readelf --segments` on a `romstage.debug` ELF binary. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20 LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4 Section to Segment mapping: Segment Sections... 00 .text 01 .data Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they are totally different for the Segment 1 holding the `.data` section. Since we need the data section `VirtAddr` to be in the Cache-As-Ram and its `PhysAddr` right after the `.text` section, the use of a new segment is mandatory. `bootblock` (#2) also uses this new segment to store the data right after the code and load it to Cache-As-RAM at runtime. However, the code involved is different. Not eXecute-In-Place pre-memory stages (#3) do not really need any special work other than enabling a data section as the code and data VMA / LMA translation vector is the same. TEST=#1 and #2 verified on rex and qemu 32 and 64 bits: - The `bootblock.debug`, `romstage.debug` and `verstage.debug` all have data stored at the end of the `.text` section and code to copy the data content to the Cache-As-RAM. - The CBFS stages included in the final image has not improperly relocated any of the `.data` section symbol. - Test purposes global data symbols we added in bootblock, romstage and verstage are properly accessible at runtime #3: for "Intel Apollolake DDR3 RVP1" board, we verified that the generated romstage ELF includes a .data section similarly to a regular memory enabled stage. Change-Id: I030407fcc72776e59def476daa5b86ad0495debe Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-08-31 00:42:09 +02:00
else
$(CONFIG_CBFS_PREFIX)/romstage-options := -S ".car.data,.data"
endif
xip: Do not pass --xip for early stages if CAR supports code execution On modern x86 platforms like apollolake, pre-RAM stages verstage and romstage run within the cache-as-ram region. Thus, we do not need to pass in the --xip parameter to cbfstool while adding these stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is default false for all x86 platforms. Apollolake selects this option since it supports code execution with CAR. Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14623 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-05-05 08:25:16 +02:00
# If CAR does not support execution of code, romstage on x86 is expected to be
# xip.
ifneq ($(CONFIG_NO_XIP_EARLY_STAGES),y)
$(CONFIG_CBFS_PREFIX)/romstage-options += --xip
arch/x86: Remove NO_FIXED_XIP_ROM_SIZE The variable SETUP_XIP_CACHE provides us a working alternative. Change-Id: I6e3befedbbc7967b71409640dc81a0c2a9b3e511 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41821 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-25 07:52:07 +02:00
# For efficient MTRR utilisation use natural alignment for romstage.
ifeq ($(CONFIG_SETUP_XIP_CACHE),y)
arch/x86: Remove XIP_ROM_SIZE When adding XIP stages on x86, the -P parameter was used to pass a page size that covers the entire file to add. The same can now be achieved with --pow2page and we no longer need to define a static Konfig for the purpose. TEST: Build asus/p2b and lenovo/x60 with "--pow2page -v -v" and inspect the generated make.log files. The effective pagesize is reduced from 64kB to 16kB for asus/p2b giving more freedom for the stage placement inside CBFS. Pagesize remained at 64kB for lenovo/x60. Change-Id: I5891fa2c2bb2d44077f745619162b143d083a6d1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41820 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Keith Hui <buurin@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-25 07:52:07 +02:00
$(CONFIG_CBFS_PREFIX)/romstage-options += --pow2page
arch/x86: Remove NO_FIXED_XIP_ROM_SIZE The variable SETUP_XIP_CACHE provides us a working alternative. Change-Id: I6e3befedbbc7967b71409640dc81a0c2a9b3e511 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41821 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-25 07:52:07 +02:00
endif # CONFIG_SETUP_XIP_CACHE
xip: Do not pass --xip for early stages if CAR supports code execution On modern x86 platforms like apollolake, pre-RAM stages verstage and romstage run within the cache-as-ram region. Thus, we do not need to pass in the --xip parameter to cbfstool while adding these stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is default false for all x86 platforms. Apollolake selects this option since it supports code execution with CAR. Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14623 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-05-05 08:25:16 +02:00
endif # CONFIG_NO_XIP_EARLY_STAGES
endif # CONFIG_ARCH_ROMSTAGE_X86_32 / CONFIG_ARCH_ROMSTAGE_X86_64
build: Mark bootblock files on x86 as IBB * Add cbfsoption --ibb to mark files as IBB * Will be used by "Legacy FIT TXT" boot Change-Id: I83313f035e7fb7e1eb484b323862522e28cb73d4 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31497 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2019-02-19 10:57:16 +01:00
ifeq ($(CONFIG_VBOOT_STARTS_IN_ROMSTAGE),y)
$(CONFIG_CBFS_PREFIX)/romstage-options += $(TXTIBB)
endif
Allow to build romstage sources inside the bootblock Having a separate romstage is only desirable: - with advanced setups like vboot or normal/fallback - boot medium is slow at startup (some ARM SOCs) - bootblock is limited in size (Intel APL 32K) When this is not the case there is no need for the extra complexity that romstage brings. Including the romstage sources inside the bootblock substantially reduces the total code footprint. Often the resulting code is 10-20k smaller. This is controlled via a Kconfig option. TESTED: works on qemu x86, arm and aarch64 with and without VBOOT. Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-05-29 08:10:49 +02:00
else # CONFIG_SEPARATE_ROMSTAGE
postinclude-hooks += $$(eval bootblock-srcs += $$(romstage-srcs))
endif
build system: Add more files through cbfs-files instead of manual rules verstage, romstage, and payload can be added through infrastructure now. Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12549 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-26 16:39:23 +01:00
Rampayload: Able to build coreboot without ramstage This patch removes all possible dependencies in order to build platform with CONFIG_RAMPAYLOAD enable(without ramstage). A. Create coreboot separate stage kconfigs This patch creates seperate stage configs as below 1. HAVE_BOOTBLOCK 2. HAVE_VERSTAGE 3. HAVE_ROMSTAGE 4. HAVE_POSTCAR 5. HAVE_RAMSTAGE B. Also ensures below kconfigs are aligned with correct stage configs 1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if CONFIG_HAVE_RAMSTAGE is selected. 2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set 3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE || CONFIG_HAVE_ROMSTAGE is selected. C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE On x86 platform: Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32 Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_ This patch fixes Case 2 usecase where platform doesn't select CONFIG_HAVE_RAMSTAGE. Also add option to create sipi_vector.manual based on $(TARGET_STAGE) variable. $(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE $(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-06-08 08:59:02 +02:00
cbfs-files-$(CONFIG_HAVE_RAMSTAGE) += $(CONFIG_CBFS_PREFIX)/ramstage
$(CONFIG_CBFS_PREFIX)/ramstage-file := $(RAMSTAGE)
build system: Move manual cbfstool add* invocations to cbfs-files Use cbfs-files-y to deal with some of the manually added cbfs files, providing more structure to that part of the build. Change-Id: Iee1b8fec81dfa5e5f0e55637a62e5f69bd0257ad Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12538 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:21:53 +01:00
$(CONFIG_CBFS_PREFIX)/ramstage-type := stage
$(CONFIG_CBFS_PREFIX)/ramstage-compression := $(CBFS_COMPRESS_FLAG)
src/lib/prog_loaders: Add preload_ramstage This will enable preloading ramstage. By preloading the file into cbfs_cache we reduce boot time. BUG=b:179699789 TEST=Boot guybrush to OS and see 12ms reduction in boot time. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ibe12de806449da25bc0033b02fcb97c3384eddc1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58982 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-11-05 17:29:24 +01:00
# The AMD LPC SPI DMA controller requires source files to be 64 byte aligned.
ifeq ($(CONFIG_SOC_AMD_COMMON_BLOCK_LPC_SPI_DMA),y)
$(CONFIG_CBFS_PREFIX)/ramstage-align := 64
endif
build system: Move manual cbfstool add* invocations to cbfs-files Use cbfs-files-y to deal with some of the manually added cbfs files, providing more structure to that part of the build. Change-Id: Iee1b8fec81dfa5e5f0e55637a62e5f69bd0257ad Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12538 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:21:53 +01:00
cbfs-files-$(CONFIG_HAVE_REFCODE_BLOB) += $(CONFIG_CBFS_PREFIX)/refcode
$(CONFIG_CBFS_PREFIX)/refcode-file := $(REFCODE_BLOB)
$(CONFIG_CBFS_PREFIX)/refcode-type := stage
$(CONFIG_CBFS_PREFIX)/refcode-compression := $(CBFS_COMPRESS_FLAG)
cbfs-files-$(CONFIG_SEABIOS_VGA_COREBOOT) += vgaroms/seavgabios.bin
vgaroms/seavgabios.bin-file := $(CONFIG_PAYLOAD_VGABIOS_FILE)
vgaroms/seavgabios.bin-type := raw
build system: move defconfig creation into a cbfs-files filter That allows this special case to become a normal cbfs-files instance, too. Change-Id: I896ffebe4cec64c9c11605b4f09c7790e5419928 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12539 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:47:56 +01:00
cbfs-files-$(CONFIG_INCLUDE_CONFIG_FILE) += config
build: List all Kconfigs in CBFS `config` file, compress it The coreboot build system automatically adds a `config` file to CBFS that lists the exact Kconfig configuration that this image was built with. This is useful to reproduce a build after the fact or to check whether support for a specific feature is enabled in the image. However, the file is currently generated using the `savedefconfig` command to Kconfig, which generates the minimal .config file that is needed to produce the required config in a coreboot build. This is fine for reproduction, but bad when you want to check if a certain config was enabled, since many configs get enabled by default or pulled in through another config's `select` statement and thus don't show up in the defconfig. This patch tries to fix that second use case by instead including the full .config instead. In order to save some space, we can remove all comments (e.g. `# CONFIG_XXX is not set`) from the file, which still makes it easy to test for a specific config (if it's in the file you can extract the right value, if not you can assume it was set to `n`). We can also LZMA compress it since this file is never read by firmware itself and only intended for later re-extraction via cbfstool, which always has LZMA support included. On a sample Trogdor device the existing (uncompressed) `config` file takes up 519 bytes in CBFS, whereas the new (compressed) file after this patch will take up 1832 bytes -- still a small amount that should hopefully not break the bank for anyone. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I5259ec6f932cdc5780b8843f46dd476da9d19728 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-11-17 02:48:46 +01:00
config-file := $(DOTCONFIG):config
build system: move defconfig creation into a cbfs-files filter That allows this special case to become a normal cbfs-files instance, too. Change-Id: I896ffebe4cec64c9c11605b4f09c7790e5419928 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12539 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:47:56 +01:00
config-type := raw
build: List all Kconfigs in CBFS `config` file, compress it The coreboot build system automatically adds a `config` file to CBFS that lists the exact Kconfig configuration that this image was built with. This is useful to reproduce a build after the fact or to check whether support for a specific feature is enabled in the image. However, the file is currently generated using the `savedefconfig` command to Kconfig, which generates the minimal .config file that is needed to produce the required config in a coreboot build. This is fine for reproduction, but bad when you want to check if a certain config was enabled, since many configs get enabled by default or pulled in through another config's `select` statement and thus don't show up in the defconfig. This patch tries to fix that second use case by instead including the full .config instead. In order to save some space, we can remove all comments (e.g. `# CONFIG_XXX is not set`) from the file, which still makes it easy to test for a specific config (if it's in the file you can extract the right value, if not you can assume it was set to `n`). We can also LZMA compress it since this file is never read by firmware itself and only intended for later re-extraction via cbfstool, which always has LZMA support included. On a sample Trogdor device the existing (uncompressed) `config` file takes up 519 bytes in CBFS, whereas the new (compressed) file after this patch will take up 1832 bytes -- still a small amount that should hopefully not break the bank for anyone. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I5259ec6f932cdc5780b8843f46dd476da9d19728 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Jakub Czapiga <jacz@semihalf.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-11-17 02:48:46 +01:00
config-compression := LZMA
build system: move defconfig creation into a cbfs-files filter That allows this special case to become a normal cbfs-files instance, too. Change-Id: I896ffebe4cec64c9c11605b4f09c7790e5419928 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12539 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-11-25 18:47:56 +01:00
cbfs-files-$(CONFIG_INCLUDE_CONFIG_FILE) += revision
revision-file := $(obj)/build.h
revision-type := raw
arch/arm: Replace .id section with build_info in CBFS For arch/arm[64], the offsets to board identification strings and CONFIG_ROM_SIZE inside .id were never really used; it was only a convenience to have the strings appear near the start of image. Add the same strings in an uncompressed file in CBFS. Change-Id: I35d3312336e9c66d657d2ca619cf30fd79e18fd4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/47602 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-11-15 08:07:36 +01:00
cbfs-files-y += build_info
build_info-file := $(obj)/build_info
build_info-type := raw
bootsplash: Add ImageMagick voodoo The JPEG decoder, that was added many years ago to display a boot- splash in coreboot, has a few quirks. People used to do some voodoo with GIMP to convert images to the right format, but we can also achieve the same with ImageMagick's `convert`. The currently known constraints are: * The framebuffer's color format is ignored, * only YCC 4:2:0 color sampling is supported, and * width and height have to be a multiple of 16 pixels. Beside that, we can only display the bootsplash if it completely fits into the framebuffer. As the latter's size is often decided at runtime, we can't do much more than offering an option to set a specific size. Change-Id: I564e0d89fb46503ff4c11e095726616700009968 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76564 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-07-16 19:24:13 +02:00
ifeq ($(CONFIG_BOOTSPLASH_CONVERT),y)
ifeq ($(shell command -v convert),)
$(error CONFIG_BOOTSPLASH_CONVERT requires the convert program (part of ImageMagick))
endif
cbfs-files-$(CONFIG_BOOTSPLASH_IMAGE) += bootsplash.jpg
bootsplash.jpg-file := $(call strip_quotes,$(CONFIG_BOOTSPLASH_FILE)):jpg420
bootsplash.jpg-type := bootsplash
else
splash: Put the suffix of splash file to CBFS name The previous code harded the suffix of splash file as "jpg". Actually, SeaBIOS supports both jpg and bmp. Change-Id: I06c4b14aae7f75be3406652a94612b5f30ce91c2 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/14932 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-05-21 04:20:58 +02:00
BOOTSPLASH_SUFFIX=$(suffix $(call strip_quotes,$(CONFIG_BOOTSPLASH_FILE)))
cbfs-files-$(CONFIG_BOOTSPLASH_IMAGE) += bootsplash$(BOOTSPLASH_SUFFIX)
bootsplash$(BOOTSPLASH_SUFFIX)-file := $(call strip_quotes,$(CONFIG_BOOTSPLASH_FILE))
bootsplash$(BOOTSPLASH_SUFFIX)-type := bootsplash
bootsplash: Add ImageMagick voodoo The JPEG decoder, that was added many years ago to display a boot- splash in coreboot, has a few quirks. People used to do some voodoo with GIMP to convert images to the right format, but we can also achieve the same with ImageMagick's `convert`. The currently known constraints are: * The framebuffer's color format is ignored, * only YCC 4:2:0 color sampling is supported, and * width and height have to be a multiple of 16 pixels. Beside that, we can only display the bootsplash if it completely fits into the framebuffer. As the latter's size is often decided at runtime, we can't do much more than offering an option to set a specific size. Change-Id: I564e0d89fb46503ff4c11e095726616700009968 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76564 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-07-16 19:24:13 +02:00
endif
Move redundant Makefile rules from arch to top level. Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others from arch level Makefile.inc to top level Makefile.inc. Also, organize Makefile.inc at arch level into per-stage rules and variables. Change-Id: I7dc5b2d31c959b55bb92d9c7811427c4dada1db5 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5571 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-23 01:33:22 +02:00
Makefile: Add build-time overlap check for programs loaded after coreboot On non-x86 platforms, coreboot uses the memlayout.ld mechanism to statically allocate the different memory regions it needs and guarantees at build time that there are no dangerous overlaps between them. At the end of its (ramstage) execution, however, it usually loads a payload (and possibly other platform-specific components) that is not integrated into the coreboot build system and therefore cannot provide the same overlap guarantees through memlayout.ld. This creates a dangerous memory hazard where a new component could be loaded over memory areas that are still in use by the code-loading ramstage and lead to arbitrary memory corruption bugs. This patch fills this gap in our build-time correctness guarantees by adding the necessary checks as a new intermediate Makefile target on route to assembling the final image. It will parse the memory footprint information of the payload (and other platform-specific post-ramstage components) from CBFS and compare it to a list of memory areas known to be still in use during late ramstage, generating a build failure in case of a possible hazard. BUG=chrome-os-partner:48008 TEST=Built Oak while moving critical regions in the way of BL31 or the payload, observing the desired build-time errors. Built Nyan, Jerry and Falco without issues for good measure. Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13949 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-03-08 02:55:43 +01:00
# Ensure that no payload segment overlaps with memory regions used by ramstage
# (not for x86 since it can relocate itself in that case)
ifneq ($(CONFIG_ARCH_X86),y)
check-ramstage-overlap-regions := ramstage
check-ramstage-overlap-files :=
ifneq ($(CONFIG_PAYLOAD_NONE),y)
check-ramstage-overlap-files += $(CONFIG_CBFS_PREFIX)/payload
endif
# will output one or more lines of "<load address in hex> <memlen in decimal>"
cbfs-get-segments-cmd = $(CBFSTOOL) $(obj)/coreboot.pre print -v | sed -n \
'\%$(1)%,\%^[^ ]\{4\}%s% .*load: \(0x[0-9a-fA-F]*\),.*length: [0-9]*/\([0-9]*\).*%\1 \2%p'
ramstage-symbol-addr-cmd = $(OBJDUMP_ramstage) -t $(objcbfs)/ramstage.elf | \
build system: Deduplicate symbols in objdump New binutils versions automatically resolve references to debug symbol files and parse their content as well when objdump'ing data. This leads to multiple mentions of symbols, so deduplicate references. Change-Id: I5d597399c515904313ba36d7aab9178bc0dade14 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56524 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2021-07-22 16:57:26 +02:00
sed -n '/ $(1)$$/s/^\([0-9a-fA-F]*\) .*/0x\1/p' | \
uniq
Makefile: Add build-time overlap check for programs loaded after coreboot On non-x86 platforms, coreboot uses the memlayout.ld mechanism to statically allocate the different memory regions it needs and guarantees at build time that there are no dangerous overlaps between them. At the end of its (ramstage) execution, however, it usually loads a payload (and possibly other platform-specific components) that is not integrated into the coreboot build system and therefore cannot provide the same overlap guarantees through memlayout.ld. This creates a dangerous memory hazard where a new component could be loaded over memory areas that are still in use by the code-loading ramstage and lead to arbitrary memory corruption bugs. This patch fills this gap in our build-time correctness guarantees by adding the necessary checks as a new intermediate Makefile target on route to assembling the final image. It will parse the memory footprint information of the payload (and other platform-specific post-ramstage components) from CBFS and compare it to a list of memory areas known to be still in use during late ramstage, generating a build failure in case of a possible hazard. BUG=chrome-os-partner:48008 TEST=Built Oak while moving critical regions in the way of BL31 or the payload, observing the desired build-time errors. Built Nyan, Jerry and Falco without issues for good measure. Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13949 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-03-08 02:55:43 +01:00
build system: Always add coreboot.pre dependency to intermediates They all operate on that file, so just add it globally. Change-Id: I953975a4078d0f4a5ec0b6248f0dcedada69afb2 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49380 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2021-01-13 09:15:07 +01:00
$(call add_intermediate, check-ramstage-overlaps)
Makefile: Add build-time overlap check for programs loaded after coreboot On non-x86 platforms, coreboot uses the memlayout.ld mechanism to statically allocate the different memory regions it needs and guarantees at build time that there are no dangerous overlaps between them. At the end of its (ramstage) execution, however, it usually loads a payload (and possibly other platform-specific components) that is not integrated into the coreboot build system and therefore cannot provide the same overlap guarantees through memlayout.ld. This creates a dangerous memory hazard where a new component could be loaded over memory areas that are still in use by the code-loading ramstage and lead to arbitrary memory corruption bugs. This patch fills this gap in our build-time correctness guarantees by adding the necessary checks as a new intermediate Makefile target on route to assembling the final image. It will parse the memory footprint information of the payload (and other platform-specific post-ramstage components) from CBFS and compare it to a list of memory areas known to be still in use during late ramstage, generating a build failure in case of a possible hazard. BUG=chrome-os-partner:48008 TEST=Built Oak while moving critical regions in the way of BL31 or the payload, observing the desired build-time errors. Built Nyan, Jerry and Falco without issues for good measure. Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13949 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-03-08 02:55:43 +01:00
programs=$$($(foreach file,$(check-ramstage-overlap-files), \
$(call cbfs-get-segments-cmd,$(file)) ; )) ; \
regions=$$($(foreach region,$(check-ramstage-overlap-regions), \
echo $(region) ; \
$(call ramstage-symbol-addr-cmd,_$(region)) ; \
$(call ramstage-symbol-addr-cmd,_e$(region)) ; )) ; \
pstart= ; pend= ; \
for x in $$programs; do \
if [ -z $$pstart ]; then pstart=$$(($$x)) ; continue ; fi ; \
pend=$$(($$pstart + $$x)) ; \
rname= ; rstart= ; rend= ; \
for y in $$regions ; do \
if [ -z $$rname ]; then rname=$$y ; continue ; fi ; \
if [ -z $$rstart ]; then rstart=$$(($$y)) ; continue ; fi ; \
rend=$$(($$y)) ; \
if [ $$pstart -lt $$rend -a $$rstart -lt $$pend ]; then \
echo "ERROR: Ramstage region _$$rname overlapped by:" \
$(check-ramstage-overlap-files) ; \
exit 1 ; \
fi ; \
rname= ; rstart= ; rend= ; \
done ; \
pstart= ; pend= ; \
done
endif