2009-08-12 17:00:51 +02:00
|
|
|
##
|
2010-01-20 19:44:30 +01:00
|
|
|
## This file is part of the coreboot project.
|
2009-08-12 17:00:51 +02:00
|
|
|
##
|
2012-08-23 09:32:58 +02:00
|
|
|
## Copyright (C) 2012 Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
2010-01-20 19:44:30 +01:00
|
|
|
## Copyright (C) 2009-2010 coresystems GmbH
|
2009-08-12 17:00:51 +02:00
|
|
|
##
|
2010-01-20 19:44:30 +01:00
|
|
|
## 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.
|
|
|
|
|
##
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2012-04-12 22:00:03 +02:00
|
|
|
mainmenu "coreboot configuration"
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2009-10-05 15:55:28 +02:00
|
|
|
menu "General setup"
|
|
|
|
|
|
|
|
|
|
config LOCALVERSION
|
2009-10-07 18:15:40 +02:00
|
|
|
string "Local version string"
|
2009-10-05 15:55:28 +02:00
|
|
|
help
|
|
|
|
|
Append an extra string to the end of the coreboot version.
|
|
|
|
|
|
2009-10-07 18:15:40 +02:00
|
|
|
This can be useful if, for instance, you want to append the
|
|
|
|
|
respective board's hostname or some other identifying string to
|
|
|
|
|
the coreboot version number, so that you can easily distinguish
|
|
|
|
|
boot logs of different boards from each other.
|
|
|
|
|
|
2010-02-09 20:35:16 +01:00
|
|
|
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.
|
|
|
|
|
|
2010-03-16 02:17:19 +01:00
|
|
|
choice
|
2012-04-12 22:00:03 +02:00
|
|
|
prompt "Compiler to use"
|
2010-03-16 02:17:19 +01:00
|
|
|
default COMPILER_GCC
|
|
|
|
|
help
|
|
|
|
|
This option allows you to select the compiler used for building
|
|
|
|
|
coreboot.
|
2016-01-19 20:01:09 +01:00
|
|
|
You must build the coreboot crosscompiler for the board that you
|
|
|
|
|
have selected.
|
|
|
|
|
|
|
|
|
|
To build all the GCC crosscompilers (takes a LONG time), run:
|
|
|
|
|
make crossgcc
|
|
|
|
|
|
|
|
|
|
For help on individual architectures, run the command:
|
|
|
|
|
make help_toolchain
|
2010-03-16 02:17:19 +01:00
|
|
|
|
|
|
|
|
config COMPILER_GCC
|
|
|
|
|
bool "GCC"
|
2012-04-12 22:00:03 +02:00
|
|
|
help
|
|
|
|
|
Use the GNU Compiler Collection (GCC) to build coreboot.
|
|
|
|
|
|
|
|
|
|
For details see http://gcc.gnu.org.
|
|
|
|
|
|
2010-03-16 02:17:19 +01:00
|
|
|
config COMPILER_LLVM_CLANG
|
2016-01-19 20:01:09 +01:00
|
|
|
bool "LLVM/clang (TESTING ONLY - Not currently working)"
|
2012-04-12 22:00:03 +02:00
|
|
|
help
|
2016-01-19 20:01:09 +01:00
|
|
|
Use LLVM/clang to build coreboot. To use this, you must build the
|
|
|
|
|
coreboot version of the clang compiler. Run the command
|
|
|
|
|
make clang
|
|
|
|
|
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.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
|
|
|
|
For details see http://clang.llvm.org.
|
|
|
|
|
|
2010-03-16 02:17:19 +01:00
|
|
|
endchoice
|
|
|
|
|
|
2013-12-29 18:45:23 +01:00
|
|
|
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.
|
|
|
|
|
|
2010-03-25 22:45:25 +01:00
|
|
|
config CCACHE
|
2012-04-12 22:00:03 +02:00
|
|
|
bool "Use ccache to speed up (re)compilation"
|
2010-03-25 22:45:25 +01:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enables the use of ccache for faster builds.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
|
|
|
|
Requires the ccache utility in your system $PATH.
|
|
|
|
|
|
|
|
|
|
For details see https://ccache.samba.org.
|
2010-03-25 22:45:25 +01:00
|
|
|
|
2015-02-26 20:47:19 +01:00
|
|
|
config FMD_GENPARSER
|
|
|
|
|
bool "Generate flashmap descriptor parser using flex and bison"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable this option if you are working on the flashmap descriptor
|
|
|
|
|
parser and made changes to fmd_scanner.l or fmd_parser.y.
|
|
|
|
|
|
|
|
|
|
Otherwise, say N to use the provided pregenerated scanner/parser.
|
|
|
|
|
|
2010-08-09 15:28:18 +02:00
|
|
|
config SCONFIG_GENPARSER
|
|
|
|
|
bool "Generate SCONFIG parser using flex and bison"
|
|
|
|
|
default n
|
|
|
|
|
help
|
2012-04-12 22:00:03 +02:00
|
|
|
Enable this option if you are working on the sconfig device tree
|
2015-02-26 20:47:19 +01:00
|
|
|
parser and made changes to sconfig.l or sconfig.y.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
2015-02-26 20:47:19 +01:00
|
|
|
Otherwise, say N to use the provided pregenerated scanner/parser.
|
2010-08-09 15:28:18 +02:00
|
|
|
|
2010-05-19 20:41:15 +02:00
|
|
|
config USE_OPTION_TABLE
|
|
|
|
|
bool "Use CMOS for configuration values"
|
|
|
|
|
default n
|
2010-07-06 23:05:04 +02:00
|
|
|
depends on HAVE_OPTION_TABLE
|
2010-05-19 20:41:15 +02:00
|
|
|
help
|
|
|
|
|
Enable this option if coreboot shall read options from the "CMOS"
|
2012-04-12 22:00:03 +02:00
|
|
|
NVRAM instead of using hard-coded values.
|
2010-05-19 20:41:15 +02:00
|
|
|
|
2015-02-14 23:15:31 +01:00
|
|
|
config STATIC_OPTION_TABLE
|
|
|
|
|
bool "Load default configuration values into CMOS on each boot"
|
|
|
|
|
default n
|
|
|
|
|
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.
|
|
|
|
|
|
2014-12-09 21:18:00 +01:00
|
|
|
config UNCOMPRESSED_RAMSTAGE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2011-05-02 21:53:04 +02:00
|
|
|
config COMPRESS_RAMSTAGE
|
|
|
|
|
bool "Compress ramstage with LZMA"
|
2014-12-09 21:18:00 +01:00
|
|
|
default y if !UNCOMPRESSED_RAMSTAGE
|
|
|
|
|
default n
|
2011-05-02 21:53:04 +02:00
|
|
|
help
|
|
|
|
|
Compress ramstage to save memory in the flash image. Note
|
|
|
|
|
that decompression might slow down booting if the boot flash
|
2012-04-12 22:00:03 +02:00
|
|
|
is connected through a slow link (i.e. SPI).
|
2011-05-02 21:53:04 +02:00
|
|
|
|
2015-09-29 22:51:35 +02:00
|
|
|
config COMPRESS_PRERAM_STAGES
|
|
|
|
|
bool "Compress romstage and verstage with LZ4"
|
2016-03-09 23:50:23 +01:00
|
|
|
depends on !ARCH_X86
|
|
|
|
|
default y
|
2015-09-29 22:51:35 +02:00
|
|
|
help
|
|
|
|
|
Compress romstage and (if it exists) verstage with LZ4 to save flash
|
|
|
|
|
space and speed up boot, since the time for reading the image from SPI
|
|
|
|
|
(and in the vboot case verifying it) is usually much greater than the
|
|
|
|
|
time spent decompressing. Doesn't work for XIP stages (assume all
|
|
|
|
|
ARCH_X86 for now) for obvious reasons.
|
|
|
|
|
|
2011-06-19 03:03:28 +02:00
|
|
|
config INCLUDE_CONFIG_FILE
|
2012-04-12 22:00:03 +02:00
|
|
|
bool "Include the coreboot .config file into the ROM image"
|
2011-06-19 03:03:28 +02:00
|
|
|
default y
|
2012-04-12 22:00:03 +02:00
|
|
|
help
|
|
|
|
|
Include the .config file that was used to compile coreboot
|
|
|
|
|
in the (CBFS) ROM image. This is useful if you want to know which
|
|
|
|
|
options were used to build a specific coreboot.rom image.
|
|
|
|
|
|
2014-07-22 18:00:56 +02:00
|
|
|
Saying Y here will increase the image size by 2-3KB.
|
2012-04-12 22:00:03 +02:00
|
|
|
|
|
|
|
|
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
|
2012-05-18 19:18:47 +02:00
|
|
|
|
2012-04-12 22:00:03 +02:00
|
|
|
Name Offset Type Size
|
|
|
|
|
cmos_layout.bin 0x0 cmos layout 1159
|
|
|
|
|
fallback/romstage 0x4c0 stage 339756
|
2014-07-22 18:00:56 +02:00
|
|
|
fallback/ramstage 0x53440 stage 186664
|
2012-04-12 22:00:03 +02:00
|
|
|
fallback/payload 0x80dc0 payload 51526
|
|
|
|
|
config 0x8d740 raw 3324
|
|
|
|
|
(empty) 0x8e480 null 3610440
|
2011-06-19 03:03:28 +02:00
|
|
|
|
2016-05-05 08:25:16 +02:00
|
|
|
config NO_XIP_EARLY_STAGES
|
|
|
|
|
bool
|
|
|
|
|
default n if ARCH_X86
|
|
|
|
|
default y
|
|
|
|
|
help
|
2016-06-01 10:53:18 +02:00
|
|
|
Identify if early stages are eXecute-In-Place(XIP).
|
2016-05-05 08:25:16 +02:00
|
|
|
|
2013-10-11 21:08:02 +02:00
|
|
|
config EARLY_CBMEM_INIT
|
2014-12-18 21:22:04 +01:00
|
|
|
def_bool !LATE_CBMEM_INIT
|
|
|
|
|
|
2016-07-25 04:52:15 +02:00
|
|
|
config EARLY_CBMEM_LIST
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable display of CBMEM during romstage and postcar.
|
|
|
|
|
|
2011-09-21 23:46:43 +02:00
|
|
|
config COLLECT_TIMESTAMPS
|
|
|
|
|
bool "Create a table of timestamps collected during boot"
|
2013-10-11 20:14:59 +02:00
|
|
|
default n
|
2011-09-21 23:46:43 +02:00
|
|
|
help
|
2012-04-12 22:00:03 +02:00
|
|
|
Make coreboot create a table of timer-ID/timer-value pairs to
|
|
|
|
|
allow measuring time spent at different phases of the boot process.
|
|
|
|
|
|
2012-04-30 21:06:10 +02:00
|
|
|
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.
|
|
|
|
|
|
Implement GCC code coverage analysis
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-19 01:23:28 +01:00
|
|
|
config COVERAGE
|
|
|
|
|
bool "Code coverage support"
|
|
|
|
|
depends on COMPILER_GCC
|
|
|
|
|
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.
|
|
|
|
|
|
2014-10-17 13:08:36 +02:00
|
|
|
config RELOCATABLE_MODULES
|
2015-05-30 22:21:37 +02:00
|
|
|
bool
|
2010-12-17 00:37:17 +01:00
|
|
|
default n
|
2014-10-17 13:08:36 +02:00
|
|
|
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.
|
2012-11-30 01:28:21 +01:00
|
|
|
|
2014-10-17 13:08:36 +02:00
|
|
|
config RELOCATABLE_RAMSTAGE
|
2015-05-30 22:21:37 +02:00
|
|
|
depends on EARLY_CBMEM_INIT
|
2014-10-17 13:08:36 +02:00
|
|
|
bool "Build the ramstage to be relocatable in 32-bit address space."
|
2012-11-29 05:16:28 +01:00
|
|
|
default n
|
2015-05-30 22:21:37 +02:00
|
|
|
select RELOCATABLE_MODULES
|
2014-10-17 13:08:36 +02:00
|
|
|
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.
|
2012-11-29 05:16:28 +01:00
|
|
|
|
2014-10-17 13:08:36 +02:00
|
|
|
config CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
|
|
|
|
|
depends on RELOCATABLE_RAMSTAGE
|
|
|
|
|
bool "Cache the relocated ramstage outside of cbmem."
|
2014-04-29 01:39:40 +02:00
|
|
|
default n
|
2014-10-17 13:08:36 +02:00
|
|
|
help
|
|
|
|
|
The relocated ramstage is saved in an area specified by the
|
|
|
|
|
by the board and/or chipset.
|
2014-02-07 03:58:24 +01:00
|
|
|
|
2016-05-06 18:20:35 +02:00
|
|
|
config NO_STAGE_CACHE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Do not save any component in stage cache for resume path. On resume,
|
|
|
|
|
all components would be read back from CBFS again.
|
|
|
|
|
|
2015-10-09 22:37:58 +02:00
|
|
|
# TODO: This doesn't belong here, move to src/arch/x86/Kconfig
|
2014-05-07 03:00:19 +02:00
|
|
|
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
|
|
|
|
|
|
2015-10-09 22:37:58 +02:00
|
|
|
# To be selected by arch, SoC or mainboard if it does not want use the normal
|
|
|
|
|
# src/lib/bootblock.c#main() C entry point.
|
|
|
|
|
config BOOTBLOCK_CUSTOM
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2014-05-07 03:00:19 +02:00
|
|
|
config BOOTBLOCK_SOURCE
|
|
|
|
|
string
|
|
|
|
|
default "bootblock_simple.c" if BOOTBLOCK_SIMPLE
|
|
|
|
|
default "bootblock_normal.c" if BOOTBLOCK_NORMAL
|
|
|
|
|
|
2015-10-03 03:01:18 +02:00
|
|
|
# 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).
|
|
|
|
|
config C_ENVIRONMENT_BOOTBLOCK
|
2016-01-21 20:30:52 +01:00
|
|
|
bool
|
|
|
|
|
default n
|
2015-10-03 03:01:18 +02:00
|
|
|
|
2015-03-16 17:47:45 +01:00
|
|
|
config SKIP_MAX_REBOOT_CNT_CLEAR
|
|
|
|
|
bool "Do not clear reboot count after successful boot"
|
|
|
|
|
default n
|
2015-11-01 09:13:17 +01:00
|
|
|
depends on BOOTBLOCK_NORMAL
|
2015-03-16 17:47:45 +01:00
|
|
|
help
|
|
|
|
|
Do not clear the reboot count immediately after successful boot.
|
|
|
|
|
Set to allow the payload to control normal/fallback image recovery.
|
2015-11-01 09:13:17 +01:00
|
|
|
Note that it is the responsibility of the payload to reset the
|
|
|
|
|
normal boot bit to 1 after each successsful boot.
|
2015-03-16 17:47:45 +01:00
|
|
|
|
2014-05-07 03:00:19 +02:00
|
|
|
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.
|
|
|
|
|
|
2016-01-20 22:59:21 +01:00
|
|
|
If unsure, select 'N'
|
|
|
|
|
|
2015-03-27 00:29:00 +01:00
|
|
|
config GENERIC_GPIO_LIB
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
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 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
|
2015-05-30 22:47:22 +02:00
|
|
|
bool
|
2015-03-27 00:29:00 +01:00
|
|
|
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 BOARD_ID_STRING
|
|
|
|
|
string "Board ID"
|
|
|
|
|
default "(none)"
|
|
|
|
|
depends on BOARD_ID_MANUAL
|
|
|
|
|
help
|
|
|
|
|
This string is placed in the 'board_id' CBFS file for indicating
|
|
|
|
|
board type.
|
|
|
|
|
|
2014-11-04 02:42:09 +01:00
|
|
|
config RAM_CODE_SUPPORT
|
2015-05-30 22:55:44 +02:00
|
|
|
bool
|
2014-11-04 02:42:09 +01:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
If enabled, coreboot discovers RAM configuration (value obtained by
|
|
|
|
|
reading board straps) and stores it in coreboot table.
|
|
|
|
|
|
2015-01-24 15:52:10 +01:00
|
|
|
config BOOTSPLASH_IMAGE
|
|
|
|
|
bool "Add a bootsplash image"
|
|
|
|
|
help
|
|
|
|
|
Select this option if you have a bootsplash image that you would
|
|
|
|
|
like to add to your ROM.
|
|
|
|
|
|
|
|
|
|
This will only add the image to the ROM. To actually run it check
|
|
|
|
|
options under 'Display' section.
|
|
|
|
|
|
|
|
|
|
config BOOTSPLASH_FILE
|
|
|
|
|
string "Bootsplash path and filename"
|
|
|
|
|
depends on BOOTSPLASH_IMAGE
|
|
|
|
|
default "bootsplash.jpg"
|
|
|
|
|
help
|
|
|
|
|
The path and filename of the file to use as graphical bootsplash
|
|
|
|
|
screen. The file format has to be jpg.
|
|
|
|
|
|
2014-10-17 13:08:36 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2015-06-20 07:17:15 +02:00
|
|
|
menu "Mainboard"
|
|
|
|
|
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/mainboard/Kconfig"
|
2014-10-17 13:08:36 +02:00
|
|
|
|
2016-09-04 16:38:33 +02:00
|
|
|
config DEVICETREE
|
|
|
|
|
string
|
|
|
|
|
default "devicetree.cb"
|
|
|
|
|
help
|
|
|
|
|
This symbol allows mainboards to select a different file under their
|
|
|
|
|
mainboard directory for the devicetree.cb file. This allows the board
|
|
|
|
|
variants that need different devicetrees to be in the same directory.
|
|
|
|
|
|
|
|
|
|
Examples: "devicetree.variant.cb"
|
|
|
|
|
"variant/devicetree.cb"
|
|
|
|
|
|
Kconfig: Move defaults for CBFS_SIZE
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-02-09 17:06:46 +01:00
|
|
|
# defaults for CBFS_SIZE are set at the end of the file.
|
2015-06-20 07:17:15 +02:00
|
|
|
config CBFS_SIZE
|
|
|
|
|
hex "Size of CBFS filesystem in ROM"
|
|
|
|
|
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.
|
|
|
|
|
|
2015-09-16 18:10:52 +02:00
|
|
|
config FMDFILE
|
|
|
|
|
string "fmap description file in fmd format"
|
2015-12-12 00:23:15 +01:00
|
|
|
default "src/mainboard/$(CONFIG_MAINBOARD_DIR)/chromeos.fmd" if CHROMEOS
|
2015-09-16 18:10:52 +02:00
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
The build system creates a default FMAP from ROM_SIZE and CBFS_SIZE,
|
|
|
|
|
but in some cases more complex setups are required.
|
|
|
|
|
When an fmd is specified, it overrides the default format.
|
|
|
|
|
|
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.
|
|
|
|
|
|
2015-12-27 00:51:16 +01:00
|
|
|
endmenu
|
|
|
|
|
|
2016-01-25 03:38:33 +01:00
|
|
|
# load site-local kconfig to allow user specific defaults and overrides
|
|
|
|
|
source "site-local/Kconfig"
|
|
|
|
|
|
2014-10-17 13:08:36 +02:00
|
|
|
config SYSTEM_TYPE_LAPTOP
|
2015-04-27 02:53:26 +02:00
|
|
|
default n
|
|
|
|
|
bool
|
2014-10-17 13:08:36 +02:00
|
|
|
|
2016-01-14 15:08:36 +01:00
|
|
|
config CBFS_AUTOGEN_ATTRIBUTES
|
|
|
|
|
default n
|
|
|
|
|
bool
|
|
|
|
|
help
|
|
|
|
|
If this option is selected, every file in cbfs which has a constraint
|
|
|
|
|
regarding position or alignment will get an additional file attribute
|
|
|
|
|
which describes this constraint.
|
|
|
|
|
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
menu "Chipset"
|
|
|
|
|
|
2015-06-09 03:11:56 +02:00
|
|
|
comment "SoC"
|
|
|
|
|
source "src/soc/*/*/Kconfig"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "CPU"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/cpu/Kconfig"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "Northbridge"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/northbridge/*/*/Kconfig"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "Southbridge"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/southbridge/*/*/Kconfig"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
comment "Super I/O"
|
2016-07-29 23:31:45 +02:00
|
|
|
source "src/superio/*/*/Kconfig"
|
2011-01-27 12:43:03 +01:00
|
|
|
comment "Embedded Controllers"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/ec/acpi/Kconfig"
|
|
|
|
|
source "src/ec/*/*/Kconfig"
|
2016-03-12 05:22:28 +01:00
|
|
|
# FIXME move to vendorcode
|
2015-04-23 07:16:31 +02:00
|
|
|
source "src/drivers/intel/fsp1_0/Kconfig"
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
|
2015-06-21 00:17:12 +02:00
|
|
|
source "src/southbridge/intel/common/firmware/Kconfig"
|
2016-07-25 20:48:03 +02:00
|
|
|
source "src/vboot/Kconfig"
|
2015-06-20 06:30:43 +02:00
|
|
|
source "src/vendorcode/*/Kconfig"
|
2015-06-21 00:17:12 +02:00
|
|
|
|
2015-06-20 06:30:43 +02:00
|
|
|
source "src/arch/*/Kconfig"
|
|
|
|
|
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
endmenu
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/device/Kconfig"
|
2012-11-14 02:00:01 +01:00
|
|
|
|
2010-05-16 17:31:53 +02:00
|
|
|
menu "Generic Drivers"
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/drivers/*/Kconfig"
|
2016-03-12 05:22:28 +01:00
|
|
|
source "src/drivers/*/*/Kconfig"
|
2010-05-16 17:31:53 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2016-05-17 19:28:23 +02:00
|
|
|
source "src/acpi/Kconfig"
|
|
|
|
|
|
2016-08-11 18:02:26 +02:00
|
|
|
# This option is for the current boards/chipsets where SPI flash
|
|
|
|
|
# is not the boot device. Currently nearly all boards/chipsets assume
|
|
|
|
|
# SPI flash is the boot device.
|
|
|
|
|
config BOOT_DEVICE_NOT_SPI_FLASH
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config BOOT_DEVICE_SPI_FLASH
|
|
|
|
|
bool
|
|
|
|
|
default y if !BOOT_DEVICE_NOT_SPI_FLASH
|
|
|
|
|
default n
|
|
|
|
|
|
2016-08-11 21:04:10 +02:00
|
|
|
config BOOT_DEVICE_MEMORY_MAPPED
|
|
|
|
|
bool
|
|
|
|
|
default y if ARCH_X86 && BOOT_DEVICE_SPI_FLASH
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Inform system if SPI is memory-mapped or not.
|
|
|
|
|
|
2016-08-12 22:00:10 +02:00
|
|
|
config BOOT_DEVICE_SUPPORTS_WRITES
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Indicate that the platform has writable boot device
|
|
|
|
|
support.
|
|
|
|
|
|
2015-04-22 13:28:21 +02:00
|
|
|
config RTC
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
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
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config HEAP_SIZE
|
|
|
|
|
hex
|
2009-10-16 21:12:49 +02:00
|
|
|
default 0x4000
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2014-09-19 22:18:16 +02:00
|
|
|
config STACK_SIZE
|
|
|
|
|
hex
|
2015-10-13 01:45:21 +02:00
|
|
|
default 0x1000 if ARCH_X86
|
|
|
|
|
default 0x0
|
2014-09-19 22:18:16 +02:00
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config MAX_CPUS
|
|
|
|
|
int
|
|
|
|
|
default 1
|
|
|
|
|
|
|
|
|
|
config MMCONF_SUPPORT_DEFAULT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config MMCONF_SUPPORT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2015-04-04 01:58:28 +02:00
|
|
|
source "src/console/Kconfig"
|
2009-08-12 17:00:51 +02:00
|
|
|
|
|
|
|
|
config HAVE_ACPI_RESUME
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2016-01-22 22:26:04 +01:00
|
|
|
config RESUME_PATH_SAME_AS_BOOT
|
|
|
|
|
bool
|
|
|
|
|
default y if ARCH_X86
|
|
|
|
|
depends on HAVE_ACPI_RESUME
|
|
|
|
|
help
|
|
|
|
|
This option indicates that when a system resumes it takes the
|
|
|
|
|
same path as a regular boot. e.g. an x86 system runs from the
|
|
|
|
|
reset vector at 0xfffffff0 on both resume and warm/cold boot.
|
|
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config HAVE_HARD_RESET
|
|
|
|
|
bool
|
2009-10-09 13:47:21 +02:00
|
|
|
default n
|
2010-02-27 09:39:04 +01:00
|
|
|
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.
|
|
|
|
|
|
2015-05-18 23:04:10 +02:00
|
|
|
config HAVE_ROMSTAGE_CONSOLE_SPINLOCK
|
|
|
|
|
bool
|
2016-07-08 12:33:00 +02:00
|
|
|
depends on EARLY_CBMEM_INIT
|
2015-05-18 23:04:10 +02:00
|
|
|
default n
|
|
|
|
|
|
2015-08-29 02:52:05 +02:00
|
|
|
config HAVE_ROMSTAGE_NVRAM_CBFS_SPINLOCK
|
|
|
|
|
bool
|
2016-07-08 12:33:00 +02:00
|
|
|
depends on EARLY_CBMEM_INIT
|
2015-08-29 02:52:05 +02:00
|
|
|
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.
|
|
|
|
|
|
2015-08-29 03:48:17 +02:00
|
|
|
config HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK
|
|
|
|
|
bool
|
2016-07-08 12:33:00 +02:00
|
|
|
depends on EARLY_CBMEM_INIT
|
2015-08-29 03:48:17 +02:00
|
|
|
default n
|
|
|
|
|
|
2013-04-30 05:31:51 +02:00
|
|
|
config HAVE_MONOTONIC_TIMER
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
The board/chipset provides a monotonic timer.
|
|
|
|
|
|
2014-09-25 17:05:15 +02:00
|
|
|
config GENERIC_UDELAY
|
|
|
|
|
def_bool n
|
|
|
|
|
depends on HAVE_MONOTONIC_TIMER
|
|
|
|
|
help
|
|
|
|
|
The board/chipset uses a generic udelay function utilizing the
|
|
|
|
|
monotonic timer.
|
|
|
|
|
|
2013-04-30 16:58:12 +02:00
|
|
|
config TIMER_QUEUE
|
|
|
|
|
def_bool n
|
|
|
|
|
depends on HAVE_MONOTONIC_TIMER
|
|
|
|
|
help
|
2013-09-13 06:57:49 +02:00
|
|
|
Provide a timer queue for performing time-based callbacks.
|
2013-04-30 16:58:12 +02:00
|
|
|
|
2013-05-06 19:20:52 +02:00
|
|
|
config COOP_MULTITASKING
|
|
|
|
|
def_bool n
|
2013-05-06 19:22:23 +02:00
|
|
|
depends on TIMER_QUEUE && ARCH_X86
|
2013-05-06 19:20:52 +02:00
|
|
|
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.
|
|
|
|
|
|
2009-08-12 17:00:51 +02:00
|
|
|
config HAVE_OPTION_TABLE
|
|
|
|
|
bool
|
2010-07-06 23:05:04 +02:00
|
|
|
default n
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
This variable specifies whether a given board has a cmos.layout
|
|
|
|
|
file containing NVRAM/CMOS bit definitions.
|
2010-07-06 23:05:04 +02:00
|
|
|
It defaults to 'n' but can be selected in mainboard/*/Kconfig.
|
2009-08-12 17:00:51 +02:00
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
2014-01-06 10:06:26 +01:00
|
|
|
config CACHE_ROM_SIZE_OVERRIDE
|
2012-08-16 23:05:42 +02:00
|
|
|
hex
|
2014-01-06 10:06:26 +01:00
|
|
|
default 0
|
2012-08-16 23:05:42 +02:00
|
|
|
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
# TODO: Can probably be removed once all chipsets have kconfig options for it.
|
2009-10-04 19:15:39 +02:00
|
|
|
config VIDEO_MB
|
|
|
|
|
int
|
Add kconfig menus for most chipset VIDEO_MB values.
VIDEO_MB is a variable that defines how many MB of RAM will be used
for onboard graphics frame buffer. It's northbridge-dependent which
values for CONFIG_MB are valid (but not board-dependent).
This patch adds choices for menuconfig to select the VIDEO_MB value for:
- Intel 82810
- Intel 82830
- VIA CN400
- VIA CN700
Note: CN400 and CN700 are based on the CX700 datasheet, not sure if they're
correct. If somebody has CN400 and CN700 datasheets, please verify.
We drop all per-board VIDEO_MB variables in per-board Kconfig files as
there's a northbridge-specific option/default now (plus the user can override
the value if needed in menuconfig).
As CONFIG_MB is chipset-specific but not board-specific (and never was), filter
it in util/compareboard/compareboard, we don't need to match those values.
Finally, put "CPU", "Northbridge", "Southbridge", "Super I/O", and
"Devices" sections into the "Chipset" menu, where NB-specific
options will appear if you select a board using a certain NB,
SB-specific options would appear in the "Southbridge" section etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4866 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26 22:42:13 +01:00
|
|
|
default 0
|
2009-10-04 19:15:39 +02:00
|
|
|
|
2009-09-22 20:49:08 +02:00
|
|
|
config USE_WATCHDOG_ON_BOOT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
|
|
|
|
config VGA
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Build board-specific VGA code.
|
|
|
|
|
|
|
|
|
|
config GFXUMA
|
|
|
|
|
bool
|
2009-10-26 16:14:07 +01:00
|
|
|
default n
|
2009-09-22 20:49:08 +02:00
|
|
|
help
|
|
|
|
|
Enable Unified Memory Architecture for graphics.
|
|
|
|
|
|
2009-10-15 15:35:47 +02:00
|
|
|
config HAVE_ACPI_TABLES
|
|
|
|
|
bool
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
This variable specifies whether a given board has ACPI table support.
|
|
|
|
|
It is usually set in mainboard/*/Kconfig.
|
2009-10-15 15:35:47 +02:00
|
|
|
|
|
|
|
|
config HAVE_MP_TABLE
|
|
|
|
|
bool
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
This variable specifies whether a given board has MP table support.
|
|
|
|
|
It is usually set in mainboard/*/Kconfig.
|
|
|
|
|
Whether or not the MP table is actually generated by coreboot
|
|
|
|
|
is configurable by the user via GENERATE_MP_TABLE.
|
2009-10-15 15:35:47 +02:00
|
|
|
|
|
|
|
|
config HAVE_PIRQ_TABLE
|
|
|
|
|
bool
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
This variable specifies whether a given board has PIRQ table support.
|
|
|
|
|
It is usually set in mainboard/*/Kconfig.
|
|
|
|
|
Whether or not the PIRQ table is actually generated by coreboot
|
|
|
|
|
is configurable by the user via GENERATE_PIRQ_TABLE.
|
2009-10-15 15:35:47 +02:00
|
|
|
|
2012-08-23 09:32:58 +02:00
|
|
|
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.
|
|
|
|
|
|
2014-10-16 12:48:19 +02:00
|
|
|
config COMMON_FADT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2015-11-17 23:31:00 +01:00
|
|
|
config ACPI_NHLT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Build support for NHLT (non HD Audio) ACPI table generation.
|
|
|
|
|
|
2009-10-26 16:14:07 +01:00
|
|
|
#These Options are here to avoid "undefined" warnings.
|
|
|
|
|
#The actual selection and help texts are in the following menu.
|
|
|
|
|
|
|
|
|
|
menu "System tables"
|
2009-09-22 20:49:08 +02:00
|
|
|
|
2009-10-15 15:35:47 +02:00
|
|
|
config GENERATE_MP_TABLE
|
2012-11-14 02:33:08 +01:00
|
|
|
prompt "Generate an MP table" if HAVE_MP_TABLE || DRIVERS_GENERIC_IOAPIC
|
|
|
|
|
bool
|
|
|
|
|
default HAVE_MP_TABLE || DRIVERS_GENERIC_IOAPIC
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
Generate an MP table (conforming to the Intel MultiProcessor
|
|
|
|
|
specification 1.4) for this board.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
2009-09-22 20:49:08 +02:00
|
|
|
|
2009-10-15 15:35:47 +02:00
|
|
|
config GENERATE_PIRQ_TABLE
|
2012-11-14 02:33:08 +01:00
|
|
|
prompt "Generate a PIRQ table" if HAVE_PIRQ_TABLE
|
|
|
|
|
bool
|
|
|
|
|
default HAVE_PIRQ_TABLE
|
2009-10-15 19:49:07 +02:00
|
|
|
help
|
|
|
|
|
Generate a PIRQ table for this board.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
2009-09-22 20:49:08 +02:00
|
|
|
|
2011-08-14 20:56:34 +02:00
|
|
|
config GENERATE_SMBIOS_TABLES
|
|
|
|
|
depends on ARCH_X86
|
|
|
|
|
bool "Generate SMBIOS tables"
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Generate SMBIOS tables for this board.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
|
|
|
|
|
2015-05-30 23:08:26 +02:00
|
|
|
config SMBIOS_PROVIDED_BY_MOBO
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2014-10-17 13:28:15 +02:00
|
|
|
config MAINBOARD_SERIAL_NUMBER
|
|
|
|
|
string "SMBIOS Serial Number"
|
|
|
|
|
depends on GENERATE_SMBIOS_TABLES
|
2015-05-30 23:08:26 +02:00
|
|
|
depends on !SMBIOS_PROVIDED_BY_MOBO
|
2014-10-17 13:28:15 +02:00
|
|
|
default "123456789"
|
2015-04-27 02:53:26 +02:00
|
|
|
help
|
2014-10-17 13:28:15 +02:00
|
|
|
The Serial Number to store in SMBIOS structures.
|
|
|
|
|
|
|
|
|
|
config MAINBOARD_VERSION
|
|
|
|
|
string "SMBIOS Version Number"
|
|
|
|
|
depends on GENERATE_SMBIOS_TABLES
|
2015-05-30 23:08:26 +02:00
|
|
|
depends on !SMBIOS_PROVIDED_BY_MOBO
|
2014-10-17 13:28:15 +02:00
|
|
|
default "1.0"
|
|
|
|
|
help
|
|
|
|
|
The Version Number to store in SMBIOS structures.
|
|
|
|
|
|
|
|
|
|
config MAINBOARD_SMBIOS_MANUFACTURER
|
|
|
|
|
string "SMBIOS Manufacturer"
|
|
|
|
|
depends on GENERATE_SMBIOS_TABLES
|
2015-05-30 23:08:26 +02:00
|
|
|
depends on !SMBIOS_PROVIDED_BY_MOBO
|
2014-10-17 13:28:15 +02:00
|
|
|
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
|
2015-05-30 23:08:26 +02:00
|
|
|
depends on !SMBIOS_PROVIDED_BY_MOBO
|
2014-10-17 13:28:15 +02:00
|
|
|
default MAINBOARD_PART_NUMBER
|
|
|
|
|
help
|
|
|
|
|
Override the default Product name stored in SMBIOS structures.
|
|
|
|
|
|
2009-09-22 20:49:08 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2016-02-05 03:52:27 +01:00
|
|
|
source "payloads/Kconfig"
|
2009-09-17 18:21:31 +02:00
|
|
|
|
2009-10-07 18:15:40 +02:00
|
|
|
menu "Debugging"
|
|
|
|
|
|
|
|
|
|
# TODO: Better help text and detailed instructions.
|
2009-08-12 17:00:51 +02:00
|
|
|
config GDB_STUB
|
2009-08-25 02:53:22 +02:00
|
|
|
bool "GDB debugging support"
|
2012-03-25 20:51:16 +02:00
|
|
|
default n
|
2015-12-10 22:04:56 +01:00
|
|
|
depends on CONSOLE_SERIAL
|
2009-08-12 17:00:51 +02:00
|
|
|
help
|
2009-08-25 02:53:22 +02:00
|
|
|
If enabled, you will be able to set breakpoints for gdb debugging.
|
2010-12-11 21:33:41 +01:00
|
|
|
See src/arch/x86/lib/c_start.S for details.
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2012-06-22 15:56:37 +02:00
|
|
|
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.
|
|
|
|
|
|
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().
|
|
|
|
|
|
2012-05-03 01:33:18 +02:00
|
|
|
config DEBUG_CBFS
|
|
|
|
|
bool "Output verbose CBFS debug messages"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables additional CBFS related debug messages.
|
|
|
|
|
|
2010-08-26 14:46:02 +02:00
|
|
|
config HAVE_DEBUG_RAM_SETUP
|
|
|
|
|
def_bool n
|
|
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
config DEBUG_RAM_SETUP
|
|
|
|
|
bool "Output verbose RAM init debug messages"
|
|
|
|
|
default n
|
2010-08-26 14:46:02 +02:00
|
|
|
depends on HAVE_DEBUG_RAM_SETUP
|
2010-03-05 11:03:50 +01:00
|
|
|
help
|
|
|
|
|
This option enables additional RAM init related debug messages.
|
|
|
|
|
It is recommended to enable this when debugging issues on your
|
|
|
|
|
board which might be RAM init related.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-10-01 16:50:12 +02:00
|
|
|
config HAVE_DEBUG_CAR
|
|
|
|
|
def_bool n
|
|
|
|
|
|
2010-11-10 03:00:32 +01:00
|
|
|
config DEBUG_CAR
|
|
|
|
|
def_bool n
|
|
|
|
|
depends on HAVE_DEBUG_CAR
|
|
|
|
|
|
|
|
|
|
if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
|
2010-11-10 01:14:32 +01:00
|
|
|
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
|
|
|
|
|
# printk(BIOS_DEBUG, ...) calls.
|
2010-10-01 16:50:12 +02:00
|
|
|
config DEBUG_CAR
|
|
|
|
|
bool "Output verbose Cache-as-RAM debug messages"
|
|
|
|
|
default n
|
2010-11-10 03:00:32 +01:00
|
|
|
depends on HAVE_DEBUG_CAR
|
2010-10-01 16:50:12 +02:00
|
|
|
help
|
|
|
|
|
This option enables additional CAR related debug messages.
|
2010-11-10 03:00:32 +01:00
|
|
|
endif
|
2010-10-01 16:50:12 +02:00
|
|
|
|
2010-06-01 21:25:31 +02:00
|
|
|
config DEBUG_PIRQ
|
|
|
|
|
bool "Check PIRQ table consistency"
|
|
|
|
|
default n
|
|
|
|
|
depends on GENERATE_PIRQ_TABLE
|
|
|
|
|
help
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-08-26 14:46:02 +02:00
|
|
|
config HAVE_DEBUG_SMBUS
|
|
|
|
|
def_bool n
|
|
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
config DEBUG_SMBUS
|
|
|
|
|
bool "Output verbose SMBus debug messages"
|
|
|
|
|
default n
|
2010-08-26 14:46:02 +02:00
|
|
|
depends on HAVE_DEBUG_SMBUS
|
2010-03-05 11:03:50 +01:00
|
|
|
help
|
|
|
|
|
This option enables additional SMBus (and SPD) debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config DEBUG_SMI
|
|
|
|
|
bool "Output verbose SMI debug messages"
|
|
|
|
|
default n
|
|
|
|
|
depends on HAVE_SMI_HANDLER
|
2015-09-28 23:27:24 +02:00
|
|
|
select SPI_FLASH_SMM if SPI_CONSOLE
|
2010-03-05 11:03:50 +01:00
|
|
|
help
|
|
|
|
|
This option enables additional SMI related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-08-01 17:41:14 +02:00
|
|
|
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.
|
|
|
|
|
|
2010-11-10 01:14:32 +01:00
|
|
|
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
|
|
|
|
|
# printk(BIOS_DEBUG, ...) calls.
|
|
|
|
|
config DEBUG_MALLOC
|
2012-11-14 02:00:01 +01:00
|
|
|
prompt "Output verbose malloc debug messages" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
|
|
|
|
|
bool
|
2010-11-10 01:14:32 +01:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables additional malloc related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
2011-07-01 23:44:39 +02:00
|
|
|
|
|
|
|
|
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
|
|
|
|
|
# printk(BIOS_DEBUG, ...) calls.
|
|
|
|
|
config DEBUG_ACPI
|
2012-11-14 02:00:01 +01:00
|
|
|
prompt "Output verbose ACPI debug messages" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
|
|
|
|
|
bool
|
2011-07-01 23:44:39 +02:00
|
|
|
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.
|
2010-11-10 01:14:32 +01:00
|
|
|
|
|
|
|
|
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
|
|
|
|
|
# printk(BIOS_DEBUG, ...) calls.
|
2010-09-08 00:30:15 +02:00
|
|
|
config REALMODE_DEBUG
|
2012-11-14 02:00:01 +01:00
|
|
|
prompt "Enable debug messages for option ROM execution" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
|
|
|
|
|
bool
|
2010-09-08 00:30:15 +02:00
|
|
|
default n
|
2010-11-10 03:00:32 +01:00
|
|
|
depends on PCI_OPTION_ROM_RUN_REALMODE
|
2010-09-08 00:30:15 +02:00
|
|
|
help
|
|
|
|
|
This option enables additional x86emu related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the time to emulate a ROM.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
config X86EMU_DEBUG
|
|
|
|
|
bool "Output verbose x86emu debug messages"
|
|
|
|
|
default n
|
|
|
|
|
depends on PCI_OPTION_ROM_RUN_YABEL
|
|
|
|
|
help
|
|
|
|
|
This option enables additional x86emu related debug messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_JMP
|
|
|
|
|
bool "Trace JMP/RETF"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print information about JMP and RETF opcodes from x86emu.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_TRACE
|
|
|
|
|
bool "Trace all opcodes"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print _all_ opcodes that are executed by x86emu.
|
2010-04-27 08:56:47 +02:00
|
|
|
|
2010-03-05 11:03:50 +01:00
|
|
|
WARNING: This will produce a LOT of output and take a long time.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_PNP
|
|
|
|
|
bool "Log Plug&Play accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print Plug And Play accesses made by option ROMs.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_DISK
|
|
|
|
|
bool "Log Disk I/O"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print Disk I/O related messages.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_PMM
|
|
|
|
|
bool "Log PMM"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to POST Memory Manager (PMM).
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_VBE
|
|
|
|
|
bool "Debug VESA BIOS Extensions"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to VESA BIOS Extension (VBE) functions.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_INT10
|
|
|
|
|
bool "Redirect INT10 output to console"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Let INT10 (i.e. character output) calls print messages to debug output.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_INTERRUPTS
|
|
|
|
|
bool "Log intXX calls"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to interrupt handling.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_CHECK_VMEM_ACCESS
|
|
|
|
|
bool "Log special memory accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print messages related to accesses to certain areas of the virtual
|
|
|
|
|
memory (e.g. BDA (BIOS Data Area) or interrupt vectors)
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_MEM
|
|
|
|
|
bool "Log all memory accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print memory accesses made by option ROM.
|
|
|
|
|
Note: This also includes accesses to fetch instructions.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config X86EMU_DEBUG_IO
|
|
|
|
|
bool "Log IO accesses"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG
|
|
|
|
|
help
|
|
|
|
|
Print I/O accesses made by option ROM.
|
|
|
|
|
|
|
|
|
|
Note: This option will increase the size of the coreboot image.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2013-05-15 00:19:49 +02:00
|
|
|
config X86EMU_DEBUG_TIMINGS
|
|
|
|
|
bool "Output timing information"
|
|
|
|
|
default n
|
|
|
|
|
depends on X86EMU_DEBUG && UDELAY_LAPIC && HAVE_MONOTONIC_TIMER
|
|
|
|
|
help
|
|
|
|
|
Print timing information needed by i915tool.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2011-11-17 21:50:54 +01:00
|
|
|
config DEBUG_TPM
|
|
|
|
|
bool "Output verbose TPM debug messages"
|
|
|
|
|
default n
|
2016-06-03 05:43:19 +02:00
|
|
|
depends on TPM || TPM2
|
2011-11-17 21:50:54 +01:00
|
|
|
help
|
|
|
|
|
This option enables additional TPM related debug messages.
|
|
|
|
|
|
2012-05-10 20:27:32 +02:00
|
|
|
config DEBUG_SPI_FLASH
|
|
|
|
|
bool "Output verbose SPI flash debug messages"
|
|
|
|
|
default n
|
|
|
|
|
depends on SPI_FLASH
|
|
|
|
|
help
|
|
|
|
|
This option enables additional SPI flash related debug messages.
|
|
|
|
|
|
2013-06-06 09:46:37 +02:00
|
|
|
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.
|
|
|
|
|
|
2012-04-04 00:07:22 +02:00
|
|
|
if SOUTHBRIDGE_INTEL_BD82X6X && DEFAULT_CONSOLE_LOGLEVEL_8
|
|
|
|
|
# Only visible with the right southbridge and loglevel.
|
|
|
|
|
config DEBUG_INTEL_ME
|
|
|
|
|
bool "Verbose logging for Intel Management Engine"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Enable verbose logging for Intel Management Engine driver that
|
|
|
|
|
is present on Intel 6-series chipsets.
|
|
|
|
|
endif
|
|
|
|
|
|
2011-09-02 23:23:41 +02:00
|
|
|
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
|
2015-11-18 17:46:53 +01:00
|
|
|
of calling function. Please note some printk related functions
|
2011-09-02 23:23:41 +02:00
|
|
|
are omitted from trace to have good looking console dumps.
|
Implement GCC code coverage analysis
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-19 01:23:28 +01:00
|
|
|
|
|
|
|
|
config DEBUG_COVERAGE
|
|
|
|
|
bool "Debug code coverage"
|
|
|
|
|
default n
|
|
|
|
|
depends on COVERAGE
|
|
|
|
|
help
|
|
|
|
|
If enabled, the code coverage hooks in coreboot will output some
|
|
|
|
|
information about the coverage data that is dumped.
|
|
|
|
|
|
2016-06-29 21:59:32 +02:00
|
|
|
config DEBUG_BOOT_STATE
|
|
|
|
|
bool "Debug boot state machine"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Control debugging of the boot state machine. When selected displays
|
|
|
|
|
the state boundaries in ramstage.
|
|
|
|
|
|
2016-08-22 19:37:15 +02:00
|
|
|
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.
|
|
|
|
|
|
2009-10-07 18:15:40 +02:00
|
|
|
endmenu
|
|
|
|
|
|
2009-10-26 16:14:07 +01:00
|
|
|
# These probably belong somewhere else, but they are needed somewhere.
|
|
|
|
|
config ENABLE_APIC_EXT_ID
|
|
|
|
|
bool
|
|
|
|
|
default n
|
2009-11-12 17:38:03 +01:00
|
|
|
|
|
|
|
|
config WARNINGS_ARE_ERRORS
|
|
|
|
|
bool
|
2014-11-17 17:17:54 +01:00
|
|
|
default y
|
2009-11-27 17:55:13 +01:00
|
|
|
|
2015-06-25 17:36:27 +02:00
|
|
|
# TODO: Remove this when all platforms are fixed.
|
|
|
|
|
config IASL_WARNINGS_ARE_ERRORS
|
|
|
|
|
def_bool y
|
|
|
|
|
help
|
|
|
|
|
Select to Fail the build if a IASL generates a warning.
|
|
|
|
|
This will be defaulted to disabled for the platforms that
|
|
|
|
|
currently fail. This allows the REST of the platforms to
|
|
|
|
|
have this check enabled while we're working to get those
|
|
|
|
|
boards fixed.
|
|
|
|
|
|
|
|
|
|
DO NOT ADD TO ANY ADDITIONAL PLATFORMS INSTEAD OF FIXING
|
|
|
|
|
THE ASL.
|
|
|
|
|
|
2010-10-13 08:23:02 +02:00
|
|
|
# The four POWER_BUTTON_DEFAULT_ENABLE, POWER_BUTTON_DEFAULT_DISABLE,
|
|
|
|
|
# POWER_BUTTON_FORCE_ENABLE and POWER_BUTTON_FORCE_DISABLE options are
|
|
|
|
|
# mutually exclusive. One of these options must be selected in the
|
|
|
|
|
# mainboard Kconfig if the chipset supports enabling and disabling of
|
|
|
|
|
# the power button. Chipset code uses the ENABLE_POWER_BUTTON option set
|
|
|
|
|
# in mainboard/Kconfig to know if the button should be enabled or not.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_DEFAULT_ENABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board has a power button which can optionally be
|
|
|
|
|
disabled by the user.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_DEFAULT_DISABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board has a power button which can optionally be
|
|
|
|
|
enabled by the user, e.g. when the board ships with a jumper over
|
|
|
|
|
the power switch contacts.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_FORCE_ENABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board requires that the power button is always
|
|
|
|
|
enabled.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_FORCE_DISABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
help
|
|
|
|
|
Select when the board requires that the power button is always
|
|
|
|
|
disabled, e.g. when it has been hardwired to ground.
|
|
|
|
|
|
|
|
|
|
config POWER_BUTTON_IS_OPTIONAL
|
|
|
|
|
bool
|
|
|
|
|
default y if POWER_BUTTON_DEFAULT_ENABLE || POWER_BUTTON_DEFAULT_DISABLE
|
|
|
|
|
default n if !(POWER_BUTTON_DEFAULT_ENABLE || POWER_BUTTON_DEFAULT_DISABLE)
|
|
|
|
|
help
|
|
|
|
|
Internal option that controls ENABLE_POWER_BUTTON visibility.
|
2013-10-31 16:26:23 +01:00
|
|
|
|
|
|
|
|
config REG_SCRIPT
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
Internal option that controls whether we compile in register scripts.
|
Introduce stage-specific architecture for coreboot
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
|
|
|
|
|
|
|
|
config MAX_REBOOT_CNT
|
|
|
|
|
int
|
|
|
|
|
default 3
|
2015-03-18 07:31:34 +01:00
|
|
|
help
|
|
|
|
|
Internal option that sets the maximum number of bootblock executions allowed
|
|
|
|
|
with the normal image enabled before assuming the normal image is defective
|
2014-07-23 18:40:02 +02:00
|
|
|
and switching to the fallback image.
|
Kconfig: Move defaults for CBFS_SIZE
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-02-09 17:06:46 +01:00
|
|
|
|
|
|
|
|
config CBFS_SIZE
|
|
|
|
|
hex
|
|
|
|
|
default ROM_SIZE
|
|
|
|
|
help
|
|
|
|
|
This is the part of the ROM actually managed by CBFS. Set it to be
|
2016-07-29 07:31:54 +02:00
|
|
|
equal to the full ROM size if that hasn't been overridden by the
|
Kconfig: Move defaults for CBFS_SIZE
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-02-09 17:06:46 +01:00
|
|
|
chipset or mainboard.
|
2016-02-15 02:01:40 +01:00
|
|
|
|
2016-05-27 02:12:17 +02:00
|
|
|
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.
|