src/: Replace GPL boilerplate with SPDX headers
Used commands:
perl -i -p0e 's|\/\*[\s*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-only */|' $(cat filelist)
perl -i -p0e 's|\/\*[\s*]*.*is[\s*]*free[\s*]*software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*either[\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License,[\s*]*or[\s*]*.at[\s*]*your[\s*]*option.[\s*]*any[\s*]*later[\s*]*version.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-or-later */|' $(cat filelist)
perl -i -p0e 's|\/\*[\s*]*.*is[\s*#]*free[\s*#]*software[;:,][\s*#]*you[\s*#]*can[\s*#]*redistribute[\s*#]*it[\s*#]*and/or[\s*#]*modify[\s*#]*it[\s*#]*under[\s*#]*the[\s*#]*terms[\s*#]*of[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*as[\s*#]*published[\s*#]*by[\s*#]*the[\s*#]*Free[\s*#]*Software[\s*#]*Foundation[;:,][\s*#]*either[\s*#]*version[\s*#]*3[\s*#]*of[\s*#]*the[\s*#]*License[;:,][\s*#]*or[\s*#]*.at[\s*#]*your[\s*#]*option.[\s*#]*any[\s*#]*later[\s*#]*version.[\s*#]*This[\s*#]*program[\s*#]*is[\s*#]*distributed[\s*#]*in[\s*#]*the[\s*#]*hope[\s*#]*that[\s*#]*it[\s*#]*will[\s*#]*be[\s*#]*useful[;:,][\s*#]*but[\s*#]*WITHOUT[\s*#]*ANY[\s*#]*WARRANTY[;:,][\s*#]*without[\s*#]*even[\s*#]*the[\s*#]*implied[\s*#]*warranty[\s*#]*of[\s*#]*MERCHANTABILITY[\s*#]*or[\s*#]*FITNESS[\s*#]*FOR[\s*#]*A[\s*#]*PARTICULAR[\s*#]*PURPOSE.[\s*#]*See[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*for[\s*#]*more[\s*#]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-3.0-or-later */|' $(cat filelist)
perl -i -p0e 's|(\#\#*)[\w]*.*is free software[:;][\#\s]*you[\#\s]*can[\#\s]*redistribute[\#\s]*it[\#\s]*and\/or[\#\s]*modify[\#\s]*it[\s\#]*under[\s \#]*the[\s\#]*terms[\s\#]*of[\s\#]*the[\s\#]*GNU[\s\#]*General[\s\#]*Public[\s\#]*License[\s\#]*as[\s\#]*published[\s\#]*by[\s\#]*the[\s\#]*Free[\s\#]*Software[\s\#]*Foundation[;,][\s\#]*version[\s\#]*2[\s\#]*of[\s\#]*the[\s\#]*License.*[\s\#]*This[\s\#]*program[\s\#]*is[\s\#]*distributed[\s\#]*in[\s\#]*the[\s\#]*hope[\s\#]*that[\s\#]*it[\s\#]*will[\#\s]*be[\#\s]*useful,[\#\s]*but[\#\s]*WITHOUT[\#\s]*ANY[\#\s]*WARRANTY;[\#\s]*without[\#\s]*even[\#\s]*the[\#\s]*implied[\#\s]*warranty[\#\s]*of[\#\s]*MERCHANTABILITY[\#\s]*or[\#\s]*FITNESS[\#\s]*FOR[\#\s]*A[\#\s]*PARTICULAR[\#\s]*PURPOSE.[\#\s]*See[\#\s]*the[\#\s]*GNU[\#\s]*General[\#\s]*Public[\#\s]*License[\#\s]*for[\#\s]*more[\#\s]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist)
perl -i -p0e 's|(\#\#*)[\w*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist)
Change-Id: Ia01908544f4b92a2e06ea621eca548e582728280
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41178
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-08 22:50:46 +02:00
|
|
|
## SPDX-License-Identifier: GPL-2.0-only
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2012-04-12 22:00:03 +02:00
|
|
|
mainmenu "coreboot configuration"
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2009-10-05 15:55:28 +02:00
|
|
|
menu "General setup"
|
|
|
|
|
|
2017-04-03 16:38:20 +02:00
|
|
|
config COREBOOT_BUILD
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
2009-10-05 15:55:28 +02:00
|
|
|
config LOCALVERSION
|
2009-10-07 18:15:40 +02:00
|
|
|
string "Local version string"
|
2009-10-05 15:55:28 +02:00
|
|
|
help
|
|
|
|
|
Append an extra string to the end of the coreboot version.
|
|
|
|
|
|
2009-10-07 18:15:40 +02:00
|
|
|
This can be useful if, for instance, you want to append the
|
|
|
|
|
respective board's hostname or some other identifying string to
|
|
|
|
|
the coreboot version number, so that you can easily distinguish
|
|
|
|
|
boot logs of different boards from each other.
|
|
|
|
|
|
2019-06-08 11:28:52 +02:00
|
|
|
config CONFIGURABLE_CBFS_PREFIX
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Select this to prompt to use to configure the prefix for cbfs files.
|
|
|
|
|
|
2019-10-06 13:34:20 +02:00
|
|
|
choice
|
|
|
|
|
prompt "CBFS prefix to use"
|
|
|
|
|
depends on CONFIGURABLE_CBFS_PREFIX
|
|
|
|
|
default CBFS_PREFIX_FALLBACK
|
|
|
|
|
|
|
|
|
|
config CBFS_PREFIX_FALLBACK
|
|
|
|
|
bool "fallback"
|
|
|
|
|
|
|
|
|
|
config CBFS_PREFIX_NORMAL
|
|
|
|
|
bool "normal"
|
|
|
|
|
|
|
|
|
|
config CBFS_PREFIX_DIY
|
|
|
|
|
bool "Define your own cbfs prefix"
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2010-02-09 20:35:16 +01:00
|
|
|
config CBFS_PREFIX
|
2019-10-06 13:34:20 +02:00
|
|
|
string "CBFS prefix to use" if CBFS_PREFIX_DIY
|
|
|
|
|
default "fallback" if !CONFIGURABLE_CBFS_PREFIX || CBFS_PREFIX_FALLBACK
|
|
|
|
|
default "normal" if CBFS_PREFIX_NORMAL
|
2010-02-09 20:35:16 +01:00
|
|
|
help
|
|
|
|
|
Select the prefix to all files put into the image. It's "fallback"
|
|
|
|
|
by default, "normal" is a common alternative.
|
|
|
|
|
|
2010-03-16 02:17:19 +01:00
|
|
|
choice
|
2012-04-12 22:00:03 +02:00
|
|
|
prompt "Compiler to use"
|
2010-03-16 02:17:19 +01:00
|
|
|
default COMPILER_GCC
|
|
|
|
|
help
|
|
|
|
|
This option allows you to select the compiler used for building
|
|
|
|
|
coreboot.
|
2016-01-19 20:01:09 +01:00
|
|
|
You must build the coreboot crosscompiler for the board that you
|
|
|
|
|
have selected.
|
|
|
|
|
|
|
|
|
|
To build all the GCC crosscompilers (takes a LONG time), run:
|
|
|
|
|
make crossgcc
|
|
|
|
|
|
|
|
|
|
For help on individual architectures, run the command:
|
|
|
|
|
make help_toolchain
|
2010-03-16 02:17:19 +01:00
|
|
|
|
|
|
|
|
config COMPILER_GCC
|
|
|
|
|
bool "GCC"
|
2012-04-12 22:00:03 +02:00
|
|
|
help
|
|
|
|
|
Use the GNU Compiler Collection (GCC) to build coreboot.
|
|
|
|
|
|
|
|
|
|
For details see http://gcc.gnu.org.
|
|
|
|
|
|
2010-03-16 02:17:19 +01:00
|
|
|
config COMPILER_LLVM_CLANG
|
2022-03-24 10:38:54 +01:00
|
|
|
bool "LLVM/clang"
|
|
|
|
|
depends on ALLOW_EXPERIMENTAL_CLANG || ARCH_SUPPORTS_CLANG
|
2012-04-12 22:00:03 +02:00
|
|
|
help
|
2016-01-19 20:01:09 +01:00
|
|
|
Use LLVM/clang to build coreboot. To use this, you must build the
|
|
|
|
|
coreboot version of the clang compiler. Run the command
|
|
|
|
|
make clang
|
2022-03-24 10:38:54 +01:00
|
|
|
Note that Clang is not currently working on all architectures.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
|
|
|
|
For details see http://clang.llvm.org.
|
|
|
|
|
|
2010-03-16 02:17:19 +01:00
|
|
|
endchoice
|
|
|
|
|
|
2022-03-24 10:38:54 +01:00
|
|
|
config ARCH_SUPPORTS_CLANG
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Opt-in flag for architectures that generally work well with CLANG.
|
|
|
|
|
By default the option would be hidden.
|
|
|
|
|
|
|
|
|
|
config ALLOW_EXPERIMENTAL_CLANG
|
|
|
|
|
bool "Allow experimental LLVM/Clang"
|
|
|
|
|
depends on !ARCH_SUPPORTS_CLANG
|
|
|
|
|
help
|
|
|
|
|
On some architectures CLANG does not work that well.
|
|
|
|
|
Use this only to try to get CLANG working.
|
|
|
|
|
|
2013-12-29 18:45:23 +01:00
|
|
|
config ANY_TOOLCHAIN
|
|
|
|
|
bool "Allow building with any toolchain"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Many toolchains break when building coreboot since it uses quite
|
2022-05-28 20:34:44 +02:00
|
|
|
unusual linker features. Unless developers explicitly request it,
|
2013-12-29 18:45:23 +01:00
|
|
|
we'll have to assume that they use their distro compiler by mistake.
|
|
|
|
|
Make sure that using patched compilers is a conscious decision.
|
|
|
|
|
|
2010-03-25 22:45:25 +01:00
|
|
|
config CCACHE
|
2012-04-12 22:00:03 +02:00
|
|
|
bool "Use ccache to speed up (re)compilation"
|
2010-03-25 22:45:25 +01:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enables the use of ccache for faster builds.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
|
|
|
|
Requires the ccache utility in your system $PATH.
|
|
|
|
|
|
|
|
|
|
For details see https://ccache.samba.org.
|
2010-03-25 22:45:25 +01:00
|
|
|
|
2022-09-28 02:13:48 +02:00
|
|
|
config IWYU
|
|
|
|
|
bool "Test platform with include-what-you-use"
|
|
|
|
|
help
|
|
|
|
|
This runs each source file through the include-what-you-use tool
|
|
|
|
|
to check the header includes.
|
|
|
|
|
|
2015-02-26 20:47:19 +01:00
|
|
|
config FMD_GENPARSER
|
|
|
|
|
bool "Generate flashmap descriptor parser using flex and bison"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable this option if you are working on the flashmap descriptor
|
|
|
|
|
parser and made changes to fmd_scanner.l or fmd_parser.y.
|
|
|
|
|
|
|
|
|
|
Otherwise, say N to use the provided pregenerated scanner/parser.
|
|
|
|
|
|
2017-04-10 03:12:42 +02:00
|
|
|
config UTIL_GENPARSER
|
2021-09-06 16:59:56 +02:00
|
|
|
bool "Generate parsers for bincfg, sconfig and kconfig locally"
|
2010-08-09 15:28:18 +02:00
|
|
|
default n
|
|
|
|
|
help
|
2012-04-12 22:00:03 +02:00
|
|
|
Enable this option if you are working on the sconfig device tree
|
2018-01-10 14:35:55 +01:00
|
|
|
parser or bincfg and made changes to the .l or .y files.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
2015-02-26 20:47:19 +01:00
|
|
|
Otherwise, say N to use the provided pregenerated scanner/parser.
|
2010-08-09 15:28:18 +02:00
|
|
|
|
2021-05-20 15:30:59 +02:00
|
|
|
choice
|
|
|
|
|
prompt "Option backend to use"
|
2021-05-20 16:43:08 +02:00
|
|
|
default USE_MAINBOARD_SPECIFIC_OPTION_BACKEND if HAVE_MAINBOARD_SPECIFIC_OPTION_BACKEND
|
2021-05-20 15:30:59 +02:00
|
|
|
default USE_OPTION_TABLE if NVRAMCUI_SECONDARY_PAYLOAD
|
|
|
|
|
|
|
|
|
|
config OPTION_BACKEND_NONE
|
|
|
|
|
bool "None"
|
|
|
|
|
|
2010-05-19 20:41:15 +02:00
|
|
|
config USE_OPTION_TABLE
|
|
|
|
|
bool "Use CMOS for configuration values"
|
2010-07-06 23:05:04 +02:00
|
|
|
depends on HAVE_OPTION_TABLE
|
2010-05-19 20:41:15 +02:00
|
|
|
help
|
|
|
|
|
Enable this option if coreboot shall read options from the "CMOS"
|
2012-04-12 22:00:03 +02:00
|
|
|
NVRAM instead of using hard-coded values.
|
2010-05-19 20:41:15 +02:00
|
|
|
|
2021-05-20 16:43:08 +02:00
|
|
|
config USE_MAINBOARD_SPECIFIC_OPTION_BACKEND
|
|
|
|
|
bool "Use mainboard-specific option backend"
|
|
|
|
|
depends on HAVE_MAINBOARD_SPECIFIC_OPTION_BACKEND
|
|
|
|
|
help
|
|
|
|
|
Use a mainboard-specific mechanism to access runtime-configurable
|
|
|
|
|
options.
|
|
|
|
|
|
2021-05-20 15:30:59 +02:00
|
|
|
endchoice
|
|
|
|
|
|
2015-02-14 23:15:31 +01:00
|
|
|
config STATIC_OPTION_TABLE
|
|
|
|
|
bool "Load default configuration values into CMOS on each boot"
|
|
|
|
|
depends on USE_OPTION_TABLE
|
|
|
|
|
help
|
|
|
|
|
Enable this option to reset "CMOS" NVRAM values to default on
|
|
|
|
|
every boot. Use this if you want the NVRAM configuration to
|
|
|
|
|
never be modified from its default values.
|
|
|
|
|
|
2023-01-05 01:26:21 +01:00
|
|
|
config MB_COMPRESS_RAMSTAGE_LZ4
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Select this in a mainboard to use LZ4 compression by default
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
prompt "Ramstage compression"
|
|
|
|
|
depends on HAVE_RAMSTAGE && !UNCOMPRESSED_RAMSTAGE
|
|
|
|
|
default COMPRESS_RAMSTAGE_LZ4 if MB_COMPRESS_RAMSTAGE_LZ4
|
|
|
|
|
default COMPRESS_RAMSTAGE_LZMA
|
|
|
|
|
|
|
|
|
|
config COMPRESS_RAMSTAGE_LZMA
|
2011-05-02 21:53:04 +02:00
|
|
|
bool "Compress ramstage with LZMA"
|
|
|
|
|
help
|
2023-01-05 01:26:21 +01:00
|
|
|
Compress ramstage with LZMA to save memory in the flash image.
|
|
|
|
|
|
|
|
|
|
config COMPRESS_RAMSTAGE_LZ4
|
|
|
|
|
bool "Compress ramstage with LZ4"
|
|
|
|
|
help
|
|
|
|
|
LZ4 doesn't give as good compression as LZMA, but decompresses much
|
|
|
|
|
faster. For large binaries such as ramstage, it's typically best to
|
|
|
|
|
use LZMA, but there can be cases where the faster decompression of
|
|
|
|
|
LZ4 can lead to a faster boot time. Testing on each individual board
|
|
|
|
|
is typically going to be needed due to the large number of factors
|
|
|
|
|
that can influence the decision. Binary size, CPU speed, ROM read
|
|
|
|
|
speed, cache, and other factors all play a part.
|
|
|
|
|
|
|
|
|
|
If you're not sure, stick with LZMA.
|
|
|
|
|
|
|
|
|
|
endchoice
|
2011-05-02 21:53:04 +02:00
|
|
|
|
2015-09-29 22:51:35 +02:00
|
|
|
config COMPRESS_PRERAM_STAGES
|
|
|
|
|
bool "Compress romstage and verstage with LZ4"
|
2019-11-04 18:57:06 +01:00
|
|
|
depends on (HAVE_ROMSTAGE || HAVE_VERSTAGE) && NO_XIP_EARLY_STAGES
|
2016-12-15 23:05:37 +01:00
|
|
|
# Default value set at the end of the file
|
2015-09-29 22:51:35 +02:00
|
|
|
help
|
|
|
|
|
Compress romstage and (if it exists) verstage with LZ4 to save flash
|
|
|
|
|
space and speed up boot, since the time for reading the image from SPI
|
|
|
|
|
(and in the vboot case verifying it) is usually much greater than the
|
2019-11-04 18:57:06 +01:00
|
|
|
time spent decompressing. Doesn't work for XIP stages for obvious
|
|
|
|
|
reasons.
|
2015-09-29 22:51:35 +02:00
|
|
|
|
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
|
|
|
config COMPRESS_BOOTBLOCK
|
|
|
|
|
bool
|
2019-06-08 08:59:02 +02:00
|
|
|
depends on HAVE_BOOTBLOCK
|
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
|
|
|
help
|
|
|
|
|
This option can be used to compress the bootblock with LZ4 and attach
|
|
|
|
|
a small self-decompression stub to its front. This can drastically
|
|
|
|
|
reduce boot time on platforms where the bootblock is loaded over a
|
|
|
|
|
very slow connection and bootblock size trumps all other factors for
|
2018-09-29 17:42:52 +02:00
|
|
|
speed. Since using this option usually requires changes to the
|
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
|
|
|
SoC memlayout and possibly extra support code, it should not be
|
|
|
|
|
user-selectable. (There's no real point in offering this to the user
|
|
|
|
|
anyway... if it works and saves boot time, you would always want it.)
|
|
|
|
|
|
2011-06-19 03:03:28 +02:00
|
|
|
config INCLUDE_CONFIG_FILE
|
2012-04-12 22:00:03 +02:00
|
|
|
bool "Include the coreboot .config file into the ROM image"
|
2016-12-15 23:05:37 +01:00
|
|
|
# Default value set at the end of the file
|
2012-04-12 22:00:03 +02:00
|
|
|
help
|
|
|
|
|
Include the .config file that was used to compile coreboot
|
|
|
|
|
in the (CBFS) ROM image. This is useful if you want to know which
|
|
|
|
|
options were used to build a specific coreboot.rom image.
|
|
|
|
|
|
2014-07-22 18:00:56 +02:00
|
|
|
Saying Y here will increase the image size by 2-3KB.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
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
|
|
|
You can then use cbfstool to extract the config from a final image:
|
2012-04-12 22:00:03 +02:00
|
|
|
|
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
|
|
|
cbfstool coreboot.rom extract -n config -f <output file path>
|
2012-04-12 22:00:03 +02:00
|
|
|
|
|
|
|
|
Alternatively, you can also use cbfstool to print the image
|
|
|
|
|
contents (including the raw 'config' item we're looking for).
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
$ cbfstool coreboot.rom print
|
|
|
|
|
coreboot.rom: 4096 kB, bootblocksize 1008, romsize 4194304,
|
|
|
|
|
offset 0x0
|
|
|
|
|
Alignment: 64 bytes
|
2012-05-18 19:18:47 +02:00
|
|
|
|
2012-04-12 22:00:03 +02:00
|
|
|
Name Offset Type Size
|
2020-02-16 10:01:33 +01:00
|
|
|
cmos_layout.bin 0x0 CMOS layout 1159
|
2012-04-12 22:00:03 +02:00
|
|
|
fallback/romstage 0x4c0 stage 339756
|
2014-07-22 18:00:56 +02:00
|
|
|
fallback/ramstage 0x53440 stage 186664
|
2012-04-12 22:00:03 +02:00
|
|
|
fallback/payload 0x80dc0 payload 51526
|
|
|
|
|
config 0x8d740 raw 3324
|
|
|
|
|
(empty) 0x8e480 null 3610440
|
2011-06-19 03:03:28 +02:00
|
|
|
|
2011-09-21 23:46:43 +02:00
|
|
|
config COLLECT_TIMESTAMPS
|
|
|
|
|
bool "Create a table of timestamps collected during boot"
|
2015-10-11 11:57:44 +02:00
|
|
|
default y if ARCH_X86
|
2011-09-21 23:46:43 +02:00
|
|
|
help
|
2012-04-12 22:00:03 +02:00
|
|
|
Make coreboot create a table of timer-ID/timer-value pairs to
|
|
|
|
|
allow measuring time spent at different phases of the boot process.
|
|
|
|
|
|
2018-03-07 23:32:16 +01:00
|
|
|
config TIMESTAMPS_ON_CONSOLE
|
|
|
|
|
bool "Print the timestamp values on the console"
|
|
|
|
|
default n
|
|
|
|
|
depends on COLLECT_TIMESTAMPS
|
|
|
|
|
help
|
2020-01-09 07:41:46 +01:00
|
|
|
Print the timestamps to the debug console if enabled at level info.
|
2018-03-07 23:32:16 +01:00
|
|
|
|
2012-04-30 21:06:10 +02:00
|
|
|
config USE_BLOBS
|
|
|
|
|
bool "Allow use of binary-only repository"
|
2019-12-28 19:10:12 +01:00
|
|
|
default y
|
2012-04-30 21:06:10 +02:00
|
|
|
help
|
|
|
|
|
This draws in the blobs repository, which contains binary files that
|
|
|
|
|
might be required for some chipsets or boards.
|
|
|
|
|
This flag ensures that a "Free" option remains available for users.
|
|
|
|
|
|
2019-10-28 22:55:03 +01:00
|
|
|
config USE_AMD_BLOBS
|
|
|
|
|
bool "Allow AMD blobs repository (with license agreement)"
|
|
|
|
|
depends on USE_BLOBS
|
|
|
|
|
help
|
|
|
|
|
This draws in the amd_blobs repository, which contains binary files
|
|
|
|
|
distributed by AMD, including VBIOS, PSP bootloaders, SMU firmwares,
|
|
|
|
|
etc. Selecting this item to download or clone the repo implies your
|
|
|
|
|
agreement to the AMD license agreement. A copy of the license text
|
|
|
|
|
may be reviewed by reading Documentation/soc/amd/amdblobs_license.md,
|
|
|
|
|
and your copy of the license is present in the repo once downloaded.
|
|
|
|
|
|
|
|
|
|
Note that for some products, omitting PSP, SMU images, or other items
|
|
|
|
|
may result in a nonbooting coreboot.rom.
|
|
|
|
|
|
2020-06-19 00:03:22 +02:00
|
|
|
config USE_QC_BLOBS
|
2020-07-01 03:47:22 +02:00
|
|
|
bool "Allow QC blobs repository (selecting this agrees to the license!)"
|
2020-06-19 00:03:22 +02:00
|
|
|
depends on USE_BLOBS
|
|
|
|
|
help
|
|
|
|
|
This draws in the qc_blobs repository, which contains binary files
|
|
|
|
|
distributed by Qualcomm that are required to build firmware for
|
|
|
|
|
certain Qualcomm SoCs (including QcLib, QC-SEC, qtiseclib and QUP
|
|
|
|
|
firmware). If you say Y here you are implicitly agreeing to the
|
|
|
|
|
Qualcomm license agreement which can be found at:
|
|
|
|
|
https://review.coreboot.org/cgit/qc_blobs.git/tree/LICENSE
|
|
|
|
|
|
|
|
|
|
*****************************************************
|
|
|
|
|
PLEASE MAKE SURE YOU READ AND AGREE TO ALL TERMS IN
|
|
|
|
|
ABOVE LICENSE AGREEMENT BEFORE SELECTING THIS OPTION!
|
|
|
|
|
*****************************************************
|
|
|
|
|
|
|
|
|
|
Not selecting this option means certain Qualcomm SoCs and related
|
|
|
|
|
mainboards cannot be built and will be hidden from the "Mainboards"
|
|
|
|
|
section.
|
|
|
|
|
|
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
|
|
|
config COVERAGE
|
|
|
|
|
bool "Code coverage support"
|
|
|
|
|
depends on COMPILER_GCC
|
|
|
|
|
help
|
|
|
|
|
Add code coverage support for coreboot. This will store code
|
|
|
|
|
coverage information in CBMEM for extraction from user space.
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2017-06-12 06:07:31 +02:00
|
|
|
config UBSAN
|
|
|
|
|
bool "Undefined behavior sanitizer support"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Instrument the code with checks for undefined behavior. If unsure,
|
|
|
|
|
say N because it adds a small performance penalty and may abort
|
|
|
|
|
on code that happens to work in spite of the UB.
|
|
|
|
|
|
2020-08-06 06:16:31 +02:00
|
|
|
config HAVE_ASAN_IN_ROMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config ASAN_IN_ROMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable address sanitizer in romstage for platform.
|
|
|
|
|
|
|
|
|
|
config HAVE_ASAN_IN_RAMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2020-06-10 05:25:16 +02:00
|
|
|
config ASAN_IN_RAMSTAGE
|
2020-08-06 06:16:31 +02:00
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable address sanitizer in ramstage for platform.
|
|
|
|
|
|
|
|
|
|
config ASAN
|
2020-06-10 05:25:16 +02:00
|
|
|
bool "Address sanitizer support"
|
|
|
|
|
default n
|
2020-08-06 06:16:31 +02:00
|
|
|
select ASAN_IN_ROMSTAGE if HAVE_ASAN_IN_ROMSTAGE
|
|
|
|
|
select ASAN_IN_RAMSTAGE if HAVE_ASAN_IN_RAMSTAGE
|
2022-03-24 00:15:46 +01:00
|
|
|
depends on COMPILER_GCC
|
2020-06-10 05:25:16 +02:00
|
|
|
help
|
|
|
|
|
Enable address sanitizer - runtime memory debugger,
|
|
|
|
|
designed to find out-of-bounds accesses and use-after-scope bugs.
|
|
|
|
|
|
|
|
|
|
This feature consumes up to 1/8 of available memory and brings about
|
|
|
|
|
~1.5x performance slowdown.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2020-08-06 06:16:31 +02:00
|
|
|
if ASAN
|
2020-07-07 08:38:31 +02:00
|
|
|
comment "Before using this feature, make sure that "
|
|
|
|
|
comment "asan_shadow_offset_callback patch is applied to GCC."
|
|
|
|
|
endif
|
|
|
|
|
|
2019-12-17 23:19:06 +01:00
|
|
|
choice
|
|
|
|
|
prompt "Stage Cache for ACPI S3 resume"
|
2022-12-19 01:11:48 +01:00
|
|
|
default NO_STAGE_CACHE if !HAVE_ACPI_RESUME || MAINBOARD_DISABLE_STAGE_CACHE
|
2019-12-17 23:19:06 +01:00
|
|
|
default TSEG_STAGE_CACHE if SMM_TSEG
|
|
|
|
|
|
|
|
|
|
config NO_STAGE_CACHE
|
|
|
|
|
bool "Disabled"
|
|
|
|
|
help
|
|
|
|
|
Do not save any component in stage cache for resume path. On resume,
|
|
|
|
|
all components would be read back from CBFS again.
|
|
|
|
|
|
2019-08-01 19:29:14 +02:00
|
|
|
config TSEG_STAGE_CACHE
|
2019-12-17 23:19:06 +01:00
|
|
|
bool "TSEG"
|
|
|
|
|
depends on SMM_TSEG
|
2019-08-01 19:29:14 +02:00
|
|
|
help
|
|
|
|
|
The option enables stage cache support for platform. Platform
|
|
|
|
|
can stash copies of postcar, ramstage and raw runtime data
|
|
|
|
|
inside SMM TSEG, to be restored on S3 resume path.
|
|
|
|
|
|
|
|
|
|
config CBMEM_STAGE_CACHE
|
2019-12-17 23:19:06 +01:00
|
|
|
bool "CBMEM"
|
|
|
|
|
depends on !SMM_TSEG
|
2014-10-17 13:08:36 +02:00
|
|
|
help
|
2019-08-01 19:29:14 +02:00
|
|
|
The option enables stage cache support for platform. Platform
|
|
|
|
|
can stash copies of postcar, ramstage and raw runtime data
|
|
|
|
|
inside CBMEM.
|
|
|
|
|
|
|
|
|
|
While the approach is faster than reloading stages from boot media
|
|
|
|
|
it is also a possible attack scenario via which OS can possibly
|
|
|
|
|
circumvent SMM locks and SPI write protections.
|
|
|
|
|
|
|
|
|
|
If unsure, select 'N'
|
2014-02-07 03:58:24 +01:00
|
|
|
|
2019-12-17 23:19:06 +01:00
|
|
|
endchoice
|
|
|
|
|
|
2022-12-19 01:11:48 +01:00
|
|
|
config MAINBOARD_DISABLE_STAGE_CACHE
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Selected by mainboards which wish to disable the stage cache.
|
|
|
|
|
E.g. mainboards which don't use S3 resume in the field may wish to
|
|
|
|
|
disable it to save boot time at the cost of increasing S3 resume time.
|
|
|
|
|
|
2014-05-07 03:00:19 +02:00
|
|
|
config UPDATE_IMAGE
|
|
|
|
|
bool "Update existing coreboot.rom image"
|
|
|
|
|
help
|
|
|
|
|
If this option is enabled, no new coreboot.rom file
|
|
|
|
|
is created. Instead it is expected that there already
|
|
|
|
|
is a suitable file for further processing.
|
|
|
|
|
The bootblock will not be modified.
|
|
|
|
|
|
2016-01-20 22:59:21 +01:00
|
|
|
If unsure, select 'N'
|
|
|
|
|
|
2015-01-24 15:52:10 +01:00
|
|
|
config BOOTSPLASH_IMAGE
|
|
|
|
|
bool "Add a bootsplash image"
|
|
|
|
|
help
|
|
|
|
|
Select this option if you have a bootsplash image that you would
|
|
|
|
|
like to add to your ROM.
|
|
|
|
|
|
|
|
|
|
This will only add the image to the ROM. To actually run it check
|
|
|
|
|
options under 'Display' section.
|
|
|
|
|
|
|
|
|
|
config BOOTSPLASH_FILE
|
|
|
|
|
string "Bootsplash path and filename"
|
|
|
|
|
depends on BOOTSPLASH_IMAGE
|
2016-12-15 23:05:37 +01:00
|
|
|
# Default value set at the end of the file
|
2015-01-24 15:52:10 +01:00
|
|
|
help
|
|
|
|
|
The path and filename of the file to use as graphical bootsplash
|
|
|
|
|
screen. The file format has to be jpg.
|
|
|
|
|
|
2020-05-10 04:20:10 +02:00
|
|
|
config FW_CONFIG
|
|
|
|
|
bool "Firmware Configuration Probing"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable support for probing devices with fw_config. This is a simple
|
|
|
|
|
bitmask broken into fields and options for probing.
|
|
|
|
|
|
|
|
|
|
config FW_CONFIG_SOURCE_CHROMEEC_CBI
|
|
|
|
|
bool "Obtain Firmware Configuration value from Google Chrome EC CBI"
|
|
|
|
|
depends on FW_CONFIG && EC_GOOGLE_CHROMEEC
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option tells coreboot to read the firmware configuration value
|
|
|
|
|
from the Google Chrome Embedded Controller CBI interface. This source
|
|
|
|
|
is not tried if FW_CONFIG_SOURCE_CBFS is enabled and the value was
|
|
|
|
|
found in CBFS.
|
|
|
|
|
|
2021-11-02 04:15:30 +01:00
|
|
|
config FW_CONFIG_SOURCE_CBFS
|
|
|
|
|
bool "Obtain Firmware Configuration value from CBFS"
|
|
|
|
|
depends on FW_CONFIG
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
With this option enabled coreboot will look for the 32bit firmware
|
|
|
|
|
configuration value in CBFS at the selected prefix with the file name
|
|
|
|
|
"fw_config". This option will override other sources and allow the
|
|
|
|
|
local image to preempt the mainboard selected source and can be used as
|
|
|
|
|
FW_CONFIG_SOURCE_CHROMEEC_CBI fallback option.
|
|
|
|
|
|
2021-11-02 04:55:25 +01:00
|
|
|
config FW_CONFIG_SOURCE_VPD
|
|
|
|
|
bool "Obtain Firmware Configuration value from VPD"
|
|
|
|
|
depends on FW_CONFIG && VPD
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
With this option enabled coreboot will look for the 32bit firmware
|
|
|
|
|
configuration value in VPD key name "fw_config". This option will
|
|
|
|
|
override other sources and allow the local image to preempt the mainboard
|
|
|
|
|
selected source and can be used for other FW_CONFIG_SOURCEs fallback option.
|
|
|
|
|
|
2019-06-06 19:36:02 +02:00
|
|
|
config HAVE_RAMPAYLOAD
|
|
|
|
|
bool
|
|
|
|
|
|
2019-05-06 10:47:41 +02:00
|
|
|
config RAMPAYLOAD
|
|
|
|
|
bool "Enable coreboot flow without executing ramstage"
|
2019-06-28 14:48:37 +02:00
|
|
|
default y if ARCH_X86
|
2019-06-06 19:36:02 +02:00
|
|
|
depends on HAVE_RAMPAYLOAD
|
2019-05-06 10:47:41 +02:00
|
|
|
help
|
|
|
|
|
If this option is enabled, coreboot flow will skip ramstage
|
|
|
|
|
loading and execution of ramstage to load payload.
|
|
|
|
|
|
|
|
|
|
Instead it is expected to load payload from postcar stage itself.
|
|
|
|
|
|
|
|
|
|
In this flow coreboot will perform basic x86 initialization
|
|
|
|
|
(DRAM resource allocation), MTRR programming,
|
|
|
|
|
Skip PCI enumeration logic and only allocate BAR for fixed devices
|
|
|
|
|
(bootable devices, TPM over GSPI).
|
|
|
|
|
|
2020-02-09 14:43:52 +01:00
|
|
|
config HAVE_CONFIGURABLE_RAMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
|
Add configurable ramstage support for minimal PCI scanning
This CL has changes that allow us to enable a configurable
ramstage, and one change that allows us to minimize PCI
scanning. Minimal scanning is a frequently requested feature.
To enable it, we add two new variables to src/Kconfig
CONFIGURABLE_RAMSTAGE
is the overall variable controlling other options for minimizing the
ramstage.
MINIMAL_PCI_SCANNING is how we indicate we wish to enable minimal
PCI scanning.
Some devices must be scanned in all cases, such as 0:0.0.
To indicate which devices we must scan, we add a new mandatory
keyword to sconfig
It is used in place of on, off, or hidden, and indicates
a device is enabled and mandatory. Mandatory
devices are always scanned. When MINIMAL_PCI_SCANNING is enabled,
ONLY mandatory devices are scanned.
We further add support in src/device/pci_device.c to manage
both MINIMAL_PCI_SCANNING and mandatory devices.
Finally, to show how this works in practice, we add mandatory
keywords to 3 devices on the qemu-q35.
TEST=
1. This is tested and working on the qemu-q35 target.
2. On CML-Hatch
Before CL:
Total Boot time: ~685ms
After CL:
Total Boot time: ~615ms
Change-Id: I2073d9f8e9297c2b02530821ebb634ea2a5c758e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
2019-10-22 04:02:24 +02:00
|
|
|
config CONFIGURABLE_RAMSTAGE
|
|
|
|
|
bool "Enable a configurable ramstage."
|
|
|
|
|
default y if ARCH_X86
|
2020-02-09 14:43:52 +01:00
|
|
|
depends on HAVE_CONFIGURABLE_RAMSTAGE
|
Add configurable ramstage support for minimal PCI scanning
This CL has changes that allow us to enable a configurable
ramstage, and one change that allows us to minimize PCI
scanning. Minimal scanning is a frequently requested feature.
To enable it, we add two new variables to src/Kconfig
CONFIGURABLE_RAMSTAGE
is the overall variable controlling other options for minimizing the
ramstage.
MINIMAL_PCI_SCANNING is how we indicate we wish to enable minimal
PCI scanning.
Some devices must be scanned in all cases, such as 0:0.0.
To indicate which devices we must scan, we add a new mandatory
keyword to sconfig
It is used in place of on, off, or hidden, and indicates
a device is enabled and mandatory. Mandatory
devices are always scanned. When MINIMAL_PCI_SCANNING is enabled,
ONLY mandatory devices are scanned.
We further add support in src/device/pci_device.c to manage
both MINIMAL_PCI_SCANNING and mandatory devices.
Finally, to show how this works in practice, we add mandatory
keywords to 3 devices on the qemu-q35.
TEST=
1. This is tested and working on the qemu-q35 target.
2. On CML-Hatch
Before CL:
Total Boot time: ~685ms
After CL:
Total Boot time: ~615ms
Change-Id: I2073d9f8e9297c2b02530821ebb634ea2a5c758e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
2019-10-22 04:02:24 +02:00
|
|
|
help
|
|
|
|
|
A configurable ramstage allows you to select which parts of the ramstage
|
|
|
|
|
to run. Currently, we can only select a minimal PCI scanning step.
|
|
|
|
|
The minimal PCI scanning will only check those parts that are enabled
|
|
|
|
|
in the devicetree.cb. By convention none of those devices should be bridges.
|
|
|
|
|
|
|
|
|
|
config MINIMAL_PCI_SCANNING
|
|
|
|
|
bool "Enable minimal PCI scanning"
|
2020-02-09 15:05:16 +01:00
|
|
|
depends on CONFIGURABLE_RAMSTAGE && PCI
|
Add configurable ramstage support for minimal PCI scanning
This CL has changes that allow us to enable a configurable
ramstage, and one change that allows us to minimize PCI
scanning. Minimal scanning is a frequently requested feature.
To enable it, we add two new variables to src/Kconfig
CONFIGURABLE_RAMSTAGE
is the overall variable controlling other options for minimizing the
ramstage.
MINIMAL_PCI_SCANNING is how we indicate we wish to enable minimal
PCI scanning.
Some devices must be scanned in all cases, such as 0:0.0.
To indicate which devices we must scan, we add a new mandatory
keyword to sconfig
It is used in place of on, off, or hidden, and indicates
a device is enabled and mandatory. Mandatory
devices are always scanned. When MINIMAL_PCI_SCANNING is enabled,
ONLY mandatory devices are scanned.
We further add support in src/device/pci_device.c to manage
both MINIMAL_PCI_SCANNING and mandatory devices.
Finally, to show how this works in practice, we add mandatory
keywords to 3 devices on the qemu-q35.
TEST=
1. This is tested and working on the qemu-q35 target.
2. On CML-Hatch
Before CL:
Total Boot time: ~685ms
After CL:
Total Boot time: ~615ms
Change-Id: I2073d9f8e9297c2b02530821ebb634ea2a5c758e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
2019-10-22 04:02:24 +02:00
|
|
|
help
|
2020-02-09 15:05:16 +01:00
|
|
|
If this option is enabled, coreboot will scan only PCI devices
|
Add configurable ramstage support for minimal PCI scanning
This CL has changes that allow us to enable a configurable
ramstage, and one change that allows us to minimize PCI
scanning. Minimal scanning is a frequently requested feature.
To enable it, we add two new variables to src/Kconfig
CONFIGURABLE_RAMSTAGE
is the overall variable controlling other options for minimizing the
ramstage.
MINIMAL_PCI_SCANNING is how we indicate we wish to enable minimal
PCI scanning.
Some devices must be scanned in all cases, such as 0:0.0.
To indicate which devices we must scan, we add a new mandatory
keyword to sconfig
It is used in place of on, off, or hidden, and indicates
a device is enabled and mandatory. Mandatory
devices are always scanned. When MINIMAL_PCI_SCANNING is enabled,
ONLY mandatory devices are scanned.
We further add support in src/device/pci_device.c to manage
both MINIMAL_PCI_SCANNING and mandatory devices.
Finally, to show how this works in practice, we add mandatory
keywords to 3 devices on the qemu-q35.
TEST=
1. This is tested and working on the qemu-q35 target.
2. On CML-Hatch
Before CL:
Total Boot time: ~685ms
After CL:
Total Boot time: ~615ms
Change-Id: I2073d9f8e9297c2b02530821ebb634ea2a5c758e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
2019-10-22 04:02:24 +02:00
|
|
|
marked as mandatory in devicetree.cb
|
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
|
|
|
|
|
|
|
|
menu "Software Bill Of Materials (SBOM)"
|
|
|
|
|
|
|
|
|
|
source "src/sbom/Kconfig"
|
|
|
|
|
|
|
|
|
|
endmenu
|
2014-10-17 13:08:36 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2015-06-20 07:17:15 +02:00
|
|
|
menu "Mainboard"
|
|
|
|
|
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/mainboard/Kconfig"
|
2014-10-17 13:08:36 +02:00
|
|
|
|
2016-09-04 16:38:33 +02:00
|
|
|
config DEVICETREE
|
|
|
|
|
string
|
|
|
|
|
default "devicetree.cb"
|
|
|
|
|
help
|
|
|
|
|
This symbol allows mainboards to select a different file under their
|
|
|
|
|
mainboard directory for the devicetree.cb file. This allows the board
|
|
|
|
|
variants that need different devicetrees to be in the same directory.
|
|
|
|
|
|
|
|
|
|
Examples: "devicetree.variant.cb"
|
|
|
|
|
"variant/devicetree.cb"
|
|
|
|
|
|
2018-06-22 03:50:48 +02:00
|
|
|
config OVERRIDE_DEVICETREE
|
|
|
|
|
string
|
|
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
This symbol 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.
|
|
|
|
|
|
|
|
|
|
Examples: "devicetree.variant-override.cb"
|
|
|
|
|
"variant/devicetree-override.cb"
|
|
|
|
|
|
2019-09-25 13:18:52 +02:00
|
|
|
config FMDFILE
|
|
|
|
|
string "fmap description file in fmd format"
|
2020-06-17 21:06:53 +02:00
|
|
|
default "src/mainboard/\$(CONFIG_MAINBOARD_DIR)/chromeos.fmd" if CHROMEOS
|
2019-09-25 13:18:52 +02:00
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
The build system creates a default FMAP from ROM_SIZE and CBFS_SIZE,
|
|
|
|
|
but in some cases more complex setups are required.
|
|
|
|
|
When an fmd is specified, it overrides the default format.
|
|
|
|
|
|
2015-06-20 07:17:15 +02:00
|
|
|
config CBFS_SIZE
|
|
|
|
|
hex "Size of CBFS filesystem in ROM"
|
2019-09-25 13:18:52 +02:00
|
|
|
depends on FMDFILE = ""
|
2016-12-15 23:05:37 +01:00
|
|
|
# Default value set at the end of the file
|
2015-06-20 07:17:15 +02:00
|
|
|
help
|
|
|
|
|
This is the part of the ROM actually managed by CBFS, located at the
|
2023-02-04 12:20:37 +01:00
|
|
|
end of the ROM (passed through cbfstool -o) on x86 and at the start
|
2015-06-20 07:17:15 +02:00
|
|
|
of the ROM (passed through cbfstool -s) everywhere else. It defaults
|
|
|
|
|
to span the whole ROM on all but Intel systems that use an Intel Firmware
|
|
|
|
|
Descriptor. It can be overridden to make coreboot live alongside other
|
|
|
|
|
components like ChromeOS's vboot/FMAP or Intel's IFD / ME / TXE
|
2019-09-25 13:18:52 +02:00
|
|
|
binaries. This symbol should only be used to generate a default FMAP and
|
|
|
|
|
is unused when a non-default fmd file is provided via CONFIG_FMDFILE.
|
2015-09-16 18:10:52 +02:00
|
|
|
|
2015-12-27 00:51:16 +01:00
|
|
|
endmenu
|
|
|
|
|
|
2016-01-25 03:38:33 +01:00
|
|
|
# load site-local kconfig to allow user specific defaults and overrides
|
|
|
|
|
source "site-local/Kconfig"
|
|
|
|
|
|
2014-10-17 13:08:36 +02:00
|
|
|
config SYSTEM_TYPE_LAPTOP
|
2015-04-27 02:53:26 +02:00
|
|
|
default n
|
|
|
|
|
bool
|
2014-10-17 13:08:36 +02:00
|
|
|
|
2019-02-01 20:33:57 +01:00
|
|
|
config SYSTEM_TYPE_TABLET
|
|
|
|
|
default n
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config SYSTEM_TYPE_DETACHABLE
|
|
|
|
|
default n
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config SYSTEM_TYPE_CONVERTIBLE
|
|
|
|
|
default n
|
|
|
|
|
bool
|
|
|
|
|
|
2016-01-14 15:08:36 +01:00
|
|
|
config CBFS_AUTOGEN_ATTRIBUTES
|
|
|
|
|
default n
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
If this option is selected, every file in cbfs which has a constraint
|
|
|
|
|
regarding position or alignment will get an additional file attribute
|
|
|
|
|
which describes this constraint.
|
|
|
|
|
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
menu "Chipset"
|
|
|
|
|
|
2015-06-09 03:11:56 +02:00
|
|
|
comment "SoC"
|
2022-06-23 04:58:06 +02:00
|
|
|
source "src/soc/*/*/Kconfig"
|
|
|
|
|
source "src/soc/*/*/Kconfig.common"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "CPU"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/cpu/Kconfig"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "Northbridge"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/northbridge/*/*/Kconfig"
|
2021-01-20 00:36:31 +01:00
|
|
|
source "src/northbridge/*/*/Kconfig.common"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "Southbridge"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/southbridge/*/*/Kconfig"
|
2021-02-16 16:13:35 +01:00
|
|
|
source "src/southbridge/*/*/Kconfig.common"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "Super I/O"
|
2016-07-29 23:31:45 +02:00
|
|
|
source "src/superio/*/*/Kconfig"
|
2011-01-27 12:43:03 +01:00
|
|
|
comment "Embedded Controllers"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/ec/acpi/Kconfig"
|
|
|
|
|
source "src/ec/*/*/Kconfig"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
|
2015-06-21 00:17:12 +02:00
|
|
|
source "src/southbridge/intel/common/firmware/Kconfig"
|
2015-06-20 06:30:43 +02:00
|
|
|
source "src/vendorcode/*/Kconfig"
|
2015-06-21 00:17:12 +02:00
|
|
|
|
2015-06-20 06:30:43 +02:00
|
|
|
source "src/arch/*/Kconfig"
|
|
|
|
|
|
2020-07-30 01:28:43 +02:00
|
|
|
config CHIPSET_DEVICETREE
|
|
|
|
|
string
|
|
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
This symbol allows a chipset to provide a set of default settings in
|
|
|
|
|
a devicetree which are common to all mainboards. This may include
|
|
|
|
|
devices (including alias names), chip drivers, register settings,
|
|
|
|
|
and others. This path is relative to the src/ directory.
|
|
|
|
|
|
|
|
|
|
Example: "chipset.cb"
|
|
|
|
|
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
endmenu
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/device/Kconfig"
|
2012-11-14 02:00:01 +01:00
|
|
|
|
2010-05-16 17:31:53 +02:00
|
|
|
menu "Generic Drivers"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/drivers/*/Kconfig"
|
2016-03-12 05:22:28 +01:00
|
|
|
source "src/drivers/*/*/Kconfig"
|
2020-08-28 21:46:35 +02:00
|
|
|
source "src/drivers/*/*/*/Kconfig"
|
2017-05-09 01:56:03 +02:00
|
|
|
source "src/commonlib/storage/Kconfig"
|
2010-05-16 17:31:53 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2017-10-16 17:09:33 +02:00
|
|
|
menu "Security"
|
|
|
|
|
|
|
|
|
|
source "src/security/Kconfig"
|
2019-11-14 14:10:28 +01:00
|
|
|
source "src/vendorcode/eltan/security/Kconfig"
|
2017-10-16 17:09:33 +02:00
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
2016-05-17 19:28:23 +02:00
|
|
|
source "src/acpi/Kconfig"
|
|
|
|
|
|
2016-08-11 18:02:26 +02:00
|
|
|
# This option is for the current boards/chipsets where SPI flash
|
|
|
|
|
# is not the boot device. Currently nearly all boards/chipsets assume
|
|
|
|
|
# SPI flash is the boot device.
|
|
|
|
|
config BOOT_DEVICE_NOT_SPI_FLASH
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config BOOT_DEVICE_SPI_FLASH
|
|
|
|
|
bool
|
|
|
|
|
default y if !BOOT_DEVICE_NOT_SPI_FLASH
|
|
|
|
|
default n
|
|
|
|
|
|
2016-08-11 21:04:10 +02:00
|
|
|
config BOOT_DEVICE_MEMORY_MAPPED
|
|
|
|
|
bool
|
|
|
|
|
default y if ARCH_X86 && BOOT_DEVICE_SPI_FLASH
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Inform system if SPI is memory-mapped or not.
|
|
|
|
|
|
2016-08-12 22:00:10 +02:00
|
|
|
config BOOT_DEVICE_SUPPORTS_WRITES
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Indicate that the platform has writable boot device
|
|
|
|
|
support.
|
|
|
|
|
|
2015-04-22 13:28:21 +02:00
|
|
|
config RTC
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config HEAP_SIZE
|
|
|
|
|
hex
|
2019-04-23 03:46:27 +02:00
|
|
|
default 0x100000 if FLATTENED_DEVICE_TREE
|
2009-10-16 21:12:49 +02:00
|
|
|
default 0x4000
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2014-09-19 22:18:16 +02:00
|
|
|
config STACK_SIZE
|
|
|
|
|
hex
|
2022-05-23 23:28:44 +02:00
|
|
|
default 0x2000 if ARCH_X86
|
2015-10-13 01:45:21 +02:00
|
|
|
default 0x0
|
2014-09-19 22:18:16 +02:00
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config MAX_CPUS
|
|
|
|
|
int
|
|
|
|
|
default 1
|
|
|
|
|
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/console/Kconfig"
|
2009-08-12 17:00:51 +02:00
|
|
|
|
|
|
|
|
config HAVE_ACPI_RESUME
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2020-01-15 11:31:25 +01:00
|
|
|
config DISABLE_ACPI_HIBERNATE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Removes S4 from the available sleepstates
|
|
|
|
|
|
2016-01-22 22:26:04 +01:00
|
|
|
config RESUME_PATH_SAME_AS_BOOT
|
|
|
|
|
bool
|
|
|
|
|
default y if ARCH_X86
|
|
|
|
|
depends on HAVE_ACPI_RESUME
|
|
|
|
|
help
|
|
|
|
|
This option indicates that when a system resumes it takes the
|
|
|
|
|
same path as a regular boot. e.g. an x86 system runs from the
|
|
|
|
|
reset vector at 0xfffffff0 on both resume and warm/cold boot.
|
|
|
|
|
|
2019-07-01 16:25:41 +02:00
|
|
|
config NO_MONOTONIC_TIMER
|
2013-04-30 05:31:51 +02:00
|
|
|
def_bool n
|
2019-07-01 16:25:41 +02:00
|
|
|
|
|
|
|
|
config HAVE_MONOTONIC_TIMER
|
|
|
|
|
bool
|
|
|
|
|
depends on !NO_MONOTONIC_TIMER
|
2019-07-01 14:38:25 +02:00
|
|
|
default y
|
2013-04-30 05:31:51 +02:00
|
|
|
help
|
|
|
|
|
The board/chipset provides a monotonic timer.
|
|
|
|
|
|
2014-09-25 17:05:15 +02:00
|
|
|
config GENERIC_UDELAY
|
2019-07-01 16:25:41 +02:00
|
|
|
bool
|
2014-09-25 17:05:15 +02:00
|
|
|
depends on HAVE_MONOTONIC_TIMER
|
2019-07-01 16:25:41 +02:00
|
|
|
default y if !ARCH_X86
|
2014-09-25 17:05:15 +02:00
|
|
|
help
|
|
|
|
|
The board/chipset uses a generic udelay function utilizing the
|
|
|
|
|
monotonic timer.
|
|
|
|
|
|
2013-04-30 16:58:12 +02:00
|
|
|
config TIMER_QUEUE
|
|
|
|
|
def_bool n
|
|
|
|
|
depends on HAVE_MONOTONIC_TIMER
|
|
|
|
|
help
|
2013-09-13 06:57:49 +02:00
|
|
|
Provide a timer queue for performing time-based callbacks.
|
2013-04-30 16:58:12 +02:00
|
|
|
|
2013-05-06 19:20:52 +02:00
|
|
|
config COOP_MULTITASKING
|
|
|
|
|
def_bool n
|
2021-11-02 18:29:33 +01:00
|
|
|
select TIMER_QUEUE
|
2022-11-01 23:48:32 +01:00
|
|
|
depends on ARCH_X86
|
2013-05-06 19:20:52 +02:00
|
|
|
help
|
|
|
|
|
Cooperative multitasking allows callbacks to be multiplexed on the
|
2021-11-02 18:29:33 +01:00
|
|
|
main thread. With this enabled it allows for multiple execution paths
|
|
|
|
|
to take place when they have udelay() calls within their code.
|
2013-05-06 19:20:52 +02:00
|
|
|
|
|
|
|
|
config NUM_THREADS
|
|
|
|
|
int
|
|
|
|
|
default 4
|
|
|
|
|
depends on COOP_MULTITASKING
|
|
|
|
|
help
|
|
|
|
|
How many execution threads to cooperatively multitask with.
|
|
|
|
|
|
2021-05-20 16:43:08 +02:00
|
|
|
config HAVE_MAINBOARD_SPECIFIC_OPTION_BACKEND
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
Selected by mainboards which implement a mainboard-specific mechanism
|
|
|
|
|
to access the values for runtime-configurable options. For example, a
|
|
|
|
|
custom BMC interface or an EEPROM with an externally-imposed layout.
|
|
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config HAVE_OPTION_TABLE
|
|
|
|
|
bool
|
2010-07-06 23:05:04 +02:00
|
|
|
default n
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
This variable specifies whether a given board has a cmos.layout
|
|
|
|
|
file containing NVRAM/CMOS bit definitions.
|
2010-07-06 23:05:04 +02:00
|
|
|
It defaults to 'n' but can be selected in mainboard/*/Kconfig.
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2021-05-17 12:12:39 +02:00
|
|
|
config CMOS_LAYOUT_FILE
|
|
|
|
|
string
|
|
|
|
|
default "src/mainboard/\$(MAINBOARDDIR)/cmos.layout"
|
|
|
|
|
depends on HAVE_OPTION_TABLE
|
|
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config PCI_IO_CFG_EXT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config IOAPIC
|
|
|
|
|
bool
|
2021-06-06 07:28:16 +02:00
|
|
|
default y if SMP
|
2009-08-12 17:00:51 +02:00
|
|
|
default n
|
|
|
|
|
|
2009-09-22 20:49:08 +02:00
|
|
|
config USE_WATCHDOG_ON_BOOT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config GFXUMA
|
|
|
|
|
bool
|
2009-10-26 16:14:07 +01:00
|
|
|
default n
|
2009-09-22 20:49:08 +02:00
|
|
|
help
|
|
|
|
|
Enable Unified Memory Architecture for graphics.
|
|
|
|
|
|
2009-10-15 15:35:47 +02:00
|
|
|
config HAVE_MP_TABLE
|
|
|
|
|
bool
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
This variable specifies whether a given board has MP table support.
|
|
|
|
|
It is usually set in mainboard/*/Kconfig.
|
|
|
|
|
Whether or not the MP table is actually generated by coreboot
|
|
|
|
|
is configurable by the user via GENERATE_MP_TABLE.
|
2009-10-15 15:35:47 +02:00
|
|
|
|
|
|
|
|
config HAVE_PIRQ_TABLE
|
|
|
|
|
bool
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
This variable specifies whether a given board has PIRQ table support.
|
|
|
|
|
It is usually set in mainboard/*/Kconfig.
|
|
|
|
|
Whether or not the PIRQ table is actually generated by coreboot
|
|
|
|
|
is configurable by the user via GENERATE_PIRQ_TABLE.
|
2009-10-15 15:35:47 +02:00
|
|
|
|
2015-11-17 23:31:00 +01:00
|
|
|
config ACPI_NHLT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Build support for NHLT (non HD Audio) ACPI table generation.
|
|
|
|
|
|
2009-10-26 16:14:07 +01:00
|
|
|
#These Options are here to avoid "undefined" warnings.
|
|
|
|
|
#The actual selection and help texts are in the following menu.
|
|
|
|
|
|
|
|
|
|
menu "System tables"
|
2009-09-22 20:49:08 +02:00
|
|
|
|
2009-10-15 15:35:47 +02:00
|
|
|
config GENERATE_MP_TABLE
|
2021-06-08 07:06:06 +02:00
|
|
|
prompt "Generate an MP table" if HAVE_MP_TABLE
|
2012-11-14 02:33:08 +01:00
|
|
|
bool
|
2021-06-08 07:06:06 +02:00
|
|
|
default HAVE_MP_TABLE
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
Generate an MP table (conforming to the Intel MultiProcessor
|
|
|
|
|
specification 1.4) for this board.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
2009-09-22 20:49:08 +02:00
|
|
|
|
2009-10-15 15:35:47 +02:00
|
|
|
config GENERATE_PIRQ_TABLE
|
2012-11-14 02:33:08 +01:00
|
|
|
prompt "Generate a PIRQ table" if HAVE_PIRQ_TABLE
|
|
|
|
|
bool
|
|
|
|
|
default HAVE_PIRQ_TABLE
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
Generate a PIRQ table for this board.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
2009-09-22 20:49:08 +02:00
|
|
|
|
2011-08-14 20:56:34 +02:00
|
|
|
config GENERATE_SMBIOS_TABLES
|
|
|
|
|
depends on ARCH_X86
|
|
|
|
|
bool "Generate SMBIOS tables"
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Generate SMBIOS tables for this board.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
|
|
|
|
|
2021-09-03 16:51:40 +02:00
|
|
|
config SMBIOS_TYPE41_PROVIDED_BY_DEVTREE
|
|
|
|
|
bool
|
|
|
|
|
depends on ARCH_X86
|
|
|
|
|
help
|
|
|
|
|
If enabled, only generate SMBIOS Type 41 entries for PCI devices in
|
|
|
|
|
the devicetree for which Type 41 information is provided, e.g. with
|
|
|
|
|
the `smbios_dev_info` devicetree syntax. This is useful to manually
|
|
|
|
|
assign specific instance IDs to onboard devices irrespective of the
|
|
|
|
|
device traversal order. It is assumed that instance IDs for devices
|
|
|
|
|
of the same class are unique.
|
|
|
|
|
When disabled, coreboot autogenerates SMBIOS Type 41 entries for all
|
|
|
|
|
appropriate PCI devices in the devicetree. Instance IDs are assigned
|
|
|
|
|
successive numbers from a monotonically increasing counter, with one
|
|
|
|
|
counter for each device class.
|
|
|
|
|
|
2015-05-30 23:08:26 +02:00
|
|
|
config SMBIOS_PROVIDED_BY_MOBO
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2014-10-17 13:28:15 +02:00
|
|
|
config MAINBOARD_SERIAL_NUMBER
|
2017-11-01 09:49:16 +01:00
|
|
|
prompt "SMBIOS Serial Number" if !SMBIOS_PROVIDED_BY_MOBO
|
|
|
|
|
string
|
2014-10-17 13:28:15 +02:00
|
|
|
depends on GENERATE_SMBIOS_TABLES
|
|
|
|
|
default "123456789"
|
2015-04-27 02:53:26 +02:00
|
|
|
help
|
2014-10-17 13:28:15 +02:00
|
|
|
The Serial Number to store in SMBIOS structures.
|
|
|
|
|
|
|
|
|
|
config MAINBOARD_VERSION
|
2017-11-01 09:49:16 +01:00
|
|
|
prompt "SMBIOS Version Number" if !SMBIOS_PROVIDED_BY_MOBO
|
|
|
|
|
string
|
2014-10-17 13:28:15 +02:00
|
|
|
depends on GENERATE_SMBIOS_TABLES
|
|
|
|
|
default "1.0"
|
|
|
|
|
help
|
|
|
|
|
The Version Number to store in SMBIOS structures.
|
|
|
|
|
|
|
|
|
|
config MAINBOARD_SMBIOS_MANUFACTURER
|
2017-11-01 09:49:16 +01:00
|
|
|
prompt "SMBIOS Manufacturer" if !SMBIOS_PROVIDED_BY_MOBO
|
|
|
|
|
string
|
2014-10-17 13:28:15 +02:00
|
|
|
depends on GENERATE_SMBIOS_TABLES
|
|
|
|
|
default MAINBOARD_VENDOR
|
|
|
|
|
help
|
|
|
|
|
Override the default Manufacturer stored in SMBIOS structures.
|
|
|
|
|
|
|
|
|
|
config MAINBOARD_SMBIOS_PRODUCT_NAME
|
2017-11-01 09:49:16 +01:00
|
|
|
prompt "SMBIOS Product name" if !SMBIOS_PROVIDED_BY_MOBO
|
|
|
|
|
string
|
2014-10-17 13:28:15 +02:00
|
|
|
depends on GENERATE_SMBIOS_TABLES
|
|
|
|
|
default MAINBOARD_PART_NUMBER
|
|
|
|
|
help
|
|
|
|
|
Override the default Product name stored in SMBIOS structures.
|
|
|
|
|
|
2020-06-03 05:44:22 +02:00
|
|
|
config VPD_SMBIOS_VERSION
|
|
|
|
|
bool "Populates SMBIOS type 0 version from the VPD_RO variable 'firmware_version'"
|
|
|
|
|
default n
|
|
|
|
|
depends on VPD && GENERATE_SMBIOS_TABLES
|
|
|
|
|
help
|
|
|
|
|
Selecting this option will read firmware_version from
|
|
|
|
|
VPD_RO and override SMBIOS type 0 version. One special
|
|
|
|
|
scenario of using this feature is to assign a BIOS version
|
|
|
|
|
to a coreboot image without the need to rebuild from source.
|
|
|
|
|
|
2009-09-22 20:49:08 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2016-02-05 03:52:27 +01:00
|
|
|
source "payloads/Kconfig"
|
2009-09-17 18:21:31 +02:00
|
|
|
|
2009-10-07 18:15:40 +02:00
|
|
|
menu "Debugging"
|
|
|
|
|
|
2018-11-13 19:28:07 +01:00
|
|
|
comment "CPU Debug Settings"
|
2019-11-04 21:50:21 +01:00
|
|
|
source "src/cpu/*/Kconfig.debug_cpu"
|
2018-11-13 19:28:07 +01:00
|
|
|
|
2019-10-20 14:20:53 +02:00
|
|
|
comment "BLOB Debug Settings"
|
|
|
|
|
source "src/drivers/intel/fsp*/Kconfig.debug_blob"
|
|
|
|
|
|
2018-11-13 19:28:07 +01:00
|
|
|
comment "General Debug Settings"
|
|
|
|
|
|
2009-10-07 18:15:40 +02:00
|
|
|
# TODO: Better help text and detailed instructions.
|
2009-08-12 17:00:51 +02:00
|
|
|
config GDB_STUB
|
2009-08-25 02:53:22 +02:00
|
|
|
bool "GDB debugging support"
|
2012-03-25 20:51:16 +02:00
|
|
|
default n
|
2019-11-04 09:33:04 +01:00
|
|
|
depends on DRIVERS_UART
|
2009-08-12 17:00:51 +02:00
|
|
|
help
|
2009-08-25 02:53:22 +02:00
|
|
|
If enabled, you will be able to set breakpoints for gdb debugging.
|
2022-02-16 22:37:44 +01:00
|
|
|
See src/arch/x86/c_start.S for details.
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2012-06-22 15:56:37 +02:00
|
|
|
config GDB_WAIT
|
2015-12-10 21:58:52 +01:00
|
|
|
bool "Wait for a GDB connection in the ramstage"
|
2012-06-22 15:56:37 +02:00
|
|
|
default n
|
|
|
|
|
depends on GDB_STUB
|
|
|
|
|
help
|
2015-12-10 21:58:52 +01:00
|
|
|
If enabled, coreboot will wait for a GDB connection in the ramstage.
|
|
|
|
|
|
2012-06-22 15:56:37 +02:00
|
|
|
|
2015-02-18 02:27:23 +01:00
|
|
|
config FATAL_ASSERTS
|
|
|
|
|
bool "Halt when hitting a BUG() or assertion error"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
If enabled, coreboot will call hlt() on a BUG() or failed ASSERT().
|
|
|
|
|
|
2018-11-13 22:06:40 +01:00
|
|
|
config HAVE_DEBUG_GPIO
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config DEBUG_GPIO
|
|
|
|
|
bool "Output verbose GPIO debug messages"
|
|
|
|
|
depends on HAVE_DEBUG_GPIO
|
|
|
|
|
|
2012-05-03 01:33:18 +02:00
|
|
|
config DEBUG_CBFS
|
|
|
|
|
bool "Output verbose CBFS debug messages"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables additional CBFS related debug messages.
|
|
|
|
|
|
2010-08-26 14:46:02 +02:00
|
|
|
config HAVE_DEBUG_RAM_SETUP
|
|
|
|
|
def_bool n
|
|
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
config DEBUG_RAM_SETUP
|
|
|
|
|
bool "Output verbose RAM init debug messages"
|
|
|
|
|
default n
|
2010-08-26 14:46:02 +02:00
|
|
|
depends on HAVE_DEBUG_RAM_SETUP
|
2010-03-05 11:03:50 +01:00
|
|
|
help
|
|
|
|
|
This option enables additional RAM init related debug messages.
|
|
|
|
|
It is recommended to enable this when debugging issues on your
|
|
|
|
|
board which might be RAM init related.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-06-01 21:25:31 +02:00
|
|
|
config DEBUG_PIRQ
|
|
|
|
|
bool "Check PIRQ table consistency"
|
|
|
|
|
default n
|
|
|
|
|
depends on GENERATE_PIRQ_TABLE
|
|
|
|
|
help
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-08-26 14:46:02 +02:00
|
|
|
config HAVE_DEBUG_SMBUS
|
|
|
|
|
def_bool n
|
|
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
config DEBUG_SMBUS
|
|
|
|
|
bool "Output verbose SMBus debug messages"
|
|
|
|
|
default n
|
2010-08-26 14:46:02 +02:00
|
|
|
depends on HAVE_DEBUG_SMBUS
|
2010-03-05 11:03:50 +01:00
|
|
|
help
|
|
|
|
|
This option enables additional SMBus (and SPD) debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config DEBUG_SMI
|
|
|
|
|
bool "Output verbose SMI debug messages"
|
|
|
|
|
default n
|
|
|
|
|
depends on HAVE_SMI_HANDLER
|
2020-10-03 12:22:04 +02:00
|
|
|
select SPI_FLASH_SMM if EM100PRO_SPI_CONSOLE || CONSOLE_SPI_FLASH
|
2010-03-05 11:03:50 +01:00
|
|
|
help
|
|
|
|
|
This option enables additional SMI related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2020-06-13 12:45:42 +02:00
|
|
|
config DEBUG_PERIODIC_SMI
|
|
|
|
|
bool "Trigger SMI periodically"
|
|
|
|
|
depends on DEBUG_SMI
|
|
|
|
|
|
2010-11-10 01:14:32 +01:00
|
|
|
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
|
|
|
|
|
# printk(BIOS_DEBUG, ...) calls.
|
|
|
|
|
config DEBUG_MALLOC
|
2020-12-02 19:34:17 +01:00
|
|
|
prompt "Output verbose malloc debug messages" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8 || CONSOLE_OVERRIDE_LOGLEVEL
|
2012-11-14 02:00:01 +01:00
|
|
|
bool
|
2010-11-10 01:14:32 +01:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables additional malloc related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
2011-07-01 23:44:39 +02:00
|
|
|
|
2020-10-12 19:44:46 +02:00
|
|
|
# Only visible if DEBUG_SPEW (8) is set.
|
|
|
|
|
config DEBUG_RESOURCES
|
2020-12-02 19:34:17 +01:00
|
|
|
bool "Output verbose PCI MEM and IO resource debug messages" if DEFAULT_CONSOLE_LOGLEVEL_8 || CONSOLE_OVERRIDE_LOGLEVEL
|
2020-10-12 19:44:46 +02:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables additional PCI memory and IO debug messages.
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2018-12-31 14:22:34 +01:00
|
|
|
config DEBUG_CONSOLE_INIT
|
|
|
|
|
bool "Debug console initialisation code"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
With this option printk()'s are attempted before console hardware
|
|
|
|
|
initialisation has been completed. Your mileage may vary.
|
|
|
|
|
|
|
|
|
|
Typically you will need to modify source in console_hw_init() such
|
|
|
|
|
that a working console appears before the one you want to debug.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-11-10 01:14:32 +01:00
|
|
|
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
|
|
|
|
|
# printk(BIOS_DEBUG, ...) calls.
|
2010-09-08 00:30:15 +02:00
|
|
|
config REALMODE_DEBUG
|
2020-12-02 19:34:17 +01:00
|
|
|
prompt "Enable debug messages for option ROM execution" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8 || CONSOLE_OVERRIDE_LOGLEVEL
|
2012-11-14 02:00:01 +01:00
|
|
|
bool
|
2010-09-08 00:30:15 +02:00
|
|
|
default n
|
2010-11-10 03:00:32 +01:00
|
|
|
depends on PCI_OPTION_ROM_RUN_REALMODE
|
2010-09-08 00:30:15 +02:00
|
|
|
help
|
|
|
|
|
This option enables additional x86emu related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the time to emulate a ROM.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
config X86EMU_DEBUG
|
|
|
|
|
bool "Output verbose x86emu debug messages"
|
|
|
|
|
default n
|
|
|
|
|
depends on PCI_OPTION_ROM_RUN_YABEL
|
|
|
|
|
help
|
|
|
|
|
This option enables additional x86emu related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_JMP
|
|
|
|
|
bool "Trace JMP/RETF"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print information about JMP and RETF opcodes from x86emu.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_TRACE
|
|
|
|
|
bool "Trace all opcodes"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print _all_ opcodes that are executed by x86emu.
|
2010-04-27 08:56:47 +02:00
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
WARNING: This will produce a LOT of output and take a long time.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_PNP
|
|
|
|
|
bool "Log Plug&Play accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print Plug And Play accesses made by option ROMs.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_DISK
|
|
|
|
|
bool "Log Disk I/O"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print Disk I/O related messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_PMM
|
|
|
|
|
bool "Log PMM"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to POST Memory Manager (PMM).
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_VBE
|
|
|
|
|
bool "Debug VESA BIOS Extensions"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to VESA BIOS Extension (VBE) functions.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_INT10
|
|
|
|
|
bool "Redirect INT10 output to console"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Let INT10 (i.e. character output) calls print messages to debug output.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_INTERRUPTS
|
|
|
|
|
bool "Log intXX calls"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to interrupt handling.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_CHECK_VMEM_ACCESS
|
|
|
|
|
bool "Log special memory accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to accesses to certain areas of the virtual
|
|
|
|
|
memory (e.g. BDA (BIOS Data Area) or interrupt vectors)
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_MEM
|
|
|
|
|
bool "Log all memory accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print memory accesses made by option ROM.
|
|
|
|
|
Note: This also includes accesses to fetch instructions.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_IO
|
|
|
|
|
bool "Log IO accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print I/O accesses made by option ROM.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2013-05-15 00:19:49 +02:00
|
|
|
config X86EMU_DEBUG_TIMINGS
|
|
|
|
|
bool "Output timing information"
|
|
|
|
|
default n
|
2019-07-10 14:10:22 +02:00
|
|
|
depends on X86EMU_DEBUG && HAVE_MONOTONIC_TIMER
|
2013-05-15 00:19:49 +02:00
|
|
|
help
|
|
|
|
|
Print timing information needed by i915tool.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2012-05-10 20:27:32 +02:00
|
|
|
config DEBUG_SPI_FLASH
|
|
|
|
|
bool "Output verbose SPI flash debug messages"
|
|
|
|
|
default n
|
|
|
|
|
depends on SPI_FLASH
|
|
|
|
|
help
|
|
|
|
|
This option enables additional SPI flash related debug messages.
|
|
|
|
|
|
2021-04-16 22:26:08 +02:00
|
|
|
config DEBUG_IPMI
|
|
|
|
|
bool "Output verbose IPMI debug messages"
|
|
|
|
|
default n
|
|
|
|
|
depends on IPMI_KCS
|
|
|
|
|
help
|
|
|
|
|
This option enables additional IPMI related debug messages.
|
|
|
|
|
|
2012-04-04 00:07:22 +02:00
|
|
|
if SOUTHBRIDGE_INTEL_BD82X6X && DEFAULT_CONSOLE_LOGLEVEL_8
|
|
|
|
|
# Only visible with the right southbridge and loglevel.
|
|
|
|
|
config DEBUG_INTEL_ME
|
|
|
|
|
bool "Verbose logging for Intel Management Engine"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable verbose logging for Intel Management Engine driver that
|
|
|
|
|
is present on Intel 6-series chipsets.
|
|
|
|
|
endif
|
|
|
|
|
|
2020-10-12 19:58:46 +02:00
|
|
|
config DEBUG_FUNC
|
2021-11-11 20:07:46 +01:00
|
|
|
bool "Enable function entry and exit reporting macros" if DEFAULT_CONSOLE_LOGLEVEL_8 || CONSOLE_OVERRIDE_LOGLEVEL
|
2020-10-12 19:58:46 +02:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables additional function entry and exit debug messages
|
2020-07-24 14:54:31 +02:00
|
|
|
for select functions.
|
2020-10-12 19:58:46 +02:00
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
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
|
|
|
config DEBUG_COVERAGE
|
|
|
|
|
bool "Debug code coverage"
|
|
|
|
|
default n
|
|
|
|
|
depends on COVERAGE
|
|
|
|
|
help
|
|
|
|
|
If enabled, the code coverage hooks in coreboot will output some
|
|
|
|
|
information about the coverage data that is dumped.
|
|
|
|
|
|
2016-06-29 21:59:32 +02:00
|
|
|
config DEBUG_BOOT_STATE
|
|
|
|
|
bool "Debug boot state machine"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Control debugging of the boot state machine. When selected displays
|
|
|
|
|
the state boundaries in ramstage.
|
|
|
|
|
|
2016-10-05 17:43:56 +02:00
|
|
|
config DEBUG_ADA_CODE
|
|
|
|
|
bool "Compile debug code in Ada sources"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Add the compiler switch `-gnata` to compile code guarded by
|
|
|
|
|
`pragma Debug`.
|
|
|
|
|
|
2018-07-12 23:26:07 +02:00
|
|
|
config HAVE_EM100_SUPPORT
|
2022-04-17 20:10:41 +02:00
|
|
|
bool
|
2018-07-12 23:26:07 +02:00
|
|
|
help
|
|
|
|
|
This is enabled by platforms which can support using the EM100.
|
|
|
|
|
|
|
|
|
|
config EM100
|
|
|
|
|
bool "Configure image for EM100 usage"
|
|
|
|
|
depends on HAVE_EM100_SUPPORT
|
|
|
|
|
help
|
|
|
|
|
The Dediprog EM100 SPI emulator allows fast loading of new SPI images
|
|
|
|
|
over USB. However it only supports a maximum SPI clock of 20MHz and
|
|
|
|
|
single data output. Enable this option to use a 20MHz SPI clock and
|
|
|
|
|
disable "Dual Output Fast Read" Support.
|
|
|
|
|
|
|
|
|
|
On AMD platforms this changes the SPI speed at run-time if the
|
|
|
|
|
mainboard code supports this. On supported Intel platforms this works
|
|
|
|
|
by changing the settings in the descriptor.bin file.
|
|
|
|
|
|
2009-10-07 18:15:40 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2016-12-15 23:25:15 +01:00
|
|
|
###############################################################################
|
|
|
|
|
# Set variables with no prompt - these can be set anywhere, and putting at
|
|
|
|
|
# the end of this file gives the most flexibility.
|
2017-05-18 18:07:34 +02:00
|
|
|
|
|
|
|
|
source "src/lib/Kconfig"
|
|
|
|
|
|
2009-11-12 17:38:03 +01:00
|
|
|
config WARNINGS_ARE_ERRORS
|
|
|
|
|
bool
|
2014-11-17 17:17:54 +01:00
|
|
|
default y
|
2009-11-27 17:55:13 +01:00
|
|
|
|
2010-10-13 08:23:02 +02:00
|
|
|
# The four POWER_BUTTON_DEFAULT_ENABLE, POWER_BUTTON_DEFAULT_DISABLE,
|
|
|
|
|
# POWER_BUTTON_FORCE_ENABLE and POWER_BUTTON_FORCE_DISABLE options are
|
|
|
|
|
# mutually exclusive. One of these options must be selected in the
|
|
|
|
|
# mainboard Kconfig if the chipset supports enabling and disabling of
|
|
|
|
|
# the power button. Chipset code uses the ENABLE_POWER_BUTTON option set
|
|
|
|
|
# in mainboard/Kconfig to know if the button should be enabled or not.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_DEFAULT_ENABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board has a power button which can optionally be
|
|
|
|
|
disabled by the user.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_DEFAULT_DISABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board has a power button which can optionally be
|
|
|
|
|
enabled by the user, e.g. when the board ships with a jumper over
|
|
|
|
|
the power switch contacts.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_FORCE_ENABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board requires that the power button is always
|
|
|
|
|
enabled.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_FORCE_DISABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board requires that the power button is always
|
|
|
|
|
disabled, e.g. when it has been hardwired to ground.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_IS_OPTIONAL
|
|
|
|
|
bool
|
|
|
|
|
default y if POWER_BUTTON_DEFAULT_ENABLE || POWER_BUTTON_DEFAULT_DISABLE
|
|
|
|
|
default n if !(POWER_BUTTON_DEFAULT_ENABLE || POWER_BUTTON_DEFAULT_DISABLE)
|
|
|
|
|
help
|
|
|
|
|
Internal option that controls ENABLE_POWER_BUTTON visibility.
|
2013-10-31 16:26:23 +01:00
|
|
|
|
|
|
|
|
config REG_SCRIPT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Internal option that controls whether we compile in register scripts.
|
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
|
|
|
|
|
|
|
|
config MAX_REBOOT_CNT
|
|
|
|
|
int
|
|
|
|
|
default 3
|
2015-03-18 07:31:34 +01:00
|
|
|
help
|
|
|
|
|
Internal option that sets the maximum number of bootblock executions allowed
|
|
|
|
|
with the normal image enabled before assuming the normal image is defective
|
2014-07-23 18:40:02 +02:00
|
|
|
and switching to the fallback image.
|
Kconfig: Move defaults for CBFS_SIZE
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-02-09 17:06:46 +01:00
|
|
|
|
2016-12-15 23:25:15 +01:00
|
|
|
config UNCOMPRESSED_RAMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config NO_XIP_EARLY_STAGES
|
|
|
|
|
bool
|
|
|
|
|
default n if ARCH_X86
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Identify if early stages are eXecute-In-Place(XIP).
|
|
|
|
|
|
|
|
|
|
config EARLY_CBMEM_LIST
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable display of CBMEM during romstage and postcar.
|
|
|
|
|
|
|
|
|
|
config RELOCATABLE_MODULES
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
If RELOCATABLE_MODULES is selected then support is enabled for
|
|
|
|
|
building relocatable modules in the RAM stage. Those modules can be
|
|
|
|
|
loaded anywhere and all the relocations are handled automatically.
|
|
|
|
|
|
|
|
|
|
config GENERIC_GPIO_LIB
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
If enabled, compile the generic GPIO library. A "generic" GPIO
|
|
|
|
|
implies configurability usually found on SoCs, particularly the
|
|
|
|
|
ability to control internal pull resistors.
|
|
|
|
|
|
|
|
|
|
config BOOTBLOCK_CUSTOM
|
|
|
|
|
# To be selected by arch, SoC or mainboard if it does not want use the normal
|
|
|
|
|
# src/lib/bootblock.c#main() C entry point.
|
|
|
|
|
bool
|
|
|
|
|
|
2022-04-05 20:42:07 +02:00
|
|
|
config BOOTBLOCK_IN_CBFS
|
|
|
|
|
bool
|
|
|
|
|
default y if ARCH_X86
|
|
|
|
|
help
|
|
|
|
|
Select this on platforms that have a top aligned bootblock inside cbfs.
|
|
|
|
|
|
2020-06-11 20:59:07 +02:00
|
|
|
config MEMLAYOUT_LD_FILE
|
|
|
|
|
string
|
2020-06-17 21:06:53 +02:00
|
|
|
default "src/mainboard/\$(CONFIG_MAINBOARD_DIR)/memlayout.ld"
|
2020-06-11 20:59:07 +02:00
|
|
|
help
|
|
|
|
|
This variable allows SoC/mainboard to supply in a custom linker file
|
|
|
|
|
if required. This determines the linker file used for all the stages
|
|
|
|
|
(bootblock, romstage, verstage, ramstage, postcar) in
|
|
|
|
|
src/arch/${ARCH}/Makefile.inc.
|
|
|
|
|
|
2016-12-15 23:05:37 +01:00
|
|
|
###############################################################################
|
|
|
|
|
# Set default values for symbols created before mainboards. This allows the
|
|
|
|
|
# option to be displayed in the general menu, but the default to be loaded in
|
|
|
|
|
# the mainboard if desired.
|
|
|
|
|
config COMPRESS_PRERAM_STAGES
|
2019-11-04 18:57:06 +01:00
|
|
|
depends on (HAVE_ROMSTAGE || HAVE_VERSTAGE) && NO_XIP_EARLY_STAGES
|
2016-12-15 23:05:37 +01:00
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config INCLUDE_CONFIG_FILE
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config BOOTSPLASH_FILE
|
|
|
|
|
depends on BOOTSPLASH_IMAGE
|
|
|
|
|
default "bootsplash.jpg"
|
|
|
|
|
|
|
|
|
|
config CBFS_SIZE
|
|
|
|
|
default ROM_SIZE
|
2019-06-08 08:59:02 +02:00
|
|
|
|
|
|
|
|
config HAVE_BOOTBLOCK
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config HAVE_VERSTAGE
|
|
|
|
|
bool
|
|
|
|
|
depends on VBOOT_SEPARATE_VERSTAGE
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config HAVE_ROMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config HAVE_RAMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
default n if RAMPAYLOAD
|
|
|
|
|
default y
|