coreboot-kgpe-d16/src/Kconfig

1266 lines
33 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 CBFS_PREFIX
string "CBFS prefix to use"
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 & BLOBTOOL parser using flex and bison"
default n
help
Enable this option if you are working on the sconfig device tree
parser or blobtool 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"
# 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"
depends on !ARCH_X86
# 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.
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 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 RELOCATABLE_RAMSTAGE
depends on EARLY_CBMEM_INIT
bool "Build the ramstage to be relocatable in 32-bit address space."
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 CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
depends on RELOCATABLE_RAMSTAGE
bool
help
The relocated ramstage is saved in an area specified by the
by the board and/or chipset.
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 BOARD_ID_STRING
string "Board ID"
# Default value set at the end of the file
depends on BOARD_ID_MANUAL
help
This string is placed in the 'board_id' CBFS file for indicating
board type.
config RAM_CODE_SUPPORT
bool
help
If enabled, coreboot discovers RAM configuration (value obtained by
reading board straps) and stores it in coreboot table.
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.
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 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.
kconfig: allow various tpm type and interface permutations Until now it was assumed that all TPM devices were of the same type (TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs and all other boards had I2C connected TPMs. With the advent of TPM2 specification there is a need to be able to configure different combinations of TPM types (TPM or TPM2) and interfaces (LPC, I2C and SPI). This patch allows to do it. Picking Chrome OS still assumes that the board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's Kconfig will trigger including of TPM2 instead. MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding SPI_TPM to the board config switches interface choice to SPI, and if neither of the two is defined, the interface is assumed to be I2C. BRANCH=none BUG=chrome-os-partner:50645 TEST=verified that none of the generated board configurations change as a result of this patch. With the rest of the stack in place it is possible to configure different combinations of TPM types and interfaces for ARM and x86 boards. Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1 Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/349850 Original-Reviewed-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/15294 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-06-03 05:43:19 +02:00
config MAINBOARD_HAS_TPM2
bool
default n
help
There is a TPM device installed on the mainboard, and it is
compliant with version 2 TCG TPM specification. Could be connected
over LPC, SPI or I2C.
endmenu
# load site-local kconfig to allow user specific defaults and overrides
source "site-local/Kconfig"
config SYSTEM_TYPE_LAPTOP
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"
# FIXME move to vendorcode
source "src/drivers/intel/fsp1_0/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
drivers: Add I2C TPM driver to coreboot On ARM platforms the TPM is not attached through LPC but through I2C. This patch adds an I2C TPM driver that supports the following chips: * Infineon SLB9635 * Infineon SLB9645 In order to select the correct TPM implementation cleanly, CONFIG_TPM is moved to src/Kconfig and does the correct choice. Old-Change-Id: I2def0e0f86a869d6fcf56fc4ccab0bc935de2bf1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/167543 Reviewed-by: ron minnich <rminnich@chromium.org> (cherry picked from commit b4049a0e96f6335a93877e1e884f9a440487c421) i2c tpm: Remove mostly useless delay code/tables. I assume from the code in the TPM driver that the TPM spec defines different types of delays and timeouts which each have a particular duration, and that the TPM can tell you how long each type is if you ask it. There was a large table, some members of a data structure, and a function or two which managed the timeouts and figured their value for different operations. The timeout values for the various "ordinals" were never set in the vendor specific data structure, however, and always defaulted to 2 minutes. Similarly the timeouts a, b, c, and d were never overridden from their defaults. This change gets rid of all the timeout management code and makes the "ordinal" timeout 2 minutes and the a, b, c, and d timeouts 2 seconds, the larger of the two default values. This is a port from depthcharge to coreboot, original change: https://chromium-review.googlesource.com/#/c/168363/ Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Stefan Reinauer <reinauer@google.com> Old-Change-Id: I79696d6329184ca07f6a1be4f6ca85e1655a7aaf Reviewed-on: https://chromium-review.googlesource.com/168583 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> (cherry picked from commit b22395a73f361c38626911808332a3706b2334fe) TPM: Stop requesting/releasing the TPM locality. The locality is requested when the TPM is initialized and released when it's cleaned up. There's no reason to set it to the same thing again and restore it back to the same value before and after every transaction. forward ported from https://chromium-review.googlesource.com/#/c/168400 Old-Change-Id: I291d1f86f220ef0eff6809c6cb00459bf95aa5e0 Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/168584 Reviewed-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit cc866c20c6f936f349d2f1773dd492dca9bbf0c1) Squashed three commits for the i2c tpm driver. Change-Id: Ie7a50c50fda8ee986c02de7fe27551666998229d Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6519 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-08-30 01:05:02 +02:00
config TPM
bool
default n
kconfig: allow various tpm type and interface permutations Until now it was assumed that all TPM devices were of the same type (TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs and all other boards had I2C connected TPMs. With the advent of TPM2 specification there is a need to be able to configure different combinations of TPM types (TPM or TPM2) and interfaces (LPC, I2C and SPI). This patch allows to do it. Picking Chrome OS still assumes that the board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's Kconfig will trigger including of TPM2 instead. MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding SPI_TPM to the board config switches interface choice to SPI, and if neither of the two is defined, the interface is assumed to be I2C. BRANCH=none BUG=chrome-os-partner:50645 TEST=verified that none of the generated board configurations change as a result of this patch. With the rest of the stack in place it is possible to configure different combinations of TPM types and interfaces for ARM and x86 boards. Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1 Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/349850 Original-Reviewed-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/15294 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-06-03 05:43:19 +02:00
select LPC_TPM if MAINBOARD_HAS_LPC_TPM
select I2C_TPM if !MAINBOARD_HAS_LPC_TPM && !SPI_TPM
drivers: Add I2C TPM driver to coreboot On ARM platforms the TPM is not attached through LPC but through I2C. This patch adds an I2C TPM driver that supports the following chips: * Infineon SLB9635 * Infineon SLB9645 In order to select the correct TPM implementation cleanly, CONFIG_TPM is moved to src/Kconfig and does the correct choice. Old-Change-Id: I2def0e0f86a869d6fcf56fc4ccab0bc935de2bf1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/167543 Reviewed-by: ron minnich <rminnich@chromium.org> (cherry picked from commit b4049a0e96f6335a93877e1e884f9a440487c421) i2c tpm: Remove mostly useless delay code/tables. I assume from the code in the TPM driver that the TPM spec defines different types of delays and timeouts which each have a particular duration, and that the TPM can tell you how long each type is if you ask it. There was a large table, some members of a data structure, and a function or two which managed the timeouts and figured their value for different operations. The timeout values for the various "ordinals" were never set in the vendor specific data structure, however, and always defaulted to 2 minutes. Similarly the timeouts a, b, c, and d were never overridden from their defaults. This change gets rid of all the timeout management code and makes the "ordinal" timeout 2 minutes and the a, b, c, and d timeouts 2 seconds, the larger of the two default values. This is a port from depthcharge to coreboot, original change: https://chromium-review.googlesource.com/#/c/168363/ Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Stefan Reinauer <reinauer@google.com> Old-Change-Id: I79696d6329184ca07f6a1be4f6ca85e1655a7aaf Reviewed-on: https://chromium-review.googlesource.com/168583 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> (cherry picked from commit b22395a73f361c38626911808332a3706b2334fe) TPM: Stop requesting/releasing the TPM locality. The locality is requested when the TPM is initialized and released when it's cleaned up. There's no reason to set it to the same thing again and restore it back to the same value before and after every transaction. forward ported from https://chromium-review.googlesource.com/#/c/168400 Old-Change-Id: I291d1f86f220ef0eff6809c6cb00459bf95aa5e0 Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/168584 Reviewed-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit cc866c20c6f936f349d2f1773dd492dca9bbf0c1) Squashed three commits for the i2c tpm driver. Change-Id: Ie7a50c50fda8ee986c02de7fe27551666998229d Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6519 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-08-30 01:05:02 +02:00
help
Enable this option to enable TPM support in coreboot.
If unsure, say N.
kconfig: allow various tpm type and interface permutations Until now it was assumed that all TPM devices were of the same type (TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs and all other boards had I2C connected TPMs. With the advent of TPM2 specification there is a need to be able to configure different combinations of TPM types (TPM or TPM2) and interfaces (LPC, I2C and SPI). This patch allows to do it. Picking Chrome OS still assumes that the board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's Kconfig will trigger including of TPM2 instead. MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding SPI_TPM to the board config switches interface choice to SPI, and if neither of the two is defined, the interface is assumed to be I2C. BRANCH=none BUG=chrome-os-partner:50645 TEST=verified that none of the generated board configurations change as a result of this patch. With the rest of the stack in place it is possible to configure different combinations of TPM types and interfaces for ARM and x86 boards. Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1 Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/349850 Original-Reviewed-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/15294 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-06-03 05:43:19 +02:00
config TPM2
bool
select LPC_TPM if MAINBOARD_HAS_LPC_TPM
select I2C_TPM if !MAINBOARD_HAS_LPC_TPM && !SPI_TPM
help
Enable this option to enable TPM2 support in coreboot.
If unsure, say N.
config POWER_OFF_ON_CR50_UPDATE
bool
help
Power off machine while waiting for CR50 update to take effect.
config MAINBOARD_HAS_TPM_CR50
bool
default y if MAINBOARD_HAS_SPI_TPM_CR50 || MAINBOARD_HAS_I2C_TPM_CR50
default n
select MAINBOARD_HAS_TPM2
select POWER_OFF_ON_CR50_UPDATE if ARCH_X86
config HEAP_SIZE
hex
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
config ACPI_HUGE_LOWMEM_BACKUP
bool
default n
help
On S3 resume path, backup low memory from RAMBASE..RAMTOP in CBMEM.
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_HARD_RESET
bool
default n
help
This variable specifies whether a given board has a hard_reset
function, no matter if it's provided by board code or chipset code.
config HAVE_ROMSTAGE_CONSOLE_SPINLOCK
bool
depends on EARLY_CBMEM_INIT
default n
config HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK
bool
depends on EARLY_CBMEM_INIT
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
depends on EARLY_CBMEM_INIT
default n
config HAVE_MONOTONIC_TIMER
def_bool n
help
The board/chipset provides a monotonic timer.
config GENERIC_UDELAY
def_bool n
depends on HAVE_MONOTONIC_TIMER
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 PIRQ_ROUTE
bool
default n
config HAVE_SMI_HANDLER
bool
default n
config PCI_IO_CFG_EXT
bool
default n
config IOAPIC
bool
default n
config CACHE_ROM_SIZE_OVERRIDE
hex
default 0x0
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 MAX_PIRQ_LINKS
int
default 4
help
This variable specifies the number of PIRQ interrupt links which are
routable. On most chipsets, this is 4, INTA through INTD. Some
chipsets offer more than four links, commonly up to INTH. They may
also have a separate link for ATA or IOAPIC interrupts. When the PIRQ
table specifies links greater than 4, pirq_route_irqs will not
function properly, unless this variable is correctly set.
config COMMON_FADT
bool
default n
config ACPI_NHLT
bool
default n
help
Build support for NHLT (non HD Audio) ACPI table generation.
#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
string "SMBIOS Serial Number"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default "123456789"
help
The Serial Number to store in SMBIOS structures.
config MAINBOARD_VERSION
string "SMBIOS Version Number"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default "1.0"
help
The Version Number to store in SMBIOS structures.
config MAINBOARD_SMBIOS_MANUFACTURER
string "SMBIOS Manufacturer"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default MAINBOARD_VENDOR
help
Override the default Manufacturer stored in SMBIOS structures.
config MAINBOARD_SMBIOS_PRODUCT_NAME
string "SMBIOS Product name"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default MAINBOARD_PART_NUMBER
help
Override the default Product name stored in SMBIOS structures.
endmenu
source "payloads/Kconfig"
menu "Debugging"
# 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 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 HAVE_DEBUG_CAR
def_bool n
config DEBUG_CAR
def_bool n
depends on HAVE_DEBUG_CAR
if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config DEBUG_CAR
bool "Output verbose Cache-as-RAM debug messages"
default n
depends on HAVE_DEBUG_CAR
help
This option enables additional CAR related debug messages.
endif
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
help
This option enables additional SMI related debug messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config DEBUG_SMM_RELOCATION
bool "Debug SMM relocation code"
default n
depends on HAVE_SMI_HANDLER
help
This option enables additional SMM handler relocation 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.
# 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_TPM
bool "Output verbose TPM debug messages"
default n
kconfig: allow various tpm type and interface permutations Until now it was assumed that all TPM devices were of the same type (TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs and all other boards had I2C connected TPMs. With the advent of TPM2 specification there is a need to be able to configure different combinations of TPM types (TPM or TPM2) and interfaces (LPC, I2C and SPI). This patch allows to do it. Picking Chrome OS still assumes that the board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's Kconfig will trigger including of TPM2 instead. MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding SPI_TPM to the board config switches interface choice to SPI, and if neither of the two is defined, the interface is assumed to be I2C. BRANCH=none BUG=chrome-os-partner:50645 TEST=verified that none of the generated board configurations change as a result of this patch. With the rest of the stack in place it is possible to configure different combinations of TPM types and interfaces for ARM and x86 boards. Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1 Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/349850 Original-Reviewed-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/15294 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
2016-06-03 05:43:19 +02:00
depends on TPM || TPM2
help
This option enables additional TPM related debug messages.
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.
config DEBUG_USBDEBUG
bool "Output verbose USB 2.0 EHCI debug dongle messages"
default n
depends on USBDEBUG
help
This option enables additional USB 2.0 debug dongle related messages.
Select this to debug the connection of usbdebug dongle. Note that
you need some other working console to receive the 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_PRINT_PAGE_TABLES
bool "Print the page tables after construction"
default n
depends on ARCH_RISCV
help
After the page tables have been built, print them on the debug
console.
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`.
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 CREATE_BOARD_CHECKLIST
bool
default n
help
When selected, creates a webpage showing the implementation status for
the board. Routines highlighted in green are complete, yellow are
optional and red are required and must be implemented. A table is
produced for each stage of the boot process except the bootblock. The
red items may be used as an implementation checklist for the board.
config MAKE_CHECKLIST_PUBLIC
bool
default n
help
When selected, build/$(CONFIG_MAINBOARD_PART_NUMBER)_checklist.html
is copied into the Documentation/$(CONFIG_MAINBOARD_VENDOR)/Board
directory.
config CHECKLIST_DATA_FILE_LOCATION
string
help
Location of the <stage>_complete.dat and <stage>_optional.dat files
that are consumed during checklist processing. <stage>_complete.dat
contains the symbols that are expected to be in the resulting image.
<stage>_optional.dat is a subset of <stage>_complete.dat and contains
a list of weak symbols which the resulting image may consume. Other
symbols contained only in <stage>_complete.dat will be flagged as
required and not implemented if a weak implementation is found in the
resulting 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_INIT
def_bool !LATE_CBMEM_INIT
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
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 GENERIC_SPD_BIN
bool
help
If enabled, add support for adding spd.hex files in cbfs as spd.bin
and locating it runtime to load SPD. Additionally provide provision to
fetch SPD over SMBus.
config DIMM_MAX
int
default 4
depends on GENERIC_SPD_BIN
help
Total number of memory DIMM slots available on motherboard.
It is multiplication of number of channel to number of DIMMs per
channel
config DIMM_SPD_SIZE
int
default 256
help
Total SPD size that will be used for DIMM.
Ex: DDR3 256, DDR4 512.
config BOARD_ID_AUTO
bool
default n
help
Mainboards that can read a board ID from the hardware straps
(ie. GPIO) select this configuration option.
config BOARD_ID_MANUAL
bool
default n
depends on !BOARD_ID_AUTO
help
If you want to maintain a board ID, but the hardware does not
have straps to automatically determine the ID, you can say Y
here and add a file named 'board_id' to CBFS. If you don't know
what this is about, say N.
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 BOARD_ID_STRING
default "(none)"
depends on BOARD_ID_MANUAL
config BOOTSPLASH_FILE
depends on BOOTSPLASH_IMAGE
default "bootsplash.jpg"
config CBFS_SIZE
default ROM_SIZE