coreboot-kgpe-d16/src/Kconfig

1142 lines
29 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.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
##
mainmenu "coreboot configuration"
menu "General setup"
config EXPERT
bool "Expert mode"
help
This allows you to select certain advanced configuration options.
Warning: Only enable this option if you really know what you are
doing! You have been warned!
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.
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"
help
Use LLVM/clang to build coreboot.
For details see http://clang.llvm.org.
endchoice
config ANY_TOOLCHAIN
bool "Allow building with any toolchain"
default n
depends on COMPILER_GCC
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 SCONFIG_GENPARSER
bool "Generate SCONFIG parser using flex and bison"
default n
depends on EXPERT
help
Enable this option if you are working on the sconfig device tree
parser and made changes to sconfig.l and sconfig.y.
Otherwise, say N.
config USE_OPTION_TABLE
bool "Use CMOS for configuration values"
default n
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 COMPRESS_RAMSTAGE
bool "Compress ramstage with LZMA"
default y
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 INCLUDE_CONFIG_FILE
bool "Include the coreboot .config file into the ROM image"
default y
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 EARLY_CBMEM_INIT
bool
default n
help
Make coreboot initialize the CBMEM structures while running in ROM
stage. This is useful when the ROM stage wants to communicate
some, for instance, execution timestamps. It needs support in
romstage.c and should be enabled by the board's Kconfig.
config BROKEN_CAR_MIGRATE
bool
default y if !EARLY_CBMEM_INIT && HAVE_ACPI_RESUME
default n
help
Many boards use CAR_GLOBAL but have no EARLY_CBMEM_INIT and
manage CAR migration on S3 resume path only. Couple boards use
CAR_GLOBAL and never do CAR migration.
cbmem: dynamic cbmem support This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13 18:41:44 +01:00
config DYNAMIC_CBMEM
bool "The CBMEM space is dynamically grown."
default n
select EARLY_CBMEM_INIT
cbmem: dynamic cbmem support This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13 18:41:44 +01:00
help
Instead of reserving a static amount of CBMEM space the CBMEM
area grows dynamically. CBMEM can be used both in romstage (after
memory initialization) and ramstage.
config COLLECT_TIMESTAMPS
bool "Create a table of timestamps collected during boot"
default n
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"
default n
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
default n
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 RELOCATABLE_MODULES
bool "Relocatable Modules"
default n
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 RELOCATABLE_RAMSTAGE
depends on (RELOCATABLE_MODULES && DYNAMIC_CBMEM)
bool "Build the ramstage to be relocatable in 32-bit address space."
default n
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 "Cache the relocated ramstage outside of cbmem."
coreboot arm64: Add support for arm64 into coreboot framework Add support for enabling different coreboot stages (bootblock, romstage and ramstage) to have arm64 architecture. Most of the files have been copied over from arm/ or arm64-generic work. Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/197397 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934) This patch is essentially a squash of aarch64 changes made by these patches: d955885 coreboot: Rename coreboot_ram stage to ramstage a492761 cbmem console: Locate the preram console with a symbol instead of a sect 96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3 3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage 25fd2e9 aarch64: Remove CAR definitions from early_variables.h 65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM 9484873 aarch64: Change default exception level to EL2 7a152c3 aarch64: Fix formatting of exception registers dump 6946464 aarch64: Implement basic exception handling c732a9d aarch64/foundation-armv8: Basic bootblock implementation 3bc412c aarch64: Comment out some parts of code to allow build ab5be71 Add initial aarch64 support The ramstage support is the only portion that has been tested on actual hardware. Bootblock and romstage support may require modifications to run on hardware. Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6915 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2014-04-29 01:39:40 +02:00
default n
help
The relocated ramstage is saved in an area specified by the
by the board and/or chipset.
choice
prompt "Bootblock behaviour"
default BOOTBLOCK_SIMPLE
config BOOTBLOCK_SIMPLE
bool "Always load fallback"
config BOOTBLOCK_NORMAL
bool "Switch to normal if CMOS says so"
endchoice
config BOOTBLOCK_SOURCE
string
default "bootblock_simple.c" if BOOTBLOCK_SIMPLE
default "bootblock_normal.c" if BOOTBLOCK_NORMAL
config UPDATE_IMAGE
bool "Update existing coreboot.rom image"
default n
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.
endmenu
source src/mainboard/Kconfig
# This option is used to set the architecture of a mainboard to X86.
# It is usually set in mainboard/*/Kconfig.
config ARCH_X86
bool
default n
select PCI
config ARCH_ARM
bool
default n
config ARCH_ARM64
bool
default n
source src/arch/x86/Kconfig
source src/arch/arm/Kconfig
source src/arch/arm64/Kconfig
source src/vendorcode/Kconfig
config SYSTEM_TYPE_LAPTOP
default n
bool
menu "Chipset"
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/Kconfig
comment "SoC"
source src/soc/Kconfig
source src/drivers/intel/fsp/Kconfig
endmenu
source src/device/Kconfig
menu "Generic Drivers"
source src/drivers/Kconfig
endmenu
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
select LPC_TPM if ARCH_X86
ARM: Generalize armv7 as arm. There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)
2013-10-01 08:00:33 +02:00
select I2C_TPM if ARCH_ARM
coreboot arm64: Add support for arm64 into coreboot framework Add support for enabling different coreboot stages (bootblock, romstage and ramstage) to have arm64 architecture. Most of the files have been copied over from arm/ or arm64-generic work. Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/197397 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934) This patch is essentially a squash of aarch64 changes made by these patches: d955885 coreboot: Rename coreboot_ram stage to ramstage a492761 cbmem console: Locate the preram console with a symbol instead of a sect 96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3 3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage 25fd2e9 aarch64: Remove CAR definitions from early_variables.h 65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM 9484873 aarch64: Change default exception level to EL2 7a152c3 aarch64: Fix formatting of exception registers dump 6946464 aarch64: Implement basic exception handling c732a9d aarch64/foundation-armv8: Basic bootblock implementation 3bc412c aarch64: Comment out some parts of code to allow build ab5be71 Add initial aarch64 support The ramstage support is the only portion that has been tested on actual hardware. Bootblock and romstage support may require modifications to run on hardware. Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6915 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2014-04-29 01:39:40 +02:00
select I2C_TPM if ARCH_ARM64
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.
config HEAP_SIZE
hex
default 0x4000
config MAX_CPUS
int
default 1
config MMCONF_SUPPORT_DEFAULT
bool
default n
config MMCONF_SUPPORT
bool
default n
config BOOTMODE_STRAPS
bool
default n
source src/console/Kconfig
config HAVE_ACPI_RESUME
bool
default n
config HAVE_ACPI_SLIC
bool
default n
config ACPI_SSDTX_NUM
int
default 0
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_MONOTONIC_TIMER
def_bool n
help
The board/chipset provides a 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 CBFS_SIZE
hex
default ROM_SIZE
config CACHE_ROM_SIZE_OVERRIDE
hex
default 0
# TODO: Can probably be removed once all chipsets have kconfig options for it.
config VIDEO_MB
int
default 0
config USE_WATCHDOG_ON_BOOT
bool
default n
config VGA
bool
default n
help
Build board-specific VGA code.
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 PER_DEVICE_ACPI_TABLES
bool
default n
#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.
endmenu
menu "Payload"
choice
prompt "Add a payload"
default PAYLOAD_NONE if !ARCH_X86
default PAYLOAD_SEABIOS if ARCH_X86
config PAYLOAD_NONE
bool "None"
help
Select this option if you want to create an "empty" coreboot
ROM image for a certain mainboard, i.e. a coreboot ROM image
which does not yet contain a payload.
For such an image to be useful, you have to use 'cbfstool'
to add a payload to the ROM image later.
config PAYLOAD_ELF
bool "An ELF executable payload"
help
Select this option if you have a payload image (an ELF file)
which coreboot should run as soon as the basic hardware
initialization is completed.
You will be able to specify the location and file name of the
payload image later.
config PAYLOAD_LINUX
bool "A Linux payload"
help
Select this option if you have a Linux bzImage which coreboot
should run as soon as the basic hardware initialization
is completed.
You will be able to specify the location and file name of the
payload image later.
config PAYLOAD_SEABIOS
bool "SeaBIOS"
depends on ARCH_X86
help
Select this option if you want to build a coreboot image
with a SeaBIOS payload. If you don't know what this is
about, just leave it enabled.
See http://coreboot.org/Payloads for more information.
config PAYLOAD_FILO
bool "FILO"
help
Select this option if you want to build a coreboot image
with a FILO payload. If you don't know what this is
about, just leave it enabled.
See http://coreboot.org/Payloads for more information.
config PAYLOAD_GRUB2
bool "GRUB2"
help
Select this option if you want to build a coreboot image
with a GRUB2 payload. If you don't know what this is
about, just leave it enabled.
See http://coreboot.org/Payloads for more information.
Project PIANO aka tianocoreboot This is a Tiano Core loader payload based on libpayload. It will load a Tiano Core DXE core from an UEFI firmware volume stored in CBFS. Currently Tiano Core dies because it does not find all the UEFI services it needs: coreboot-4.0-3316-gc5c9ff8-dirty Mon Jan 28 15:37:12 PST 2013 starting... [..] Tiano Core Loader v1.0 Copyright (C) 2013 Google Inc. All rights reserved. Memory Map (5 entries): 1. 0000000000000000 - 0000000000000fff [10] 2. 0000000000001000 - 000000000009ffff [01] 3. 00000000000c0000 - 0000000003ebffff [01] 4. 0000000003ec0000 - 0000000003ffffff [10] 5. 00000000ff800000 - 00000000ffffffff [02] DXE code: 03e80000 DXE stack: 03e60000 HOB list: 03d5c000 Found UEFI firmware volume. GUID: 8c8ce578-8a3d-4f1c-9935-896185c32dd3 length: 0x0000000000260000 Found DXE core at 0xffc14e0c Section 0: .text size=000158a0 rva=00000240 in file=000158a0/00000240 flags=60000020 Section 1: .data size=00006820 rva=00015ae0 in file=00006820/00015ae0 flags=c0000040 Section 2: .reloc size=000010a0 rva=0001c300 in file=000010a0/0001c300 flags=42000040 Jumping to DXE core at 0x3e80000 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3E96708 HOBLIST address in DXE = 0x3E56010 Memory Allocation 0x00000003 0x3E80000 - 0x3EBFFFF FV Hob 0xFFC14D78 - 0xFFE74D77 InstallProtocolInterface: D8117CFE-94A6-11D4-9A3A-0090273FC14D 3E95EA0 InstallProtocolInterface: EE4E5898-3914-4259-9D6E-DC7BD79403CF 3E9630C Security Arch Protocol not present!! CPU Arch Protocol not present!! Metronome Arch Protocol not present!! Timer Arch Protocol not present!! Bds Arch Protocol not present!! Watchdog Timer Arch Protocol not present!! Runtime Arch Protocol not present!! Variable Arch Protocol not present!! Variable Write Arch Protocol not present!! Capsule Arch Protocol not present!! Monotonic Counter Arch Protocol not present!! Reset Arch Protocol not present!! Real Time Clock Arch Protocol not present!! ASSERT_EFI_ERROR (Status = Not Found) ASSERT /home/reinauer/svn/Tiano/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c(461): !EFI_ERROR (Status) Change-Id: I14068e9a28ff67ab1bf03105d56dab2e8be7b230 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2154 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-16 02:02:58 +01:00
config PAYLOAD_TIANOCORE
bool "Tiano Core"
help
Select this option if you want to build a coreboot image
with a Tiano Core payload. If you don't know what this is
about, just leave it enabled.
See http://coreboot.org/Payloads for more information.
endchoice
choice
prompt "SeaBIOS version"
default SEABIOS_STABLE
depends on PAYLOAD_SEABIOS
config SEABIOS_STABLE
bool "1.7.5"
help
Stable SeaBIOS version
config SEABIOS_MASTER
bool "master"
help
Newest SeaBIOS version
endchoice
config SEABIOS_PS2_TIMEOUT
prompt "PS/2 keyboard controller initialization timeout (milliseconds)" if PAYLOAD_SEABIOS
default 0
depends on EXPERT
int
help
Some PS/2 keyboard controllers don't respond to commands immediately
after powering on. This specifies how long SeaBIOS will wait for the
keyboard controller to become ready before giving up.
config SEABIOS_THREAD_OPTIONROMS
prompt "Hardware init during option ROM execution" if PAYLOAD_SEABIOS
default n
bool
help
Allow hardware init to run in parallel with optionrom execution.
This can reduce boot time, but can cause some timing
variations during option ROM code execution. It is not
known if all option ROMs will behave properly with this option.
config SEABIOS_MALLOC_UPPERMEMORY
bool
default y
depends on PAYLOAD_SEABIOS
help
Use the "Upper Memory Block" area (0xc0000-0xf0000) for internal
"low memory" allocations. If this is not selected, the memory is
instead allocated from the "9-segment" (0x90000-0xa0000).
This is not typically needed, but may be required on some platforms
to allow USB and SATA buffers to be written correctly by the
hardware. In general, if this is desired, the option will be
set to 'N' by the chipset Kconfig.
config SEABIOS_VGA_COREBOOT
prompt "Include generated option rom that implements legacy VGA BIOS compatibility" if PAYLOAD_SEABIOS
default n
depends on !VGA_BIOS && MAINBOARD_DO_NATIVE_VGA_INIT
bool
help
Coreboot can initialize the GPU of some mainboards.
After initializing the GPU, the information about it can be passed to the payload.
Provide an option rom that implements this legacy VGA BIOS compatibility requirement.
choice
prompt "GRUB2 version"
default GRUB2_MASTER
depends on PAYLOAD_GRUB2
config GRUB2_MASTER
bool "HEAD"
help
Newest GRUB2 version
endchoice
choice
prompt "FILO version"
default FILO_STABLE
depends on PAYLOAD_FILO
config FILO_STABLE
bool "0.6.0"
help
Stable FILO version
config FILO_MASTER
bool "HEAD"
help
Newest FILO version
endchoice
config PAYLOAD_FILE
string "Payload path and filename"
depends on PAYLOAD_ELF
default "payload.elf"
help
The path and filename of the ELF executable file to use as payload.
config PAYLOAD_FILE
string "Linux path and filename"
depends on PAYLOAD_LINUX
default "bzImage"
help
The path and filename of the bzImage kernel to use as payload.
config PAYLOAD_FILE
depends on PAYLOAD_SEABIOS
default "payloads/external/SeaBIOS/seabios/out/bios.bin.elf"
config PAYLOAD_VGABIOS_FILE
string
depends on PAYLOAD_SEABIOS && SEABIOS_VGA_COREBOOT
default "payloads/external/SeaBIOS/seabios/out/vgabios.bin"
config PAYLOAD_FILE
depends on PAYLOAD_FILO
default "payloads/external/FILO/filo/build/filo.elf"
config PAYLOAD_FILE
depends on PAYLOAD_GRUB2
default "payloads/external/GRUB2/grub2/build/default_payload.elf"
config PAYLOAD_FILE
string "Tianocore firmware volume"
depends on PAYLOAD_TIANOCORE
default "COREBOOT.fd"
help
The result of a corebootPkg build
# TODO: Defined if no payload? Breaks build?
config COMPRESSED_PAYLOAD_LZMA
bool "Use LZMA compression for payloads"
default y
depends on PAYLOAD_ELF || PAYLOAD_SEABIOS || PAYLOAD_FILO || PAYLOAD_TIANOCORE || PAYLOAD_GRUB2
help
In order to reduce the size payloads take up in the ROM chip
coreboot can compress them using the LZMA algorithm.
config LINUX_COMMAND_LINE
string "Linux command line"
depends on PAYLOAD_LINUX
default ""
help
A command line to add to the Linux kernel.
config LINUX_INITRD
string "Linux initrd"
depends on PAYLOAD_LINUX
default ""
help
An initrd image to add to the Linux kernel.
endmenu
menu "Debugging"
# TODO: Better help text and detailed instructions.
config GDB_STUB
bool "GDB debugging support"
default n
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"
default n
depends on GDB_STUB
help
If enabled, coreboot will wait for a GDB connection.
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
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
depends on TPM
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 releated 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.
endmenu
# These probably belong somewhere else, but they are needed somewhere.
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 y if ARCH_X86
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
# Maximum reboot count
# TODO: Improve description.
config MAX_REBOOT_CNT
int
default 3