coreboot-kgpe-d16/src/Kconfig

1116 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.
##
mainmenu "coreboot configuration"
menu "General setup"
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.
Provide a common CBFS wrapper for SPI storage Coreboot has all necessary infrastructure to use the proper SPI flash interface in bootblock for CBFS. This patch creates a common CBFS wrapper which can be enabled on different platforms as required. COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the common CBFS interface and prevents default inclusion of all SPI chip drivers, only explicitly configured ones will be included when the new feature is enabled. Since the wrapper uses the same driver at all stages, enabling the new feature will also make it necessary to include the SPI chip drivers in bootblock and romstage images. init_default_cbfs_media() can now be common for different platforms, and as such is defined in the library. BUG=none TEST=manual . with this change and the rest of the patches coreboot on AP148 comes up all the way to attempting to boot the payload (reading earlier stages from the SPI flash along the way). Original-Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/197800 Original-Tested-by: Vadim Bendebury <vbendeb@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 60eb16ebe624f9420c6191afa6ba239b8e83a6e6) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I7b0bf3dda915c227659ab62743e405312dedaf41 Reviewed-on: http://review.coreboot.org/7932 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-05-01 21:23:09 +02:00
config COMMON_CBFS_SPI_WRAPPER
bool
default n
depends on SPI_FLASH
depends on !ARCH_X86
help
Use common wrapper to interface CBFS to SPI bootrom.
config MULTIPLE_CBFS_INSTANCES
bool "Multiple CBFS instances in the bootrom"
default n
help
Account for the firmware image containing more than one CBFS
instance. Locations of instances are known at build time and are
communicated between coreboot stages to make sure the next stage is
loaded from the appropriate instance.
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 FMD_GENPARSER
bool "Generate flashmap descriptor parser using flex and bison"
default n
help
Enable this option if you are working on the flashmap descriptor
parser and made changes to fmd_scanner.l or fmd_parser.y.
Otherwise, say N to use the provided pregenerated scanner/parser.
config SCONFIG_GENPARSER
bool "Generate SCONFIG parser using flex and bison"
default n
help
Enable this option if you are working on the sconfig device tree
parser and made changes to sconfig.l or sconfig.y.
Otherwise, say N to use the provided pregenerated scanner/parser.
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 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.
config UNCOMPRESSED_RAMSTAGE
bool
default n
config COMPRESS_RAMSTAGE
bool "Compress ramstage with LZMA"
default y if !UNCOMPRESSED_RAMSTAGE
default n
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
def_bool !LATE_CBMEM_INIT
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 HAS_PRECBMEM_TIMESTAMP_REGION
bool "Timestamp region exists for pre-cbmem timestamps"
default y if ARCH_ROMSTAGE_X86_32 && CACHE_AS_RAM
depends on COLLECT_TIMESTAMPS
help
A separate region is maintained to allow storing of timestamps before
cbmem comes up. This is useful for storing timestamps across different
stage boundaries.
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
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 EARLY_CBMEM_INIT
bool "Build the ramstage to be relocatable in 32-bit address space."
default n
select RELOCATABLE_MODULES
help
The reloctable ramstage support allows for the ramstage to be built
as a relocatable module. The stage loader can identify a place
out of the OS way so that copying memory is unnecessary during an S3
wake. When selecting this option the romstage is responsible for
determing a stack location to use for loading the ramstage.
config CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
depends on RELOCATABLE_RAMSTAGE
bool "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.
config FLASHMAP_OFFSET
hex "Flash Map Offset"
default 0x00670000 if NORTHBRIDGE_INTEL_SANDYBRIDGE_MRC
default 0x00610000 if NORTHBRIDGE_INTEL_IVYBRIDGE_MRC
default CBFS_SIZE if !ARCH_X86
default 0
help
Offset of flash map in firmware image
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 SKIP_MAX_REBOOT_CNT_CLEAR
bool "Do not clear reboot count after successful boot"
default n
depends on BOOTBLOCK_NORMAL
help
Do not clear the reboot count immediately after successful boot.
Set to allow the payload to control normal/fallback image recovery.
Note that it is the responsibility of the payload to reset the
normal boot bit to 1 after each successsful boot.
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.
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
bool
default n
depends on !BOARD_ID_AUTO
help
If you want to maintain a board ID, but the hardware does not
have straps to automatically determine the ID, you can say Y
here and add a file named 'board_id' to CBFS. If you don't know
what this is about, say N.
config 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.
config RAM_CODE_SUPPORT
bool
default n
help
If enabled, coreboot discovers RAM configuration (value obtained by
reading board straps) and stores it in coreboot table.
config BOOTSPLASH_IMAGE
bool "Add a bootsplash image"
help
Select this option if you have a bootsplash image that you would
like to add to your ROM.
This will only add the image to the ROM. To actually run it check
options under 'Display' section.
config BOOTSPLASH_FILE
string "Bootsplash path and filename"
depends on BOOTSPLASH_IMAGE
default "bootsplash.jpg"
help
The path and filename of the file to use as graphical bootsplash
screen. The file format has to be jpg.
endmenu
source "src/acpi/Kconfig"
menu "Mainboard"
source "src/mainboard/Kconfig"
config CBFS_SIZE
hex "Size of CBFS filesystem in ROM"
default 0x100000 if HAVE_INTEL_FIRMWARE || \
NORTHBRIDGE_INTEL_GM45 || NORTHBRIDGE_INTEL_SANDYBRIDGE_MRC || \
NORTHBRIDGE_INTEL_IVYBRIDGE_MRC || NORTHBRIDGE_INTEL_IVYBRIDGE || \
NORTHBRIDGE_INTEL_SANDYBRIDGE || \
NORTHBRIDGE_INTEL_NEHALEM || SOC_INTEL_BRASWELL || \
SOC_INTEL_BROADWELL
default 0x200000 if SOC_INTEL_SKYLAKE
default ROM_SIZE
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.
endmenu
config SYSTEM_TYPE_LAPTOP
default n
bool
menu "Chipset"
comment "SoC"
source "src/soc/*/*/Kconfig"
comment "CPU"
source "src/cpu/Kconfig"
comment "Northbridge"
source "src/northbridge/*/*/Kconfig"
comment "Southbridge"
source "src/southbridge/*/*/Kconfig"
comment "Super I/O"
source "src/superio/*/Kconfig"
comment "Embedded Controllers"
source "src/ec/acpi/Kconfig"
source "src/ec/*/*/Kconfig"
source "src/drivers/intel/fsp1_0/Kconfig"
source "src/southbridge/intel/common/firmware/Kconfig"
source "src/vendorcode/*/Kconfig"
source "src/arch/*/Kconfig"
endmenu
source "src/device/Kconfig"
menu "Generic Drivers"
source "src/drivers/*/Kconfig"
endmenu
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
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 RAMTOP
hex
default 0x200000
depends on ARCH_X86
config HEAP_SIZE
hex
default 0x4000
2014-09-19 22:18:16 +02:00
config STACK_SIZE
hex
default 0x0 if (ARCH_RAMSTAGE_ARM || ARCH_RAMSTAGE_MIPS || ARCH_RAMSTAGE_RISCV)
2014-09-19 22:18:16 +02:00
default 0x1000
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_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 GENERIC_UDELAY
def_bool n
depends on HAVE_MONOTONIC_TIMER
help
The board/chipset uses a generic udelay function utilizing the
monotonic timer.
config TIMER_QUEUE
def_bool n
depends on HAVE_MONOTONIC_TIMER
help
Provide a timer queue for performing time-based callbacks.
config COOP_MULTITASKING
def_bool n
depends on TIMER_QUEUE && ARCH_X86
help
Cooperative multitasking allows callbacks to be multiplexed on the
main thread of ramstage. With this enabled it allows for multiple
execution paths to take place when they have udelay() calls within
their code.
config NUM_THREADS
int
default 4
depends on COOP_MULTITASKING
help
How many execution threads to cooperatively multitask with.
config HAVE_OPTION_TABLE
bool
default n
help
This variable specifies whether a given board has a cmos.layout
file containing NVRAM/CMOS bit definitions.
It defaults to 'n' but can be selected in mainboard/*/Kconfig.
config PIRQ_ROUTE
bool
default n
config HAVE_SMI_HANDLER
bool
default n
config PCI_IO_CFG_EXT
bool
default n
config IOAPIC
bool
default n
config CACHE_ROM_SIZE_OVERRIDE
hex
default 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 COMMON_FADT
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.
config SMBIOS_PROVIDED_BY_MOBO
bool
default n
config MAINBOARD_SERIAL_NUMBER
string "SMBIOS Serial Number"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default "123456789"
help
The Serial Number to store in SMBIOS structures.
config MAINBOARD_VERSION
string "SMBIOS Version Number"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default "1.0"
help
The Version Number to store in SMBIOS structures.
config MAINBOARD_SMBIOS_MANUFACTURER
string "SMBIOS Manufacturer"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default MAINBOARD_VENDOR
help
Override the default Manufacturer stored in SMBIOS structures.
config MAINBOARD_SMBIOS_PRODUCT_NAME
string "SMBIOS Product name"
depends on GENERATE_SMBIOS_TABLES
depends on !SMBIOS_PROVIDED_BY_MOBO
default MAINBOARD_PART_NUMBER
help
Override the default Product name stored in SMBIOS structures.
endmenu
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.
source "payloads/external/*/Kconfig.name"
endchoice
source "payloads/external/*/Kconfig"
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.
# TODO: Defined if no payload? Breaks build?
config COMPRESSED_PAYLOAD_LZMA
bool "Use LZMA compression for payloads"
default y
depends on !PAYLOAD_NONE && !PAYLOAD_LINUX
help
In order to reduce the size payloads take up in the ROM chip
coreboot can compress them using the LZMA algorithm.
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.
Fix non-x86 __PRE_RAM__ assertions and add FATAL_ASSERTS Kconfig option This patch fixes a bug that caused non-x86 boards to use the poor man's assert() version with a lot more instructions per invocation and hexadecimal line numbers in __PRE_RAM__ environments. This was really just an oversight in the ARM port... even x86 uses a proper printk() in most cases (those with CAR) and there's no reason not to do so on the generally even more flexible SRAM-based architectures. Additionally, it adds a new Kconfig option to make failed assertions and BUG() calls halt again. This seems to have been the original intention, but was commented out once out of fear that this might prevent production systems from booting. It is still a useful debugging feature though (since otherwise assertions can easily just scroll past and get overlooked), so the user should be able to decide the this based on his needs. (Also changed error messages for both to include the word "ERROR", since grepping for that is the most sophisticated way we currently have to detect firmware problems. Some automated Chromium OS suspend tests check for that.) BRANCH=veyron BUG=None TEST=Booted Jerry. Compared binary sizes before and after, new version's bootblock is some ~600 bytes smaller. Change-Id: I894da18d77e12bf104e443322e2d58e60564e4b7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6a5343124719c18a1c969477e3d18bda13c0bf26 Original-Change-Id: I0268cfd67d8c894406b18bb3759a577944bcffb1 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/250661 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9775 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-02-18 02:27:23 +01:00
config FATAL_ASSERTS
bool "Halt when hitting a BUG() or assertion error"
default n
help
If enabled, coreboot will call hlt() on a BUG() or failed ASSERT().
config DEBUG_CBFS
bool "Output verbose CBFS debug messages"
default n
help
This option enables additional CBFS related debug messages.
config HAVE_DEBUG_RAM_SETUP
def_bool n
config DEBUG_RAM_SETUP
bool "Output verbose RAM init debug messages"
default n
depends on HAVE_DEBUG_RAM_SETUP
help
This option enables additional RAM init related debug messages.
It is recommended to enable this when debugging issues on your
board which might be RAM init related.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config HAVE_DEBUG_CAR
def_bool n
config DEBUG_CAR
def_bool n
depends on HAVE_DEBUG_CAR
if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config DEBUG_CAR
bool "Output verbose Cache-as-RAM debug messages"
default n
depends on HAVE_DEBUG_CAR
help
This option enables additional CAR related debug messages.
endif
config DEBUG_PIRQ
bool "Check PIRQ table consistency"
default n
depends on GENERATE_PIRQ_TABLE
help
If unsure, say N.
config HAVE_DEBUG_SMBUS
def_bool n
config DEBUG_SMBUS
bool "Output verbose SMBus debug messages"
default n
depends on HAVE_DEBUG_SMBUS
help
This option enables additional SMBus (and SPD) debug messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config DEBUG_SMI
bool "Output verbose SMI debug messages"
default n
depends on HAVE_SMI_HANDLER
select SPI_FLASH_SMM if SPI_CONSOLE
help
This option enables additional SMI related debug messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config DEBUG_SMM_RELOCATION
bool "Debug SMM relocation code"
default n
depends on HAVE_SMI_HANDLER
help
This option enables additional SMM handler relocation related
debug messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config DEBUG_MALLOC
prompt "Output verbose malloc debug messages" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
bool
default n
help
This option enables additional malloc related debug messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config DEBUG_ACPI
prompt "Output verbose ACPI debug messages" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
bool
default n
help
This option enables additional ACPI related debug messages.
Note: This option will slightly increase the size of the coreboot image.
If unsure, say N.
# Only visible if debug level is DEBUG (7) or SPEW (8) as it does additional
# printk(BIOS_DEBUG, ...) calls.
config REALMODE_DEBUG
prompt "Enable debug messages for option ROM execution" if DEFAULT_CONSOLE_LOGLEVEL_7 || DEFAULT_CONSOLE_LOGLEVEL_8
bool
default n
depends on PCI_OPTION_ROM_RUN_REALMODE
help
This option enables additional x86emu related debug messages.
Note: This option will increase the time to emulate a ROM.
If unsure, say N.
config X86EMU_DEBUG
bool "Output verbose x86emu debug messages"
default n
depends on PCI_OPTION_ROM_RUN_YABEL
help
This option enables additional x86emu related debug messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_JMP
bool "Trace JMP/RETF"
default n
depends on X86EMU_DEBUG
help
Print information about JMP and RETF opcodes from x86emu.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_TRACE
bool "Trace all opcodes"
default n
depends on X86EMU_DEBUG
help
Print _all_ opcodes that are executed by x86emu.
WARNING: This will produce a LOT of output and take a long time.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_PNP
bool "Log Plug&Play accesses"
default n
depends on X86EMU_DEBUG
help
Print Plug And Play accesses made by option ROMs.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_DISK
bool "Log Disk I/O"
default n
depends on X86EMU_DEBUG
help
Print Disk I/O related messages.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_PMM
bool "Log PMM"
default n
depends on X86EMU_DEBUG
help
Print messages related to POST Memory Manager (PMM).
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_VBE
bool "Debug VESA BIOS Extensions"
default n
depends on X86EMU_DEBUG
help
Print messages related to VESA BIOS Extension (VBE) functions.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_INT10
bool "Redirect INT10 output to console"
default n
depends on X86EMU_DEBUG
help
Let INT10 (i.e. character output) calls print messages to debug output.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_INTERRUPTS
bool "Log intXX calls"
default n
depends on X86EMU_DEBUG
help
Print messages related to interrupt handling.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_CHECK_VMEM_ACCESS
bool "Log special memory accesses"
default n
depends on X86EMU_DEBUG
help
Print messages related to accesses to certain areas of the virtual
memory (e.g. BDA (BIOS Data Area) or interrupt vectors)
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_MEM
bool "Log all memory accesses"
default n
depends on X86EMU_DEBUG
help
Print memory accesses made by option ROM.
Note: This also includes accesses to fetch instructions.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_IO
bool "Log IO accesses"
default n
depends on X86EMU_DEBUG
help
Print I/O accesses made by option ROM.
Note: This option will increase the size of the coreboot image.
If unsure, say N.
config X86EMU_DEBUG_TIMINGS
bool "Output timing information"
default n
depends on X86EMU_DEBUG && UDELAY_LAPIC && HAVE_MONOTONIC_TIMER
help
Print timing information needed by i915tool.
If unsure, say N.
config DEBUG_TPM
bool "Output verbose TPM debug messages"
default n
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 n
help
Internal option that controls whether we compile in register scripts.
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
config MAX_REBOOT_CNT
int
default 3
help
Internal option that sets the maximum number of bootblock executions allowed
with the normal image enabled before assuming the normal image is defective
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-07-23 18:40:02 +02:00
and switching to the fallback image.