coreboot-kgpe-d16/src/Kconfig

1222 lines
32 KiB
Plaintext
Raw Normal View History

##
## This file is part of the coreboot project.
##
## Copyright (C) 2012 Alexandru Gagniuc <mr.nuke.me@gmail.com>
## Copyright (C) 2009-2010 coresystems GmbH
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; version 2 of the License.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
mainmenu "coreboot configuration"
menu "General setup"
config COREBOOT_BUILD
bool
default y
config LOCALVERSION
string "Local version string"
help
Append an extra string to the end of the coreboot version.
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.
config CONFIGURABLE_CBFS_PREFIX
bool
help
Select this to prompt to use to configure the prefix for cbfs files.
config CBFS_PREFIX
string "CBFS prefix to use" if CONFIGURABLE_CBFS_PREFIX
default "fallback"
help
Select the prefix to all files put into the image. It's "fallback"
by default, "normal" is a common alternative.
choice
prompt "Compiler to use"
default COMPILER_GCC
help
This option allows you to select the compiler used for building
coreboot.
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
config COMPILER_GCC
bool "GCC"
help
Use the GNU Compiler Collection (GCC) to build coreboot.
For details see http://gcc.gnu.org.
config COMPILER_LLVM_CLANG
bool "LLVM/clang (TESTING ONLY - Not currently working)"
help
Use LLVM/clang to build coreboot. To use this, you must build the
coreboot version of the clang compiler. Run the command
make clang
Note that this option is not currently working correctly and should
really only be selected if you're trying to work on getting clang
operational.
For details see http://clang.llvm.org.
endchoice
config ANY_TOOLCHAIN
bool "Allow building with any toolchain"
default n
help
Many toolchains break when building coreboot since it uses quite
unusual linker features. Unless developers explicitely request it,
we'll have to assume that they use their distro compiler by mistake.
Make sure that using patched compilers is a conscious decision.
config CCACHE
bool "Use ccache to speed up (re)compilation"
default n
help
Enables the use of ccache for faster builds.
Requires the ccache utility in your system $PATH.
For details see https://ccache.samba.org.
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.
config UTIL_GENPARSER
bool "Generate SCONFIG & BINCFG parser using flex and bison"
default n
help
Enable this option if you are working on the sconfig device tree
parser or bincfg and made changes to the .l or .y files.
Otherwise, say N to use the provided pregenerated scanner/parser.
config USE_OPTION_TABLE
bool "Use CMOS for configuration values"
depends on HAVE_OPTION_TABLE
help
Enable this option if coreboot shall read options from the "CMOS"
NVRAM instead of using hard-coded values.
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.
config COMPRESS_RAMSTAGE
bool "Compress ramstage with LZMA"
Rampayload: Able to build coreboot without ramstage This patch removes all possible dependencies in order to build platform with CONFIG_RAMPAYLOAD enable(without ramstage). A. Create coreboot separate stage kconfigs This patch creates seperate stage configs as below 1. HAVE_BOOTBLOCK 2. HAVE_VERSTAGE 3. HAVE_ROMSTAGE 4. HAVE_POSTCAR 5. HAVE_RAMSTAGE B. Also ensures below kconfigs are aligned with correct stage configs 1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if CONFIG_HAVE_RAMSTAGE is selected. 2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set 3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE || CONFIG_HAVE_ROMSTAGE is selected. C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE On x86 platform: Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32 Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_ This patch fixes Case 2 usecase where platform doesn't select CONFIG_HAVE_RAMSTAGE. Also add option to create sipi_vector.manual based on $(TARGET_STAGE) variable. $(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE $(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-06-08 08:59:02 +02:00
depends on HAVE_RAMSTAGE
# Default value set at the end of the file
help
Compress ramstage to save memory in the flash image. Note
that decompression might slow down booting if the boot flash
is connected through a slow link (i.e. SPI).
config COMPRESS_PRERAM_STAGES
bool "Compress romstage and verstage with LZ4"
Rampayload: Able to build coreboot without ramstage This patch removes all possible dependencies in order to build platform with CONFIG_RAMPAYLOAD enable(without ramstage). A. Create coreboot separate stage kconfigs This patch creates seperate stage configs as below 1. HAVE_BOOTBLOCK 2. HAVE_VERSTAGE 3. HAVE_ROMSTAGE 4. HAVE_POSTCAR 5. HAVE_RAMSTAGE B. Also ensures below kconfigs are aligned with correct stage configs 1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if CONFIG_HAVE_RAMSTAGE is selected. 2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set 3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE || CONFIG_HAVE_ROMSTAGE is selected. C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE On x86 platform: Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32 Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_ This patch fixes Case 2 usecase where platform doesn't select CONFIG_HAVE_RAMSTAGE. Also add option to create sipi_vector.manual based on $(TARGET_STAGE) variable. $(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE $(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-06-08 08:59:02 +02:00
depends on !ARCH_X86 && (HAVE_ROMSTAGE || HAVE_VERSTAGE)
# Default value set at the end of the file
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
time spent decompressing. Doesn't work for XIP stages (assume all
ARCH_X86 for now) for obvious reasons.
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
Rampayload: Able to build coreboot without ramstage This patch removes all possible dependencies in order to build platform with CONFIG_RAMPAYLOAD enable(without ramstage). A. Create coreboot separate stage kconfigs This patch creates seperate stage configs as below 1. HAVE_BOOTBLOCK 2. HAVE_VERSTAGE 3. HAVE_ROMSTAGE 4. HAVE_POSTCAR 5. HAVE_RAMSTAGE B. Also ensures below kconfigs are aligned with correct stage configs 1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if CONFIG_HAVE_RAMSTAGE is selected. 2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set 3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE || CONFIG_HAVE_ROMSTAGE is selected. C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE On x86 platform: Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32 Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_ This patch fixes Case 2 usecase where platform doesn't select CONFIG_HAVE_RAMSTAGE. Also add option to create sipi_vector.manual based on $(TARGET_STAGE) variable. $(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE $(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-06-08 08:59:02 +02:00
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
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.)
config INCLUDE_CONFIG_FILE
bool "Include the coreboot .config file into the ROM image"
# Default value set at the end of the file
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.
Saying Y here will increase the image size by 2-3KB.
You can use the following command to easily list the options:
grep -a CONFIG_ coreboot.rom
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
Name Offset Type Size
cmos_layout.bin 0x0 cmos layout 1159
fallback/romstage 0x4c0 stage 339756
fallback/ramstage 0x53440 stage 186664
fallback/payload 0x80dc0 payload 51526
config 0x8d740 raw 3324
(empty) 0x8e480 null 3610440
config COLLECT_TIMESTAMPS
bool "Create a table of timestamps collected during boot"
default y if ARCH_X86
help
Make coreboot create a table of timer-ID/timer-value pairs to
allow measuring time spent at different phases of the boot process.
config TIMESTAMPS_ON_CONSOLE
bool "Print the timestamp values on the console"
default n
depends on COLLECT_TIMESTAMPS
help
Print the timestamps to the debug console if enabled at level spew.
config USE_BLOBS
bool "Allow use of binary-only repository"
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.
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.
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.
config NO_RELOCATABLE_RAMSTAGE
bool
default n if ARCH_X86
default y
config RELOCATABLE_RAMSTAGE
bool
default !NO_RELOCATABLE_RAMSTAGE
select RELOCATABLE_MODULES
help
The reloctable ramstage support allows for the ramstage to be built
as a relocatable module. The stage loader can identify a place
out of the OS way so that copying memory is unnecessary during an S3
wake. When selecting this option the romstage is responsible for
determing a stack location to use for loading the ramstage.
config TSEG_STAGE_CACHE
bool
default y
depends on !NO_STAGE_CACHE && SMM_TSEG
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
bool "Cache stages in CBMEM"
depends on !NO_STAGE_CACHE && !TSEG_STAGE_CACHE
help
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'
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.
If unsure, select 'N'
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
# Default value set at the end of the file
help
The path and filename of the file to use as graphical bootsplash
screen. The file format has to be jpg.
config HAVE_RAMPAYLOAD
bool
config RAMPAYLOAD
bool "Enable coreboot flow without executing ramstage"
default y if ARCH_X86
depends on HAVE_RAMPAYLOAD
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).
endmenu
menu "Mainboard"
source "src/mainboard/Kconfig"
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"
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"
config CBFS_SIZE
hex "Size of CBFS filesystem in ROM"
# Default value set at the end of the file
help
This is the part of the ROM actually managed by CBFS, located at the
end of the ROM (passed through cbfstool -o) on x86 and at at the start
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
binaries.
config FMDFILE
string "fmap description file in fmd format"
default "src/mainboard/$(CONFIG_MAINBOARD_DIR)/chromeos.fmd" if CHROMEOS
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.
endmenu
# load site-local kconfig to allow user specific defaults and overrides
source "site-local/Kconfig"
config SYSTEM_TYPE_LAPTOP
default n
bool
config SYSTEM_TYPE_TABLET
default n
bool
config SYSTEM_TYPE_DETACHABLE
default n
bool
config SYSTEM_TYPE_CONVERTIBLE
default n
bool
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.
menu "Chipset"
comment "SoC"
source "src/soc/*/Kconfig"
comment "CPU"
source "src/cpu/Kconfig"
comment "Northbridge"
source "src/northbridge/*/*/Kconfig"
comment "Southbridge"
source "src/southbridge/*/*/Kconfig"
comment "Super I/O"
source "src/superio/*/*/Kconfig"
comment "Embedded Controllers"
source "src/ec/acpi/Kconfig"
source "src/ec/*/*/Kconfig"
source "src/southbridge/intel/common/firmware/Kconfig"
source "src/vendorcode/*/Kconfig"
source "src/arch/*/Kconfig"
endmenu
source "src/device/Kconfig"
menu "Generic Drivers"
source "src/drivers/*/Kconfig"
source "src/drivers/*/*/Kconfig"
source "src/commonlib/storage/Kconfig"
endmenu
menu "Security"
source "src/security/Kconfig"
endmenu
source "src/acpi/Kconfig"
# 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
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.
config BOOT_DEVICE_SUPPORTS_WRITES
bool
default n
help
Indicate that the platform has writable boot device
support.
config RTC
bool
default n
config HEAP_SIZE
hex
default 0x100000 if FLATTENED_DEVICE_TREE
default 0x4000
2014-09-19 22:18:16 +02:00
config STACK_SIZE
hex
arm64: Implement generic stage transitions for non-Tegra SoCs The existing arm64 architecture code has been developed for the Tegra132 and Tegra210 SoCs, which only start their ARM64 cores in ramstage. It interweaves the stage entry point with code that initializes a CPU (and should not be run again if that CPU already ran a previous stage). It also still contains some vestiges of SMP/secmon support (such as setting up stacks in the BSS instead of using the stage-peristent one from memlayout). This patch splits those functions apart and makes the code layout similar to how things work on ARM32. The default stage_entry() symbol is a no-op wrapper that just calls main() for the current stage, for the normal case where a stage ran on the same core as the last one. It can be overridden by SoC code to support special cases like Tegra. The CPU initialization code is split out into armv8/cpu.S (similar to what arm_init_caches() does for ARM32) and called by the default bootblock entry code. SoCs where a CPU starts up in a later stage can call the same code from a stage_entry() override instead. The Tegra132 and Tegra210 code is not touched by this patch to make it easier to review and validate. A follow-up patch will bring those SoCs in line with the model. BRANCH=None BUG=None TEST=Booted Oak with a single mmu_init()/mmu_enable(). Built Ryu and Smaug. Change-Id: I28302a6ace47e8ab7a736e089f64922cef1a2f93 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12077 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-13 01:45:21 +02:00
default 0x1000 if ARCH_X86
default 0x0
2014-09-19 22:18:16 +02:00
config MAX_CPUS
int
default 1
source "src/console/Kconfig"
config HAVE_ACPI_RESUME
bool
default n
depends on RELOCATABLE_RAMSTAGE
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.
config HAVE_ROMSTAGE_CONSOLE_SPINLOCK
bool
default n
config HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK
bool
default n
help
This should be enabled on certain plaforms, such as the AMD
SR565x, that cannot handle concurrent CBFS accesses from
multiple APs during early startup.
config HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK
bool
default n
config NO_MONOTONIC_TIMER
def_bool n
config HAVE_MONOTONIC_TIMER
bool
depends on !NO_MONOTONIC_TIMER
default y
help
The board/chipset provides a monotonic timer.
config GENERIC_UDELAY
bool
depends on HAVE_MONOTONIC_TIMER
default y if !ARCH_X86
help
The board/chipset uses a generic udelay function utilizing the
monotonic timer.
config TIMER_QUEUE
def_bool n
depends on HAVE_MONOTONIC_TIMER
help
Provide a timer queue for performing time-based callbacks.
config COOP_MULTITASKING
def_bool n
depends on TIMER_QUEUE && ARCH_X86
help
Cooperative multitasking allows callbacks to be multiplexed on the
main thread of ramstage. With this enabled it allows for multiple
execution paths to take place when they have udelay() calls within
their code.
config NUM_THREADS
int
default 4
depends on COOP_MULTITASKING
help
How many execution threads to cooperatively multitask with.
config HAVE_OPTION_TABLE
bool
default n
help
This variable specifies whether a given board has a cmos.layout
file containing NVRAM/CMOS bit definitions.
It defaults to 'n' but can be selected in mainboard/*/Kconfig.
config PCI_IO_CFG_EXT
bool
default n
config IOAPIC
bool
default n
config USE_WATCHDOG_ON_BOOT
bool
default n
config GFXUMA
bool
default n
help
Enable Unified Memory Architecture for graphics.
config HAVE_ACPI_TABLES
bool
help
This variable specifies whether a given board has ACPI table support.
It is usually set in mainboard/*/Kconfig.
config HAVE_MP_TABLE
bool
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.
config HAVE_PIRQ_TABLE
bool
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.
config COMMON_FADT
bool
default n
config ACPI_NHLT
bool
default n
help
Build support for NHLT (non HD Audio) ACPI table generation.
arch/x86: Add BERT region support functions Add code for generating the region pointed to in an ACPI Boot Error Record Table. The BERT region must be reported as Reserved to the OSPM, so this code calls out to a system-specific region locator. cbmem is reported as type 16 and is not usable for the BERT region. Events reported via BERT are Generic Error Data, and are constructed as follows (see ACPI and UEFI specs for reference): * Each event begins with a Generic Error Status Block, which may contain zero or more Generic Data Entries * Each Generic Data Entry is identifiable by its Section Type field, and the data structures associated are also in the UEFI spec. * The GUIDs are listed in the Section Type field of the CPER Section Descriptor structure. BERT doesn't use this structure but simply uses its GUIDs. * Data structures used in the Generic Data Entry are named as Error Sections in the UEFI spec. * Some sections may optionally include a variable number of additional structures, e.g. an IA32/X64 processor error can report error information as well as machine contexts. It is worth noting that the Linux kernel (as of v4.4) does not attempt to parse IA32/X64 sections, and opts to hexdump them instead. BUG=b:65446699 TEST=inspect BERT region, and dmesg, on full patch stack. Use test data plus a failing Grunt system. Change-Id: I54826981639b5647a8ca33b8b55ff097681402b9 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/28470 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-09-04 20:32:56 +02:00
config ACPI_BERT
bool
depends on HAVE_ACPI_TABLES
help
Build an ACPI Boot Error Record Table.
#These Options are here to avoid "undefined" warnings.
#The actual selection and help texts are in the following menu.
menu "System tables"
config GENERATE_MP_TABLE
prompt "Generate an MP table" if HAVE_MP_TABLE || DRIVERS_GENERIC_IOAPIC
bool
default HAVE_MP_TABLE || DRIVERS_GENERIC_IOAPIC
help
Generate an MP table (conforming to the Intel MultiProcessor
specification 1.4) for this board.
If unsure, say Y.
config GENERATE_PIRQ_TABLE
prompt "Generate a PIRQ table" if HAVE_PIRQ_TABLE
bool
default HAVE_PIRQ_TABLE
help
Generate a PIRQ table for this board.
If unsure, say Y.
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.
config SMBIOS_PROVIDED_BY_MOBO
bool
default n
config MAINBOARD_SERIAL_NUMBER
prompt "SMBIOS Serial Number" if !SMBIOS_PROVIDED_BY_MOBO
string
depends on GENERATE_SMBIOS_TABLES
default "123456789"
help
The Serial Number to store in SMBIOS structures.
config MAINBOARD_VERSION
prompt "SMBIOS Version Number" if !SMBIOS_PROVIDED_BY_MOBO
string
depends on GENERATE_SMBIOS_TABLES
default "1.0"
help
The Version Number to store in SMBIOS structures.
config MAINBOARD_SMBIOS_MANUFACTURER
prompt "SMBIOS Manufacturer" if !SMBIOS_PROVIDED_BY_MOBO
string
depends on GENERATE_SMBIOS_TABLES
default MAINBOARD_VENDOR
help
Override the default Manufacturer stored in SMBIOS structures.
config MAINBOARD_SMBIOS_PRODUCT_NAME
prompt "SMBIOS Product name" if !SMBIOS_PROVIDED_BY_MOBO
string
depends on GENERATE_SMBIOS_TABLES
default MAINBOARD_PART_NUMBER
help
Override the default Product name stored in SMBIOS structures.
config SMBIOS_ENCLOSURE_TYPE
hex
depends on GENERATE_SMBIOS_TABLES
default 0x09 if SYSTEM_TYPE_LAPTOP
default 0x1e if SYSTEM_TYPE_TABLET
default 0x1f if SYSTEM_TYPE_CONVERTIBLE
default 0x20 if SYSTEM_TYPE_DETACHABLE
default 0x03
help
System Enclosure or Chassis Types as defined in SMBIOS specification.
The default value is SMBIOS_ENCLOSURE_DESKTOP (0x03) but laptop,
convertible, or tablet enclosure will be used if the appropriate
system type is selected.
endmenu
source "payloads/Kconfig"
menu "Debugging"
comment "CPU Debug Settings"
source "src/cpu/*/Kconfig.debug"
comment "General Debug Settings"
# TODO: Better help text and detailed instructions.
config GDB_STUB
bool "GDB debugging support"
default n
depends on CONSOLE_SERIAL
help
If enabled, you will be able to set breakpoints for gdb debugging.
See src/arch/x86/lib/c_start.S for details.
config GDB_WAIT
bool "Wait for a GDB connection in the ramstage"
default n
depends on GDB_STUB
help
If enabled, coreboot will wait for a GDB connection in the ramstage.
Fix non-x86 __PRE_RAM__ assertions and add FATAL_ASSERTS Kconfig option This patch fixes a bug that caused non-x86 boards to use the poor man's assert() version with a lot more instructions per invocation and hexadecimal line numbers in __PRE_RAM__ environments. This was really just an oversight in the ARM port... even x86 uses a proper printk() in most cases (those with CAR) and there's no reason not to do so on the generally even more flexible SRAM-based architectures. Additionally, it adds a new Kconfig option to make failed assertions and BUG() calls halt again. This seems to have been the original intention, but was commented out once out of fear that this might prevent production systems from booting. It is still a useful debugging feature though (since otherwise assertions can easily just scroll past and get overlooked), so the user should be able to decide the this based on his needs. (Also changed error messages for both to include the word "ERROR", since grepping for that is the most sophisticated way we currently have to detect firmware problems. Some automated Chromium OS suspend tests check for that.) BRANCH=veyron BUG=None TEST=Booted Jerry. Compared binary sizes before and after, new version's bootblock is some ~600 bytes smaller. Change-Id: I894da18d77e12bf104e443322e2d58e60564e4b7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6a5343124719c18a1c969477e3d18bda13c0bf26 Original-Change-Id: I0268cfd67d8c894406b18bb3759a577944bcffb1 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/250661 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9775 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
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().
config HAVE_DEBUG_GPIO
bool
config DEBUG_GPIO
bool "Output verbose GPIO debug messages"
depends on HAVE_DEBUG_GPIO
config DEBUG_CBFS
bool "Output verbose CBFS debug messages"
default n
help
This option enables additional CBFS related debug messages.
config HAVE_DEBUG_RAM_SETUP
def_bool n
config DEBUG_RAM_SETUP
bool "Output verbose RAM init debug messages"
default n
depends on HAVE_DEBUG_RAM_SETUP
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.
config DEBUG_PIRQ
bool "Check PIRQ table consistency"
default n
depends on GENERATE_PIRQ_TABLE
help
If unsure, say N.
config HAVE_DEBUG_SMBUS
def_bool n
config DEBUG_SMBUS
bool "Output verbose SMBus debug messages"
default n
depends on HAVE_DEBUG_SMBUS
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
select SPI_FLASH_SMM if SPI_CONSOLE || CONSOLE_SPI_FLASH
help
This option enables additional SMI related debug messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config DEBUG_MALLOC
prompt "Output verbose malloc debug messages" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
bool
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.
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config DEBUG_ACPI
prompt "Output verbose ACPI debug messages" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
bool
default n
help
This option enables additional ACPI related debug messages.
Note: This option will slightly increase the size of the coreboot image.
If unsure, say N.
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.
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config REALMODE_DEBUG
prompt "Enable debug messages for option ROM execution" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
bool
default n
depends on PCI_OPTION_ROM_RUN_REALMODE
help
This option enables additional x86emu related debug messages.
Note: This option will increase the time to emulate a ROM.
If unsure, say N.
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.
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.
config X86EMU_DEBUG_TIMINGS
bool "Output timing information"
default n
depends on X86EMU_DEBUG && UDELAY_LAPIC && HAVE_MONOTONIC_TIMER
help
Print timing information needed by i915tool.
If unsure, say N.
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.
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
config TRACE
bool "Trace function calls"
default n
help
If enabled, every function will print information to console once
the function is entered. The syntax is ~0xaaaabbbb(0xccccdddd)
the 0xaaaabbbb is the actual function and 0xccccdddd is EIP
of calling function. Please note some printk related functions
are omitted from trace to have good looking console dumps.
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.
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.
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`.
config HAVE_EM100_SUPPORT
bool "Platform can support the Dediprog EM100 SPI emulator"
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.
endmenu
###############################################################################
# Set variables with no prompt - these can be set anywhere, and putting at
# the end of this file gives the most flexibility.
source "src/lib/Kconfig"
config ENABLE_APIC_EXT_ID
bool
default n
config WARNINGS_ARE_ERRORS
bool
default y
Enable or disable the power button in Kconfig Some mainboards need to disable the power button to avoid turning off right after being turned on, while other boards ship with a jumper over the power button and should allow the user to configure the behavior. This adds infrastructure in the form of four mutually exclusive options which can be selected in a mainboard Kconfig (power button forced on/off, and user-controllable with default on/off) and one result bool which source code can test. (Enable the button or not.) The options have been implemented in CS5536 code and for all mainboards which select SOUTHBRIDGE_AMD_CS5536, but should be used also by other chipsets where applicable. Note that if chipset code uses the result bool ENABLE_POWER_BUTTON, then every board using that chipset must select one out of the four control options in order to build. All touched boards should have unchanged behavior, except pcengines/alix1c, traverse/geos and lippert/hurricane-lx where the power button can now be configured by the user. Build tested for alix1c, alix2d, hurricane-lx and wyse-s50. Confirmed to work as advertised on alix1c both with button enabled and disabled. Includes additional traverse/geos changes from Nathan and lippert/hurricane-lx changes from Jens to correctly use the new feature on those boards. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Aurelien Guillaume <aurelien@iwi.me> Acked-by: Nils Jacobs <njacobs8@hetnet.nl> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5948 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
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.
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
help
Internal option that sets the maximum number of bootblock executions allowed
with the normal image enabled before assuming the normal image is defective
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-07-23 18:40:02 +02:00
and switching to the fallback image.
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 NO_STAGE_CACHE
bool
default y if !HAVE_ACPI_RESUME || !RELOCATABLE_RAMSTAGE
help
Do not save any component in stage cache for resume path. On resume,
all components would be read back from CBFS again.
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
config C_ENVIRONMENT_BOOTBLOCK
# To be selected by arch or platform if a C environment is available during the
# bootblock. Normally this signifies availability of RW memory (e.g. SRAM).
bool
###############################################################################
# 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_RAMSTAGE
default y if !UNCOMPRESSED_RAMSTAGE
config COMPRESS_PRERAM_STAGES
depends on !ARCH_X86
default y
config INCLUDE_CONFIG_FILE
default y
config BOOTSPLASH_FILE
depends on BOOTSPLASH_IMAGE
default "bootsplash.jpg"
config CBFS_SIZE
default ROM_SIZE
Rampayload: Able to build coreboot without ramstage This patch removes all possible dependencies in order to build platform with CONFIG_RAMPAYLOAD enable(without ramstage). A. Create coreboot separate stage kconfigs This patch creates seperate stage configs as below 1. HAVE_BOOTBLOCK 2. HAVE_VERSTAGE 3. HAVE_ROMSTAGE 4. HAVE_POSTCAR 5. HAVE_RAMSTAGE B. Also ensures below kconfigs are aligned with correct stage configs 1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if CONFIG_HAVE_RAMSTAGE is selected. 2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set 3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE || CONFIG_HAVE_ROMSTAGE is selected. C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE On x86 platform: Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32 Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0 >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_ This patch fixes Case 2 usecase where platform doesn't select CONFIG_HAVE_RAMSTAGE. Also add option to create sipi_vector.manual based on $(TARGET_STAGE) variable. $(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE $(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-06-08 08:59:02 +02:00
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_POSTCAR
bool
depends on POSTCAR_STAGE
default y
config HAVE_RAMSTAGE
bool
default n if RAMPAYLOAD
default y