This is an automatically generated list of '''coreboot compile-time options'''.

Last update: 4.13-1405-g56868b8045
<table border="0" style="font-size: smaller">
<tr bgcolor="#6699dd">
<td align="left">Option</td>
<td align="left">Source</td>
<td align="left">Format</td>
<td align="left">Short&nbsp;Description</td>
<td align="left">Description</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: General setup</td></tr>
<tr bgcolor="#eeeeee">
<td>LOCALVERSION</td><td>toplevel</td><td>string</td><td>Local version string</td><td>
Append an extra string to the end of the coreboot version.<br />
<br />
This can be useful if, for instance, you want to append the<br />
respective board's hostname or some other identifying string to<br />
the coreboot version number, so that you can easily distinguish<br />
boot logs of different boards from each other.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONFIGURABLE_CBFS_PREFIX</td><td>toplevel</td><td>bool</td><td></td><td>
Select this to prompt to use to configure the prefix for cbfs files.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_PREFIX</td><td>toplevel</td><td>string</td><td>CBFS prefix to use</td><td>
Select the prefix to all files put into the image. It's "fallback"<br />
by default, "normal" is a common alternative.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_PREFIX</td><td>toplevel</td><td>string</td><td>Compiler to use</td><td>
This option allows you to select the compiler used for building<br />
coreboot.<br />
You must build the coreboot crosscompiler for the board that you<br />
have selected.<br />
<br />
To build all the GCC crosscompilers (takes a LONG time), run:<br />
make crossgcc<br />
<br />
For help on individual architectures, run the command:<br />
make help_toolchain<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPILER_GCC</td><td>toplevel</td><td>bool</td><td>GCC</td><td>
Use the GNU Compiler Collection (GCC) to build coreboot.<br />
<br />
For details see http://gcc.gnu.org.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPILER_LLVM_CLANG</td><td>toplevel</td><td>bool</td><td>LLVM/clang (TESTING ONLY - Not currently working)</td><td>
Use LLVM/clang to build coreboot.  To use this, you must build the<br />
coreboot version of the clang compiler.  Run the command<br />
make clang<br />
Note that this option is not currently working correctly and should<br />
really only be selected if you're trying to work on getting clang<br />
operational.<br />
<br />
For details see http://clang.llvm.org.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ANY_TOOLCHAIN</td><td>toplevel</td><td>bool</td><td>Allow building with any toolchain</td><td>
Many toolchains break when building coreboot since it uses quite<br />
unusual linker features. Unless developers explicitely request it,<br />
we'll have to assume that they use their distro compiler by mistake.<br />
Make sure that using patched compilers is a conscious decision.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CCACHE</td><td>toplevel</td><td>bool</td><td>Use ccache to speed up (re)compilation</td><td>
Enables the use of ccache for faster builds.<br />
<br />
Requires the ccache utility in your system $PATH.<br />
<br />
For details see https://ccache.samba.org.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FMD_GENPARSER</td><td>toplevel</td><td>bool</td><td>Generate flashmap descriptor parser using flex and bison</td><td>
Enable this option if you are working on the flashmap descriptor<br />
parser and made changes to fmd_scanner.l or fmd_parser.y.<br />
<br />
Otherwise, say N to use the provided pregenerated scanner/parser.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UTIL_GENPARSER</td><td>toplevel</td><td>bool</td><td>Generate SCONFIG &amp; BINCFG parser using flex and bison</td><td>
Enable this option if you are working on the sconfig device tree<br />
parser or bincfg and made changes to the .l or .y files.<br />
<br />
Otherwise, say N to use the provided pregenerated scanner/parser.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_OPTION_TABLE</td><td>toplevel</td><td>bool</td><td>Use CMOS for configuration values</td><td>
Enable this option if coreboot shall read options from the "CMOS"<br />
NVRAM instead of using hard-coded values.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STATIC_OPTION_TABLE</td><td>toplevel</td><td>bool</td><td>Load default configuration values into CMOS on each boot</td><td>
Enable this option to reset "CMOS" NVRAM values to default on<br />
every boot.  Use this if you want the NVRAM configuration to<br />
never be modified from its default values.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPRESS_RAMSTAGE</td><td>toplevel</td><td>bool</td><td>Compress ramstage with LZMA</td><td>
Compress ramstage to save memory in the flash image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPRESS_PRERAM_STAGES</td><td>toplevel</td><td>bool</td><td>Compress romstage and verstage with LZ4</td><td>
Compress romstage and (if it exists) verstage with LZ4 to save flash<br />
space and speed up boot, since the time for reading the image from SPI<br />
(and in the vboot case verifying it) is usually much greater than the<br />
time spent decompressing. Doesn't work for XIP stages (assume all<br />
ARCH_X86 for now) for obvious reasons.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPRESS_BOOTBLOCK</td><td>toplevel</td><td>bool</td><td></td><td>
This option can be used to compress the bootblock with LZ4 and attach<br />
a small self-decompression stub to its front. This can drastically<br />
reduce boot time on platforms where the bootblock is loaded over a<br />
very slow connection and bootblock size trumps all other factors for<br />
speed. Since using this option usually requires changes to the<br />
SoC memlayout and possibly extra support code, it should not be<br />
user-selectable. (There's no real point in offering this to the user<br />
anyway... if it works and saves boot time, you would always want it.)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INCLUDE_CONFIG_FILE</td><td>toplevel</td><td>bool</td><td>Include the coreboot .config file into the ROM image</td><td>
Include the .config file that was used to compile coreboot<br />
in the (CBFS) ROM image. This is useful if you want to know which<br />
options were used to build a specific coreboot.rom image.<br />
<br />
Saying Y here will increase the image size by 2-3KB.<br />
<br />
You can use the following command to easily list the options:<br />
<br />
grep -a CONFIG_ coreboot.rom<br />
<br />
Alternatively, you can also use cbfstool to print the image<br />
contents (including the raw 'config' item we're looking for).<br />
<br />
Example:<br />
<br />
$ cbfstool coreboot.rom print<br />
coreboot.rom: 4096 kB, bootblocksize 1008, romsize 4194304,<br />
offset 0x0<br />
Alignment: 64 bytes<br />
<br />
Name                           Offset     Type         Size<br />
cmos_layout.bin                0x0        CMOS layout  1159<br />
fallback/romstage              0x4c0      stage        339756<br />
fallback/ramstage              0x53440    stage        186664<br />
fallback/payload               0x80dc0    payload      51526<br />
config                         0x8d740    raw          3324<br />
(empty)                        0x8e480    null         3610440<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COLLECT_TIMESTAMPS</td><td>toplevel</td><td>bool</td><td>Create a table of timestamps collected during boot</td><td>
Make coreboot create a table of timer-ID/timer-value pairs to<br />
allow measuring time spent at different phases of the boot process.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIMESTAMPS_ON_CONSOLE</td><td>toplevel</td><td>bool</td><td>Print the timestamp values on the console</td><td>
Print the timestamps to the debug console if enabled at level info.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_BLOBS</td><td>toplevel</td><td>bool</td><td>Allow use of binary-only repository</td><td>
This draws in the blobs repository, which contains binary files that<br />
might be required for some chipsets or boards.<br />
This flag ensures that a "Free" option remains available for users.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_AMD_BLOBS</td><td>toplevel</td><td>bool</td><td>Allow AMD blobs repository (with license agreement)</td><td>
This draws in the amd_blobs repository, which contains binary files<br />
distributed by AMD, including VBIOS, PSP bootloaders, SMU firmwares,<br />
etc.  Selecting this item to download or clone the repo implies your<br />
agreement to the AMD license agreement.  A copy of the license text<br />
may be reviewed by reading Documentation/soc/amd/amdblobs_license.md,<br />
and your copy of the license is present in the repo once downloaded.<br />
<br />
Note that for some products, omitting PSP, SMU images, or other items<br />
may result in a nonbooting coreboot.rom.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_QC_BLOBS</td><td>toplevel</td><td>bool</td><td>Allow QC blobs repository (selecting this agrees to the license!)</td><td>
This draws in the qc_blobs repository, which contains binary files<br />
distributed by Qualcomm that are required to build firmware for<br />
certain Qualcomm SoCs (including QcLib, QC-SEC, qtiseclib and QUP<br />
firmware). If you say Y here you are implicitly agreeing to the<br />
Qualcomm license agreement which can be found at:<br />
https://review.coreboot.org/cgit/qc_blobs.git/tree/LICENSE<br />
<br />
*****************************************************<br />
PLEASE MAKE SURE YOU READ AND AGREE TO ALL TERMS IN<br />
ABOVE LICENSE AGREEMENT BEFORE SELECTING THIS OPTION!<br />
*****************************************************<br />
<br />
Not selecting this option means certain Qualcomm SoCs and related<br />
mainboards cannot be built and will be hidden from the "Mainboards"<br />
section.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COVERAGE</td><td>toplevel</td><td>bool</td><td>Code coverage support</td><td>
Add code coverage support for coreboot. This will store code<br />
coverage information in CBMEM for extraction from user space.<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UBSAN</td><td>toplevel</td><td>bool</td><td>Undefined behavior sanitizer support</td><td>
Instrument the code with checks for undefined behavior. If unsure,<br />
say N because it adds a small performance penalty and may abort<br />
on code that happens to work in spite of the UB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ASAN_IN_ROMSTAGE</td><td>toplevel</td><td>bool</td><td></td><td>
Enable address sanitizer in romstage for platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ASAN_IN_RAMSTAGE</td><td>toplevel</td><td>bool</td><td></td><td>
Enable address sanitizer in ramstage for platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ASAN</td><td>toplevel</td><td>bool</td><td>Address sanitizer support</td><td>
Enable address sanitizer - runtime memory debugger,<br />
designed to find out-of-bounds accesses and use-after-scope bugs.<br />
<br />
This feature consumes up to 1/8 of available memory and brings about<br />
~1.5x performance slowdown.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>Before using this feature, make sure that</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>asan_shadow_offset_callback patch is applied to GCC.</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_STAGE_CACHE</td><td>toplevel</td><td>bool</td><td>Disabled</td><td>
Do not save any component in stage cache for resume path. On resume,<br />
all components would be read back from CBFS again.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TSEG_STAGE_CACHE</td><td>toplevel</td><td>bool</td><td>TSEG</td><td>
The option enables stage cache support for platform. Platform<br />
can stash copies of postcar, ramstage and raw runtime data<br />
inside SMM TSEG, to be restored on S3 resume path.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBMEM_STAGE_CACHE</td><td>toplevel</td><td>bool</td><td>CBMEM</td><td>
The option enables stage cache support for platform. Platform<br />
can stash copies of postcar, ramstage and raw runtime data<br />
inside CBMEM.<br />
<br />
While the approach is faster than reloading stages from boot media<br />
it is also a possible attack scenario via which OS can possibly<br />
circumvent SMM locks and SPI write protections.<br />
<br />
If unsure, select 'N'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UPDATE_IMAGE</td><td>toplevel</td><td>bool</td><td>Update existing coreboot.rom image</td><td>
If this option is enabled, no new coreboot.rom file<br />
is created. Instead it is expected that there already<br />
is a suitable file for further processing.<br />
The bootblock will not be modified.<br />
<br />
If unsure, select 'N'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTSPLASH_IMAGE</td><td>toplevel</td><td>bool</td><td>Add a bootsplash image</td><td>
Select this option if you have a bootsplash image that you would<br />
like to add to your ROM.<br />
<br />
This will only add the image to the ROM. To actually run it check<br />
options under 'Display' section.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTSPLASH_FILE</td><td>toplevel</td><td>string</td><td>Bootsplash path and filename</td><td>
The path and filename of the file to use as graphical bootsplash<br />
screen. The file format has to be jpg.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FW_CONFIG</td><td>toplevel</td><td>bool</td><td>Firmware Configuration Probing</td><td>
Enable support for probing devices with fw_config.  This is a simple<br />
bitmask broken into fields and options for probing.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FW_CONFIG_SOURCE_CBFS</td><td>toplevel</td><td>bool</td><td>Obtain Firmware Configuration value from CBFS</td><td>
With this option enabled coreboot will look for the 32bit firmware<br />
configuration value in CBFS at the selected prefix with the file name<br />
"fw_config".  This option will override other sources and allow the<br />
local image to preempt the mainboard selected source.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FW_CONFIG_SOURCE_CHROMEEC_CBI</td><td>toplevel</td><td>bool</td><td>Obtain Firmware Configuration value from Google Chrome EC CBI</td><td>
This option tells coreboot to read the firmware configuration value<br />
from the Google Chrome Embedded Controller CBI interface.  This source<br />
is not tried if FW_CONFIG_SOURCE_CBFS is enabled and the value was<br />
found in CBFS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAMPAYLOAD</td><td>toplevel</td><td>bool</td><td>Enable coreboot flow without executing ramstage</td><td>
If this option is enabled, coreboot flow will skip ramstage<br />
loading and execution of ramstage to load payload.<br />
<br />
Instead it is expected to load payload from postcar stage itself.<br />
<br />
In this flow coreboot will perform basic x86 initialization<br />
(DRAM resource allocation), MTRR programming,<br />
Skip PCI enumeration logic and only allocate BAR for fixed devices<br />
(bootable devices, TPM over GSPI).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONFIGURABLE_RAMSTAGE</td><td>toplevel</td><td>bool</td><td>Enable a configurable ramstage.</td><td>
A configurable ramstage allows you to select which parts of the ramstage<br />
to run. Currently, we can only select a minimal PCI scanning step.<br />
The minimal PCI scanning will only check those parts that are enabled<br />
in the devicetree.cb. By convention none of those devices should be bridges.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MINIMAL_PCI_SCANNING</td><td>toplevel</td><td>bool</td><td>Enable minimal PCI scanning</td><td>
If this option is enabled, coreboot will scan only PCI devices<br />
marked as mandatory in devicetree.cb<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Mainboard</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard</td><td>(comment)</td><td></td><td>Important: Run 'make distclean' before switching boards</td></tr>
<tr bgcolor="#eeeeee">
<td>ONBOARD_MEM_SAMSUNG</td><td>mainboard/portwell/m107</td><td>bool</td><td>Samsung</td><td>
Samsung K4B8G1646D memory<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ONBOARD_MEM_MICRON</td><td>mainboard/portwell/m107</td><td>bool</td><td>Micron</td><td>
Micron MT41K512M16HA memory<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ONBOARD_MEM_KINGSTON</td><td>mainboard/portwell/m107</td><td>bool</td><td>Kingston</td><td>
Kingston B5116ECMDXGGB memory<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BMC_INFO_LOC</td><td>mainboard/scaleway/tagada</td><td>hex</td><td>BMC information location in flash</td><td>
Location of BMC SERIAL information.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_LEGACY_FREE</td><td>mainboard/bap/ode_e20XX</td><td>bool</td><td>Select DDR3 clock</td><td>
Select your preferred DDR3 clock setting.<br />
<br />
Note: This option changes the total power consumption.<br />
<br />
If unsure, use DDR3-1066.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOARD_EMULATION_QEMU_AARCH64</td><td>mainboard/emulation/qemu-aarch64.name</td><td>bool</td><td>QEMU AArch64 (virt)</td><td>
To execute, do:<br />
qemu-system-aarch64 -bios ./build/coreboot.rom -M virt,secure=on,virtualization=on -cpu cortex-a53 -nographic -m 8192M<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_DIR</td><td>mainboard/kontron/mal10</td><td>string</td><td>Carrier board</td><td>
This option sets the type of carrier board to be used with<br />
the Kontron mAL10 COMe module.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOARD_KONTRON_T10_TNI</td><td>mainboard/kontron/mal10</td><td>bool</td><td>Kontron i-T10-TNIx</td><td>
By selecting this option, the target ROM image will be built for<br />
the Kontron Ref.Carrier-i T10-TNI carrier board.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/adlink</td><td>(comment)</td><td></td><td>see under vendor LiPPERT</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/kahlee.name</td><td>(comment)</td><td></td><td>Kahlee</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/deltaur.name</td><td>(comment)</td><td></td><td>Deltaur</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/beltino.name</td><td>(comment)</td><td></td><td>Beltino</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/jecht.name</td><td>(comment)</td><td></td><td>Jecht</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/zork.name</td><td>(comment)</td><td></td><td>Zork</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/oak.name</td><td>(comment)</td><td></td><td>Oak</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/auron.name</td><td>(comment)</td><td></td><td>Auron</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/trogdor.name</td><td>(comment)</td><td></td><td>Trogdor</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/trogdor.name</td><td>(comment)</td><td></td><td>(Trogdor requires 'Allow QC blobs repository')</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/slippy.name</td><td>(comment)</td><td></td><td>Slippy</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/sarien.name</td><td>(comment)</td><td></td><td>Sarien</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/reef.name</td><td>(comment)</td><td></td><td>Reef</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/hatch.name</td><td>(comment)</td><td></td><td>Hatch</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/glados.name</td><td>(comment)</td><td></td><td>Glados</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/guybrush.name</td><td>(comment)</td><td></td><td>Guybrush</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/drallion.name</td><td>(comment)</td><td></td><td>Drallion</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/volteer.name</td><td>(comment)</td><td></td><td>Volteer</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/gru.name</td><td>(comment)</td><td></td><td>Gru</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/veyron.name</td><td>(comment)</td><td></td><td>Veyron</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/octopus.name</td><td>(comment)</td><td></td><td>Octopus</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/poppy.name</td><td>(comment)</td><td></td><td>Poppy</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/rambi.name</td><td>(comment)</td><td></td><td>Rambi</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/cyan.name</td><td>(comment)</td><td></td><td>Cyan</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/asurada.name</td><td>(comment)</td><td></td><td>Asurada</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/fizz.name</td><td>(comment)</td><td></td><td>Fizz</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/kukui.name</td><td>(comment)</td><td></td><td>Kukui</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/google/kukui.name</td><td>(comment)</td><td></td><td>Jacuzzi</td></tr>
<tr bgcolor="#eeeeee">
<td>FMDFILE</td><td>mainboard/google/kahlee</td><td>string</td><td></td><td>
The build system creates a default FMAP from ROM_SIZE and CBFS_SIZE,<br />
but in some cases more complex setups are required.<br />
When an fmd is specified, it overrides the default format.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_OEM_BIN</td><td>mainboard/google/kahlee</td><td>bool</td><td>Add an oem.bin file</td><td>
Add an oem.bin file to identify the manufacturer in SMBIOS, overriding the<br />
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER value.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_PART_NUMBER</td><td>mainboard/google/nyan</td><td>string</td><td>BCT boot media</td><td>
Which boot media to configure the BCT for.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NYAN_BCT_CFG_SPI</td><td>mainboard/google/nyan</td><td>bool</td><td>SPI</td><td>
Configure the BCT for booting from SPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NYAN_BCT_CFG_EMMC</td><td>mainboard/google/nyan</td><td>bool</td><td>eMMC</td><td>
Configure the BCT for booting from eMMC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_BUS</td><td>mainboard/google/nyan</td><td>int</td><td>SPI bus with boot media ROM</td><td>
Which SPI bus the boot media is connected to.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PICASSO_FW_A_POSITION</td><td>mainboard/google/zork</td><td>hex</td><td></td><td>
Location of the AMD firmware in the RW_A region. This is the<br />
start of the RW-A region + 64 bytes for the cbfs header.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PICASSO_FW_B_POSITION</td><td>mainboard/google/zork</td><td>hex</td><td></td><td>
Location of the AMD firmware in the RW_B region. This is the<br />
start of the RW-A region + 64 bytes for the cbfs header.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VARIANT_SUPPORTS_PRE_V3_SCHEMATICS</td><td>mainboard/google/zork</td><td>bool</td><td></td><td>
Whether this variant supports pre-v3 version of schematics.<br />
Eventually, when a variant moves to a point where it no<br />
longer has to support pre-v3 schematics, `default y` entry<br />
for it can be dropped.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VARIANT_MIN_BOARD_ID_V3_6_SCHEMATICS</td><td>mainboard/google/zork</td><td>int</td><td></td><td>
Minimum board version where the variant starts supporting<br />
v3.6+ version of reference schematics.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VARIANT_MIN_BOARD_ID_V3_SCHEMATICS</td><td>mainboard/google/zork</td><td>int</td><td></td><td>
Minimum board version where the variant starts supporting<br />
v3 version of reference schematics.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VARIANT_SUPPORTS_WIFI_POWER_ACTIVE_HIGH</td><td>mainboard/google/zork</td><td>bool</td><td></td><td>
Whether this variant supports active high power enable for<br />
WiFi. For pre-v3 schematics, this is always true. There are<br />
some variants which used v3 schematics, but did not pick up<br />
the change for active low WiFi power enable. Those variants<br />
will have to set this config to true. Eventually, when a<br />
variant needs to only support v3 schematics with active low<br />
power enable for WiFi, `default y` entry for it can be<br />
dropped.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VARIANT_MIN_BOARD_ID_WIFI_POWER_ACTIVE_LOW</td><td>mainboard/google/zork</td><td>int</td><td></td><td>
Minimum board version where the variant starts supporting<br />
active low power enable for WiFi.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VARIANT_HAS_FPMCU</td><td>mainboard/google/zork</td><td>bool</td><td></td><td>
Select y if any SKU of the board has a fingerprint sensor<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VARIANT_MAX_BOARD_ID_BROKEN_FMPCU_POWER</td><td>mainboard/google/zork</td><td>int</td><td></td><td>
Last board version that needs the extra delay for FPMCU init.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_PART_NUMBER</td><td>mainboard/google/nyan_big</td><td>string</td><td>BCT boot media</td><td>
Which boot media to configure the BCT for.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NYAN_BIG_BCT_CFG_SPI</td><td>mainboard/google/nyan_big</td><td>bool</td><td>SPI</td><td>
Configure the BCT for booting from SPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NYAN_BIG_BCT_CFG_EMMC</td><td>mainboard/google/nyan_big</td><td>bool</td><td>eMMC</td><td>
Configure the BCT for booting from eMMC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_BUS</td><td>mainboard/google/nyan_big</td><td>int</td><td>SPI bus with boot media ROM</td><td>
Which SPI bus the boot media is connected to.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_FWM_POSITION_INDEX</td><td>mainboard/google/guybrush</td><td>int</td><td></td><td>
TODO: might need to be adapted for better placement of files in cbfs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRAM_SIZE_MB</td><td>mainboard/google/foster</td><td>int</td><td>BCT boot media</td><td>
Which boot media to configure the BCT for.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FOSTER_BCT_CFG_SPI</td><td>mainboard/google/foster</td><td>bool</td><td>SPI</td><td>
Configure the BCT for booting from SPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FOSTER_BCT_CFG_EMMC</td><td>mainboard/google/foster</td><td>bool</td><td>eMMC</td><td>
Configure the BCT for booting from eMMC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_BUS</td><td>mainboard/google/foster</td><td>int</td><td>SPI bus with boot media ROM</td><td>
Which SPI bus the boot media is connected to.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_PART_NUMBER</td><td>mainboard/google/nyan_blaze</td><td>string</td><td>BCT boot media</td><td>
Which boot media to configure the BCT for.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NYAN_BLAZE_BCT_CFG_SPI</td><td>mainboard/google/nyan_blaze</td><td>bool</td><td>SPI</td><td>
Configure the BCT for booting from SPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NYAN_BLAZE_BCT_CFG_EMMC</td><td>mainboard/google/nyan_blaze</td><td>bool</td><td>eMMC</td><td>
Configure the BCT for booting from eMMC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_BUS</td><td>mainboard/google/nyan_blaze</td><td>int</td><td>SPI bus with boot media ROM</td><td>
Which SPI bus the boot media is connected to.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_SPD_DATA</td><td>mainboard/google/cyan</td><td>bool</td><td>Display Memory Serial Presence Detect Data</td><td>
When enabled displays the memory configuration data.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRAM_SIZE_MB</td><td>mainboard/google/smaug</td><td>int</td><td>BCT boot media</td><td>
Which boot media to configure the BCT for.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMAUG_BCT_CFG_SPI</td><td>mainboard/google/smaug</td><td>bool</td><td>SPI</td><td>
Configure the BCT for booting from SPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMAUG_BCT_CFG_EMMC</td><td>mainboard/google/smaug</td><td>bool</td><td>eMMC</td><td>
Configure the BCT for booting from eMMC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_BUS</td><td>mainboard/google/smaug</td><td>int</td><td>SPI bus with boot media ROM</td><td>
Which SPI bus the boot media is connected to.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/clevo/cml-u.name</td><td>(comment)</td><td></td><td>Comet Lake U</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/clevo/kbl-u.name</td><td>(comment)</td><td></td><td>Kaby Lake U</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_USE_1_0_0_4_HEADER</td><td>mainboard/pcengines/apu2</td><td>bool</td><td></td><td>
Due to a bug in AGESA 1.0.0.A affecting boards without UMA, it is<br />
impossible to use the newest blob. Using an older 1.0.0.4 blob<br />
workarounds the problem, however some headers changes between blob<br />
revisions. This option removes the changes in headers introduced<br />
with AGESA 1.0.0.A to fit the 1.0.0.4 revision.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HWM_PORT</td><td>mainboard/amd/padmelon</td><td>hex</td><td></td><td>
HWM base address must be an odd address. Hardware monitor used<br />
addresses are HWM_PORT for index an HWM_PORT + 1 for data.<br />
If changed, make sure fan_init.c IO window setting. The HWM<br />
(Hardware Monitor) is used for fan control within padmelon.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_LPC_DEBUG_CARD</td><td>mainboard/amd/mandolin</td><td>bool</td><td>Enable LPC-Serial debug card on the debug header</td><td>
AMD's debug card contains an SMSC SIO1036 device which provides an<br />
I/O-mapped UART in the system. This is mutually exclusive with<br />
AMD_SOC_CONSOLE_UART which selects the SoC's integrated memory-mapped<br />
UART for coreboot console output.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_FWM_POSITION_INDEX</td><td>mainboard/amd/mandolin</td><td>int</td><td></td><td>
TODO: might need to be adapted for better placement of files in cbfs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MANDOLIN_MCHP_FW_FILE</td><td>mainboard/amd/mandolin</td><td>string</td><td></td><td>
The EC firmware blob is usually the first 128kByte of the stock<br />
firmware image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MANDOLIN_MCHP_FW_FILE</td><td>mainboard/amd/mandolin</td><td>string</td><td>State of IOMux for LPC/eMMC signals</td><td>
Mandolin is designed to use either LPC or eMMC signals.  Use this<br />
selection to determine which are configured for this image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MANDOLIN_LPC</td><td>mainboard/amd/mandolin</td><td>bool</td><td></td><td>
Picasso's LPC bus signals are MUXed with some of the EMMC signals.<br />
Select this option if LPC signals are required.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_DGPU_ID</td><td>mainboard/amd/mandolin</td><td>string</td><td></td><td>
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_FWM_POSITION_INDEX</td><td>mainboard/amd/majolica</td><td>int</td><td></td><td>
TODO: might need to be adapted for better placement of files in cbfs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAJOLICA_MCHP_FW_FILE</td><td>mainboard/amd/majolica</td><td>string</td><td></td><td>
The EC firmware blob is usually the first 128kByte of the stock<br />
firmware image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/intel/coffeelake_rvp.name</td><td>(comment)</td><td></td><td>Coffeelake RVP</td></tr>
<tr bgcolor="#eeeeee">
<td>DIMM_SPD_SIZE</td><td>mainboard/intel/tglrvp</td><td>int</td><td>ON BOARD EC</td><td>
This option allows you to select the on board EC to use.<br />
Select whether the board  has Intel EC or Chrome EC<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Debugging</td></tr>
<tr bgcolor="#eeeeee">
<td>DISABLE_UART_ON_TESTPADS</td><td>mainboard/intel/dcp847ske</td><td>bool</td><td>Disable UART on testpads</td><td>
Serial output requires soldering to the testpad next to<br />
NCT5577D pin 18 (txd) and gnd.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>VGA_BIOS_FILE</td><td>mainboard/intel/strago</td><td>string</td><td></td><td>
The C0 version of the video BIOS gets computed from this name<br />
so that they can both be added.  Only the correct one for the<br />
system will be run.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>mainboard/intel/strago</td><td>string</td><td></td><td>
The VGA_BIOS_ID for the C0 version of the video BIOS is hardcoded<br />
in soc/intel/braswell/Makefile.inc as 8086,22b1<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BASEBOARD_GLKRVP_LAPTOP</td><td>mainboard/intel/glkrvp</td><td>None</td><td>ON BOARD EC</td><td>
This option allows you to select the on board EC to use.<br />
Select whether the board  has Intel EC or Chrome EC<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GALILEO_GEN2</td><td>mainboard/intel/galileo</td><td>bool</td><td>Board generation: GEN1 (n) or GEN2 (y)</td><td>
The coreboot binary will configure only one generation of the Galileo<br />
board since coreboot can not determine the board generation at<br />
runtime.  Select which generation of the Galileo that coreboot<br />
should initialize.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_BUILD_TYPE_DEBUG</td><td>mainboard/intel/galileo</td><td>bool</td><td>Debug</td><td>
Use the debug version of FSP<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_BUILD_TYPE_RELEASE</td><td>mainboard/intel/galileo</td><td>bool</td><td>Release</td><td>
Use the release version of FSP<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TYPE_2_0</td><td>mainboard/intel/galileo</td><td>bool</td><td>MemInit subroutine</td><td>
FSP 2.0 implemented as subroutines, no EDK-II cores<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TYPE_2_0_PEI</td><td>mainboard/intel/galileo</td><td>bool</td><td>SEC + PEI Core + MemInit PEIM</td><td>
FSP 2.0 implemented using SEC and PEI core<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_DEBUG_ALL</td><td>mainboard/intel/galileo</td><td>bool</td><td>Enable all FSP debug support</td><td>
Turn on debug support to display HOBS, MTRRS, SMM_MEMORY_MAP, UPD_DATA<br />
also turn on FSP 2.0 debug support for ESRAM_LAYOUT,<br />
FSP_CALLS_AND_STATUS, FSP_HEADER, POSTCAR_CONSOLE and VERIFY_HOBS<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_WITH_CRYPTO_SHIELD</td><td>mainboard/intel/galileo</td><td>bool</td><td>Verified boot using the Crypto Shield board</td><td>
Perform a verified boot using the TPM on the Crypto Shield board.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVER_TPM_I2C_ADDR</td><td>mainboard/intel/galileo</td><td>hex</td><td>Address of the I2C TPM chip</td><td>
I2C address of the TPM chip on the Crypto Shield board.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FMDFILE</td><td>mainboard/intel/galileo</td><td>string</td><td>FMAP description file in fmd format</td><td>
The build system creates a default FMAP from ROM_SIZE and CBFS_SIZE,<br />
but in some cases more complex setups are required.<br />
<br />
When an FMD descriptionn file is specified, the build system uses it<br />
instead of creating a default FMAP file.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DIMM_SPD_SIZE</td><td>mainboard/intel/adlrvp</td><td>int</td><td>ON BOARD EC</td><td>
This option allows you to select the on board EC to use.<br />
Select whether the board has Intel EC or Chrome EC<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_FSP_MEMORY_DOWN</td><td>mainboard/intel/harcuvar</td><td>bool</td><td>Enable Memory Down</td><td>
Select this option to enable Memory Down function.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPD_LOC</td><td>mainboard/intel/harcuvar</td><td>hex</td><td>SPD binary location in cbfs</td><td>
Location of SPD binary for memory down function.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ONBOARD_SAMSUNG_MEM</td><td>mainboard/facebook/fbg1701</td><td>bool</td><td>Onboard memory manufacturer Samsung</td><td>
Samsung K4B8G1646D memory<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOARD_EXAMPLE_MIN86</td><td>mainboard/example/min86.name</td><td>bool</td><td>Minimal x86 fake board</td><td>
This example mainboard code along with the example/min86 SoC<br />
should serve as a minimal example how a buildable x86 SoC code<br />
base can look like.<br />
<br />
This can serve, for instance, as a basis to add new SoCs to<br />
coreboot. Starting with a buildable commit should help with<br />
the review of the actual code, and also avoid any regressions<br />
when common coreboot code changes.<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_FILE</td><td>mainboard/protectli/vault_bsw</td><td>string</td><td></td><td>
The C0 version of the video bios gets computed from this name<br />
so that they can both be added.  Only the correct one for the<br />
system will be run.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>mainboard/protectli/vault_bsw</td><td>string</td><td></td><td>
The VGA_BIOS_ID for the C0 version of the video bios is hardcoded<br />
in soc/intel/braswell/Makefile.inc as 8086,22b1<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOARD_ASUS_F2A85_M_DDR3_VOLT_135</td><td>mainboard/asus/f2a85-m</td><td>bool</td><td>1.35V</td><td>
Set DRR3 memory voltage to 1.35V<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOARD_ASUS_F2A85_M_DDR3_VOLT_150</td><td>mainboard/asus/f2a85-m</td><td>bool</td><td>1.50V</td><td>
Set DRR3 memory voltage to 1.50V<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOARD_ASUS_F2A85_M_DDR3_VOLT_165</td><td>mainboard/asus/f2a85-m</td><td>bool</td><td>1.65V</td><td>
Set DRR3 memory voltage to 1.65V<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/siemens/chili.name</td><td>(comment)</td><td></td><td>CHILI</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/siemens/mc_apl1.name</td><td>(comment)</td><td></td><td>MC APLx</td></tr>
<tr bgcolor="#eeeeee">
<td>INCLUDE_SMSC_SCH5545_EC_FW</td><td>mainboard/dell/optiplex_9010</td><td>bool</td><td>Include SMSC SCH5545 EC firmware binary</td><td>
This option allows to add the SMSC SCH5545 Environmental Controller<br />
firmware binary. The firmware must be loaded after each power failure<br />
in order to properly initialize the fan control, because EC loses its<br />
configuration when power is cut off. Otherwise the fans will keep<br />
running at full speed after power failure.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>mainboard/lippert</td><td>(comment)</td><td></td><td>was acquired by ADLINK</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_UART_8250IO</td><td>mainboard/purism/librem_bdw</td><td>string</td><td></td><td>
This platform does not have any way to get standard<br />
serial output so disable it by default.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOARD_ROMSIZE_KB_65536</td><td>mainboard</td><td>bool</td><td>ROM chip size</td><td>
Select the size of the ROM chip you intend to flash coreboot on.<br />
<br />
The build system will take care of creating a coreboot.rom file<br />
of the matching size.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_256</td><td>mainboard</td><td>bool</td><td>256 KB</td><td>
Choose this option if you have a 256 KB ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_512</td><td>mainboard</td><td>bool</td><td>512 KB</td><td>
Choose this option if you have a 512 KB ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_1024</td><td>mainboard</td><td>bool</td><td>1024 KB (1 MB)</td><td>
Choose this option if you have a 1024 KB (1 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_2048</td><td>mainboard</td><td>bool</td><td>2048 KB (2 MB)</td><td>
Choose this option if you have a 2048 KB (2 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_4096</td><td>mainboard</td><td>bool</td><td>4096 KB (4 MB)</td><td>
Choose this option if you have a 4096 KB (4 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_5120</td><td>mainboard</td><td>bool</td><td>5120 KB (5 MB)</td><td>
Choose this option if you have a 5120 KB (5 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_6144</td><td>mainboard</td><td>bool</td><td>6144 KB (6 MB)</td><td>
Choose this option if you have a 6144 KB (6 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_8192</td><td>mainboard</td><td>bool</td><td>8192 KB (8 MB)</td><td>
Choose this option if you have a 8192 KB (8 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_10240</td><td>mainboard</td><td>bool</td><td>10240 KB (10 MB)</td><td>
Choose this option if you have a 10240 KB (10 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_12288</td><td>mainboard</td><td>bool</td><td>12288 KB (12 MB)</td><td>
Choose this option if you have a 12288 KB (12 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_16384</td><td>mainboard</td><td>bool</td><td>16384 KB (16 MB)</td><td>
Choose this option if you have a 16384 KB (16 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_32768</td><td>mainboard</td><td>bool</td><td>32768 KB (32 MB)</td><td>
Choose this option if you have a 32768 KB (32 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COREBOOT_ROMSIZE_KB_65536</td><td>mainboard</td><td>bool</td><td>65536 KB (64 MB)</td><td>
Choose this option if you have a 65536 KB (64 MB) ROM chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_POWER_BUTTON</td><td>mainboard</td><td>bool</td><td>Enable the power button</td><td>
The selected mainboard can optionally have the power button tied<br />
to ground with a jumper so that the button appears to be<br />
constantly depressed. If this option is enabled and the jumper is<br />
installed then the board will turn on, but turn off again after a<br />
short timeout, usually 4 seconds.<br />
<br />
Select Y here if you have removed the jumper and want to use an<br />
actual power button. Select N if you have the jumper installed.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_STATE_DEFAULT_ON_AFTER_FAILURE</td><td>mainboard</td><td>bool</td><td></td><td>
Selected by platforms or mainboards that want a "default on"<br />
behaviour.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_STATE_DEFAULT_ON_AFTER_FAILURE</td><td>mainboard</td><td>bool</td><td>System Power State after Failure</td><td>
Provides a default for the power state the system should<br />
go into after G3 (power loss). On many boards this can be<br />
overridden by an NVRAM option.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_STATE_OFF_AFTER_FAILURE</td><td>mainboard</td><td>bool</td><td>S5 Soft Off</td><td>
Choose this option if you want to put system into<br />
S5 after reapplying power after failure.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_STATE_ON_AFTER_FAILURE</td><td>mainboard</td><td>bool</td><td>S0 Full On</td><td>
Choose this option if you want to keep system in<br />
S0 after reapplying power after failure.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_STATE_PREVIOUS_AFTER_FAILURE</td><td>mainboard</td><td>bool</td><td>Keep Previous State</td><td>
Choose this option if you want to keep system in the<br />
same power state as before failure after reapplying<br />
power.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEVICETREE</td><td>toplevel</td><td>string</td><td></td><td>
This symbol allows mainboards to select a different file under their<br />
mainboard directory for the devicetree.cb file.  This allows the board<br />
variants that need different devicetrees to be in the same directory.<br />
<br />
Examples: "devicetree.variant.cb"<br />
"variant/devicetree.cb"<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>OVERRIDE_DEVICETREE</td><td>toplevel</td><td>string</td><td></td><td>
This symbol allows variants to provide an override devicetree file to<br />
override the registers and/or add new devices on top of the ones<br />
provided by baseboard devicetree using CONFIG_DEVICETREE.<br />
<br />
Examples: "devicetree.variant-override.cb"<br />
"variant/devicetree-override.cb"<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FMDFILE</td><td>toplevel</td><td>string</td><td>fmap description file in fmd format</td><td>
The build system creates a default FMAP from ROM_SIZE and CBFS_SIZE,<br />
but in some cases more complex setups are required.<br />
When an fmd is specified, it overrides the default format.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_SIZE</td><td>toplevel</td><td>hex</td><td>Size of CBFS filesystem in ROM</td><td>
This is the part of the ROM actually managed by CBFS, located at the<br />
end of the ROM (passed through cbfstool -o) on x86 and at at the start<br />
of the ROM (passed through cbfstool -s) everywhere else. It defaults<br />
to span the whole ROM on all but Intel systems that use an Intel Firmware<br />
Descriptor.  It can be overridden to make coreboot live alongside other<br />
components like ChromeOS's vboot/FMAP or Intel's IFD / ME / TXE<br />
binaries. This symbol should only be used to generate a default FMAP and<br />
is unused when a non-default fmd file is provided via CONFIG_FMDFILE.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>CBFS_AUTOGEN_ATTRIBUTES</td><td>toplevel</td><td>bool</td><td></td><td>
If this option is selected, every file in cbfs which has a constraint<br />
regarding position or alignment will get an additional file attribute<br />
which describes this constraint.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Chipset</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>SoC</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_DRAM</td><td>soc/mediatek/mt8183</td><td>bool</td><td>Output verbose DRAM related debug messages</td><td>
This option enables additional DRAM related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MT8183_DRAM_EMCP</td><td>soc/mediatek/mt8183</td><td>bool</td><td></td><td>
The eMCP platform should select this option to run at different DRAM<br />
frequencies.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MT8183_DRAM_DVFS</td><td>soc/mediatek/mt8183</td><td>bool</td><td></td><td>
This options enables DRAM calibration with multiple frequencies (low,<br />
medium and high) for DVFS feature.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SSPM_FIRMWARE</td><td>soc/mediatek/mt8183</td><td>string</td><td></td><td>
The file name of the MediaTek SSPM firmware.<br />
<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_DRAM</td><td>soc/mediatek/mt8192</td><td>bool</td><td>Output verbose DRAM related debug messages</td><td>
This option enables additional DRAM related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MT8192_DRAM_EMCP</td><td>soc/mediatek/mt8192</td><td>bool</td><td></td><td>
The eMCP platform should select this option to run at different DRAM<br />
frequencies.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MT8192_DRAM_DVFS</td><td>soc/mediatek/mt8192</td><td>bool</td><td></td><td>
This option enables DRAM calibration with multiple frequencies (low,<br />
medium and high frequency groups, with total 7 frequencies) for DVFS<br />
feature. All supported data rates are: 800, 1200, 1600, 1866, 2400,<br />
3200, 4266.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MEMORY_TEST</td><td>soc/mediatek/mt8192</td><td>bool</td><td></td><td>
This option enables memory basic compare test to verify the DRAM read<br />
or write is as expected.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DPM_DM_FIRMWARE</td><td>soc/mediatek/mt8192</td><td>string</td><td></td><td>
The file name of the MediaTek DPM DM firmware<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DPM_PM_FIRMWARE</td><td>soc/mediatek/mt8192</td><td>string</td><td></td><td>
The file name of the MediaTek DPM PM firmware<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MCUPM_FIRMWARE</td><td>soc/mediatek/mt8192</td><td>string</td><td></td><td>
The file name of the MediaTek MCUPM firmware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPM_FIRMWARE</td><td>soc/mediatek/mt8192</td><td>string</td><td></td><td>
The file name of the MediaTek SPM firmware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SSPM_FIRMWARE</td><td>soc/mediatek/mt8192</td><td>string</td><td></td><td>
The file name of the MediaTek SSPM firmware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FLASH_DUAL_READ</td><td>soc/mediatek/mt8192</td><td>bool</td><td></td><td>
When this option is enabled, the flash controller provides the ability<br />
to dual read mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SRCLKEN_RC_SUPPORT</td><td>soc/mediatek/mt8192</td><td>bool</td><td></td><td>
This option enables clock buffer remote controller module<br />
to control PMIC 26MHz clock output.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_DRAM</td><td>soc/mediatek/mt8173</td><td>bool</td><td>Output verbose DRAM related debug messages</td><td>
This option enables additional DRAM related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_I2C</td><td>soc/mediatek/mt8173</td><td>bool</td><td>Output verbose I2C related debug messages</td><td>
This option enables I2C related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_PMIC</td><td>soc/mediatek/mt8173</td><td>bool</td><td>Output verbose PMIC related debug messages</td><td>
This option enables PMIC related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_PMIC_WRAP</td><td>soc/mediatek/mt8173</td><td>bool</td><td>Output verbose PMIC WRAP related debug messages</td><td>
This option enables PMIC WRAP related debug messages.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SBL_BLOB</td><td>soc/qualcomm/ipq806x</td><td>string</td><td>file name of the Qualcomm SBL blob</td><td>
The path and filename of the binary blob containing<br />
ipq806x early initialization code, as supplied by the<br />
vendor.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_QUALCOMM_COMMON</td><td>soc/qualcomm/common</td><td>bool</td><td></td><td>
Selected by platforms that use the common code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPQ_QFN_PART</td><td>soc/qualcomm/ipq40xx</td><td>bool</td><td></td><td>
Is the SoC a QFN part (as opposed to a BGA part)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SBL_ELF</td><td>soc/qualcomm/ipq40xx</td><td>string</td><td>file name of the QCA SBL ELF</td><td>
The path and filename of the binary blob containing<br />
ipq40xx early initialization code, as supplied by the<br />
vendor.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SBL_UTIL_PATH</td><td>soc/qualcomm/ipq40xx</td><td>string</td><td>Path for utils to combine SBL_ELF and bootblock</td><td>
Path for utils to combine SBL_ELF and bootblock<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UART_FOR_CONSOLE</td><td>soc/qualcomm/sc7180</td><td>int</td><td></td><td>
Select the QUP instance to be used for UART console output.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_CEZANNE</td><td>soc/amd/cezanne</td><td>bool</td><td></td><td>
AMD Cezanne support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EARLY_RESERVED_DRAM_BASE</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
This variable defines the base address of the DRAM which is reserved<br />
for usage by coreboot in early stages (i.e. before ramstage is up).<br />
This memory gets reserved in BIOS tables to ensure that the OS does<br />
not use it, thus preventing corruption of OS memory in case of S3<br />
resume.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_APOB_DRAM_ADDRESS</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
Location in DRAM where the PSP will copy the AGESA PSP Output<br />
Block.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PRERAM_CBMEM_CONSOLE_SIZE</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
Increase this value if preram cbmem console is getting truncated<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>C_ENV_BOOTBLOCK_SIZE</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
Sets the size of the bootblock stage that should be loaded in DRAM.<br />
This variable controls the DRAM allocation size in linker script<br />
for bootblock stage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ROMSTAGE_ADDR</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
Sets the address in DRAM where romstage should be loaded.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ROMSTAGE_SIZE</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
Sets the size of DRAM allocation for romstage in linker script.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_ADDR</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
Sets the address in DRAM where FSP-M should be loaded. cbfstool<br />
performs relocation of FSP-M to this address.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_SIZE</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
Sets the size of DRAM allocation for FSP-M in linker script.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/amd/cezanne</td><td>hex</td><td></td><td>
The amount of coreboot-allocated heap and stack usage by the FSP.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: PSP Configuration Options</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_FWM_POSITION_INDEX</td><td>soc/amd/cezanne</td><td>int</td><td>Firmware Directory Table location (0 to 5)</td><td>
Typically this is calculated by the ROM size, but there may<br />
be situations where you want to put the firmware directory<br />
table in a different location.<br />
0: 512 KB - 0xFFFA0000<br />
1: 1 MB   - 0xFFF20000<br />
2: 2 MB   - 0xFFE20000<br />
3: 4 MB   - 0xFFC20000<br />
4: 8 MB   - 0xFF820000<br />
5: 16 MB  - 0xFF020000<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/cezanne</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 512KB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/cezanne</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 1MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/cezanne</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 2MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/cezanne</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 4MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/cezanne</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 8MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/cezanne</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 16MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_PSPSECUREOS</td><td>soc/amd/cezanne</td><td>bool</td><td></td><td>
Include the PspSecureOs and PspTrustlet binaries in the PSP build.<br />
<br />
If unsure, answer 'y'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_LOAD_MP2_FW</td><td>soc/amd/cezanne</td><td>bool</td><td></td><td>
Include the MP2 firmwares and configuration into the PSP build.<br />
<br />
If unsure, answer 'n'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_LOAD_S0I3_FW</td><td>soc/amd/cezanne</td><td>bool</td><td></td><td>
Select this item to include the S0i3 file into the PSP build.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_UNLOCK_SECURE_DEBUG</td><td>soc/amd/cezanne</td><td>bool</td><td>Unlock secure debug</td><td>
Select this item to enable secure debug options in PSP.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>SOC_AMD_STONEYRIDGE</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
AMD support for SOCs in Family 15h Models 60h-6Fh and Models 70h-7Fh.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_APU_STONEYRIDGE</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
AMD Stoney Ridge APU<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_APU_PRAIRIEFALCON</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
AMD Embedded Prairie Falcon APU<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_APU_MERLINFALCON</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
AMD Embedded Merlin Falcon APU<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_APU_PKG_FP4</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
AMD FP4 package<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_APU_PKG_FT4</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
AMD FT4 package<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/amd/stoneyridge</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PRERAM_CBMEM_CONSOLE_SIZE</td><td>soc/amd/stoneyridge</td><td>hex</td><td></td><td>
Increase this value if preram cbmem console is getting truncated<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOTTOMIO_POSITION</td><td>soc/amd/stoneyridge</td><td>hex</td><td>Bottom of 32-bit IO space</td><td>
If PCI peripherals with big BARs are connected to the system<br />
the bottom of the IO must be decreased to allocate such<br />
devices.<br />
<br />
Declare the beginning of the 128MB-aligned MMIO region.  This<br />
option is useful when PCI peripherals requesting large address<br />
ranges are present.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>soc/amd/stoneyridge</td><td>string</td><td></td><td>
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STONEYRIDGE_XHCI_ENABLE</td><td>soc/amd/stoneyridge</td><td>bool</td><td>Enable Stoney Ridge XHCI Controller</td><td>
The XHCI controller must be enabled and the XHCI firmware<br />
must be added in order to have USB 3.0 support configured<br />
by coreboot. The OS will be responsible for enabling the XHCI<br />
controller if the XHCI firmware is available but the<br />
XHCI controller is not enabled by coreboot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STONEYRIDGE_XHCI_FWM</td><td>soc/amd/stoneyridge</td><td>bool</td><td>Add xhci firmware</td><td>
Add Stoney Ridge XHCI Firmware to support the onboard USB 3.0<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STONEYRIDGE_GEC_FWM</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
Add Stoney Ridge GEC Firmware to support the onboard gigabit Ethernet MAC.<br />
Must be connected to a Broadcom B50610 or B50610M PHY on the motherboard.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STONEYRIDGE_SATA_MODE</td><td>soc/amd/stoneyridge</td><td>int</td><td>SATA Mode</td><td>
Select the mode in which SATA should be driven.<br />
The default is NATIVE.<br />
0: NATIVE mode does not require a ROM.<br />
2: AHCI may work with or without AHCI ROM. It depends on the payload support.<br />
For example, seabios does not require the AHCI ROM.<br />
3: LEGACY IDE<br />
4: IDE to AHCI<br />
5: AHCI7804: ROM Required, and AMD driver required in the OS.<br />
6: IDE to AHCI7804: ROM Required, and AMD driver required in the OS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>NATIVE</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AHCI</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>LEGACY IDE</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>IDE to AHCI</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AHCI7804</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>IDE to AHCI7804</td></tr>
<tr bgcolor="#eeeeee">
<td>STONEYRIDGE_LEGACY_FREE</td><td>soc/amd/stoneyridge</td><td>bool</td><td>System is legacy free</td><td>
Select y if there is no keyboard controller in the system.<br />
This sets variables in AGESA and ACPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIRQ_CONTINUOUS_MODE</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
Set this option to y for serial IRQ in continuous mode.<br />
Otherwise it is in quiet mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STONEYRIDGE_ACPI_IO_BASE</td><td>soc/amd/stoneyridge</td><td>hex</td><td></td><td>
Base address for the ACPI registers.<br />
This value must match the hardcoded value of AGESA.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_BERT</td><td>soc/amd/stoneyridge</td><td>bool</td><td>Build ACPI BERT Table</td><td>
Report Machine Check errors identified in POST to the OS in an<br />
ACPI Boot Error Record Table.  This option reserves an 8MB region<br />
for building the error structures.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_PSPSECUREOS</td><td>soc/amd/stoneyridge</td><td>bool</td><td>Include PSP SecureOS blobs in AMD firmware</td><td>
Include the PspSecureOs, PspTrustlet and TrustletKey binaries<br />
in the amdfw section.<br />
<br />
If unsure, answer 'y'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_PSP_SELECTABLE_SMU_FW</td><td>soc/amd/stoneyridge</td><td>bool</td><td></td><td>
Some ST implementations allow storing SMU firmware into cbfs and<br />
calling the PSP to load the blobs at the proper time.<br />
<br />
Merlin Falcon does not support it. If you are using 00670F00 SOC,<br />
ask your AMD representative if it supports it or not.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMDFW_OUTSIDE_CBFS</td><td>soc/amd/stoneyridge</td><td>bool</td><td>The AMD firmware is outside CBFS</td><td>
The AMDFW (PSP) is typically locatable in cbfs.  Select this<br />
option to manually attach the generated amdfw.rom outside of<br />
cbfs.  The location is selected by the FWM position.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_FWM_POSITION_INDEX</td><td>soc/amd/stoneyridge</td><td>int</td><td>Firmware Directory Table location (0 to 5)</td><td>
Typically this is calculated by the ROM size, but there may<br />
be situations where you want to put the firmware directory<br />
table in a different location.<br />
0: 512 KB - 0xFFFA0000<br />
1: 1 MB   - 0xFFF20000<br />
2: 2 MB   - 0xFFE20000<br />
3: 4 MB   - 0xFFC20000<br />
4: 8 MB   - 0xFF820000<br />
5: 16 MB  - 0xFF020000<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 512KB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 1MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 2MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 4MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 8MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/stoneyridge</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 16MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_POWER_RESTORE</td><td>soc/amd/stoneyridge</td><td>int</td><td></td><td>
This option determines what state to go to once power is restored<br />
after having been lost in S0.  Select this option to automatically<br />
return to S0.  Otherwise the system will remain in S5 once power<br />
is restored.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_PICASSO</td><td>soc/amd/picasso</td><td>bool</td><td></td><td>
AMD Picasso support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_FILE</td><td>soc/amd/picasso</td><td>string</td><td>FSP-M (memory init) binary path and filename</td><td>
The path and filename of the FSP-M binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_S_FILE</td><td>soc/amd/picasso</td><td>string</td><td>FSP-S (silicon init) binary path and filename</td><td>
The path and filename of the FSP-S binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EARLY_RESERVED_DRAM_BASE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
This variable defines the base address of the DRAM which is reserved<br />
for usage by coreboot in early stages (i.e. before ramstage is up).<br />
This memory gets reserved in BIOS tables to ensure that the OS does<br />
not use it, thus preventing corruption of OS memory in case of S3<br />
resume.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_APOB_DRAM_ADDRESS</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Location in DRAM where the PSP will copy the AGESA PSP Output<br />
Block.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_SHAREDMEM_BASE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
This variable defines the base address in DRAM memory where PSP copies<br />
vboot workbuf to. This is used in linker script to have a static<br />
allocation for the buffer as well as for adding relevant entries in<br />
BIOS directory table for the PSP.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_SHAREDMEM_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the maximum size for the PSP to pass the vboot workbuf and<br />
any logs or timestamps back to coreboot.  This will be copied<br />
into main memory by the PSP and will be available when the x86 is<br />
started.  The workbuf's base depends on the address of the reset<br />
vector.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PRERAM_CBMEM_CONSOLE_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Increase this value if preram cbmem console is getting truncated<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>C_ENV_BOOTBLOCK_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the size of the bootblock stage that should be loaded in DRAM.<br />
This variable controls the DRAM allocation size in linker script<br />
for bootblock stage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ROMSTAGE_ADDR</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the address in DRAM where romstage should be loaded.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ROMSTAGE_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the size of DRAM allocation for romstage in linker script.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_ADDR</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the address in DRAM where FSP-M should be loaded. cbfstool<br />
performs relocation of FSP-M to this address.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the size of DRAM allocation for FSP-M in linker script.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VERSTAGE_ADDR</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the address in DRAM where verstage should be loaded if running<br />
as a separate stage on x86.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VERSTAGE_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Sets the size of DRAM allocation for verstage in linker script if<br />
running as a separate stage on x86.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>soc/amd/picasso</td><td>string</td><td></td><td>
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev_rev() function in northbridge.c.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_SECOND_ID</td><td>soc/amd/picasso</td><td>string</td><td></td><td>
Because Dali and Picasso need different video BIOSes, but have the<br />
same vendor/device IDs, we need an alternate method to determine the<br />
correct video BIOS. In map_oprom_vendev_rev(), we look at the cpuid<br />
and decide which rom to load.<br />
<br />
Even though the hardware has the same vendor/device IDs, the vBIOS<br />
contains a *different* device ID, confusing the situation even more.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHECK_REV_IN_OPROM_NAME</td><td>soc/amd/picasso</td><td>bool</td><td></td><td>
Select this in the platform BIOS or chipset if the option rom has a<br />
revision that needs to be checked when searching CBFS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PICASSO_FCH_IOAPIC_ID</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
The Picasso APU has two IOAPICs, one in the FCH and one in the<br />
northbridge.  Set this value for the intended ID to assign to the<br />
FCH IOAPIC.  The value should be &gt;= MAX_CPUS and different from<br />
the GNB's IOAPIC_ID.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PICASSO_GNB_IOAPIC_ID</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
The Picasso APU has two IOAPICs, one in the FCH and one in the<br />
northbridge.  Set this value for the intended ID to assign to the<br />
GNB IOAPIC.  The value should be &gt;= MAX_CPUS and different from<br />
the FCH's IOAPIC_ID.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIRQ_CONTINUOUS_MODE</td><td>soc/amd/picasso</td><td>bool</td><td></td><td>
Set this option to y for serial IRQ in continuous mode.<br />
Otherwise it is in quiet mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PICASSO_ACPI_IO_BASE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Base address for the ACPI registers.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_BERT</td><td>soc/amd/picasso</td><td>bool</td><td>Build ACPI BERT Table</td><td>
Report Machine Check errors identified in POST to the OS in an<br />
ACPI Boot Error Record Table.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_BERT_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Specify the amount of DRAM reserved for gathering the data used to<br />
generate the ACPI table.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_SSDT_PSD_INDEPENDENT</td><td>soc/amd/picasso</td><td>bool</td><td>Allow core p-state independent transitions</td><td>
AMD recommends the ACPI _PSD object to be configured to cause<br />
cores to transition between p-states independently. A vendor may<br />
choose to generate _PSD object to allow cores to transition together.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISABLE_SPI_FLASH_ROM_SHARING</td><td>soc/amd/picasso</td><td>int</td><td></td><td>
Instruct the chipset to not honor the EGPIO67_SPI_ROM_REQ pin<br />
which indicates a board level ROM transaction request. This<br />
removes arbitration with board and assumes the chipset controls<br />
the SPI flash bus entirely.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_POWER_RESTORE</td><td>soc/amd/picasso</td><td>int</td><td></td><td>
This option determines what state to go to once power is restored<br />
after having been lost in S0.  Select this option to automatically<br />
return to S0.  Otherwise the system will remain in S5 once power<br />
is restored.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
The amount of coreboot-allocated heap and stack usage by the FSP.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: PSP Configuration Options</td></tr>
<tr bgcolor="#eeeeee">
<td>AMD_FWM_POSITION_INDEX</td><td>soc/amd/picasso</td><td>int</td><td>Firmware Directory Table location (0 to 5)</td><td>
Typically this is calculated by the ROM size, but there may<br />
be situations where you want to put the firmware directory<br />
table in a different location.<br />
0: 512 KB - 0xFFFA0000<br />
1: 1 MB   - 0xFFF20000<br />
2: 2 MB   - 0xFFE20000<br />
3: 4 MB   - 0xFFC20000<br />
4: 8 MB   - 0xFF820000<br />
5: 16 MB  - 0xFF020000<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/picasso</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 512KB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/picasso</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 1MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/picasso</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 2MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/picasso</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 4MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/picasso</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 8MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/amd/picasso</td><td>(comment)</td><td></td><td>AMD Firmware Directory Table set to location for 16MB ROM</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_PSPSECUREOS</td><td>soc/amd/picasso</td><td>bool</td><td></td><td>
Include the PspSecureOs and PspTrustlet binaries in the PSP build.<br />
<br />
If unsure, answer 'y'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_LOAD_MP2_FW</td><td>soc/amd/picasso</td><td>bool</td><td></td><td>
Include the MP2 firmwares and configuration into the PSP build.<br />
<br />
If unsure, answer 'n'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_LOAD_S0I3_FW</td><td>soc/amd/picasso</td><td>bool</td><td></td><td>
Select this item to include the S0i3 file into the PSP build.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_PSP_WHITELIST_FILE</td><td>soc/amd/picasso</td><td>bool</td><td>Include a debug whitelist file in PSP build</td><td>
Support secured unlock prior to reset using a whitelisted<br />
number?  This feature requires a signed whitelist image and<br />
bootloader from AMD.<br />
<br />
If unsure, answer 'n'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_SHAREDMEM_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td>Maximum size of shared memory area</td><td>
Sets the maximum size for the PSP to pass the vboot workbuf and<br />
any logs or timestamps back to coreboot.  This will be copied<br />
into main memory by the PSP and will be available when the x86 is<br />
started.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_UNLOCK_SECURE_DEBUG</td><td>soc/amd/picasso</td><td>bool</td><td>Unlock secure debug</td><td>
Select this item to enable secure debug options in PSP.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_VERSTAGE_FILE</td><td>soc/amd/picasso</td><td>string</td><td>Specify the PSP_verstage file path</td><td>
Add psp_verstage file to the build &amp; PSP Directory Table<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PSP_VERSTAGE_SIGNING_TOKEN</td><td>soc/amd/picasso</td><td>string</td><td>Specify the PSP_verstage Signature Token file path</td><td>
Add psp_verstage signature token to the build &amp; PSP Directory Table<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>VBOOT_STARTS_BEFORE_BOOTBLOCK</td><td>soc/amd/picasso</td><td>string</td><td></td><td>
Runs verstage on the PSP.  Only available on<br />
certain Chrome OS branded parts from AMD.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_HASH_BLOCK_SIZE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Because the bulk of the time in psp_verstage to hash the RO cbfs is<br />
spent in the overhead of doing svc calls, increasing the hash block<br />
size significantly cuts the verstage hashing time as seen below.<br />
<br />
4k takes 180ms<br />
16k takes 44ms<br />
32k takes 33.7ms<br />
36k takes 32.5ms<br />
There's actually still room for an even bigger stack, but we've<br />
reached a point of diminishing returns.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CMOS_RECOVERY_BYTE</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
If the workbuf is not passed from the PSP to coreboot, set the<br />
recovery flag and reboot.  The PSP will read this byte, mark the<br />
recovery request in VBNV, and reset the system into recovery mode.<br />
<br />
This is the byte before the default first byte used by VBNV<br />
(0x26 + 0x0E - 1)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RWA_REGION_ONLY</td><td>soc/amd/picasso</td><td>string</td><td></td><td>
Add a space-delimited list of filenames that should only be in the<br />
RW-A section.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RWB_REGION_ONLY</td><td>soc/amd/picasso</td><td>string</td><td></td><td>
Add a space-delimited list of filenames that should only be in the<br />
RW-B section.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PICASSO_FW_A_POSITION</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Location of the AMD firmware in the RW_A region<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PICASSO_FW_B_POSITION</td><td>soc/amd/picasso</td><td>hex</td><td></td><td>
Location of the AMD firmware in the RW_B region<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON</td><td>soc/amd/common.common</td><td>bool</td><td></td><td>
common code blocks for AMD SOCs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_ACPIMMIO</td><td>soc/amd/common/block/acpimmio</td><td>bool</td><td></td><td>
Select this option to enable hardware blocks in the AcpiMmio<br />
address space (0xfed8xxxx).<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_SPI</td><td>soc/amd/common/block/spi</td><td>bool</td><td></td><td>
Select this option to add FCH SPI controller functions to the build.<br />
This overwrites the structure spi_flash_ops to use FCH SPI code<br />
instead of individual SPI specific code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EFS_SPI_READ_MODE</td><td>soc/amd/common/block/spi</td><td>int</td><td></td><td>
SPI read mode to be programmed by the PSP.<br />
The numbers in the options below indicate how many wires<br />
are utilized for command, address and data. For instance 1-1-2<br />
means 1 command, 1 address and 2 data wires.<br />
0: Normal Read (up to 33M)<br />
1: Reserved<br />
2: Dual IO (1-1-2)<br />
3: Quad IO (1-1-4)<br />
4: Dual IO (1-2-2)<br />
5: Quad IO (1-4-4)<br />
6: Normal Read (up to 66M)<br />
7: Fast Read<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EFS_SPI_SPEED</td><td>soc/amd/common/block/spi</td><td>int</td><td></td><td>
SPI Fast Speed to be programmed by the PSP.<br />
0: 66.66Mhz<br />
1: 33.33MHz<br />
2: 22.22MHz<br />
3: 16.66MHz<br />
4: 100MHz<br />
5: 800KHz<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EFS_SPI_MICRON_FLAG</td><td>soc/amd/common/block/spi</td><td>int</td><td></td><td>
For Family 17h Model 00h and later SoC the PSP must be aware if a Micron<br />
part is present in EFS. Automatic detection (option 2) is available<br />
for Family 17h Model 30h-3Fh but is unsupported otherwise.<br />
0: Board does not use Micron parts<br />
1: Board always uses Micron parts<br />
2: Micron parts are optional<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_S3</td><td>soc/amd/common/block/s3</td><td>bool</td><td></td><td>
Select this option to add S3 related functions to the build.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_GRAPHICS</td><td>soc/amd/common/block/graphics</td><td>bool</td><td></td><td>
Select this option to use AMD common graphics driver support.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_GRAPHICS_ATIF</td><td>soc/amd/common/block/graphics</td><td>bool</td><td></td><td>
Select this option to provide ATIF method with display brightness querying.<br />
Currently, the exported values only open up 0-255 as the brightness range for<br />
the display.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_SMI</td><td>soc/amd/common/block/smi</td><td>bool</td><td></td><td>
Select this option to add the common functions for setting up the SMI<br />
configuration to the build.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_PSP</td><td>soc/amd/common/block/psp</td><td>bool</td><td></td><td>
This option builds in the Platform Security Processor initialization<br />
functions. Do not select this directly in SoC code, select<br />
SOC_AMD_COMMON_BLOCK_PSP_GENx instead.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_PSP_GEN1</td><td>soc/amd/common/block/psp</td><td>bool</td><td></td><td>
Used by the PSP in AMD systems before family 17h, e.g. stoneyridge.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_PSP_GEN2</td><td>soc/amd/common/block/psp</td><td>bool</td><td></td><td>
Used by the PSP in AMD family 17h, 19h and possibly newer CPUs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_PSP_SELECTABLE_SMU_FW</td><td>soc/amd/common/block/psp</td><td>bool</td><td></td><td>
Some PSP implementations allow storing SMU firmware into cbfs and<br />
calling the PSP to load the blobs at the proper time.<br />
<br />
The soc/&lt;codename&gt; should select this if its PSP supports the feature<br />
and each mainboard can choose to select an appropriate fanless or<br />
fanned set of blobs.  Ask your AMD representative whether your APU<br />
is considered fanless.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_BANKED_GPIOS</td><td>soc/amd/common/block/gpio_banks</td><td>bool</td><td></td><td>
Select this option to use the newer style banks of GPIO signals.<br />
These are at offsets +0x1500, +0x1600, and +0x1700 from the AcpiMmio<br />
base.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_ALINK</td><td>soc/amd/common/block/alink</td><td>bool</td><td></td><td>
Select this option to access the FCH A-link configuration registers.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_SATA</td><td>soc/amd/common/block/sata</td><td>bool</td><td></td><td>
Select this option to use AMD common SATA driver support.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_ACPI</td><td>soc/amd/common/block/acpi</td><td>bool</td><td></td><td>
Select this option to use the AcpiMmio ACPI registers.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_PI</td><td>soc/amd/common/block/pi</td><td>bool</td><td></td><td>
This option builds functions that interface AMD's AGESA reference<br />
code packaged in the binaryPI form.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PI_AGESA_CAR_HEAP_BASE</td><td>soc/amd/common/block/pi</td><td>hex</td><td></td><td>
The AGESA PI blob may be built to allow an optional callout for<br />
AgesaHeapRebase.  If AGESA calls AgesaHeapRebase, this option<br />
determines the location of the heap prior to DRAM availability.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PI_AGESA_TEMP_RAM_BASE</td><td>soc/amd/common/block/pi</td><td>hex</td><td></td><td>
During a boot from S5, AGESA copies its CAR-based heap to a temporary<br />
location in DRAM.  Once coreboot has established cbmem, the heap<br />
is moved again.  This symbol determines the temporary location for<br />
the heap.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PI_AGESA_HEAP_SIZE</td><td>soc/amd/common/block/pi</td><td>hex</td><td></td><td>
This option determines the amount of space allowed for AGESA heap<br />
prior to DRAM availability.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_PCI</td><td>soc/amd/common/block/pci</td><td>bool</td><td></td><td>
This option builds functions used to program PCI interrupt<br />
routing, both PIC and APIC modes.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_PCI_MMCONF</td><td>soc/amd/common/block/pci</td><td>bool</td><td></td><td>
Selecting this option adds the AMD-common enable_pci_mmconf function<br />
to the build.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_CAR</td><td>soc/amd/common/block/cpu</td><td>bool</td><td></td><td>
This option allows the SOC to use a standard AMD cache-as-ram (CAR)<br />
implementation.  CAR setup is built into bootblock and teardown is<br />
in postcar.  The teardown procedure does not preserve the stack so<br />
it may not be appropriate for a romstage implementation without<br />
additional consideration.  If this option is not used, the SOC must<br />
implement these functions separately.<br />
This is only used for AMD CPU before family 17h. From family 17h on<br />
the RAM is already initialized by the PSP before the x86 cores are<br />
released from reset.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_NONCAR</td><td>soc/amd/common/block/cpu</td><td>bool</td><td></td><td>
From family 17h on AMD CPUs/APUs don't use cache as RAM (CAR) any<br />
more, since the RAM initialization is already done by the PSP when<br />
the x86 cores are released from reset.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H</td><td>soc/amd/common/block/cpu</td><td>bool</td><td></td><td>
Select this option to add the common functions for getting the TSC<br />
frequency of AMD family 17h and 19h CPUs/APUs and to provide TSC-<br />
based monotonic timer functionality to the build.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_HDA</td><td>soc/amd/common/block/hda</td><td>bool</td><td></td><td>
Select this option to use AMD common High Definition Audio<br />
driver support.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_LPC</td><td>soc/amd/common/block/lpc</td><td>bool</td><td></td><td>
Select this option to use the traditional LPC-ISA bridge at D14F3.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PROVIDES_ROM_SHARING</td><td>soc/amd/common/block/lpc</td><td>bool</td><td></td><td>
Select this option if the LPC bridge supports ROM sharing.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_HAS_ESPI</td><td>soc/amd/common/block/lpc</td><td>bool</td><td></td><td>
Select this option if platform supports eSPI using D14F3 configuration<br />
registers.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_USE_ESPI</td><td>soc/amd/common/block/lpc</td><td>bool</td><td></td><td>
Select this option if mainboard uses eSPI instead of LPC (if supported<br />
by platform).<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_UART</td><td>soc/amd/common/block/uart</td><td>bool</td><td></td><td>
Select this option to add the common functions for setting up the<br />
UART configuration to the build.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_SMBUS</td><td>soc/amd/common/block/smbus</td><td>bool</td><td></td><td>
Select this option to add FCH SMBus controller functions to the build.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_SMU</td><td>soc/amd/common/block/smu</td><td>bool</td><td></td><td>
Select this option to add functions to communicate with the SMU to the build.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_AOAC</td><td>soc/amd/common/block/aoac</td><td>bool</td><td></td><td>
Select this option to add the common functions for the AOAC block to<br />
the build.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_AMD_COMMON_BLOCK_IOMMU</td><td>soc/amd/common/block/iommu</td><td>bool</td><td></td><td>
Select this option to use AMD common IOMMU support.<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_ELKHARTLAKE</td><td>soc/intel/elkhartlake</td><td>bool</td><td></td><td>
Intel Elkhartlake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/elkhartlake</td><td>int</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/elkhartlake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages. In the case of FSP_USES_CB_STACK default value will be<br />
sum of FSP-M stack requirement (192KiB) and CB romstage stack requirement (~1KiB).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/intel/elkhartlake</td><td>hex</td><td></td><td>
The amount of anticipated heap usage in CAR by FSP.<br />
Refer to Platform FSP integration guide document to know<br />
the exact FSP requirement for Heap setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/elkhartlake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_ELKHARTLAKE_DEBUG_CONSENT</td><td>soc/intel/elkhartlake</td><td>int</td><td>Debug Consent for EHL</td><td>
This is to control debug interface on SOC.<br />
Setting non-zero value will allow to use DBC or DCI to debug SOC.<br />
PlatformDebugConsent in FspmUpd.h has the details.<br />
<br />
Desired platform debug type are<br />
0:Disabled, 1:Enabled (DCI OOB+[DbC]), 2:Enabled (DCI OOB),<br />
3:Enabled (USB3 DbC), 4:Enabled (XDP/MIPI60), 5:Enabled (USB2 DbC),<br />
6:Enable (2-wire DCI OOB), 7:Manual<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_ICELAKE</td><td>soc/intel/icelake</td><td>bool</td><td></td><td>
Intel Icelake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/icelake</td><td>bool</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/icelake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages. In the case of FSP_USES_CB_STACK default value will be<br />
sum of FSP-M stack requirement (128KiB) and CB romstage stack requirement (~1KiB).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/intel/icelake</td><td>hex</td><td></td><td>
The amount of anticipated heap usage in CAR by FSP.<br />
Refer to Platform FSP integration guide document to know<br />
the exact FSP requirement for Heap setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/icelake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_ICELAKE_DEBUG_CONSENT</td><td>soc/intel/icelake</td><td>int</td><td>Debug Consent for ICL</td><td>
This is to control debug interface on SOC.<br />
Setting non-zero value will allow to use DBC or DCI to debug SOC.<br />
PlatformDebugConsent in FspmUpd.h has the details.<br />
<br />
Desired platform debug types are<br />
0:Disabled, 1:Enabled (DCI OOB+[DbC]), 2:Enabled (DCI OOB),<br />
3:Enabled (USB3 DbC), 4:Enabled (XDP/MIPI60), 5:Enabled (USB2 DbC),<br />
6:Enable (2-wire DCI OOB), 7:Manual<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/xeon_sp/skx</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/xeon_sp/cpx</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/xeon_sp/cpx</td><td>hex</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. FSP-T reserves the upper 0x100 for<br />
FspReservedBuffer.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/xeon_sp/cpx</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages. It needs to include FSP-M stack requirement and<br />
CB romstage stack requirement. The integration documentation<br />
says this needs to be 256KiB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_RC_HEAP_SIZE</td><td>soc/intel/xeon_sp/cpx</td><td>hex</td><td></td><td>
On xeon_sp/cpx FSP-M has two separate heap managers, one regular<br />
whose size and base are controllable via the StackBase and<br />
StackSize UPDs and a 'rc' heap manager that is statically<br />
allocated at 0xfe800000 (the CAR base) and consumes about 0x130000<br />
bytes of memory.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/intel/xeon_sp/cpx</td><td>hex</td><td></td><td>
The amount of anticipated heap usage in CAR by FSP.<br />
Refer to Platform FSP integration guide document to know<br />
the exact FSP requirement for Heap setup.  The FSP integration<br />
documentation says this needs to be at least 128KiB, but practice<br />
show this needs to be 256KiB or more.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_SINIT_SIZE</td><td>soc/intel/xeon_sp/cpx</td><td>hex</td><td></td><td>
According to document number 572782 this needs to be 256KiB<br />
for the SINIT module and 64KiB for SINIT data.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_HEAP_SIZE</td><td>soc/intel/xeon_sp/cpx</td><td>hex</td><td></td><td>
This must be 960KiB according to 572782.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_SKYLAKE_SP</td><td>soc/intel/xeon_sp</td><td>bool</td><td></td><td>
Intel Skylake-SP support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COOPERLAKE_SP</td><td>soc/intel/xeon_sp</td><td>bool</td><td></td><td>
Intel Cooperlake-SP support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/xeon_sp</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_BROADWELL</td><td>soc/intel/broadwell</td><td>bool</td><td></td><td>
Intel Broadwell and Haswell ULT support.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BROADWELL_VBOOT_IN_BOOTBLOCK</td><td>soc/intel/broadwell</td><td>bool</td><td>Start verstage in bootblock</td><td>
Broadwell can either start verstage in a separate stage<br />
right after the bootblock has run or it can start it<br />
after romstage for compatibility reasons.<br />
Broadwell however uses a mrc.bin to initialse memory which<br />
needs to be located at a fixed offset. Therefore even with<br />
a separate verstage starting after the bootblock that same<br />
binary is used meaning a jump is made from RW to the RO region<br />
and back to the RW region after the binary is done.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/broadwell</td><td>hex</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE<br />
must add up to a power of 2.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_MRC_VAR_SIZE</td><td>soc/intel/broadwell</td><td>hex</td><td></td><td>
The amount of cache-as-ram region required by the reference code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/broadwell</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_MRC</td><td>soc/intel/broadwell</td><td>bool</td><td>Add a Memory Reference Code binary</td><td>
Select this option to add a Memory Reference Code binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary coreboot will not work<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_FILE</td><td>soc/intel/broadwell</td><td>string</td><td>Intel Memory Reference Code path and filename</td><td>
The filename of the file to use as Memory Reference Code binary.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PRE_GRAPHICS_DELAY</td><td>soc/intel/broadwell</td><td>int</td><td>Graphics initialization delay in ms</td><td>
On some systems, coreboot boots so fast that connected monitors<br />
(mostly TVs) won't be able to wake up fast enough to talk to the<br />
VBIOS. On those systems we need to wait for a bit before executing<br />
the VBIOS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIRQ_CONTINUOUS_MODE</td><td>soc/intel/broadwell</td><td>bool</td><td></td><td>
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_REFCODE_BLOB</td><td>soc/intel/broadwell</td><td>bool</td><td>An external reference code blob should be put into cbfs.</td><td>
The reference code blob will be placed into cbfs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>REFCODE_BLOB_FILE</td><td>soc/intel/broadwell</td><td>string</td><td>Path and filename to reference code blob.</td><td>
The path and filename to the file to be added to cbfs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_ALDERLAKE</td><td>soc/intel/alderlake</td><td>bool</td><td></td><td>
Intel Alderlake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_ALDERLAKE_PCH_M</td><td>soc/intel/alderlake</td><td>bool</td><td></td><td>
Choose this option if you have PCH-M chipset.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/alderlake</td><td>int</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/alderlake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages. In the case of FSP_USES_CB_STACK default value will be<br />
sum of FSP-M stack requirement(512KiB) and CB romstage stack requirement<br />
(~1KiB).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/intel/alderlake</td><td>hex</td><td></td><td>
The amount of anticipated heap usage in CAR by FSP.<br />
Refer to Platform FSP integration guide document to know<br />
the exact FSP requirement for Heap setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/alderlake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_ALDERLAKE_DEBUG_CONSENT</td><td>soc/intel/alderlake</td><td>int</td><td>Debug Consent for ADL</td><td>
This is to control debug interface on SOC.<br />
Setting non-zero value will allow to use DBC or DCI to debug SOC.<br />
PlatformDebugConsent in FspmUpd.h has the details.<br />
<br />
Desired platform debug type are<br />
0:Disabled, 1:Enabled (DCI OOB+[DbC]), 2:Enabled (DCI OOB),<br />
3:Enabled (USB3 DbC), 4:Enabled (XDP/MIPI60), 5:Enabled (USB2 DbC),<br />
6:Enable (2-wire DCI OOB), 7:Manual<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_BAYTRAIL</td><td>soc/intel/baytrail</td><td>bool</td><td></td><td>
Bay Trail M/D part support.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_MRC</td><td>soc/intel/baytrail</td><td>bool</td><td>Add a System Agent binary</td><td>
Select this option to add a System Agent binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary coreboot will not work<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_FILE</td><td>soc/intel/baytrail</td><td>string</td><td>Intel System Agent path and filename</td><td>
The path and filename of the file to use as System Agent<br />
binary.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/baytrail</td><td>hex</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE<br />
must add up to a power of 2.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_MRC_VAR_SIZE</td><td>soc/intel/baytrail</td><td>hex</td><td></td><td>
The amount of cache-as-ram region required by the reference code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_BUILTIN_COM1</td><td>soc/intel/baytrail</td><td>bool</td><td>Enable builtin COM1 Serial Port</td><td>
The PMC has a legacy COM1 serial port. Choose this option to<br />
configure the pads and enable it. This serial port can be used for<br />
the debug console.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_REFCODE_BLOB</td><td>soc/intel/baytrail</td><td>bool</td><td>Use a binary refcode blob instead of native ModPHY init</td><td>
Use the ChromeBook refcode to intitialize high-speed PHYs instead of<br />
native code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>REFCODE_BLOB_FILE</td><td>soc/intel/baytrail</td><td>string</td><td>Path and filename to reference code blob.</td><td>
The path and filename to the file to be added to cbfs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_SKYLAKE</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Intel Skylake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_KABYLAKE</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Intel Kabylake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/skylake</td><td>hex</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/skylake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EXCLUDE_NATIVE_SD_INTERFACE</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
If you set this option to n, will not use native SD controller.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/skylake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SKYLAKE_SOC_PCH_H</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Choose this option if you have a PCH-H chipset.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_1CH</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 1 channel DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_2CH</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 2 channel DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_4CH</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 4 channel DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_NAU88L25</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for nau88l25 headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_MAX98357</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for max98357 amplifier.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_MAX98373</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for max98373 amplifier.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_SSM4567</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for ssm4567 smart amplifier.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_RT5514</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for rt5514 DSP.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_RT5663</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for rt5663 headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_MAX98927</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for max98927 amplifier.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DA7219</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Include DSP firmware settings for DA7219 headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_FADT_8042</td><td>soc/intel/skylake</td><td>bool</td><td></td><td>
Choose this option if you want to disable 8042 Keyboard<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_DENVERTON_NS</td><td>soc/intel/denverton_ns</td><td>bool</td><td></td><td>
Intel Denverton-NS SoC support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_T_ADDR</td><td>soc/intel/denverton_ns</td><td>hex</td><td>Intel FSP-T (temp RAM init) binary location</td><td>
The memory location of the Intel FSP-T binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_ADDR</td><td>soc/intel/denverton_ns</td><td>hex</td><td>Intel FSP-M (memory init) binary location</td><td>
The memory location of the Intel FSP-M binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_S_ADDR</td><td>soc/intel/denverton_ns</td><td>hex</td><td>Intel FSP-S (silicon init) binary location</td><td>
The memory location of the Intel FSP-S binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/denverton_ns</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NON_LEGACY_UART_MODE</td><td>soc/intel/denverton_ns</td><td>bool</td><td>Non Legacy Mode</td><td>
Disable legacy UART mode<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LEGACY_UART_MODE</td><td>soc/intel/denverton_ns</td><td>bool</td><td>Legacy Mode</td><td>
Enable legacy UART mode<br />
select CONSOLE_SERIAL<br />
select DRIVERS_UART<br />
select DRIVERS_UART_8250IO<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>C_ENV_BOOTBLOCK_SIZE</td><td>soc/intel/denverton_ns</td><td>hex</td><td>Cache-as-ram implementation</td><td>
This option allows you to select how cache-as-ram (CAR) is set up.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_DENVERTON_NS_CAR_NEM_ENHANCED</td><td>soc/intel/denverton_ns</td><td>bool</td><td>Enhanced Non-evict mode</td><td>
A current limitation of NEM (Non-Evict mode) is that code and data sizes<br />
are derived from the requirement to not write out any modified cache line.<br />
With NEM, if there is no physical memory behind the cached area,<br />
the modified data will be lost and NEM results will be inconsistent.<br />
ENHANCED NEM guarantees that modified data is always<br />
kept in cache while clean data is replaced.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_DENVERTON_NS_FSP_CAR</td><td>soc/intel/denverton_ns</td><td>bool</td><td>Use FSP CAR</td><td>
Use FSP APIs to initialize and tear down the Cache-As-Ram.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_BRASWELL</td><td>soc/intel/braswell</td><td>bool</td><td></td><td>
Braswell M/D part support.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/braswell</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/braswell</td><td>hex</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE<br />
must add up to a power of 2.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_BUILTIN_COM1</td><td>soc/intel/braswell</td><td>bool</td><td>Enable builtin COM1 Serial Port</td><td>
The PMC has a legacy COM1 serial port. Choose this option to<br />
configure the pads and enable it. This serial port can be used for<br />
the debug console.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISABLE_HPET</td><td>soc/intel/braswell</td><td>bool</td><td>Disable the HPET device</td><td>
Enable this to disable the HPET support<br />
Solves the Linux MP-BIOS bug timer not connected.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_GOOGLE_FSP</td><td>soc/intel/braswell</td><td>bool</td><td></td><td>
Select this to use Google's custom Braswell FSP header/binary<br />
instead of the public release on Github. Only google/cyan<br />
variants require this; all other boards should use the public release.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_HEADER_PATH</td><td>soc/intel/braswell</td><td>string</td><td></td><td>
Location of FSP header file FspUpdVpd.h<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_APOLLOLAKE</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Intel Apollolake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_GEMINILAKE</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Intel GLK support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_ON_FAST_SPI</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
TPM part is conntected on Fast SPI interface, but the LPC MMIO<br />
TPM transactions are decoded and serialized over the SPI interface.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/apollolake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/apollolake</td><td>hex</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/apollolake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ROMSTAGE_ADDR</td><td>soc/intel/apollolake</td><td>hex</td><td></td><td>
The base address (in CAR) where romstage should be linked<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VERSTAGE_ADDR</td><td>soc/intel/apollolake</td><td>hex</td><td></td><td>
The base address (in CAR) where verstage should be linked<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_ADDR</td><td>soc/intel/apollolake</td><td>hex</td><td></td><td>
The address FSP-M will be relocated to during build time<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NEED_LBP2</td><td>soc/intel/apollolake</td><td>bool</td><td>Write contents for logical boot partition 2.</td><td>
Write the contents from a file into the logical boot partition 2<br />
region defined by LBP2_FMAP_NAME.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LBP2_FMAP_NAME</td><td>soc/intel/apollolake</td><td>string</td><td>Name of FMAP region to put logical boot partition 2</td><td>
Name of FMAP region to write logical boot partition 2 data.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LBP2_FROM_IFWI</td><td>soc/intel/apollolake</td><td>bool</td><td>Extract the LBP2 from the IFWI binary</td><td>
The Logical Boot Partition will be automatically extracted<br />
from the supplied IFWI binary<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LBP2_FILE_NAME</td><td>soc/intel/apollolake</td><td>string</td><td>Path of file to write to logical boot partition 2 region</td><td>
Name of file to store in the logical boot partition 2 region.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NEED_IFWI</td><td>soc/intel/apollolake</td><td>bool</td><td>Write content into IFWI region</td><td>
Write the content from a file into IFWI region defined by<br />
IFWI_FMAP_NAME.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IFWI_FMAP_NAME</td><td>soc/intel/apollolake</td><td>string</td><td>Name of FMAP region to pull IFWI into</td><td>
Name of FMAP region to write IFWI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IFWI_FILE_NAME</td><td>soc/intel/apollolake</td><td>string</td><td>Path of file to write to IFWI region</td><td>
Name of file to store in the IFWI region.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_1CH_16B</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 1 channel 16B DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_2CH_16B</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 2 channel 16B DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_4CH_16B</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 4 channel 16B DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_MAX98357</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Include DSP firmware settings for headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DA7219</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Include DSP firmware settings for headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_RT5682</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Include DSP firmware settings for headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_RT5682</td><td>soc/intel/apollolake</td><td>bool</td><td>Cache-as-ram implementation</td><td>
This option allows you to select how cache-as-ram (CAR) is set up.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAR_NEM</td><td>soc/intel/apollolake</td><td>bool</td><td>Non-evict mode</td><td>
Traditionally, CAR is set up by using Non-Evict mode. This method<br />
does not allow CAR and cache to co-exist, because cache fills are<br />
block in NEM mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAR_CQOS</td><td>soc/intel/apollolake</td><td>bool</td><td>Cache Quality of Service</td><td>
Cache Quality of Service allows more fine-grained control of cache<br />
usage. As result, it is possible to set up portion of L2 cache for<br />
CAR and use remainder for actual caching.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_APOLLOLAKE_FSP_CAR</td><td>soc/intel/apollolake</td><td>bool</td><td>Use FSP CAR</td><td>
Use FSP APIs to initialize &amp; tear down the Cache-As-Ram.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>APL_SKIP_SET_POWER_LIMITS</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Some Apollo Lake mainboards do not need the Running Average Power<br />
Limits (RAPL) algorithm for a constant power management.<br />
Set this config option to skip the RAPL configuration.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>APL_SET_MIN_CLOCK_RATIO</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
If the power budget of the mainboard is limited, it can be useful to<br />
limit the CPU power dissipation at the cost of performance by setting<br />
the lowest possible CPU clock. Enable this option if you need smallest<br />
possible CPU clock. This setting can be overruled by the OS if it has an<br />
p-state driver which can adjust the clock to its need.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_ESPI</td><td>soc/intel/apollolake</td><td>bool</td><td></td><td>
Use eSPI bus instead of LPC<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_JASPERLAKE</td><td>soc/intel/jasperlake</td><td>bool</td><td></td><td>
Intel Jasperlake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/jasperlake</td><td>bool</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/jasperlake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages. In the case of FSP_USES_CB_STACK default value<br />
will be sum of FSP-M stack requirement(192 KiB) and CB romstage<br />
stack requirement(~1KiB).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/intel/jasperlake</td><td>hex</td><td></td><td>
The amount of anticipated heap usage in CAR by FSP.<br />
Refer to Platform FSP integration guide document to know<br />
the exact FSP requirement for Heap setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/jasperlake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_JASPERLAKE_DEBUG_CONSENT</td><td>soc/intel/jasperlake</td><td>int</td><td>Debug Consent for JSL</td><td>
This is to control debug interface on SOC.<br />
Setting non-zero value will allow to use DBC or DCI to debug SOC.<br />
PlatformDebugConsent in FspmUpd.h has the details.<br />
<br />
Desired platform debug type are<br />
0:Disabled, 1:Enabled (DCI OOB+[DbC]), 2:Enabled (DCI OOB),<br />
3:Enabled (USB3 DbC), 4:Enabled (XDP/MIPI60), 5:Enabled (USB2 DbC),<br />
6:Enable (2-wire DCI OOB), 7:Manual<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_QUARK</td><td>soc/intel/quark</td><td>bool</td><td></td><td>
Intel Quark support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_BUILTIN_HSUART0</td><td>soc/intel/quark</td><td>bool</td><td>Enable built-in HSUART0</td><td>
The Quark SoC has two HSUART. Choose this option to configure the pads<br />
and enable HSUART0, which can be used for the debug console.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_BUILTIN_HSUART1</td><td>soc/intel/quark</td><td>bool</td><td>Enable built-in HSUART1</td><td>
The Quark SoC has two HSUART. Choose this option to configure the pads<br />
and enable HSUART1, which can be used for the debug console.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TTYS0_BASE</td><td>soc/intel/quark</td><td>hex</td><td>HSUART Base Address</td><td>
Memory mapped MMIO of HSUART.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_DEBUG_LED</td><td>soc/intel/quark</td><td>bool</td><td></td><td>
Enable the use of the SD LED for early debugging before serial output<br />
is available.  Setting this LED indicates that control has reached the<br />
desired check point.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_DEBUG_LED_ESRAM</td><td>soc/intel/quark</td><td>bool</td><td>SD LED indicates ESRAM initialized</td><td>
Indicate that ESRAM has been successfully initialized.  If the SD LED<br />
does not light then the ESRAM initialization needs to be debugged.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_DEBUG_LED_BOOTBLOCK_ENTRY</td><td>soc/intel/quark</td><td>bool</td><td>SD LED indicates bootblock.c successfully entered</td><td>
Indicate that bootblock_c_entry was entered.  If the SD LED does not<br />
light then debug the code between ESRAM and bootblock_c_entry.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_DEBUG_LED_SOC_EARLY_INIT_ENTRY</td><td>soc/intel/quark</td><td>bool</td><td>SD LED indicates bootblock_soc_early_init successfully entered</td><td>
Indicate that bootblock_soc_early_init was entered.  If the SD LED<br />
does not light then debug the code in bootblock_main_with_timestamp.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_DEBUG_LED_SOC_EARLY_INIT_EXIT</td><td>soc/intel/quark</td><td>bool</td><td>SD LED indicates bootblock_soc_early_init successfully exited</td><td>
Indicate that bootblock_soc_early_init exited.  If the SD LED does not<br />
light then debug the scripts in bootblock_soc_early_init.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_DEBUG_LED_SOC_INIT_ENTRY</td><td>soc/intel/quark</td><td>bool</td><td>SD LED indicates bootblock_soc_init successfully entered</td><td>
Indicate that bootblock_soc_init was entered.  If the SD LED does not<br />
light then debug the code in bootblock_mainboard_early_init and<br />
console_init.  If the SD LED does light but there is no serial then<br />
debug the serial port configuration and initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_ESRAM_LAYOUT</td><td>soc/intel/quark</td><td>bool</td><td>Display ESRAM layout</td><td>
Select this option to display coreboot's use of ESRAM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_SIZE</td><td>soc/intel/quark</td><td>hex</td><td></td><td>
Specify the size of the coreboot file system in the read-only (recovery)<br />
portion of the flash part.  On Quark systems the firmware image stores<br />
more than just coreboot, including:<br />
- The chipset microcode (RMU) binary file located at 0xFFF00000<br />
- Intel Trusted Execution Engine firmware<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_ESRAM_LOC</td><td>soc/intel/quark</td><td>hex</td><td></td><td>
The location in ESRAM where a copy of the FSP binary is placed.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ADD_RMU_FILE</td><td>soc/intel/quark</td><td>bool</td><td>Should the RMU binary be added to the flash image?</td><td>
The RMU file is required to get the chip out of reset.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RMU_FILE</td><td>soc/intel/quark</td><td>string</td><td></td><td>
The path and filename of the Intel Quark RMU binary.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RMU_LOC</td><td>soc/intel/quark</td><td>hex</td><td></td><td>
The location in CBFS that the RMU is located. It must match the<br />
strap-determined base address.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STORAGE_TEST</td><td>soc/intel/quark</td><td>bool</td><td>Test SD/MMC/eMMC card or device access</td><td>
Read block 0 from each parition of the storage device.  User<br />
must also enable one or both of COMMONLIB_STORAGE_SD or<br />
COMMONLIB_STORAGE_MMC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>I2C_DEBUG</td><td>soc/intel/quark</td><td>bool</td><td>Enable I2C debugging</td><td>
Display the I2C segments and controller errors<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COFFEELAKE</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Intel Coffeelake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_WHISKEYLAKE</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Intel Whiskeylake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMETLAKE</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Intel Cometlake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CANNONLAKE_PCH_H</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Choose this option if you have a PCH-H chipset.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/cannonlake</td><td>int</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/cannonlake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages. In the case of FSP_USES_CB_STACK default value will be<br />
sum of FSP-M stack requirement (128KiB) and CB romstage stack requirement (~1KiB).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/intel/cannonlake</td><td>hex</td><td></td><td>
The amount of anticipated heap usage in CAR by FSP.<br />
Refer to Platform FSP integration guide document to know<br />
the exact FSP requirement for Heap setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_1CH_16B</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 1 channel 16B DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_2CH_16B</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 2 channel 16B DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DMIC_4CH_16B</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Include DSP firmware settings for 4 channel 16B DMIC array.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_MAX98357</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Include DSP firmware settings for headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_MAX98373</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Include DSP firmware settings for headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NHLT_DA7219</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Include DSP firmware settings for headset codec.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/cannonlake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MB_HAS_ACTIVE_HIGH_SD_PWR_ENABLE</td><td>soc/intel/cannonlake</td><td>bool</td><td></td><td>
Select this if the board has a SD_PWR_ENABLE pin connected to a<br />
active high sensing load switch to turn on power to the card reader.<br />
This will enable a workaround in ASL _PS3 and _PS0 methods to force<br />
SD_PWR_ENABLE to stay low in D3.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MB_HAS_ACTIVE_HIGH_SD_PWR_ENABLE</td><td>soc/intel/cannonlake</td><td>bool</td><td>Cache-as-ram implementation</td><td>
This option allows you to select how cache-as-ram (CAR) is set up.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_CANNONLAKE_CAR_NEM_ENHANCED</td><td>soc/intel/cannonlake</td><td>bool</td><td>Enhanced Non-evict mode</td><td>
A current limitation of NEM (Non-Evict mode) is that code and data<br />
sizes are derived from the requirement to not write out any modified<br />
cache line. With NEM, if there is no physical memory behind the<br />
cached area, the modified data will be lost and NEM results will be<br />
inconsistent. ENHANCED NEM guarantees that modified data is always<br />
kept in cache while clean data is replaced.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_CANNONLAKE_FSP_CAR</td><td>soc/intel/cannonlake</td><td>bool</td><td>Use FSP CAR</td><td>
Use FSP APIs to initialize and tear down the Cache-As-Ram.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CANNONLAKE_DEBUG_CONSENT</td><td>soc/intel/cannonlake</td><td>int</td><td>Debug Consent for CNL</td><td>
This is to control debug interface on SOC.<br />
Setting non-zero value will allow to use DBC or DCI to debug SOC.<br />
PlatformDebugConsent in FspmUpd.h has the details.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_TIGERLAKE</td><td>soc/intel/tigerlake</td><td>bool</td><td></td><td>
Intel Tigerlake support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>soc/intel/tigerlake</td><td>bool</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>soc/intel/tigerlake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages. In the case of FSP_USES_CB_STACK default value will be<br />
sum of FSP-M stack requirement(256KiB) and CB romstage stack requirement<br />
(~1KiB).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>soc/intel/tigerlake</td><td>hex</td><td></td><td>
The amount of anticipated heap usage in CAR by FSP.<br />
Refer to Platform FSP integration guide document to know<br />
the exact FSP requirement for Heap setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_BASE_ADDRESS</td><td>soc/intel/tigerlake</td><td>hex</td><td></td><td>
This option allows you to select MMIO Base Address of sideband bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_TIGERLAKE_DEBUG_CONSENT</td><td>soc/intel/tigerlake</td><td>int</td><td>Debug Consent for TGL</td><td>
This is to control debug interface on SOC.<br />
Setting non-zero value will allow to use DBC or DCI to debug SOC.<br />
PlatformDebugConsent in FspmUpd.h has the details.<br />
<br />
Desired platform debug type are<br />
0:Disabled, 1:Enabled (DCI OOB+[DbC]), 2:Enabled (DCI OOB),<br />
3:Enabled (USB3 DbC), 4:Enabled (XDP/MIPI60), 5:Enabled (USB2 DbC),<br />
6:Enable (2-wire DCI OOB), 7:Manual<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EARLY_TCSS_DISPLAY</td><td>soc/intel/tigerlake</td><td>bool</td><td>Enable early TCSS display</td><td>
Enable displays to be detected over Type-C ports during boot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON</td><td>soc/intel/common.common</td><td>bool</td><td></td><td>
common code for Intel SOCs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/intel/common.common</td><td>(comment)</td><td></td><td>Intel SoC Common Code for IP blocks</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK</td><td>soc/intel/common/block</td><td>bool</td><td></td><td>
SoC driver for intel common IP code<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SMM</td><td>soc/intel/common/block/smm</td><td>bool</td><td></td><td>
Intel Processor common SMM support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SMM_IO_TRAP</td><td>soc/intel/common/block/smm</td><td>bool</td><td></td><td>
Intel Processor trap flag if it is supported<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SMM_ESPI_DISABLE</td><td>soc/intel/common/block/smm</td><td>bool</td><td></td><td>
Disable eSPI SMI source to prevent the embedded controller<br />
from asserting SMI while in firmware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SMM_TCO_ENABLE</td><td>soc/intel/common/block/smm</td><td>bool</td><td>Enable TCO SMI</td><td>
Enable TCO SMI source to e.g. handle case instrusion.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SMM_S5_DELAY_MS</td><td>soc/intel/common/block/smm</td><td>int</td><td></td><td>
Time in milliseconds that SLP_SMI for S5 waits for before<br />
enabling sleep. This is required to avoid any race between<br />
SLP_SMI and PWRBTN SMI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HECI_DISABLE_USING_SMM</td><td>soc/intel/common/block/smm</td><td>bool</td><td></td><td>
HECI disable using SMM. Select this option to make HECI disable<br />
using SMM mode, independent of dedicated UPD to perform HECI disable.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_DSP</td><td>soc/intel/common/block/dsp</td><td>bool</td><td></td><td>
Intel Processor common DSP support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_CSE</td><td>soc/intel/common/block/cse</td><td>bool</td><td></td><td>
Driver for communication with Converged Security Engine (CSE)<br />
over Host Embedded Controller Interface (HECI)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_HECI_DISABLE_IN_SMM</td><td>soc/intel/common/block/cse</td><td>bool</td><td></td><td>
Use this config to include common CSE block to make HECI function<br />
disable in SMM mode<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_LITE_SKU</td><td>soc/intel/common/block/cse</td><td>bool</td><td></td><td>
Enables CSE Lite SKU<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_RW_UPDATE</td><td>soc/intel/common/block/cse</td><td>bool</td><td>Enable the CSE RW Update Feature</td><td>
This config will enable CSE RW firmware update feature and also will be used ensure<br />
all the required configs are provided by mainboard.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_FMAP_NAME</td><td>soc/intel/common/block/cse</td><td>string</td><td>Name of CSE Region in FMAP</td><td>
Name of CSE region in FMAP<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_RW_A_FMAP_NAME</td><td>soc/intel/common/block/cse</td><td>string</td><td>Location of CSE RW A in FMAP</td><td>
Name of CSE RW A region in FMAP<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_RW_B_FMAP_NAME</td><td>soc/intel/common/block/cse</td><td>string</td><td>Location of CSE RW B in FMAP</td><td>
Name of CSE RW B region in FMAP<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_RW_CBFS_NAME</td><td>soc/intel/common/block/cse</td><td>string</td><td>CBFS entry name for CSE RW blob</td><td>
CBFS entry name for Intel CSE CBFS RW blob<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_RW_METADATA_CBFS_NAME</td><td>soc/intel/common/block/cse</td><td>string</td><td>CBFS name for CSE RW metadata file</td><td>
CBFS name for Intel CSE CBFS RW metadata file<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_RW_FILE</td><td>soc/intel/common/block/cse</td><td>string</td><td>Intel CSE CBFS RW path and filename</td><td>
Intel CSE CBFS RW blob path and file name<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CSE_RW_VERSION</td><td>soc/intel/common/block/cse</td><td>string</td><td>Intel CSE RW firmware version</td><td>
This config contains the Intel CSE RW version of the blob that is provided by<br />
SOC_INTEL_CSE_RW_FILE config and the version must be set in the format<br />
major.minor.hotfix.build (ex: 14.0.40.1209).<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_THERMAL</td><td>soc/intel/common/block/thermal</td><td>bool</td><td></td><td>
This option allows to configure PCH thermal registers for supported PCH.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_CNVI</td><td>soc/intel/common/block/cnvi</td><td>bool</td><td></td><td>
Common CNVI module for Intel PCH<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SPI</td><td>soc/intel/common/block/spi</td><td>bool</td><td></td><td>
Intel Processor common SPI support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SRAM</td><td>soc/intel/common/block/sram</td><td>bool</td><td></td><td>
Intel Processor common SRAM support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_PCIE</td><td>soc/intel/common/block/pcie</td><td>bool</td><td></td><td>
Intel Processor common PCIE support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_PCIE_RTD3</td><td>soc/intel/common/block/pcie/rtd3</td><td>bool</td><td></td><td>
When enabled, this driver will add support for ACPI controlled<br />
Runtime D3 using GPIOs for power/reset control of the device<br />
attached to a PCIe root port.<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIE_DEBUG_INFO</td><td>soc/intel/common/block/pcie</td><td>bool</td><td></td><td>
Enable debug logs in PCIe module. Allows debug information on memory<br />
base and limit, prefetchable memory base and limit, prefetchable memory<br />
base upper 32 bits and prefetchable memory limit upper 32 bits.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_I2C</td><td>soc/intel/common/block/i2c</td><td>bool</td><td></td><td>
Intel Processor Common I2C support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_DTT</td><td>soc/intel/common/block/dtt</td><td>bool</td><td></td><td>
Minimal PCI Driver for enabling SSDT generation of Intel<br />
Dynamic Tuning Technology (DTT) policies and controls, also<br />
known as Intel DPTF (Dynamic Platform and Thermal Framework)<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_P2SB</td><td>soc/intel/common/block/p2sb</td><td>bool</td><td></td><td>
Intel Processor common P2SB driver<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_CHIP_CONFIG</td><td>soc/intel/common/block/chip</td><td>bool</td><td></td><td>
Intel Processor common soc/chip configuration support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SCS</td><td>soc/intel/common/block/scs</td><td>bool</td><td></td><td>
Intel Processor common storage and communication subsystem support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_EARLY_MMC_WAKE</td><td>soc/intel/common/block/scs</td><td>bool</td><td></td><td>
Send CMD1 early in romstage to improve boot time. It requires emmc<br />
DLL tuning parameters to be added to devicetree.cb<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_MMC_OVERRIDE</td><td>soc/intel/common/block/scs</td><td>bool</td><td></td><td>
Override the MMC settings after FSP-S.<br />
It should be used only when there is no FSP UPDs for certain setting.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_DMI</td><td>soc/intel/common/block/dmi</td><td>bool</td><td></td><td>
Intel Processor common DMI support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_GRAPHICS</td><td>soc/intel/common/block/graphics</td><td>bool</td><td></td><td>
Intel Processor common Graphics support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_CONFIGURE_DDI_A_4_LANES</td><td>soc/intel/common/block/graphics</td><td>bool</td><td></td><td>
Selected by platforms that require DDI-A bifurcation setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_DISABLE_IGD</td><td>soc/intel/common/block/graphics</td><td>bool</td><td>Disable Integrated GFX Controller (0:2:0)</td><td>
Selected by mainboard user that need to skip IGD initialization<br />
where OS can only use one GPU hence need to disable IGD and don't<br />
need to run FSP GOP.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_IPU</td><td>soc/intel/common/block/ipu</td><td>bool</td><td></td><td>
Intel Image Processing Unit driver<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_FAST_SPI</td><td>soc/intel/common/block/fast_spi</td><td>bool</td><td></td><td>
Intel Processor common FAST_SPI support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FAST_SPI_DISABLE_WRITE_STATUS</td><td>soc/intel/common/block/fast_spi</td><td>bool</td><td>Disable write status SPI opcode</td><td>
Disable the write status SPI opcode in Intel Fast SPI block.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FAST_SPI_SUPPORTS_EXT_BIOS_WINDOW</td><td>soc/intel/common/block/fast_spi</td><td>bool</td><td></td><td>
Fast SPI controller on the platform supports additional<br />
window for memory mapping BIOS region (region 1) on the SPI<br />
flash beyond the standard limit of 16MiB. Depending upon the<br />
size of the SPI flash part used by the mainboard, two decode<br />
windows will be enabled:<br />
1. Fixed decode window up to a maximum size of 16MiB under<br />
4G boundary.<br />
2. Extended decode window up to a maximum size provided by<br />
the platform to map the rest of the BIOS region.<br />
SoC selecting this config is expected to provide the base and<br />
maximum size of the extended window in the host address space<br />
using configs EXT_BIOS_WIN_BASE and EXT_BIOS_WIN_SIZE.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EXT_BIOS_WIN_BASE</td><td>soc/intel/common/block/fast_spi</td><td>hex</td><td></td><td>
If an additional window for mapping BIOS region greater than<br />
16MiB is supported, then this config is used to provide the<br />
base address reserved for the mapping. Since the mapping is<br />
done at the top of the window, depending upon the size of the<br />
BIOS region, the actual base address configured in the fast<br />
SPI controller can be higher at runtime.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EXT_BIOS_WIN_SIZE</td><td>soc/intel/common/block/fast_spi</td><td>hex</td><td></td><td>
Maximum size of the extended window reserved for mapping BIOS<br />
region greater than 16MiB. The actual mapped window might be<br />
smaller depending upon the size of the BIOS region.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_ITSS</td><td>soc/intel/common/block/itss</td><td>bool</td><td></td><td>
Intel Processor common interrupt timer subsystem support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_GPIO</td><td>soc/intel/common/block/gpio</td><td>bool</td><td></td><td>
Intel Processor common GPIO support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SATA</td><td>soc/intel/common/block/sata</td><td>bool</td><td></td><td>
Common SATA module for Intel PCH<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_XHCI</td><td>soc/intel/common/block/xhci</td><td>bool</td><td></td><td>
Intel Processor common XHCI support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_XHCI_ELOG</td><td>soc/intel/common/block/xhci</td><td>bool</td><td></td><td>
Set this option to identify if XHCI caused a wake up and log that<br />
information into the event log.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_ACPI</td><td>soc/intel/common/block/acpi</td><td>bool</td><td></td><td>
Intel Processor common code for ACPI<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_ACPI_LPIT</td><td>soc/intel/common/block/acpi</td><td>bool</td><td></td><td>
Generate LPIT table with LPI state entries.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_ACPI_CPPC</td><td>soc/intel/common/block/acpi</td><td>bool</td><td></td><td>
Generate CPPC entries for Intel SpeedShift<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_RTC</td><td>soc/intel/common/block/rtc</td><td>bool</td><td></td><td>
Intel Processor common RTC support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_TIMER</td><td>soc/intel/common/block/timer</td><td>bool</td><td></td><td>
Intel Processor common TIMER support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_LEGACY_8254_TIMER</td><td>soc/intel/common/block/timer</td><td>bool</td><td>Use Legacy 8254 Timer</td><td>
Setting this makes the Legacy 8254 Timer available by disabling<br />
clock gating. This needs to be enabled in order to boot a legacy<br />
BIOS or OS not supporting other timers like PM timer or TSC.<br />
<br />
While SeaBIOS does not require this timer anymore, it is needed<br />
when OpRoms are being used.<br />
<br />
Disable this setting to save power, when the timer is not needed.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_XDCI</td><td>soc/intel/common/block/xdci</td><td>bool</td><td></td><td>
Intel Processor common XDCI support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_CPU</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
This option selects Intel Common CPU Model support code<br />
which provides various CPU related APIs which are common<br />
between all Intel Processor families. Common CPU code is supported<br />
for SOCs starting from SKL,KBL,APL, and future.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_CPU_MPINIT</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
This option selects Intel Common CPU MP Init code. In<br />
this common MP Init mechanism, the MP Init is occurring before<br />
calling FSP Silicon Init. Hence, MP Init will be pulled to<br />
BS_DEV_INIT_CHIPS Entry. And on Exit of BS_DEV_INIT, it is<br />
ensured that all MTRRs are re-programmed based on the DRAM<br />
resource settings.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_CAR</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
This option allows you to select how cache-as-ram (CAR) is set up.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_CAR_NEM</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
Traditionally, CAR is set up by using Non-Evict mode. This method<br />
does not allow CAR and cache to co-exist, because cache fills are<br />
blocked in NEM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_CAR_CQOS</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
Cache Quality of Service allows more fine-grained control of cache<br />
usage. As result, it is possible to set up a portion of L2 cache for<br />
CAR and use the remainder for actual caching.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_CAR_NEM_ENHANCED</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
A current limitation of NEM (Non-Evict mode) is that code and data sizes<br />
are derived from the requirement to not write out any modified cache line.<br />
With NEM, if there is no physical memory behind the cached area,<br />
the modified data will be lost and NEM results will be inconsistent.<br />
ENHANCED NEM guarantees that modified data is always<br />
kept in cache while clean data is replaced.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAR_HAS_SF_MASKS</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
In the case of non-inclusive cache architecture Snoop Filter MSR<br />
IA32_L3_SF_MASK_x programming is required along with the data ways.<br />
This is applicable for TGL and beyond.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COS_MAPPED_TO_MSB</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
On TGL and JSL platform the class of service configuration<br />
is mapped to MSB of MSR IA32_PQR_ASSOC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_INTEL_FSP_MP_INIT</td><td>soc/intel/common/block/cpu</td><td>bool</td><td>Perform MP Initialization by FSP</td><td>
This option allows FSP to perform multiprocessor initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI</td><td>soc/intel/common/block/cpu</td><td>bool</td><td>Perform MP Initialization by FSP using coreboot MP PPI service</td><td>
This option allows FSP to make use of MP services PPI published by<br />
coreboot to perform multiprocessor initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TME</td><td>soc/intel/common/block/cpu</td><td>bool</td><td>Total Memory Encryption (TME)/Multi-key TME (MKTME)</td><td>
Enable Total Memory Encryption (TME)/Multi-key TME (MKTME). The spec is<br />
available at "https://software.intel.com/sites/default/files/managed/a5<br />
/16/Multi-Key-Total-Memory-Encryption-Spec.pdf". If CPU supports TME,<br />
it would get enabled. If CPU supports MKTME, this same config option<br />
enables MKTME.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_XTAL_HZ</td><td>soc/intel/common/block/cpu</td><td>int</td><td></td><td>
Base clock which virtually everything runs on.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_SUPPORTS_PM_TIMER_EMULATION</td><td>soc/intel/common/block/cpu</td><td>bool</td><td></td><td>
Select this if the SoC's ucode supports PM ACPI timer emulation (Common<br />
timer Copy), which is required to be able to disable the TCO PM ACPI<br />
timer for power saving.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_POWER_LIMIT</td><td>soc/intel/common/block/power_limit</td><td>bool</td><td></td><td>
This option allows to configure processor power limit values.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_PCR</td><td>soc/intel/common/block/pcr</td><td>bool</td><td></td><td>
Intel Processor common Private configuration registers (PCR)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCR_COMMON_IOSF_1_0</td><td>soc/intel/common/block/pcr</td><td>bool</td><td></td><td>
The mapping of addresses via the SBREG_BAR assumes the IOSF-SB<br />
agents are using 32-bit aligned accesses for their configuration<br />
registers. For IOSF versions greater than 1_0, IOSF-SB<br />
agents can use any access (8/16/32 bit aligned) for their<br />
configuration registers<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_HDA</td><td>soc/intel/common/block/hda</td><td>bool</td><td></td><td>
Intel Processor common High Definition Audio driver support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_HDA_VERB</td><td>soc/intel/common/block/hda</td><td>bool</td><td></td><td>
Enable initialization of HDA codecs.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_GSPI</td><td>soc/intel/common/block/gspi</td><td>bool</td><td></td><td>
Intel Processor Common GSPI support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_GSPI_CLOCK_MHZ</td><td>soc/intel/common/block/gspi</td><td>int</td><td></td><td>
The input clock speed into the SPI controller IP block, in MHz.<br />
No default is set here as this is an SOC-specific value<br />
and must be provided by the SOC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_GSPI_MAX</td><td>soc/intel/common/block/gspi</td><td>int</td><td></td><td>
Maximum number of GSPI controllers supported by the PCH. SoC<br />
must define this config if SOC_INTEL_COMMON_BLOCK_GSPI is<br />
selected.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_GSPI_VERSION_2</td><td>soc/intel/common/block/gspi</td><td>bool</td><td></td><td>
Intel Processor Common GSPI support with quirks to handle<br />
SPI_CS_CONTROL changes introduced in CNL.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_LPC</td><td>soc/intel/common/block/lpc</td><td>bool</td><td></td><td>
Use common LPC code for platform. Only soc specific code needs to<br />
be implemented as per requirement.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_LPC_COMB_ENABLE</td><td>soc/intel/common/block/lpc</td><td>bool</td><td></td><td>
By default COMA range to LPC is enable. COMB range to LPC is optional<br />
and should select based on platform dedicated selection.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_LPC_MIRROR_TO_DMI</td><td>soc/intel/common/block/lpc</td><td>bool</td><td></td><td>
Mirror LPC registers for IO/MMIO to their corresponding DMI registers.<br />
Required for platforms starting from SPT.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_UART</td><td>soc/intel/common/block/uart</td><td>bool</td><td></td><td>
Intel Processor common UART support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_LPSS_UART_FOR_CONSOLE</td><td>soc/intel/common/block/uart</td><td>bool</td><td></td><td>
Selected by mainboards that use one of the SoC's LPSS UARTS<br />
for the coreboot console.<br />
WARNING: UART_FOR_CONSOLE has to be set to a correct value,<br />
otherwise wrong pad configurations might be selected.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_PMC</td><td>soc/intel/common/block/pmc</td><td>bool</td><td></td><td>
Intel Processor common code for Power Management controller(PMC)<br />
subsystem<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_PMC_DISCOVERABLE</td><td>soc/intel/common/block/pmc</td><td>bool</td><td></td><td>
Select this on platforms where the PMC device is discoverable<br />
when scanning busses.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PMC_INVALID_READ_AFTER_WRITE</td><td>soc/intel/common/block/pmc</td><td>bool</td><td></td><td>
Enable this for PMC devices where a read back of ACPI BAR and<br />
IO access bit does not return the previously written value.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PMC_IPC_ACPI_INTERFACE</td><td>soc/intel/common/block/pmc</td><td>bool</td><td></td><td>
Enable this to have the PMC IPC mailbox ACPI interface added<br />
to the SSDT for use by other drivers.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PMC_GLOBAL_RESET_ENABLE_LOCK</td><td>soc/intel/common/block/pmc</td><td>bool</td><td></td><td>
Enable this for PMC devices where the reset configuration<br />
and lock register is located under PMC BASE at offset ETR.<br />
Note that the reset register is still at 0xCF9 this only<br />
controls the enable and lock feature.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PMC_LOW_POWER_MODE_PROGRAM</td><td>soc/intel/common/block/pmc</td><td>bool</td><td></td><td>
Enable this for PMC devices to perform registers programming<br />
to ensure low power in active idle scenario.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PM_ACPI_TIMER_OPTIONAL</td><td>soc/intel/common/block/pmc</td><td>bool</td><td></td><td>
This needs to be selected by SoCs, where the hardware PM Timer<br />
can be disabled, to show the ACPI PM Timer Kconfig in menuconfig.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_PM_ACPI_TIMER</td><td>soc/intel/common/block/pmc</td><td>bool</td><td>Enable ACPI PM timer</td><td>
This should be disabled for devices running on battery since<br />
it can draw much power. Further, it must be disabled, if S0ix<br />
is enabled.<br />
<br />
Disabling this option also stops the hardware TCO timer and makes<br />
the TCO watchdog unavailable.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_LPSS</td><td>soc/intel/common/block/lpss</td><td>bool</td><td></td><td>
Intel Processor common LPSS support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_USB4</td><td>soc/intel/common/block/usb4</td><td>bool</td><td></td><td>
Minimal PCI Driver for enabling SSDT generation for the DMA component<br />
of Intel Thunderbolt/USB4 ports.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_USB4_PCIE</td><td>soc/intel/common/block/usb4</td><td>bool</td><td></td><td>
Chip driver for adding PCI ops and SSDT generation for common Intel<br />
USB4/Thunderbolt root ports.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_USB4_XHCI</td><td>soc/intel/common/block/usb4</td><td>bool</td><td></td><td>
Minimal PCI driver for adding PCI ops and SSDT generation for common<br />
Intel USB4/Thunderbolt North XHCI ports.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SA</td><td>soc/intel/common/block/systemagent</td><td>bool</td><td></td><td>
Intel Processor common System Agent support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SA_PCIEX_LENGTH</td><td>soc/intel/common/block/systemagent</td><td>hex</td><td></td><td>
This option allows you to select length of PCIEX region.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SA_ENABLE_IMR</td><td>soc/intel/common/block/systemagent</td><td>bool</td><td></td><td>
This option allows you to add the isolated memory ranges (IMRs).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SA_ENABLE_DPR</td><td>soc/intel/common/block/systemagent</td><td>bool</td><td></td><td>
This option allows you to add the DMA Protected Range (DPR).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SMBUS</td><td>soc/intel/common/block/smbus</td><td>bool</td><td></td><td>
Intel Processor common SMBus support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_TCO</td><td>soc/intel/common/block/smbus</td><td>bool</td><td></td><td>
Intel Processor common TCO support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_TCO_ENABLE_THROUGH_SMBUS</td><td>soc/intel/common/block/smbus</td><td>bool</td><td></td><td>
Select this config to enable TCO BAR through SMBUS<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_MEMINIT</td><td>soc/intel/common/block/memory</td><td>bool</td><td></td><td>
Intel common block support for performing initialization<br />
of FSPM UPDs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DIMMS_PER_CHANNEL</td><td>soc/intel/common/block/memory</td><td>int</td><td></td><td>
Maximum number of DIMMs per channel if the memory controller<br />
supports DIMM modules for any memory technology.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DATA_BUS_WIDTH</td><td>soc/intel/common/block/memory</td><td>int</td><td></td><td>
Data bus width of the platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_CHANNEL_WIDTH</td><td>soc/intel/common/block/memory</td><td>int</td><td></td><td>
Width of the memory channel from the perspective of MRC. This<br />
determines the UPD organization. SoC using this common block<br />
support is expected to set MRC_CHANNEL_WIDTH as per the FSP<br />
MRC expectation.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SGX</td><td>soc/intel/common/block/sgx</td><td>bool</td><td></td><td>
Intel Processor common SGX support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SGX_LOCK_MEMORY</td><td>soc/intel/common/block/sgx</td><td>bool</td><td></td><td>
Lock memory before SGX activation. This is only needed if MCHECK does not do it.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SGX_ENABLE</td><td>soc/intel/common/block/sgx</td><td>bool</td><td>Enable Software Guard Extensions (SGX) if available</td><td>
Intel Software Guard Extensions (SGX) is a set of new CPU instructions that can be<br />
used by applications to set aside private regions (so-called Secure Enclaves) of<br />
code and data.<br />
<br />
SGX will only be enabled when supported by the CPU!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BLOCK_SGX_PRMRR_SIZE</td><td>soc/intel/common/block/sgx</td><td>int</td><td>PRMRR size</td><td>
PRMRR (Protected Memory Range) is the space in RAM that is used to provide a protected<br />
memory area (e.g. for the Intel SGX Secure Enclaves). The memory region is accessible<br />
only by the processor itself to protect the data from unauthorized access.<br />
<br />
This option selects the maximum size that gets reserved. Depending on the SoC a lower,<br />
compatible value may be chosen at runtime as not all values are supported on all<br />
families.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/intel/common.common</td><td>(comment)</td><td></td><td>Intel SoC Common PCH Code</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_PCH_BASE</td><td>soc/intel/common/pch</td><td>bool</td><td></td><td>
All common PCH code blocks between Gen-6 till latest-PCH should be<br />
part of this directory. A SoC Kconfig might select this option to include<br />
base PCH package while building new SOC block. Currently majority of<br />
common IP code blocks are part of soc/intel/common/block/ and<br />
SoC Kconfig just select those Kconfig option. Addition to that SoC<br />
code now having option to select required base PCH block to include<br />
common IP block.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_PCH_LOCKDOWN</td><td>soc/intel/common/pch/lockdown</td><td>bool</td><td></td><td>
This option allows to have chipset lockdown for DMI, FAST_SPI and<br />
soc_lockdown_config() to implement any additional lockdown as PMC,<br />
LPC for supported PCH.<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>soc/intel/common.common</td><td>(comment)</td><td></td><td>Intel SoC Common coreboot stages and non-IP blocks</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_BASECODE</td><td>soc/intel/common/basecode</td><td>bool</td><td></td><td>
Common coreboot stages and non-IP block for Intel platform<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_CONSOLE</td><td>soc/intel/common.common</td><td>bool</td><td></td><td>
Provide a mechanism for serial console based ACPI debug.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAVP</td><td>soc/intel/common.common</td><td>bool</td><td>Enable PAVP (Protected Audio-Video Path) support</td><td>
Protected Audio-Video Path is an Intel technology used to enforce digital<br />
rights protections on multimedia content. Streaming or other media playback<br />
services may require it to be enabled for correct functioning.<br />
<br />
Users might disable PAVP if the concept of digital rights management (DRM)<br />
offends them, or if they have concerns about the security of<br />
the Management Engine, which is where this technology is implemented.<br />
<br />
Set this option to n to disable support.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MMA</td><td>soc/intel/common.common</td><td>bool</td><td>Enable MMA (Memory Margin Analysis) support for Intel Core</td><td>
Set this option to y to enable MMA (Memory Margin Analysis) support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_TIS_ACPI_INTERRUPT</td><td>soc/intel/common.common</td><td>int</td><td></td><td>
acpi_get_gpe() is used to provide interrupt status to TPM layer.<br />
This option specifies the GPE number.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_DEBUG_CONSENT</td><td>soc/intel/common.common</td><td>bool</td><td>Enable SOC debug interface</td><td>
Set this option to enable default debug interface of SoC such as DBC<br />
or DCI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_HAS_TOP_SWAP</td><td>soc/intel</td><td>bool</td><td></td><td>
Set this config if the Intel SoC supports top swap feature<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_ADD_TOP_SWAP_BOOTBLOCK</td><td>soc/intel</td><td>bool</td><td>Include a Top swap bootblock</td><td>
Intel PCH/Southbridges have feature that it is possible to have<br />
the southbridge/PCH look for the bootblock at a 64K or<br />
128K/256K/512K/1MB (in case of newer SoCs) offset<br />
instead of the usual top of flash.<br />
Select this to put a 'second' bootblock.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TOP_SWAP_BOOTBLOCK_SIZE</td><td>soc/intel</td><td>hex</td><td>Size of top swap boot block</td><td>
Set this config to a supported topswap size.<br />
Valid sizes: 0x10000 0x20000 0x40000 0x80000 0x100000<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TOP_SWAP_FIT_ENTRY_FMAP_REG</td><td>soc/intel</td><td>string</td><td></td><td>
Use this config to specify the name of a FMAP region (which should<br />
hold a microcode) whose address as the first entry in the topswap FIT.<br />
This is useful in creating a asymmetric FIT in top swap bootblock<br />
than the one in non-topswap bootblock. This string will be passed<br />
onto ifittool (-A -n option). ifittool will not parse the region for MCU<br />
entries, and only locate the region and insert its address into FIT.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>RK3399_SPREAD_SPECTRUM_DDR</td><td>soc/rockchip/rk3399</td><td>bool</td><td>Spread-spectrum DDR clock</td><td>
Select Spread Spectrum Modulator (SSMOD) is a fully-digital circuit<br />
used to modulate the frequency of the Silicon Creations' Fractional<br />
PLL in order to reduce EMI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_EXAMPLE_MIN86</td><td>soc/example/min86</td><td>bool</td><td></td><td>
This example SoC code along with the example/min86 mainboard<br />
should serve as a minimal example how a buildable x86 SoC code<br />
base can look like.<br />
<br />
This can serve, for instance, as a basis to add new SoCs to<br />
coreboot. Starting with a buildable commit should help with<br />
the review of the actual code, and also avoid any regressions<br />
when common coreboot code changes.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_DO_DSI_INIT</td><td>soc/nvidia/tegra210</td><td>bool</td><td>Use dsi graphics interface</td><td>
Initialize dsi display<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_DO_SOR_INIT</td><td>soc/nvidia/tegra210</td><td>bool</td><td>Use dp graphics interface</td><td>
Initialize dp display<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_TEGRA210_UARTA</td><td>soc/nvidia/tegra210</td><td>bool</td><td>UARTA</td><td>
Serial console on UART A.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_TEGRA210_UARTB</td><td>soc/nvidia/tegra210</td><td>bool</td><td>UARTB</td><td>
Serial console on UART B.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_TEGRA210_UARTC</td><td>soc/nvidia/tegra210</td><td>bool</td><td>UARTC</td><td>
Serial console on UART C.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_TEGRA210_UARTD</td><td>soc/nvidia/tegra210</td><td>bool</td><td>UARTD</td><td>
Serial console on UART D.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_TEGRA210_UARTE</td><td>soc/nvidia/tegra210</td><td>bool</td><td>UARTE</td><td>
Serial console on UART E.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_TEGRA210_UART_ADDRESS</td><td>soc/nvidia/tegra210</td><td>hex</td><td></td><td>
Map the UART names to the respective MMIO addres.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTROM_SDRAM_INIT</td><td>soc/nvidia/tegra210</td><td>bool</td><td>SoC BootROM does SDRAM init with full BCT</td><td>
Use during Foster LPDDR4 bringup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TRUSTZONE_CARVEOUT_SIZE_MB</td><td>soc/nvidia/tegra210</td><td>hex</td><td>Size of Trust Zone region</td><td>
Size of Trust Zone area in MiB to reserve in memory map.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TTB_SIZE_MB</td><td>soc/nvidia/tegra210</td><td>hex</td><td>Size of TTB</td><td>
Maximum size of Translation Table Buffer in MiB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEC_COMPONENT_SIZE_MB</td><td>soc/nvidia/tegra210</td><td>hex</td><td>Size of resident EL3 components</td><td>
Maximum size of resident EL3 components in MiB including BL31 and<br />
Secure OS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_MTC</td><td>soc/nvidia/tegra210</td><td>bool</td><td>Add external Memory controller Training Code binary</td><td>
Select this option to add emc training firmware<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MTC_FILE</td><td>soc/nvidia/tegra210</td><td>string</td><td>tegra mtc firmware filename</td><td>
The filename of the mtc firmware<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MTC_DIRECTORY</td><td>soc/nvidia/tegra210</td><td>string</td><td>Directory where MTC firmware file is located</td><td>
Path to directory where MTC firmware file is located.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MTC_ADDRESS</td><td>soc/nvidia/tegra210</td><td>hex</td><td></td><td>
The DRAM location where MTC firmware to be loaded in. This location<br />
needs to be consistent with the location defined in tegra_mtc.ld<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>CPU</td></tr>
<tr bgcolor="#eeeeee">
<td>PARALLEL_MP</td><td>cpu/x86</td><td>bool</td><td></td><td>
This option uses common MP infrastructure for bringing up APs<br />
in parallel. It additionally provides a more flexible mechanism<br />
for sequencing the steps of bringing up the APs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PARALLEL_MP_AP_WORK</td><td>cpu/x86</td><td>bool</td><td></td><td>
Allow APs to do other work after initialization instead of going<br />
to sleep.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LAPIC_MONOTONIC_TIMER</td><td>cpu/x86</td><td>bool</td><td></td><td>
Expose monotonic time using the local APIC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TSC_MONOTONIC_TIMER</td><td>cpu/x86</td><td>bool</td><td></td><td>
Expose monotonic time using the TSC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TSC_SYNC_LFENCE</td><td>cpu/x86</td><td>bool</td><td></td><td>
The CPU driver should select this if the CPU needs<br />
to execute an lfence instruction in order to synchronize<br />
rdtsc. This is true for all modern AMD CPUs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TSC_SYNC_MFENCE</td><td>cpu/x86</td><td>bool</td><td></td><td>
The CPU driver should select this if the CPU needs<br />
to execute an mfence instruction in order to synchronize<br />
rdtsc. This is true for all modern Intel CPUs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SETUP_XIP_CACHE</td><td>cpu/x86</td><td>bool</td><td></td><td>
Select this option to set up an MTRR to cache XIP stages loaded<br />
from the bootblock. This is useful on platforms lacking a<br />
non-eviction mode and therefore need to be careful to avoid<br />
eviction.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMM_MODULE_HEAP_SIZE</td><td>cpu/x86</td><td>hex</td><td></td><td>
This option determines the size of the heap within the SMM handler<br />
modules.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMM_MODULE_STACK_SIZE</td><td>cpu/x86</td><td>hex</td><td></td><td>
This option determines the size of the stack within the SMM handler<br />
modules.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMM_STUB_STACK_SIZE</td><td>cpu/x86</td><td>hex</td><td></td><td>
This option determines the size of the stack within the SMM handler<br />
modules.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86_SMM_LOADER_VERSION2</td><td>cpu/x86</td><td>bool</td><td></td><td>
This option enables SMM module loader that works with server<br />
platforms which may contain more than 32 CPU threads.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIALIZED_SMM_INITIALIZATION</td><td>cpu/x86</td><td>bool</td><td></td><td>
On some CPUs, there is a race condition in SMM.<br />
This can occur when both hyperthreads change SMM state<br />
variables in parallel without coordination.<br />
Setting this option serializes the SMM initialization<br />
to avoid an ugly hang in the boot process at the cost<br />
of a slightly longer boot time.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86_AMD_FIXED_MTRRS</td><td>cpu/x86</td><td>bool</td><td></td><td>
This option informs the MTRR code to use the RdMem and WrMem fields<br />
in the fixed MTRR MSRs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86_AMD_INIT_SIPI</td><td>cpu/x86</td><td>bool</td><td></td><td>
This option limits the number of SIPI signals sent during during the<br />
common AP setup.  Intel documentation specifies an INIT SIPI SIPI<br />
sequence, however this doesn't work on some AMD platforms.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_SETS_MSRS</td><td>cpu/x86</td><td>bool</td><td></td><td>
The SoC requires different access methods for reading and writing<br />
the MSRs.  Use SoC specific routines to handle the MSR access.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_MRC_CACHE</td><td>cpu/amd/agesa</td><td>bool</td><td>Use cached memory configuration</td><td>
Try to restore memory training results<br />
from non-volatile memory.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FORCE_AM1_SOCKET_SUPPORT</td><td>cpu/amd/agesa/family16kb</td><td>bool</td><td></td><td>
Force AGESA to ignore package type mismatch between CPU and northbridge<br />
in memory code. This enables Socket AM1 support with current AGESA<br />
version for Kabini platform.<br />
Enable this option only if you have Socket AM1 board.<br />
Note that the AGESA release shipped with coreboot does not officially<br />
support the AM1 socket. Selecting this option might damage your hardware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_INTEL_SOCKET_FCBGA559</td><td>cpu/intel/socket_FCBGA559</td><td>bool</td><td></td><td>
Select this socket on Intel Pineview<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>cpu/intel/socket_FCBGA559</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_INTEL_FIRMWARE_INTERFACE_TABLE</td><td>cpu/intel/fit</td><td>None</td><td></td><td>
This option selects building a Firmware Interface Table (FIT).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_INTEL_NUM_FIT_ENTRIES</td><td>cpu/intel/fit</td><td>int</td><td></td><td>
This option selects the number of empty entries in the FIT table.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED</td><td>cpu/intel/turbo</td><td>None</td><td></td><td>
This option indicates that the turbo mode setting is not package<br />
scoped. i.e. enable_turbo() needs to be called on not just the bsp<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SET_IA32_FC_LOCK_BIT</td><td>cpu/intel/common</td><td>bool</td><td>Set IA32_FEATURE_CONTROL lock bit</td><td>
Although the Intel manual says you must set the lock bit in addition<br />
to the VMX bit in order for VMX to work, this isn't strictly true, so<br />
we have the option to leave it unlocked and allow the OS (e.g. Linux)<br />
to manage things itself. This is beneficial for testing purposes as<br />
there is no need to reflash the firmware just to toggle the lock bit.<br />
However, leaving the lock bit unset will break Windows' detection of<br />
VMX support and built-in virtualization features like Hyper-V.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SET_MSR_AESNI_LOCK_BIT</td><td>cpu/intel/common</td><td>bool</td><td>Lock the AES-NI enablement state</td><td>
This config sets the AES-NI lock bit, if available, to prevent any<br />
further change of AES-NI enablement. This may be disabled for e.g.<br />
testing or debugging.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MICROCODE_UPDATE_PRE_RAM</td><td>cpu/intel/microcode</td><td>bool</td><td></td><td>
Select this option if you want to update the microcode<br />
during the cache as RAM setup.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_HAS_L2_ENABLE_MSR</td><td>cpu/intel/car/non-evict</td><td>bool</td><td></td><td>
Select this in Kconfig of CPU sockets/SOC where the CPU<br />
has an MSR to enable the L2 CPU cache<br />
<br />
</td></tr>
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMP</td><td>cpu</td><td>bool</td><td></td><td>
This option is used to enable certain functions to make coreboot<br />
work correctly on symmetric multi processor (SMP) systems.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MMX</td><td>cpu</td><td>bool</td><td></td><td>
Select MMX in your socket or model Kconfig if your CPU has MMX<br />
streaming SIMD instructions.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SSE</td><td>cpu</td><td>bool</td><td></td><td>
Select SSE in your socket or model Kconfig if your CPU has SSE<br />
streaming SIMD instructions.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SSE2</td><td>cpu</td><td>bool</td><td></td><td>
Select SSE2 in your socket or model Kconfig if your CPU has SSE2<br />
streaming SIMD instructions. Some parts of coreboot can be built<br />
with more efficient code if SSE2 instructions are available.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USES_MICROCODE_HEADER_FILES</td><td>cpu</td><td>bool</td><td></td><td>
This is selected by a board or chipset to set the default for the<br />
microcode source choice to a list of external microcode headers<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MICROCODE_BLOB_NOT_IN_BLOB_REPO</td><td>cpu</td><td>bool</td><td></td><td>
Selected by platforms that don't maintain microcode updates in the<br />
blobs repo yet.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MICROCODE_BLOB_NOT_HOOKED_UP</td><td>cpu</td><td>bool</td><td></td><td>
Selected by platforms that haven't hooked microcode updates up yet.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MICROCODE_BLOB_UNDISCLOSED</td><td>cpu</td><td>bool</td><td></td><td>
Selected by work-in-progress platforms that don't have microcode<br />
updates available yet.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_CPU_MICROCODE_CBFS_BINS</td><td>cpu</td><td>bool</td><td></td><td>
Automatically selected below to add binary microcode files<br />
(`cpu_microcode_bins` in the makefiles) to CBFS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_MICROCODE_CBFS_DEFAULT_BINS</td><td>cpu</td><td>bool</td><td>Generate from tree</td><td>
Select this option if you want microcode updates to be assembled when<br />
building coreboot and included in the final image as a separate CBFS<br />
file. Microcode will not be hard-coded into ramstage.<br />
<br />
The microcode file may be removed from the ROM image at a later<br />
time with cbfstool, if desired.<br />
<br />
If unsure, select this option.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_MICROCODE_CBFS_EXTERNAL_BINS</td><td>cpu</td><td>bool</td><td>Include external microcode binary</td><td>
Select this option if you want to include external binary files<br />
in the CPUs native format. They will be included as a separate<br />
file in CBFS.<br />
<br />
A word of caution: only select this option if you are sure the<br />
microcode that you have is newer than the microcode shipping with<br />
coreboot.<br />
<br />
The microcode file may be removed from the ROM image at a later<br />
time with cbfstool, if desired.<br />
<br />
If unsure, and applicable, select "Generate from tree"<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_MICROCODE_CBFS_EXTERNAL_HEADER</td><td>cpu</td><td>bool</td><td>Include external microcode header files</td><td>
Select this option if you want to include external c header files<br />
containing the CPU microcode. This will be included as a separate<br />
file in CBFS.<br />
<br />
A word of caution: only select this option if you are sure the<br />
microcode that you have is newer than the microcode shipping with<br />
coreboot.<br />
<br />
The microcode file may be removed from the ROM image at a later<br />
time with cbfstool, if desired.<br />
<br />
If unsure, and applicable, select "Generate from tree"<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_MICROCODE_CBFS_NONE</td><td>cpu</td><td>bool</td><td>Do not include microcode updates</td><td>
Select this option if you do not want CPU microcode included in CBFS.<br />
<br />
Microcode may be added to the ROM image at a later time with cbfstool,<br />
if desired.<br />
<br />
If unsure, and applicable, select "Generate from tree"<br />
<br />
The GOOD:<br />
Microcode updates intend to solve issues that have been discovered<br />
after CPU production. The expected effect is that systems work as<br />
intended with the updated microcode, but we have also seen cases where<br />
issues were solved by not applying microcode updates.<br />
<br />
The BAD:<br />
Note that some operating system include these same microcode patches,<br />
so you may need to also disable microcode updates in your operating<br />
system for this option to have an effect.<br />
<br />
The UGLY:<br />
A word of CAUTION: some CPUs depend on microcode updates to function<br />
correctly. Not updating the microcode may leave the CPU operating at<br />
less than optimal performance, or may cause outright hangups.<br />
There are CPUs where coreboot cannot properly initialize the CPU<br />
without microcode updates<br />
For example, if running with the factory microcode, some Intel<br />
SandyBridge CPUs may hang when enabling CAR, or some VIA Nano CPUs<br />
will hang when changing the frequency.<br />
<br />
Make sure you have a way of flashing the ROM externally before<br />
selecting this option.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_MICROCODE_MULTIPLE_FILES</td><td>cpu</td><td>bool</td><td></td><td>
Select this option to install separate microcode container files into<br />
CBFS instead of using the traditional monolithic microcode file format.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_MICROCODE_HEADER_FILES</td><td>cpu</td><td>string</td><td>List of space separated microcode header files with the path</td><td>
A list of one or more microcode header files with path from the<br />
coreboot directory.  These should be separated by spaces.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_UCODE_BINARIES</td><td>cpu</td><td>string</td><td>Microcode binary path and filename</td><td>
Some platforms have microcode in the blobs directory, and these can<br />
be hardcoded in the makefiles.  For platforms with microcode<br />
binaries that aren't in the makefile, set this option to pull<br />
in the microcode.<br />
<br />
This should contain the full path of the file for one or more<br />
microcode binary files to include, separated by spaces.<br />
<br />
If unsure, leave this blank.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>Northbridge</td></tr>
<tr bgcolor="#eeeeee">
<td>BOTTOMIO_POSITION</td><td>northbridge/amd/agesa</td><td>hex</td><td>Bottom of 32-bit IO space</td><td>
If PCI peripherals with big BARs are connected to the system<br />
the bottom of the IO must be decreased to allocate such devices.<br />
<br />
Declare the beginning of the 128MB-aligned MMIO region.  This<br />
option is useful when PCI peripherals requesting large address<br />
ranges are present, for example, graphic cards.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>northbridge/amd/agesa/family16kb</td><td>string</td><td></td><td>
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOTTOMIO_POSITION</td><td>northbridge/amd/pi</td><td>hex</td><td>Bottom of 32-bit IO space</td><td>
If PCI peripherals with big BARs are connected to the system<br />
the bottom of the IO must be decreased to allocate such<br />
devices.<br />
<br />
Declare the beginning of the 128MB-aligned MMIO region.  This<br />
option is useful when PCI peripherals requesting large address<br />
ranges are present.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>northbridge/amd/pi/00630F01</td><td>string</td><td></td><td>
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>northbridge/amd/pi/00730F01</td><td>string</td><td></td><td>
The default VGA BIOS PCI vendor/device ID should be set to the<br />
result of the map_oprom_vendev() function in northbridge.c.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>northbridge/intel/ironlake</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SANDYBRIDGE_VBOOT_IN_ROMSTAGE</td><td>northbridge/intel/sandybridge</td><td>bool</td><td></td><td>
Selected by boards to force VBOOT_STARTS_IN_ROMSTAGE.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SANDYBRIDGE_VBOOT_IN_BOOTBLOCK</td><td>northbridge/intel/sandybridge</td><td>bool</td><td>Start verstage in bootblock</td><td>
Sandy Bridge can either start verstage in a separate stage<br />
right after the bootblock has run or it can start it<br />
after romstage for compatibility reasons.<br />
Sandy Bridge however uses a mrc.bin to initialize memory which<br />
needs to be located at a fixed offset. Therefore even with<br />
a separate verstage starting after the bootblock that same<br />
binary is used meaning a jump is made from RW to the RO region<br />
and back to the RW region after the binary is done.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_NATIVE_RAMINIT</td><td>northbridge/intel/sandybridge</td><td>bool</td><td>Use native raminit</td><td>
Select if you want to use coreboot implementation of raminit rather than<br />
System Agent/MRC.bin. You should answer Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NATIVE_RAMINIT_IGNORE_MAX_MEM_FUSES</td><td>northbridge/intel/sandybridge</td><td>bool</td><td>Ignore vendor programmed fuses that limit max. DRAM frequency</td><td>
Ignore the mainboard's vendor programmed fuses that might limit the<br />
maximum DRAM frequency. By selecting this option the fuses will be<br />
ignored and the only limits on DRAM frequency are set by RAM's SPD and<br />
hard fuses in southbridge's clockgen.<br />
Disabled by default as it might causes system instability.<br />
Handle with care!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NATIVE_RAMINIT_IGNORE_XMP_MAX_DIMMS</td><td>northbridge/intel/sandybridge</td><td>bool</td><td>Ignore XMP profile max DIMMs per channel</td><td>
Ignore the max DIMMs per channel restriciton defined in XMP profiles.<br />
Disabled by default as it might cause system instability.<br />
Handle with care!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NATIVE_RAMINIT_IGNORE_XMP_REQUESTED_VOLTAGE</td><td>northbridge/intel/sandybridge</td><td>bool</td><td>Ignore XMP profile requested voltage</td><td>
Native raminit only supports 1.5V operation, but there are DIMMs<br />
which request 1.65V operation in XMP profiles. This option allows<br />
raminit to use these XMP profiles anyway, instead of falling back<br />
to non-XMP settings.<br />
Disabled by default because it allows forcing memory to run out of<br />
specification. Consider this to be an overclocking option.<br />
Handle with care!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MMCONF_BASE_ADDRESS</td><td>northbridge/intel/sandybridge</td><td>hex</td><td></td><td>
The MRC blob requires it to be at 0xf0000000.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>northbridge/intel/sandybridge</td><td>hex</td><td></td><td>
The amount of BSP stack anticipated in bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAMINIT_ALWAYS_ALLOW_DLL_OFF</td><td>northbridge/intel/sandybridge</td><td>bool</td><td>Also enable memory DLL-off mode on desktops and servers</td><td>
If enabled, allow enabling DLL-off mode for platforms other than<br />
mobile. Saves power at the expense of higher exit latencies. Has<br />
no effect on mobile platforms, where DLL-off is always allowed.<br />
Power down is disabled for stability when running at high clocks.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAMINIT_ENABLE_ECC</td><td>northbridge/intel/sandybridge</td><td>bool</td><td>Enable ECC if supported</td><td>
Enable ECC if supported by both, host and RAM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_FILE</td><td>northbridge/intel/sandybridge</td><td>string</td><td>Intel System Agent path and filename</td><td>
The path and filename of the file to use as System Agent<br />
binary.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SDRAMPWR_4DIMM</td><td>northbridge/intel/i440bx</td><td>bool</td><td></td><td>
This option affects how the SDRAMC register is programmed.<br />
Memory clock signals will not be routed properly if this option<br />
is set wrong.<br />
<br />
If your board has 4 DIMM slots, you must use select this option, in<br />
your Kconfig file of the board. On boards with 3 DIMM slots,<br />
do _not_ select this option.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>I945_LVDS</td><td>northbridge/intel/i945</td><td>string</td><td></td><td>
Selected by mainboards that use native graphics initialization<br />
for the LVDS port. A linear framebuffer is only supported for<br />
LVDS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>OVERRIDE_CLOCK_DISABLE</td><td>northbridge/intel/i945</td><td>bool</td><td></td><td>
Usually system firmware turns off system memory clock<br />
signals to unused SO-DIMM slots to reduce EMI and power<br />
consumption.<br />
However, some boards do not like unused clock signals to<br />
be disabled.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAXIMUM_SUPPORTED_FREQUENCY</td><td>northbridge/intel/i945</td><td>int</td><td></td><td>
If non-zero, this designates the maximum DDR frequency<br />
the board supports, despite what the chipset should be<br />
capable of.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHECK_SLFRCS_ON_RESUME</td><td>northbridge/intel/i945</td><td>int</td><td></td><td>
On some boards it may be neccessary to hard reset early<br />
during resume from S3 if the SLFRCS register indicates that<br />
a memory channel is not guaranteed to be in self-refresh.<br />
On other boards the check always creates a false positive,<br />
effectively making it impossible to resume.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HASWELL_VBOOT_IN_BOOTBLOCK</td><td>northbridge/intel/haswell</td><td>bool</td><td>Start verstage in bootblock</td><td>
Haswell can either start verstage in a separate stage<br />
right after the bootblock has run or it can start it<br />
after romstage for compatibility reasons.<br />
Haswell however uses a mrc.bin to initialize memory which<br />
needs to be located at a fixed offset. Therefore even with<br />
a separate verstage starting after the bootblock that same<br />
binary is used meaning a jump is made from RW to the RO region<br />
and back to the RW region after the binary is done.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_SIZE</td><td>northbridge/intel/haswell</td><td>hex</td><td></td><td>
The size of the cache-as-ram region required during bootblock<br />
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE<br />
must add up to a power of 2.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_RAM_MRC_VAR_SIZE</td><td>northbridge/intel/haswell</td><td>hex</td><td></td><td>
The amount of cache-as-ram region required by the reference code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DCACHE_BSP_STACK_SIZE</td><td>northbridge/intel/haswell</td><td>hex</td><td></td><td>
The amount of anticipated stack usage in CAR by bootblock and<br />
other stages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_MRC</td><td>northbridge/intel/haswell</td><td>bool</td><td>Add a System Agent binary</td><td>
Select this option to add a System Agent binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary coreboot will not work<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_FILE</td><td>northbridge/intel/haswell</td><td>string</td><td>Intel System Agent path and filename</td><td>
The path and filename of the file to use as System Agent<br />
binary.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HASWELL_HIDE_PEG_FROM_MRC</td><td>northbridge/intel/haswell</td><td>bool</td><td>Hide PEG devices from MRC to work around hardcoded MRC behavior</td><td>
If set, hides all PEG devices from MRC. This allows the iGPU<br />
to be used even when a dedicated graphics card is present.<br />
However, it prevents MRC from programming PEG AFE registers,<br />
which can make PEG devices unstable. When unsure, choose N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PRE_GRAPHICS_DELAY</td><td>northbridge/intel/haswell</td><td>int</td><td>Graphics initialization delay in ms</td><td>
On some systems, coreboot boots so fast that connected monitors<br />
(mostly TVs) won't be able to wake up fast enough to talk to the<br />
VBIOS. On those systems we need to wait for a bit before executing<br />
the VBIOS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_DDR_2X_REFRESH</td><td>northbridge/intel/haswell</td><td>bool</td><td>Enable DRAM Refresh 2x support</td><td>
When enabled, the memory controller will refresh the DRAM twice as often.<br />
This probably only happens when the DRAM gets hot, but what MRC exactly<br />
does when this setting is enabled has not been investigated.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>Southbridge</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_XHCI_ENABLE</td><td>southbridge/amd/agesa/hudson</td><td>bool</td><td>Enable Hudson XHCI Controller</td><td>
The XHCI controller must be enabled and the XHCI firmware<br />
must be added in order to have USB 3.0 support configured<br />
by coreboot. The OS will be responsible for enabling the XHCI<br />
controller if the XHCI firmware is available but the<br />
XHCI controller is not enabled by coreboot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_XHCI_FWM</td><td>southbridge/amd/agesa/hudson</td><td>bool</td><td>Add xhci firmware</td><td>
Add Hudson 2/3/4 XHCI Firmware to support the onboard USB 3.0<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_IMC_FWM</td><td>southbridge/amd/agesa/hudson</td><td>bool</td><td>Add IMC firmware</td><td>
Add Hudson 2/3/4 IMC Firmware to support the onboard fan control<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_GEC_FWM</td><td>southbridge/amd/agesa/hudson</td><td>bool</td><td></td><td>
Add Hudson 2/3/4 GEC Firmware to support the onboard gigabit Ethernet MAC.<br />
Must be connected to a Broadcom B50610 or B50610M PHY on the motherboard.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_SATA_MODE</td><td>southbridge/amd/agesa/hudson</td><td>int</td><td>SATA Mode</td><td>
Select the mode in which SATA should be driven. NATIVE AHCI, or RAID.<br />
The default is NATIVE.<br />
0: NATIVE mode does not require a ROM.<br />
1: RAID mode must have the two ROM files.<br />
2: AHCI may work with or without AHCI ROM. It depends on the payload support.<br />
For example, seabios does not require the AHCI ROM.<br />
3: LEGACY IDE<br />
4: IDE to AHCI<br />
5: AHCI7804: ROM Required, and AMD driver required in the OS.<br />
6: IDE to AHCI7804: ROM Required, and AMD driver required in the OS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/agesa/hudson</td><td>(comment)</td><td></td><td>NATIVE</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/agesa/hudson</td><td>(comment)</td><td></td><td>RAID</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/agesa/hudson</td><td>(comment)</td><td></td><td>AHCI</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/agesa/hudson</td><td>(comment)</td><td></td><td>LEGACY IDE</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/agesa/hudson</td><td>(comment)</td><td></td><td>IDE to AHCI</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/agesa/hudson</td><td>(comment)</td><td></td><td>AHCI7804</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/agesa/hudson</td><td>(comment)</td><td></td><td>IDE to AHCI7804</td></tr>
<tr bgcolor="#eeeeee">
<td>RAID_ROM_ID</td><td>southbridge/amd/agesa/hudson</td><td>string</td><td>RAID device PCI IDs</td><td>
1022,7802 for SATA NON-RAID5 module, 1022,7803 for SATA RAID5 mode<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAID_MISC_ROM_POSITION</td><td>southbridge/amd/agesa/hudson</td><td>hex</td><td>RAID Misc ROM Position</td><td>
The RAID ROM requires that the MISC ROM is located between the range<br />
0xFFF0_0000 to 0xFFF0_FFFF. Also, it must 1K bytes aligned.<br />
The CONFIG_ROM_SIZE must be larger than 0x100000.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_LEGACY_FREE</td><td>southbridge/amd/agesa/hudson</td><td>bool</td><td>System is legacy free</td><td>
Select y if there is no keyboard controller in the system.<br />
This sets variables in AGESA and ACPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AZ_PIN</td><td>southbridge/amd/agesa/hudson</td><td>hex</td><td></td><td>
bit 1,0 - pin 0<br />
bit 3,2 - pin 1<br />
bit 5,4 - pin 2<br />
bit 7,6 - pin 3<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ENABLE_IDE_COMBINED_MODE</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>Enable SATA IDE combined mode</td><td>
If Combined Mode is enabled. IDE controller is exposed and<br />
SATA controller has control over Port0 through Port3,<br />
IDE controller has control over Port4 and Port5.<br />
<br />
If Combined Mode is disabled, IDE controller is hidden and<br />
SATA controller has full control of all 6 Ports when operating in non-IDE mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IDE_COMBINED_MODE</td><td>southbridge/amd/cimx/sb800</td><td>hex</td><td>SATA Mode</td><td>
Select the mode in which SATA should be driven. NATIVE AHCI, or RAID.<br />
The default is AHCI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_SATA_IDE</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>NATIVE</td><td>
NATIVE does not require a ROM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_SATA_AHCI</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>AHCI</td><td>
AHCI is the default and may work with or without AHCI ROM. It depends on the payload support.<br />
For example, seabios does not require the AHCI ROM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_SATA_RAID</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>RAID</td><td>
sb800 RAID mode must have the two required ROM files.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAID_ROM_ID</td><td>southbridge/amd/cimx/sb800</td><td>string</td><td>RAID device PCI IDs</td><td>
1002,4392 for SATA NON-RAID5 module, 1002,4393 for SATA RAID5 mode<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAID_MISC_ROM_POSITION</td><td>southbridge/amd/cimx/sb800</td><td>hex</td><td>RAID Misc ROM Position</td><td>
The RAID ROM requires that the MISC ROM is located between the range<br />
0xFFF0_0000 to 0xFFF0_FFFF. Also, it must 1K bytes aligned.<br />
The CONFIG_ROM_SIZE must larger than 0x100000.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_IMC_FWM</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>Add IMC firmware</td><td>
Add SB800 / Hudson 1 IMC Firmware to support the onboard fan control.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_FWM_AT_FFFA0000</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>0xFFFA0000</td><td>
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory.  The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_FWM_AT_FFF20000</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>0xFFF20000</td><td>
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory.  The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_FWM_AT_FFE20000</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>0xFFE20000</td><td>
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory.  The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_FWM_AT_FFC20000</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>0xFFC20000</td><td>
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory.  The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_FWM_AT_FF820000</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>0xFF820000</td><td>
The IMC and GEC ROMs requires a 'signature' located at one of several<br />
fixed locations in memory.  The location used shouldn't matter, just<br />
select an area that doesn't conflict with anything else.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EHCI_BAR</td><td>southbridge/amd/cimx/sb800</td><td>hex</td><td>Fan Control</td><td>
Select the method of SB800 fan control to be used.  None would be<br />
for either fixed maximum speed fans connected to the SB800 or for<br />
an external chip controlling the fan speeds.  Manual control sets<br />
up the SB800 fan control registers.  IMC fan control uses the SB800<br />
IMC to actively control the fan speeds.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_NO_FAN_CONTROL</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>None</td><td>
No SB800 Fan control - Do not set up the SB800 fan control registers.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_MANUAL_FAN_CONTROL</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>Manual</td><td>
Configure the SB800 fan control registers in devicetree.cb.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SB800_IMC_FAN_CONTROL</td><td>southbridge/amd/cimx/sb800</td><td>bool</td><td>IMC Based</td><td>
Set up the SB800 to use the IMC based Fan controller.  This requires<br />
the IMC ROM from AMD.  Configure the registers in devicetree.cb.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_XHCI_ENABLE</td><td>southbridge/amd/pi/hudson</td><td>bool</td><td>Enable Hudson XHCI Controller</td><td>
The XHCI controller must be enabled and the XHCI firmware<br />
must be added in order to have USB 3.0 support configured<br />
by coreboot. The OS will be responsible for enabling the XHCI<br />
controller if the XHCI firmware is available but the<br />
XHCI controller is not enabled by coreboot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_XHCI_FWM</td><td>southbridge/amd/pi/hudson</td><td>bool</td><td>Add xhci firmware</td><td>
Add Hudson 2/3/4 XHCI Firmware to support the onboard USB 3.0<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_IMC_FWM</td><td>southbridge/amd/pi/hudson</td><td>bool</td><td>Add IMC firmware</td><td>
Add Hudson 2/3/4 IMC Firmware to support the onboard fan control<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_GEC_FWM</td><td>southbridge/amd/pi/hudson</td><td>bool</td><td></td><td>
Add Hudson 2/3/4 GEC Firmware to support the onboard gigabit Ethernet MAC.<br />
Must be connected to a Broadcom B50610 or B50610M PHY on the motherboard.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_SATA_MODE</td><td>southbridge/amd/pi/hudson</td><td>int</td><td>SATA Mode</td><td>
Select the mode in which SATA should be driven. NATIVE AHCI, or RAID.<br />
The default is NATIVE.<br />
0: NATIVE mode does not require a ROM.<br />
1: RAID mode must have the two ROM files.<br />
2: AHCI may work with or without AHCI ROM. It depends on the payload support.<br />
For example, seabios does not require the AHCI ROM.<br />
3: LEGACY IDE<br />
4: IDE to AHCI<br />
5: AHCI7804: ROM Required, and AMD driver required in the OS.<br />
6: IDE to AHCI7804: ROM Required, and AMD driver required in the OS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/pi/hudson</td><td>(comment)</td><td></td><td>NATIVE</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/pi/hudson</td><td>(comment)</td><td></td><td>RAID</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/pi/hudson</td><td>(comment)</td><td></td><td>AHCI</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/pi/hudson</td><td>(comment)</td><td></td><td>LEGACY IDE</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/pi/hudson</td><td>(comment)</td><td></td><td>IDE to AHCI</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/pi/hudson</td><td>(comment)</td><td></td><td>AHCI7804</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/amd/pi/hudson</td><td>(comment)</td><td></td><td>IDE to AHCI7804</td></tr>
<tr bgcolor="#eeeeee">
<td>RAID_ROM_ID</td><td>southbridge/amd/pi/hudson</td><td>string</td><td>RAID device PCI IDs</td><td>
1022,7802 for SATA NON-RAID5 module, 1022,7803 for SATA RAID5 mode<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAID_MISC_ROM_POSITION</td><td>southbridge/amd/pi/hudson</td><td>hex</td><td>RAID Misc ROM Position</td><td>
The RAID ROM requires that the MISC ROM is located between the range<br />
0xFFF0_0000 to 0xFFF0_FFFF. Also, it must 1K bytes aligned.<br />
The CONFIG_ROM_SIZE must be larger than 0x100000.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_LEGACY_FREE</td><td>southbridge/amd/pi/hudson</td><td>bool</td><td>System is legacy free</td><td>
Select y if there is no keyboard controller in the system.<br />
This sets variables in AGESA and ACPI.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AZ_PIN</td><td>southbridge/amd/pi/hudson</td><td>hex</td><td></td><td>
bit 1,0 - pin 0<br />
bit 3,2 - pin 1<br />
bit 5,4 - pin 2<br />
bit 7,6 - pin 3<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AMDFW_OUTSIDE_CBFS</td><td>southbridge/amd/pi/hudson</td><td>hex</td><td></td><td>
The AMDFW (PSP) is typically locatable in cbfs.  Select this<br />
option to manually attach the generated amdfw.rom at an<br />
offset of 0x20000 from the bottom of the coreboot ROM image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIRQ_CONTINUOUS_MODE</td><td>southbridge/amd/pi/hudson</td><td>bool</td><td></td><td>
Set this option to y for serial IRQ in continuous mode.<br />
Otherwise it is in quiet mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_ACPI_IO_BASE</td><td>southbridge/amd/pi/hudson</td><td>hex</td><td></td><td>
Base address for the ACPI registers.<br />
This value must match the hardcoded value of AGESA.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HUDSON_UART</td><td>southbridge/amd/pi/hudson</td><td>bool</td><td>UART controller on Kern</td><td>
There are two UART controllers in Kern.<br />
The UART registers are memory-mapped. UART<br />
controller 0 registers range from FEDC_6000h<br />
to FEDC_6FFFh. UART controller 1 registers<br />
range from FEDC_8000h to FEDC_8FFFh.<br />
<br />
</td></tr>
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIRQ_CONTINUOUS_MODE</td><td>southbridge/intel/ibexpeak</td><td>bool</td><td></td><td>
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_LYNXPOINT_LP</td><td>southbridge/intel/lynxpoint</td><td>bool</td><td></td><td>
Set this option to y for Lynxpont LP (Haswell ULT).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIRQ_CONTINUOUS_MODE</td><td>southbridge/intel/lynxpoint</td><td>bool</td><td></td><td>
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FINALIZE_USB_ROUTE_XHCI</td><td>southbridge/intel/lynxpoint</td><td>bool</td><td>Route all ports to XHCI controller in finalize step</td><td>
If you set this option to y, the USB ports will be routed<br />
to the XHCI controller during the finalize SMM callback.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_DESCRIPTOR_MODE_CAPABLE</td><td>southbridge/intel/common</td><td>bool</td><td></td><td>
This config simply states that the platform is *capable* of running in<br />
descriptor mode (when the descriptor in flash is valid).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_DESCRIPTOR_MODE_REQUIRED</td><td>southbridge/intel/common</td><td>bool</td><td></td><td>
This config states descriptor mode is *required* for the platform to<br />
function properly, or to function at all.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VALIDATE_INTEL_DESCRIPTOR</td><td>southbridge/intel/common</td><td>bool</td><td>Validate Intel firmware descriptor</td><td>
This config enables validating the Intel firmware descriptor against the<br />
fmap layout. If the firmware descriptor layout does not match the fmap<br />
then the bootimage cannot be built.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_CHIPSET_LOCKDOWN</td><td>southbridge/intel/common</td><td>bool</td><td>Lock down chipset in coreboot</td><td>
Some registers within host bridge on particular chipsets should be<br />
locked down on each normal boot path (done by either coreboot or payload)<br />
and S3 resume (always done by coreboot). Select this to let coreboot<br />
to do this on normal boot path.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SERIRQ_CONTINUOUS_MODE</td><td>southbridge/intel/bd82x6x</td><td>bool</td><td></td><td>
If you set this option to y, the serial IRQ machine will be<br />
operated in continuous mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>Super I/O</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_NUVOTON_COMMON_COM_A</td><td>superio/nuvoton/common</td><td>bool</td><td></td><td>
When enabled, the 'nuvoton_enable_serial()' function will unset<br />
global CR 0x2a bit 7 to route COM A to the GPIO8 pin group.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>W83977TF_HAVE_SEPARATE_IR_DEVICE</td><td>superio/winbond/w83977tf</td><td>bool</td><td></td><td>
Mainboard should select this option if it contains an old<br />
version of W83977TF with a separate IR logical device.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ITE_ENV_CTRL_FAN16_CONFIG</td><td>superio/ite/common</td><td>bool</td><td></td><td>
Enable extended, 16-bit wide tacho counters.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ITE_ENV_CTRL_8BIT_PWM</td><td>superio/ite/common</td><td>bool</td><td></td><td>
PWM duty cycles are set in 8-bit registers (instead of 7 bit).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ITE_ENV_CTRL_PWM_FREQ2</td><td>superio/ite/common</td><td>bool</td><td></td><td>
The second FAN controller has a separate frequency setting.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ITE_ENV_CTRL_NO_ONOFF</td><td>superio/ite/common</td><td>bool</td><td></td><td>
FAN controller always works in SmartGuardian mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ITE_ENV_CTRL_5FANS</td><td>superio/ite/common</td><td>bool</td><td></td><td>
ITE FAN controller has 5 independent outputs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ITE_ENV_CTRL_7BIT_SLOPE_REG</td><td>superio/ite/common</td><td>bool</td><td></td><td>
Slope PWM registers have no separate BIT6 and are set directly by<br />
7-bit values instead.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ITE_ENV_CTRL_EXT_ANY_TMPIN</td><td>superio/ite/common</td><td>bool</td><td></td><td>
Temperature can be read to any TMPIN from an external sensor via SST/PECI<br />
(instead of TMPIN3 only).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUPERIO_ASPEED_USE_UART_DELAY_WORKAROUND</td><td>superio/aspeed/common</td><td>bool</td><td>Workaround for BMC serial console setup bug</td><td>
Some mainboards with an ASPEED BMC have scrambled console output in early boot phases<br />
because the serial output routing is not set up fast enough by the BMC. By enabling<br />
this a delay of 500ms gets added before setting up the console and before any console<br />
output gets printed.<br />
<br />
Note: this problem may disappear with future BMC firmware versions. Another approach<br />
is using a different BMC firmware like OpenBMC, u-bmc, ...<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>Embedded Controllers</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_ACPI</td><td>ec/acpi</td><td>bool</td><td></td><td>
ACPI Embedded Controller interface. Mostly found in laptops.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_SUPPORTS_DPTF_TEVT</td><td>ec/acpi</td><td>bool</td><td></td><td>
The EC ASL code supports calling of TEVT method when provided by<br />
SoC or mainboard.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_HP_KBC1126</td><td>ec/hp/kbc1126</td><td>bool</td><td></td><td>
Interface to SMSC KBC1126 embedded controller in HP laptops.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>ec/hp/kbc1126</td><td>(comment)</td><td></td><td>Please select the following otherwise your laptop cannot be powered on.</td></tr>
<tr bgcolor="#eeeeee">
<td>KBC1126_FIRMWARE</td><td>ec/hp/kbc1126</td><td>bool</td><td>Add firmware images for KBC1126 EC</td><td>
Select this option to add the two firmware blobs for KBC1126.<br />
You need these two blobs to power on your machine.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>KBC1126_FW1</td><td>ec/hp/kbc1126</td><td>string</td><td>KBC1126 firmware #1 path and filename</td><td>
The path and filename of the file to use as KBC1126 firmware #1.<br />
You can use util/kbc1126/kbc1126_ec_dump to dump it from the<br />
vendor firmware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>KBC1126_FW2</td><td>ec/hp/kbc1126</td><td>string</td><td>KBC1126 filename #2 path and filename</td><td>
The path and filename of the file to use as KBC1126 firmware #2.<br />
You can use util/kbc1126/kbc1126_ec_dump to dump it from the<br />
vendor firmware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_KONTRON_IT8516E</td><td>ec/kontron/it8516e</td><td>bool</td><td></td><td>
Kontron uses an ITE IT8516E on the KTQM77. Its firmware might<br />
come from Fintek (mentioned as Finte*c* somewhere in their Linux<br />
driver).<br />
The KTQM77 is an embedded board and the IT8516E seems to be<br />
only used for fan control and GPIO.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_KONTRON_KEMPLD</td><td>ec/kontron/kempld</td><td>bool</td><td></td><td>
Driver for Kontron's express module programmable logic device used<br />
on their COMexpress modules.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Google's Chrome EC<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_ACPI_MEMMAP</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
When defined, ACPI accesses EC memmap data on ports 66h/62h. When<br />
not defined, the memmap data is instead accessed on 900h-9ffh via<br />
the LPC bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_ACPI_USB_PORT_POWER</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Expose methods for enabling and disabling port power on individual USB<br />
ports through the EC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_BOARDID</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Provides common routine for reading boardid from Chrome EC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_I2C</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Google's Chrome EC via I2C bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_I2C_PROTO3</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Use only proto3 for i2c EC communication.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_ESPI</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Google Chrome EC via eSPI bus.<br />
<br />
The EC communication code is the same between eSPI and LPC, so<br />
this option simply enables the LPC EC code.  The eSPI device<br />
still needs to correctly configure the bus transactions.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_LPC</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Google Chrome EC via LPC bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_MEC</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Microchip EC variant for LPC register access.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_PD</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Indicates that Google's Chrome USB PD chip is present.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_SPI</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Google's Chrome EC via SPI bus.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_SPI_WAKEUP_DELAY_US</td><td>ec/google/chromeec</td><td>int</td><td></td><td>
Force delay after asserting /CS to allow EC to wakeup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_SKUID</td><td>ec/google/chromeec</td><td>hex</td><td></td><td>
Provides common routine for reporting the skuid to ChromeOS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_BOARDNAME</td><td>ec/google/chromeec</td><td>string</td><td>Chrome EC board name for EC</td><td>
The board name used in the Chrome EC code base to build<br />
the EC firmware.  If set, the coreboot build with also<br />
build the EC firmware and add it to the image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_PD_BOARDNAME</td><td>ec/google/chromeec</td><td>string</td><td>Chrome EC board name for PD</td><td>
The board name used in the Chrome EC code base to build<br />
the PD firmware.  If set, the coreboot build with also<br />
build the EC firmware and add it to the image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_RTC</td><td>ec/google/chromeec</td><td>bool</td><td>Enable Chrome OS EC RTC</td><td>
Enable support for the real-time clock on the Chrome OS EC. This<br />
uses the EC_CMD_RTC_GET_VALUE command to read the current time.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_FIRMWARE_NONE</td><td>ec/google/chromeec</td><td>bool</td><td>No EC firmware is included</td><td>
Disable building and including any EC firmware in the image.<br />
<br />
config EC_GOOGLE_CHROMEEC_FIRMWARE_EXTERNAL<br />
bool "External EC firmware is included"<br />
help<br />
Include EC firmware binary in the image from an external source.<br />
It is expected to be built externally.<br />
<br />
config EC_GOOGLE_CHROMEEC_FIRMWARE_BUILTIN<br />
bool "Builtin EC firmware is included"<br />
help<br />
Build and include EC firmware binary in the image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_FIRMWARE_FILE</td><td>ec/google/chromeec</td><td>string</td><td>Chrome EC firmware path and filename</td><td>
The path and filename of the EC firmware file to use.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_PD_FIRMWARE_NONE</td><td>ec/google/chromeec</td><td>bool</td><td>No PD firmware is included</td><td>
Disable building and including any PD firmware in the image.<br />
<br />
config EC_GOOGLE_CHROMEEC_PD_FIRMWARE_EXTERNAL<br />
bool "External PD firmware is included"<br />
help<br />
Include PD firmware binary in the image from an external source.<br />
It is expected to be built externally.<br />
<br />
config EC_GOOGLE_CHROMEEC_PD_FIRMWARE_BUILTIN<br />
bool "Builtin PD firmware is included"<br />
help<br />
Build and include PD firmware binary in the image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_PD_FIRMWARE_FILE</td><td>ec/google/chromeec</td><td>string</td><td>Chrome EC firmware path and filename for PD</td><td>
The path and filename of the PD firmware file to use.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_SWITCHES</td><td>ec/google/chromeec</td><td>bool</td><td></td><td>
Enable support for Chrome OS mode switches provided by the Chrome OS<br />
EC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_I2C_TUNNEL</td><td>ec/google/chromeec/i2c_tunnel</td><td>bool</td><td></td><td>
This enables the Cros EC I2C tunnel driver that is required to fill the<br />
SSDT nodes for the I2C tunnel used by the mainboard.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_CHROMEEC_AUDIO_CODEC</td><td>ec/google/chromeec/audio_codec</td><td>bool</td><td></td><td>
This enables the Cros EC audio codec driver that is required to fill the<br />
SSDT nodes for the codec device used by the mainboard.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_COMMON_MEC</td><td>ec/google/common</td><td>bool</td><td></td><td>
Google common EC functions for Microchip EMI region.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_GOOGLE_WILCO</td><td>ec/google/wilco</td><td>bool</td><td></td><td>
Google Wilco Embedded Controller interface.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_BASE_ACPI_DATA</td><td>ec/google/wilco</td><td>hex</td><td></td><td>
This option provides the 16-bit IO base address for the ACPI<br />
data interface.  This is the standard ACPI EC interface that<br />
is used by the ACPI EC drivers in the OS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_BASE_ACPI_COMMAND</td><td>ec/google/wilco</td><td>hex</td><td></td><td>
This option provides the 16-bit IO base address for the ACPI<br />
EC command interface.  This is the standard ACPI EC interface<br />
that is used by the ACPI EC drivers in the OS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_BASE_HOST_DATA</td><td>ec/google/wilco</td><td>hex</td><td></td><td>
This option provides the 16-bit IO base address for the host<br />
data interface.  This is the interface that is used to drive<br />
the mailbox protocol.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_BASE_HOST_COMMAND</td><td>ec/google/wilco</td><td>hex</td><td></td><td>
This option provides the 16-bit IO base address for the host<br />
command interface.  This is the interface that is used to drive<br />
the mailbox protocol.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_BASE_PACKET</td><td>ec/google/wilco</td><td>hex</td><td></td><td>
This option provides the 16-bit IO base address for the EC<br />
mailbox interface data region.  This data buffer is used along<br />
with the host command and data registers to drive the EC<br />
mailbox interface.  This is also the MEC EMI base address.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_QUANTA_IT8518</td><td>ec/quanta/it8518</td><td>bool</td><td></td><td>
Interface to QUANTA IT8518 Embedded Controller.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_QUANTA_ENE_KB3940Q</td><td>ec/quanta/ene_kb3940q</td><td>bool</td><td></td><td>
Interface to QUANTA ENE KB3940Q Embedded Controller.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>H8_BEEP_ON_DEATH</td><td>ec/lenovo/h8</td><td>bool</td><td>Beep on fatal error</td><td>
Beep when encountered a fatal error.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>H8_FLASH_LEDS_ON_DEATH</td><td>ec/lenovo/h8</td><td>bool</td><td>Flash LEDs on fatal error</td><td>
Flash all LEDs when encountered a fatal error.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>H8_SUPPORT_BT_ON_WIFI</td><td>ec/lenovo/h8</td><td>bool</td><td>Support bluetooth on wifi cards</td><td>
Disable BDC detection and assume bluetooth is installed. Required for<br />
bluetooth on wifi cards, as it's not possible to detect it in coreboot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>H8_FN_KEY_AS_VBOOT_RECOVERY_SW</td><td>ec/lenovo/h8</td><td>bool</td><td>Enable Fn-Key as VBOOT recovery switch</td><td>
If VBOOT is enabled, press Fn-Key at power on to force a recovery mode<br />
boot instead of regular FW_MAIN_x boot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>THINKPADEC_HKEY_EISAID</td><td>ec/lenovo/h8</td><td>string</td><td></td><td>
Motherboards of newer thinkpad models can override the default to match<br />
vendor drivers and quirks.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_RODA_IT8518</td><td>ec/roda/it8518</td><td>bool</td><td></td><td>
Interface to IT8518 embedded controller in Roda notebooks.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_SMSC_MEC1308</td><td>ec/smsc/mec1308</td><td>bool</td><td></td><td>
Shared memory mailbox interface to SMSC MEC1308 Embedded Controller.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_COMPAL_ENE932</td><td>ec/compal/ene932</td><td>bool</td><td></td><td>
Interface to COMPAL ENE932 Embedded Controller.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_SYSTEM76_EC</td><td>ec/system76/ec</td><td>bool</td><td></td><td>
System76 EC<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_PURISM_LIBREM</td><td>ec/purism/librem</td><td>bool</td><td></td><td>
Purism Librem EC<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_51NB_NPCE985LA0DX</td><td>ec/51nb/npce985la0dx</td><td>bool</td><td></td><td>
Support for the 51NB NPCE985LA0DX EC<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>ec/51nb/npce985la0dx</td><td>(comment)</td><td></td><td>Please select the following otherwise your laptop cannot be powered on.</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_51NB_NPCE985LA0DX_FIRMWARE</td><td>ec/51nb/npce985la0dx</td><td>bool</td><td>Add firmware image for 51NB NPCE985LA0DX EC</td><td>
Select this option to add the firmware blob for the 51NB EC.<br />
You need this blob to power on your machine.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_51NB_NPCE985LA0DX_FW</td><td>ec/51nb/npce985la0dx</td><td>string</td><td>51NB EC firmware path</td><td>
The path and filename of the file to use as 51NB firmware.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_INTEL_FIRMWARE</td><td>southbridge/intel/common/firmware</td><td>bool</td><td></td><td>
Platform uses the Intel Firmware Descriptor to describe the<br />
layout of the SPI ROM chip. Enabling this option will allow you to<br />
select further features that rely on this like providing individual<br />
firmware blobs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/intel/common/firmware</td><td>(comment)</td><td></td><td>Intel Firmware</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_IFD_BIN</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Add Intel descriptor.bin file</td><td>
The descriptor binary<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_ME_BIN</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Add Intel ME/TXE firmware</td><td>
The Intel processor in the selected system requires a special firmware<br />
for an integrated controller.  This might be called the Management<br />
Engine (ME), the Trusted Execution Engine (TXE) or something else<br />
depending on the chip. This firmware might or might not be available<br />
in coreboot's 3rdparty/blobs repository. If it is not and if you don't<br />
have access to the firmware from elsewhere, you can still build<br />
coreboot without it. In this case however, you'll have to make sure<br />
that you don't overwrite your ME/TXE firmware on your flash ROM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHECK_ME</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Verify the integrity of the supplied ME/TXE firmware</td><td>
Verify the integrity of the supplied Intel ME/TXE firmware before<br />
proceeding with the build, in order to prevent an accidental loading<br />
of a corrupted ME/TXE image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ME_REGION_ALLOW_CPU_READ_ACCESS</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Allows HOST/CPU read access to ME region</td><td>
The config ensures Host has read access to the ME region if it is locked<br />
through LOCK_MANAGEMENT_ENGINE config. This config is enabled when the CSE<br />
Lite SKU is integrated.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_ME_CLEANER</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Strip down the Intel ME/TXE firmware</td><td>
Use me_cleaner to remove all the non-fundamental code from the Intel<br />
ME/TXE firmware.<br />
The resulting Intel ME/TXE firmware will have only the code<br />
responsible for the very basic hardware initialization, leaving the<br />
ME/TXE subsystem essentially in a disabled state.<br />
<br />
Don't flash a modified ME/TXE firmware and a new coreboot image at the<br />
same time, test them in two different steps.<br />
<br />
WARNING: this tool isn't based on any official Intel documentation but<br />
only on reverse engineering and trial &amp; error.<br />
<br />
See the project's page<br />
https://github.com/corna/me_cleaner<br />
or the wiki<br />
https://github.com/corna/me_cleaner/wiki/How-to-apply-me_cleaner<br />
https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F<br />
https://github.com/corna/me_cleaner/wiki/me_cleaner-status<br />
for more info about this tool<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>southbridge/intel/common/firmware</td><td>(comment)</td><td></td><td>Please test the modified ME/TXE firmware and coreboot in two steps</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_GBE_BIN</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Add gigabit ethernet configuration</td><td>
The integrated gigabit ethernet controller needs a configuration<br />
file. Select this if you are going to use the PCH integrated<br />
controller and want to add that file.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_EC_BIN</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Add EC firmware</td><td>
The embedded controller needs a firmware file.<br />
<br />
Select this if you are going to use the PCH integrated controller<br />
and have the EC firmware. EC firmware will be added to final image<br />
through ifdtool.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EC_BIN_PATH</td><td>southbridge/intel/common/firmware</td><td>string</td><td>Protect flash regions</td><td>
This option allows you to protect flash regions.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DO_NOT_TOUCH_DESCRIPTOR_REGION</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Use the preset values to protect the regions</td><td>
Read and write access permissions to different regions in the flash<br />
can be controlled via dedicated bitfields in the flash descriptor.<br />
These permissions can be modified with the Intel Flash Descriptor<br />
Tool (ifdtool). If you don't want to change these permissions and<br />
keep the ones provided in the initial descriptor, use this option.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LOCK_MANAGEMENT_ENGINE</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Lock ME/TXE section</td><td>
The Intel Firmware Descriptor supports preventing write and read<br />
accesses from the host to the ME or TXE section. If the section<br />
is locked, it can only be overwritten with an external SPI flash<br />
programmer or HECI HMRFPO_ENABLE command needs to be sent to CSE<br />
before writing to the ME Section. If CSE Lite SKU is integrated,<br />
the Kconfig prevents only writing to the ME section.<br />
<br />
If unsure, select "Unlock flash regions".<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UNLOCK_FLASH_REGIONS</td><td>southbridge/intel/common/firmware</td><td>bool</td><td>Unlock flash regions</td><td>
All regions are completely unprotected and can be overwritten using<br />
a flash programming tool.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_SIZE</td><td>southbridge/intel/common/firmware</td><td>hex</td><td></td><td>
Reduce CBFS size to give room to the IFD blobs.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: ChromeOS</td></tr>
<tr bgcolor="#eeeeee">
<td>CHROMEOS</td><td>vendorcode/google/chromeos</td><td>bool</td><td>Build for ChromeOS</td><td>
Enable ChromeOS specific features like the GPIO sub table in<br />
the coreboot table. NOTE: Enabling this option on an unsupported<br />
board will most likely break your build.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_TPM_RESUME</td><td>vendorcode/google/chromeos</td><td>bool</td><td></td><td>
On some boards the TPM stays powered up in S3. On those<br />
boards, booting Windows will break if the TPM resume command<br />
is sent during an S3 resume.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_REGULATORY_DOMAIN</td><td>vendorcode/google/chromeos</td><td>bool</td><td>Add regulatory domain methods</td><td>
This option is needed to add ACPI regulatory domain methods<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHROMEOS_DISABLE_PLATFORM_HIERARCHY_ON_RESUME</td><td>vendorcode/google/chromeos</td><td>bool</td><td></td><td>
Disable the platform heirarchy on resume path if the firmware<br />
is involved in resume. The hierarchy is disabled prior to jumping<br />
to the OS.  Note that this option is sepcific to TPM2 boards.<br />
This option is auto selected if CHROMEOS because it matches with<br />
vboot_reference model which disables the platform hierarchy in<br />
the boot loader. However, those operations need to be symmetric<br />
on normal boot as well as resume and coreboot is only involved<br />
in the resume piece w.r.t. the platform hierarchy.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHROMEOS_USE_EC_WATCHDOG_FLAG</td><td>vendorcode/google/chromeos</td><td>bool</td><td></td><td>
Use the AP watchdog flag stored in EC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHROMEOS_DSM_CALIB</td><td>vendorcode/google/chromeos</td><td>bool</td><td></td><td>
On some boards, there are calibrated parameters for Dynamic Speaker Management(DSM)<br />
stored in VPD. Enable this config to read and parse these VPD values and write them<br />
to ACPI DSD table in device driver. These parameters will be applied by kernel driver<br />
through device property at boot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHROMEOS_CSE_BOARD_RESET_OVERRIDE</td><td>vendorcode/google/chromeos</td><td>bool</td><td></td><td>
On some boards that run old firmware version in cr50, Embedded Controller (EC) needs<br />
to trigger the cold reset of Application Processor (AP) when CSE jumps from RO to RW<br />
so that cr50 resets the TPM state. This is required on boards where the cr50 firmware<br />
does not understand the new cr50 strap config (applicable only to boards using strap<br />
config 0xe). Enabling this config will help to override the default global reset.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHROMEOS_DRAM_PART_NUMBER_IN_CBI</td><td>vendorcode/google/chromeos</td><td>bool</td><td></td><td>
Some boards declare the DRAM part number in the CBI instead of the SPD.  This option<br />
allows those boards to declare that their DRAM part number is stored in the CBI.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>GOOGLE_SMBIOS_MAINBOARD_VERSION</td><td>vendorcode/google</td><td>bool</td><td></td><td>
Provide a common implementation for mainboard version,<br />
which returns a formatted 'rev%d' board_id() string.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK</td><td>vendorcode/cavium</td><td>None</td><td></td><td>
Build Cavium's BDK in romstage.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: BDK</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_VERBOSE_INIT</td><td>vendorcode/cavium</td><td>bool</td><td>Enable verbose init</td><td>
Build Cavium's BDK with verbose init code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_VERBOSE_DRAM</td><td>vendorcode/cavium</td><td>bool</td><td>Enable verbose dram init</td><td>
Build Cavium's BDK with verbose dram init code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_VERBOSE_DRAM_TEST</td><td>vendorcode/cavium</td><td>bool</td><td>Enable verbose raminit tests</td><td>
Build Cavium's BDK with verbose DRAM testing code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_VERBOSE_QLM</td><td>vendorcode/cavium</td><td>bool</td><td>Enable verbose qlm init</td><td>
Build Cavium's BDK with verbose QLM code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_VERBOSE_PCIE_CONFIG</td><td>vendorcode/cavium</td><td>bool</td><td>Enable verbose pcie config</td><td>
Build Cavium's BDK with verbose PCIe config code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_VERBOSE_PCIE</td><td>vendorcode/cavium</td><td>bool</td><td>Enable verbose pcie init</td><td>
Build Cavium's BDK with verbose PCIe code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_VERBOSE_PHY</td><td>vendorcode/cavium</td><td>bool</td><td>Enable verbose phy init</td><td>
Build Cavium's BDK with verbose PHY code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CAVIUM_BDK_DDR_TUNE_HW_OFFSETS</td><td>vendorcode/cavium</td><td>bool</td><td>Hardware assisted DLL read offset tuning</td><td>
Automatically tune the data byte DLL read offsets.<br />
Always done by default, but allow use of HW-assist.<br />
NOTE: HW-assist will also tune the ECC byte.<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: AMD Platform Initialization</td></tr>
<tr bgcolor="#eeeeee">
<td>None</td><td>vendorcode/amd</td><td>None</td><td>AGESA source</td><td>
Select the method for including the AMD Platform Initialization<br />
code into coreboot.  Platform Initialization code is required for<br />
all AMD processors.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_AMD_AGESA_BINARY_PI</td><td>vendorcode/amd</td><td>bool</td><td>binary PI</td><td>
Use a binary PI package.  Generally, these will be stored in the<br />
"3rdparty/blobs" directory.  For some processors, these must be obtained<br />
directly from AMD Embedded Processors Group<br />
(http://www.amd.com/embedded).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_AMD_AGESA_OPENSOURCE</td><td>vendorcode/amd</td><td>bool</td><td>open-source AGESA</td><td>
Build the PI package ("AGESA") from source code in the "vendorcode"<br />
directory.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>None</td><td>vendorcode/amd/agesa</td><td>None</td><td>DDR3 memory profile</td><td>
Choose the DDR3 memory profile to use for your RAM sticks, e.g. XMP 1.<br />
XMP support is experimental, and your PC will fail booting if you choose<br />
a profile which does not exist on ANY of your RAM sticks! If in doubt<br />
check their SPD Data using a coreboot's great fork of memtest86+ 5.01.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_AMD_AGESA_OPENSOURCE_MEM_JEDEC</td><td>vendorcode/amd/agesa</td><td>bool</td><td>JEDEC</td><td>
JEDEC memory profile, standard and stable. Is guaranteed to be working.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_AMD_AGESA_OPENSOURCE_MEM_XMP_1</td><td>vendorcode/amd/agesa</td><td>bool</td><td>XMP 1</td><td>
XMP 1 memory profile. Check that it exists on ALL of your RAM sticks!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_AMD_AGESA_OPENSOURCE_MEM_XMP_2</td><td>vendorcode/amd/agesa</td><td>bool</td><td>XMP 2</td><td>
XMP 2 memory profile. Check that it exists on ALL of your RAM sticks!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CPU_AMD_AGESA_OPENSOURCE_MEM_CUSTOM</td><td>vendorcode/amd/agesa</td><td>bool</td><td>CUSTOM</td><td>
Custom memory profile. Use the XMP SPD values as the base, if available.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_BINARY_PI_VENDORCODE_PATH</td><td>vendorcode/amd/pi</td><td>string</td><td>AGESA PI directory path</td><td>
Specify where to find the AGESA header files<br />
for AMD platform initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_BINARY_PI_FILE</td><td>vendorcode/amd/pi</td><td>string</td><td>AGESA PI binary file name</td><td>
Specify the binary file to use for AMD platform initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_BINARY_PI_AS_STAGE</td><td>vendorcode/amd/pi</td><td>bool</td><td>AGESA Binary PI is added as stage to CBFS.</td><td>
AGESA will be added as a stage utilizing --xip cbfstool options<br />
as needed relocating the image to the proper location in memory-mapped<br />
cpu address space. It's required that the file be in ELF format<br />
containing the relocations necessary for relocating at runtime.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_SPLIT_MEMORY_FILES</td><td>vendorcode/amd/pi</td><td>bool</td><td>Split AGESA Binary PI into pre- and post-memory files.</td><td>
Specifies that AGESA is split into two binaries for pre- and<br />
post-memory.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_PRE_MEMORY_BINARY_PI_FILE</td><td>vendorcode/amd/pi</td><td>string</td><td>Pre memory Binary PI file name</td><td>
Specify the binary file to use for pre-memory AMD platform<br />
initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_POST_MEMORY_BINARY_PI_FILE</td><td>vendorcode/amd/pi</td><td>string</td><td>Post memory Binary PI file name</td><td>
Specify the binary file to use for post-memory AMD platform<br />
initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_BINARY_PI_LOCATION</td><td>vendorcode/amd/pi</td><td>hex</td><td>AGESA PI binary address in ROM</td><td>
Specify the ROM address at which to store the binary Platform<br />
Initialization code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>AGESA_EXTRA_TIMESTAMPS</td><td>vendorcode/amd</td><td>bool</td><td>Add instrumentation for AGESA calls</td><td>
Insert additional timestamps around each entrypoint into<br />
AGESA vendorcode.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>UDK_VERSION</td><td>vendorcode/intel</td><td>int</td><td></td><td>
UEFI Development Kit version for Platform<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ARCH_ARMV8_EXTENSION</td><td>arch/arm64/armv8</td><td>int</td><td></td><td>
Specify ARMv8 extension, for example '1' for ARMv8.1, to control the<br />
'-march' option passed into the compiler. Defaults to 0 for vanilla<br />
ARMv8 but may be overridden in the SoC's Kconfig.<br />
<br />
All ARMv8 implementations are downwards-compatible, so this does not<br />
need to be changed unless specific features (e.g. new instructions)<br />
are used by the SoC's coreboot code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ARM64_BL31_EXTERNAL_FILE</td><td>arch/arm64</td><td>string</td><td>Path to external BL31.ELF (leave empty to build from source)</td><td>
The blob to use instead of building the Arm Trusted Firmware<br />
from tree. It is discouraged as compatibility with out-of-tree<br />
blobs may break anytime.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ARM64_SECURE_OS_FILE</td><td>arch/arm64</td><td>string</td><td>Secure OS binary file</td><td>
Secure OS binary file.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ARM64_A53_ERRATUM_843419</td><td>arch/arm64</td><td>bool</td><td></td><td>
Some early Cortex-A53 revisions had a hardware bug that results in<br />
incorrect address calculations in rare cases. This option enables a<br />
linker workaround to avoid those cases if your toolchain supports it.<br />
Should be selected automatically by SoCs that are affected.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RISCV_OPENSBI</td><td>arch/riscv</td><td>bool</td><td>Use OpenSBI to hand over control to payload</td><td>
Load OpenSBI after payload has been loaded and use it to<br />
provide the SBI and to handover control to payload.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>OPENSBI_PLATFORM</td><td>arch/riscv</td><td>string</td><td></td><td>
The OpenSBI platform to build for.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>OPENSBI_TEXT_START</td><td>arch/riscv</td><td>hex</td><td></td><td>
The linking address used to build opensbi.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ARCH_X86_64_PGTBL_LOC</td><td>arch/x86</td><td>hex</td><td>x86_64 page table location in CBFS</td><td>
The position where to place pagetables. Needs to be known at<br />
compile time. Must not overlap other files in CBFS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_MARCH_586</td><td>arch/x86</td><td>hex</td><td></td><td>
Allow a platform or processor to select to be compiled using<br />
the '-march=i586' option instead of the typical '-march=i686'<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RESET_VECTOR_IN_RAM</td><td>arch/x86</td><td>bool</td><td></td><td>
Select this option if the x86 processor's reset vector is in<br />
preinitialized DRAM instead of the traditional 0xfffffff0 location.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PRERAM_CBMEM_CONSOLE_SIZE</td><td>arch/x86</td><td>hex</td><td></td><td>
Increase this value if preram cbmem console is getting truncated<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_MCACHE_SIZE</td><td>arch/x86</td><td>hex</td><td></td><td>
Increase this value if you see CBFS mcache overflow warnings.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTBLOCK_DEBUG_SPINLOOP</td><td>arch/x86</td><td>bool</td><td></td><td>
Add a spin (JMP .) in bootblock_crt0.S during early bootblock to wait<br />
for a JTAG debugger to break into the execution sequence.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VERSTAGE_DEBUG_SPINLOOP</td><td>arch/x86</td><td>bool</td><td></td><td>
Add a spin (JMP .) in assembly_entry.S during early verstage to wait<br />
for a JTAG debugger to break into the execution sequence.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ROMSTAGE_DEBUG_SPINLOOP</td><td>arch/x86</td><td>bool</td><td></td><td>
Add a spin (JMP .) in assembly_entry.S during early romstage to wait<br />
for a JTAG debugger to break into the execution sequence.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SKIP_MAX_REBOOT_CNT_CLEAR</td><td>arch/x86</td><td>bool</td><td>Do not clear reboot count after successful boot</td><td>
Do not clear the reboot count immediately after successful boot.<br />
Set to allow the payload to control normal/fallback image recovery.<br />
Note that it is the responsibility of the payload to reset the<br />
normal boot bit to 1 after each successful boot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_BERT</td><td>arch/x86</td><td>bool</td><td></td><td>
Build an ACPI Boot Error Record Table.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COLLECT_TIMESTAMPS_NO_TSC</td><td>arch/x86</td><td>bool</td><td></td><td>
Use a non-TSC platform-dependent source for timestamps.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COLLECT_TIMESTAMPS_TSC</td><td>arch/x86</td><td>bool</td><td></td><td>
Use the TSC as the timestamp source.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAGING_IN_CACHE_AS_RAM</td><td>arch/x86</td><td>bool</td><td></td><td>
Chipsets scan select this option to preallocate area in cache-as-ram<br />
for storing paging data structures. PAE paging is currently the<br />
only thing being supported.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NUM_CAR_PAGE_TABLE_PAGES</td><td>arch/x86</td><td>int</td><td></td><td>
The number of 4KiB pages that should be pre-allocated for page tables.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAX_PIRQ_LINKS</td><td>arch/x86</td><td>int</td><td></td><td>
This variable specifies the number of PIRQ interrupt links which are<br />
routable. On most chipsets, this is 4, INTA through INTD. Some<br />
chipsets offer more than four links, commonly up to INTH. They may<br />
also have a separate link for ATA or IOAPIC interrupts. When the PIRQ<br />
table specifies links greater than 4, pirq_route_irqs will not<br />
function properly, unless this variable is correctly set.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAX_ACPI_TABLE_SIZE_KB</td><td>arch/x86</td><td>int</td><td></td><td>
Set the maximum size of all ACPI tables in KiB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHIPSET_DEVICETREE</td><td>toplevel</td><td>string</td><td></td><td>
This symbol allows a chipset to provide a set of default settings in<br />
a devicetree which are common to all mainboards. This may include<br />
devices (including alias names), chip drivers, register settings,<br />
and others. This path is relative to the src/ directory.<br />
<br />
Example: "chipset.cb"<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Devices</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_VGA_TEXT_FRAMEBUFFER</td><td>device</td><td>bool</td><td></td><td>
Selected by graphics drivers that support legacy VGA text mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_VBE_LINEAR_FRAMEBUFFER</td><td>device</td><td>bool</td><td></td><td>
Selected by graphics drivers that can set up a VBE linear-framebuffer<br />
mode.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_LINEAR_FRAMEBUFFER</td><td>device</td><td>bool</td><td></td><td>
Selected by graphics drivers that can set up a generic linear<br />
framebuffer.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_FSP_GOP</td><td>device</td><td>bool</td><td></td><td>
Selected by drivers that support to run a blob that implements<br />
the Graphics Output Protocol (GOP).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_NO_FSP_GOP</td><td>device</td><td>bool</td><td></td><td>
Selected by mainboards that do not have any graphics ports connected to the SoC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_NATIVE_VGA_INIT</td><td>device</td><td>bool</td><td></td><td>
Selected by mainboards / drivers that provide native graphics<br />
init within coreboot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_FORCE_NATIVE_VGA_INIT</td><td>device</td><td>bool</td><td></td><td>
Selected by mainboards / chipsets whose graphics driver can't or<br />
shouldn't be disabled.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_ROM_RUN_DEFAULT</td><td>device</td><td>bool</td><td></td><td>
Selected by mainboards whose graphics initialization depends on VGA OpROM.<br />
coreboot needs to load/execute legacy VGA OpROM in order to initialize GFX.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_LIBGFXINIT</td><td>device</td><td>bool</td><td></td><td>
Selected by mainboards that implement support for `libgfxinit`.<br />
Usually this requires a list of ports to be probed for displays.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_DO_NATIVE_VGA_INIT</td><td>device</td><td>bool</td><td>Use native graphics init</td><td>
Some mainboards, such as the Google Link, allow initializing the<br />
display without the need of a binary only VGA OPROM. Enabling this<br />
option may be faster, but also lacks flexibility in setting modes.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_USE_LIBGFXINIT</td><td>device</td><td>bool</td><td>Use libgfxinit</td><td>
Use the SPARK library `libgfxinit` for the native graphics<br />
initialization. This requires an Ada toolchain.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_ROM_RUN</td><td>device</td><td>bool</td><td>Run VGA Option ROMs</td><td>
Execute VGA Option ROMs in coreboot if found. This can be used<br />
to enable PCI/AGP/PCI-E video cards when not using a SeaBIOS<br />
payload.<br />
<br />
When using a SeaBIOS payload it runs all option ROMs with much<br />
more complete BIOS interrupt services available than coreboot,<br />
which some option ROMs require in order to function correctly.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RUN_FSP_GOP</td><td>device</td><td>bool</td><td>Run a GOP driver</td><td>
Some platforms (e.g. Intel Braswell and Skylake/Kaby Lake) support<br />
to run a GOP blob. This option enables graphics initialization with<br />
such a blob.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_GFX_INIT</td><td>device</td><td>bool</td><td>None</td><td>
Select this to not perform any graphics initialization in<br />
coreboot. This is useful if the payload (e.g. SeaBIOS) can<br />
initialize graphics or if pre-boot graphics are not required.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ONBOARD_VGA_IS_PRIMARY</td><td>device</td><td>bool</td><td>Use onboard VGA as primary video device</td><td>
This option lets you select which VGA device will be used<br />
to decode legacy VGA cycles. Not all chipsets implement this<br />
however. If not selected, the last adapter found will be used,<br />
else the onboard adapter is used.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>S3_VGA_ROM_RUN</td><td>device</td><td>bool</td><td>Re-run VGA Option ROMs on S3 resume</td><td>
Execute VGA Option ROMs in coreboot when resuming from S3 suspend.<br />
<br />
When using a SeaBIOS payload it runs all option ROMs with much<br />
more complete BIOS interrupt services available than coreboot,<br />
which some option ROMs require in order to function correctly.<br />
<br />
If unsure, say N when using SeaBIOS as payload, Y otherwise.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ALWAYS_LOAD_OPROM</td><td>device</td><td>bool</td><td></td><td>
Always load option ROMs if any are found. The decision to run<br />
the ROM is still determined at runtime, but the distinction<br />
between loading and not running comes into play for CHROMEOS.<br />
<br />
An example where this is required is that VBT (Video BIOS Tables)<br />
are needed for the kernel's display driver to know how a piece of<br />
hardware is configured to be used.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ALWAYS_RUN_OPROM</td><td>device</td><td>bool</td><td></td><td>
Always uncondtionally run the option regardless of other<br />
policies.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ON_DEVICE_ROM_LOAD</td><td>device</td><td>bool</td><td>Load Option ROMs on PCI devices</td><td>
Load Option ROMs stored on PCI/PCIe/AGP VGA devices in coreboot.<br />
<br />
If disabled, only Option ROMs stored in CBFS will be executed by<br />
coreboot. If you are concerned about security, you might want to<br />
disable this option, but it might leave your system in a state of<br />
degraded functionality.<br />
<br />
When using a SeaBIOS payload it runs all option ROMs with much<br />
more complete BIOS interrupt services available than coreboot,<br />
which some option ROMs require in order to function correctly.<br />
<br />
If unsure, say N when using SeaBIOS as payload, Y otherwise.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCI_OPTION_ROM_RUN_REALMODE</td><td>device</td><td>bool</td><td>Native mode</td><td>
If you select this option, PCI Option ROMs will be executed<br />
natively on the CPU in real mode. No CPU emulation is involved,<br />
so this is the fastest, but also the least secure option.<br />
(only works on x86/x64 systems)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCI_OPTION_ROM_RUN_YABEL</td><td>device</td><td>bool</td><td>Secure mode</td><td>
If you select this option, the x86emu CPU emulator will be used to<br />
execute PCI Option ROMs.<br />
<br />
This option prevents Option ROMs from doing dirty tricks with the<br />
system (such as installing SMM modules or hypervisors), but it is<br />
also significantly slower than the native Option ROM initialization<br />
method.<br />
<br />
This is the default choice for non-x86 systems.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABEL_PCI_ACCESS_OTHER_DEVICES</td><td>device</td><td>bool</td><td>Allow Option ROMs to access other devices</td><td>
Per default, YABEL only allows Option ROMs to access the PCI device<br />
that they are associated with. However, this causes trouble for some<br />
onboard graphics chips whose Option ROM needs to reconfigure the<br />
north bridge.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG</td><td>device</td><td>bool</td><td>Fake success on writing other device's config space</td><td>
By default, YABEL aborts when the Option ROM tries to write to other<br />
devices' config spaces. With this option enabled, the write doesn't<br />
follow through, but the Option ROM is allowed to go on.<br />
This can create issues such as hanging Option ROMs (if it depends on<br />
that other register changing to the written value), so test for<br />
impact before using this option.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABEL_VIRTMEM_LOCATION</td><td>device</td><td>hex</td><td>Location of YABEL's virtual memory</td><td>
YABEL requires 1MB memory for its CPU emulation. This memory is<br />
normally located at 16MB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABEL_DIRECTHW</td><td>device</td><td>bool</td><td>Direct hardware access</td><td>
YABEL consists of two parts: It uses x86emu for the CPU emulation and<br />
additionally provides a PC system emulation that filters bad device<br />
and memory access (such as PCI config space access to other devices<br />
than the initialized one).<br />
<br />
When choosing this option, x86emu will pass through all hardware<br />
accesses to memory and I/O devices to the underlying memory and I/O<br />
addresses. While this option prevents Option ROMs from doing dirty<br />
tricks with the CPU (such as installing SMM modules or hypervisors),<br />
they can still access all devices in the system.<br />
Enable this option for a good compromise between security and speed.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Display</td></tr>
<tr bgcolor="#eeeeee">
<td>FRAMEBUFFER_SET_VESA_MODE</td><td>device</td><td>bool</td><td>Set framebuffer graphics resolution</td><td>
Set VESA/native framebuffer mode (needed for bootsplash and graphical framebuffer console)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FRAMEBUFFER_SET_VESA_MODE</td><td>device</td><td>bool</td><td>framebuffer graphics resolution</td><td>
This option sets the resolution used for the coreboot framebuffer (and<br />
bootsplash screen).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_TEXT_FRAMEBUFFER</td><td>device</td><td>bool</td><td>Legacy VGA text mode</td><td>
If this option is enabled, coreboot will initialize graphics in<br />
legacy VGA text mode or, if a VGA BIOS is used and a VESA mode set,<br />
switch to text mode before handing control to a payload.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBE_LINEAR_FRAMEBUFFER</td><td>device</td><td>bool</td><td>VESA framebuffer</td><td>
This option keeps the framebuffer mode set after coreboot finishes<br />
execution. If this option is enabled, coreboot will pass a<br />
framebuffer entry in its coreboot table and the payload will need a<br />
compatible driver.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GENERIC_LINEAR_FRAMEBUFFER</td><td>device</td><td>bool</td><td>Linear \"high-resolution\" framebuffer</td><td>
This option enables a high-resolution, linear framebuffer. If this<br />
option is enabled, coreboot will pass a framebuffer entry in its<br />
coreboot table and the payload will need a compatible driver.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTSPLASH</td><td>device</td><td>bool</td><td>Show graphical bootsplash</td><td>
This option shows a graphical bootsplash screen. The graphics are<br />
loaded from the CBFS file bootsplash.jpg.<br />
<br />
You can either specify the location and file name of the<br />
image in the 'General' section or add it manually to CBFS, using,<br />
for example, cbfstool.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINEAR_FRAMEBUFFER_MAX_WIDTH</td><td>device</td><td>int</td><td>Maximum width in pixels</td><td>
Set the maximum width of the framebuffer. This may help with<br />
default fonts too tiny for high-resolution displays.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINEAR_FRAMEBUFFER_MAX_HEIGHT</td><td>device</td><td>int</td><td>Maximum height in pixels</td><td>
Set the maximum height of the framebuffer. This may help with<br />
default fonts too tiny for high-resolution displays.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>PCI_ALLOW_BUS_MASTER</td><td>device</td><td>bool</td><td>Allow coreboot to set optional PCI bus master bits</td><td>
For security reasons, bus mastering should be enabled as late as<br />
possible. In coreboot, it's usually not necessary and payloads<br />
should only enable it for devices they use. Since not all payloads<br />
enable bus mastering properly yet, this option gives some sort of<br />
"backwards compatibility" and is enabled by default to keep the<br />
traditional behaviour for now. This is currently necessary, for<br />
instance, for libpayload based payloads as the drivers don't enable<br />
bus mastering for PCI bridges.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCI_SET_BUS_MASTER_PCI_BRIDGES</td><td>device</td><td>bool</td><td>PCI bridges</td><td>
Let coreboot configure bus mastering for PCI bridges. Enabling bus<br />
mastering for a PCI bridge also allows it to forward requests from<br />
downstream devices. Currently, payloads ignore this and only enable<br />
bus mastering for the downstream device. Hence, this option is needed<br />
for compatibility until payloads are fixed.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCI_ALLOW_BUS_MASTER_ANY_DEVICE</td><td>device</td><td>bool</td><td>Any devices</td><td>
Allow coreboot to enable PCI bus mastering for any device. The actual<br />
selection of devices depends on the various PCI drivers in coreboot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_COMMON_CLOCK</td><td>device</td><td>bool</td><td>Enable PCIe Common Clock</td><td>
Detect and enable Common Clock on PCIe links.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_ASPM</td><td>device</td><td>bool</td><td>Enable PCIe ASPM</td><td>
Detect and enable ASPM (Active State Power Management) on PCIe links.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_CLK_PM</td><td>device</td><td>bool</td><td>Enable PCIe Clock Power Management</td><td>
Detect and enable Clock Power Management on PCIe.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_L1_SUB_STATE</td><td>device</td><td>bool</td><td>Enable PCIe ASPM L1 SubState</td><td>
Detect and enable ASPM on PCIe links.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_HOTPLUG</td><td>device</td><td>bool</td><td>Enable PCIe Hotplug Support</td><td>
Allocate resources for PCIe hotplug bridges<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_HOTPLUG_BUSES</td><td>device</td><td>int</td><td>PCI Express Hotplug Buses</td><td>
This is the number of buses allocated for hotplug PCI express<br />
bridges, for use by hotplugged child devices. The default is 32<br />
buses.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_HOTPLUG_MEM</td><td>device</td><td>hex</td><td>PCI Express Hotplug Memory</td><td>
This is the amount of memory space, in bytes, to allocate to<br />
hotplug PCI express bridges, for use by hotplugged child devices.<br />
This size should be page-aligned. The default is 8 MiB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_HOTPLUG_PREFETCH_MEM</td><td>device</td><td>hex</td><td>PCI Express Hotplug Prefetch Memory</td><td>
This is the amount of pre-fetchable memory space, in bytes, to<br />
allocate to hot-plug PCI express bridges, for use by hotplugged<br />
child devices. This size should be page-aligned. The default is<br />
256 MiB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_HOTPLUG_PREFETCH_MEM_ABOVE_4G</td><td>device</td><td>bool</td><td></td><td>
This enables prefetch memory allocation above 4G boundary for the<br />
hotplug resources.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_HOTPLUG_PREFETCH_MEM_BELOW_4G</td><td>device</td><td>bool</td><td>PCI Express Hotplug Prefetch Memory Allocation below 4G boundary</td><td>
This enables prefetch memory allocation below 4G boundary for the<br />
hotplug resources.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PCIEXP_HOTPLUG_IO</td><td>device</td><td>hex</td><td>PCI Express Hotplug I/O Space</td><td>
This is the amount of I/O space to allocate to hot-plug PCI<br />
express bridges, for use by hotplugged child devices. The default<br />
is 8 KiB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EARLY_PCI_BRIDGE</td><td>device</td><td>bool</td><td>Early PCI bridge</td><td>
While coreboot is executing code from ROM, the coreboot resource<br />
allocator has not been running yet. Hence PCI devices living behind<br />
a bridge are not yet visible to the system.<br />
<br />
This option enables static configuration for a single pre-defined<br />
PCI bridge function on bus 0.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUBSYSTEM_VENDOR_ID</td><td>device</td><td>hex</td><td>Override PCI Subsystem Vendor ID</td><td>
This config option will override the devicetree settings for<br />
PCI Subsystem Vendor ID.<br />
<br />
Note: This option is not meant for a board's Kconfig; use the<br />
devicetree setting `subsystemid` instead.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SUBSYSTEM_DEVICE_ID</td><td>device</td><td>hex</td><td>Override PCI Subsystem Device ID</td><td>
This config option will override the devicetree settings for<br />
PCI Subsystem Device ID.<br />
<br />
Note: This option is not meant for a board's Kconfig; use the<br />
devicetree setting `subsystemid` instead.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS</td><td>device</td><td>bool</td><td>Add a VGA BIOS image</td><td>
Select this option if you have a VGA BIOS image that you would<br />
like to add to your ROM.<br />
<br />
You will be able to specify the location and file name of the<br />
image later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_FILE</td><td>device</td><td>string</td><td>VGA BIOS path and filename</td><td>
The path and filename of the file to use as VGA BIOS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_ID</td><td>device</td><td>string</td><td>VGA device PCI IDs</td><td>
The comma-separated PCI vendor and device ID with optional revision if that<br />
feature is enabled that would associate your vBIOS to your video card.<br />
<br />
Example: 1106,3230 or 1106,3230,a3<br />
<br />
In the above example 1106 is the PCI vendor ID (in hex, but without<br />
the "0x" prefix) and 3230 specifies the PCI device ID of the<br />
video card (also in hex, without "0x" prefix). a3 specifies the revision.<br />
<br />
Under GNU/Linux you can run `lspci -nn` to list the IDs of your PCI devices.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_SECOND</td><td>device</td><td>bool</td><td>Add a 2nd video BIOS image</td><td>
Select this option if you have a 2nd video BIOS image that you would<br />
like to add to your ROM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_SECOND_FILE</td><td>device</td><td>string</td><td>2nd video BIOS path and filename</td><td>
The path and filename of the file to use as video BIOS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_SECOND_ID</td><td>device</td><td>string</td><td>Graphics device PCI IDs</td><td>
The comma-separated PCI vendor and device ID with optional revision if that<br />
feature is enabled that would associate your vBIOS to your video card.<br />
<br />
Example: 1106,3230 or 1106,3230,a3<br />
<br />
In the above example 1106 is the PCI vendor ID (in hex, but without<br />
the "0x" prefix) and 3230 specifies the PCI device ID of the<br />
video card (also in hex, without "0x" prefix). a3 specifies the revision.<br />
<br />
Under GNU/Linux you can run `lspci -nn` to list the IDs of your PCI devices.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHECK_REV_IN_OPROM_NAME</td><td>device</td><td>string</td><td></td><td>
Select this in the platform BIOS or chipset if the option rom has a revision<br />
that needs to be checked when searching CBFS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_DGPU</td><td>device</td><td>bool</td><td>Add a discrete VGA BIOS image</td><td>
Select this option if you have a VGA BIOS image for discrete GPU<br />
that you would like to add to your ROM.<br />
<br />
You will be able to specify the location and file name of the<br />
image later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_DGPU_FILE</td><td>device</td><td>string</td><td>Discrete VGA BIOS path and filename</td><td>
The path and filename of the file to use as VGA BIOS for discrete GPU.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA_BIOS_DGPU_ID</td><td>device</td><td>string</td><td>Discrete VGA device PCI IDs</td><td>
The comma-separated PCI vendor and device ID that would associate<br />
your VGA BIOS to your discrete video card.<br />
<br />
Examples:<br />
1002,6663 for HD 8570M<br />
1002,6665 for R5 M230<br />
<br />
In the above examples 1002 is the PCI vendor ID (in hex, but without<br />
the "0x" prefix) and 6663 / 6665 specifies the PCI device ID of the<br />
discrete video card (also in hex, without "0x" prefix).<br />
<br />
Under GNU/Linux you can run `lspci -nn` to list the IDs of your PCI devices.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_GMA_HAVE_VBT</td><td>device</td><td>bool</td><td></td><td>
Select this in the mainboard Kconfig to indicate the board has<br />
a data.vbt file.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_GMA_ADD_VBT</td><td>device</td><td>bool</td><td>Add a Video BIOS Table (VBT) binary to CBFS</td><td>
Add a VBT data file to CBFS. The VBT describes the integrated<br />
GPU and connections, and is needed by the GOP driver integrated into<br />
FSP and the OS driver in order to initialize the display.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_GMA_VBT_FILE</td><td>device</td><td>string</td><td>VBT binary path and filename</td><td>
The path and filename of the VBT binary.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOFTWARE_I2C</td><td>device</td><td>bool</td><td>Enable I2C controller emulation in software</td><td>
This config option will enable code to override the i2c_transfer<br />
routine with a (simple) software emulation of the protocol. This may<br />
be useful for debugging or on platforms where a driver for the real<br />
I2C controller is not (yet) available. The platform code needs to<br />
provide bindings to manually toggle I2C lines.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RESOURCE_ALLOCATOR_V3</td><td>device</td><td>bool</td><td></td><td>
This config option enables resource allocator v3 which performs<br />
top down allocation of resources in a single MMIO window. This is the<br />
old resource allocator meant to be used only until the broken AMD<br />
chipsets are fixed. DO NOT USE THIS FOR ANY NEW CHIPSETS!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RESOURCE_ALLOCATOR_V4</td><td>device</td><td>bool</td><td></td><td>
This config option enables resource allocator v4 which uses multiple<br />
ranges for allocating resources. This allows allocation of resources<br />
above 4G boundary as well.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>XHCI_UTILS</td><td>device</td><td>bool</td><td></td><td>
Provides xHCI utility functions.<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Generic Drivers</td></tr>
<tr bgcolor="#eeeeee">
<td>CACHE_MRC_SETTINGS</td><td>drivers/mrc_cache</td><td>bool</td><td></td><td>
Save cached MRC settings<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_WRITE_NV_LATE</td><td>drivers/mrc_cache</td><td>bool</td><td></td><td>
MRC settings are normally written to NVRAM at BS_DEV_ENUMERATE-EXIT.<br />
If a platform requires MRC settings written to NVRAM later than<br />
normal, select this item.  This will cause the write to occur at<br />
BS_OS_RESUME_CHECK-ENTRY.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_STASH_TO_CBMEM</td><td>drivers/mrc_cache</td><td>bool</td><td></td><td>
Instead of writing back MRC_CACHE training data back to the<br />
MRC_CACHE right away, stash the data into cbmem.  This data<br />
will be written back later to MRC_CACHE.  This is selected<br />
for platforms which either do not support writes to SPI<br />
flash in early stages<br />
(BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES) or the platforms<br />
that need to write back the MRC data in late ramstage boot<br />
states (MRC_WRITE_NV_LATE).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MRC_SAVE_HASH_IN_TPM</td><td>drivers/mrc_cache</td><td>bool</td><td>Save a hash of the MRC_CACHE data in TPM NVRAM</td><td>
Store a hash of the MRC_CACHE training data in a TPM NVRAM<br />
space to ensure that it cannot be tampered with.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMMON_CBFS_SPI_WRAPPER</td><td>drivers/spi</td><td>bool</td><td></td><td>
Use common wrapper to interface CBFS to SPI bootrom.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_SDCARD</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI sdcard.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_BUS</td><td>drivers/spi</td><td>int</td><td></td><td>
Which SPI bus the boot device is connected to.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_RW_NOMMAP</td><td>drivers/spi</td><td>bool</td><td></td><td>
Provide common implementation of the RW boot device that<br />
doesn't provide mmap() operations.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES</td><td>drivers/spi</td><td>bool</td><td></td><td>
For platforms who do not allow writes to SPI flash in early<br />
stages like romstage.  Not selecting this config will result<br />
in the auto-selection of<br />
BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY if<br />
BOOT_DEVICE_SPI_FLASH_RW_NOMMAP is selected by the platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY</td><td>drivers/spi</td><td>bool</td><td></td><td>
Include the common implementation in all stages, including the<br />
early ones.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_SMM</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if you want SPI flash support in SMM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_NO_FAST_READ</td><td>drivers/spi</td><td>bool</td><td>Disable Fast Read command</td><td>
Select this option if your setup requires to avoid "fast read"s<br />
from the SPI flash parts.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_ADESTO</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Adesto Technologies.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_AMIC</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by AMIC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_ATMEL</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Atmel.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_EON</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by EON.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_GIGADEVICE</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Gigadevice.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_MACRONIX</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Macronix.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_SPANSION</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Spansion.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_SST</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by SST.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_STMICRO</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by ST MICRO.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_WINBOND</td><td>drivers/spi</td><td>bool</td><td></td><td>
Select this option if your chipset driver needs to store certain<br />
data in the SPI flash and your SPI flash is made by Winbond.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_FLASH_HAS_VOLATILE_GROUP</td><td>drivers/spi</td><td>bool</td><td></td><td>
Allows chipset to group write/erase operations under a single volatile<br />
group.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>REALTEK_8168_RESET</td><td>drivers/net</td><td>bool</td><td></td><td>
This forces a realtek 10ec:8168 card to reset to ensure power state<br />
is correct at boot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>REALTEK_8168_MACADDRESS</td><td>drivers/net</td><td>string</td><td>Realtek rt8168 mac address</td><td>
This is a string to set the mac address on a Realtek rt8168 card.<br />
It must be in the form  of "xx:xx:xx:xx:xx:xx", where x is a<br />
hexadecimal number for it to be valid. Failing to do so will<br />
result in the default macaddress being used.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RT8168_SUPPORT_LEGACY_VPD_MAC</td><td>drivers/net</td><td>bool</td><td></td><td>
Previously VPD expected that device_indexes set to zero were<br />
special cased. Selecting this Kconfig restores the legacy<br />
VPD format and behaviour. If unsure, you likely do not need this!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RT8168_SET_LED_MODE</td><td>drivers/net</td><td>bool</td><td></td><td>
This is to set a customized LED mode to distinguish 10/100/1000<br />
link and speed status with limited LEDs avaiable on a board.<br />
Please refer to RTL811x datasheet section 7.2 Customizable LED<br />
Configuration for details. With this flag enabled, the<br />
customized_leds variable will be read from devicetree setting.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ATHEROS_ATL1E_SETMAC</td><td>drivers/net</td><td>bool</td><td></td><td>
This sets the MAC address on boards featuring the atheros 1968:1026<br />
NIC which lack an eeprom to store it.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ATHEROS_ATL1E_MACADDRESS</td><td>drivers/net</td><td>string</td><td>Atheros AR8121/AR8113/AR8114 mac address</td><td>
This is a string to set the mac address on an Atheros atl1e card.<br />
It must be in the form  of "xx:xx:xx:xx:xx:xx", where x is a<br />
hexadecimal number for it to be valid. Failing to do so will<br />
result in the default MAC address being used.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_INIT</td><td>drivers/tpm</td><td>bool</td><td></td><td>
This driver automatically initializes the TPM if vboot is not used.<br />
The TPM driver init is done during the ramstage chip init phase.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_PPI</td><td>drivers/tpm</td><td>bool</td><td>Generate ACPI code to implement TPM physical presence interface</td><td>
This driver automatically generates ACPI tables for the Physical<br />
Presence Interface defined by the TCG. If not activated only a stub<br />
will be generated without any functionality.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>GIC</td><td>drivers/gic</td><td>None</td><td></td><td>
This option enables GIC support, the ARM generic interrupt controller.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>VPD</td><td>drivers/vpd</td><td>bool</td><td>Support for Vital Product Data tables</td><td>
Enable support for flash based vital product data.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VPD_FMAP_NAME</td><td>drivers/vpd</td><td>string</td><td></td><td>
Name of the FMAP region created in the default FMAP to store VPD tables.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VPD_FMAP_SIZE</td><td>drivers/vpd</td><td>hex</td><td></td><td>
Size in bytes of the FMAP region created to store VPD tables.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DIGITIZER_AUTODETECT</td><td>drivers/lenovo</td><td>bool</td><td>Autodetect</td><td>
The presence of digitizer is inferred from model number stored in<br />
AT24RF chip.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DIGITIZER_PRESENT</td><td>drivers/lenovo</td><td>bool</td><td>Present</td><td>
The digitizer is assumed to be present.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DIGITIZER_ABSENT</td><td>drivers/lenovo</td><td>bool</td><td>Absent</td><td>
The digitizer is assumed to be absent.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG</td><td>drivers/usb</td><td>bool</td><td>USB 2.0 EHCI debug dongle support</td><td>
This option allows you to use a so-called USB EHCI Debug device<br />
(such as the Ajays NET20DC, AMIDebug RX, or a system using the<br />
Linux "EHCI Debug Device gadget" driver found in recent kernel)<br />
to retrieve the coreboot debug messages (instead, or in addition<br />
to, a serial port).<br />
<br />
This feature is NOT supported on all chipsets in coreboot!<br />
<br />
It also requires a USB2 controller which supports the EHCI<br />
Debug Port capability.<br />
<br />
See https://www.coreboot.org/EHCI_Debug_Port for an up-to-date list<br />
of supported controllers.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG_IN_PRE_RAM</td><td>drivers/usb</td><td>bool</td><td>Enable early (pre-RAM) usbdebug</td><td>
Configuring USB controllers in system-agent binary may cause<br />
problems to usbdebug. Disabling this option delays usbdebug to<br />
be setup on entry to ramstage.<br />
<br />
If unsure, say Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG_HCD_INDEX</td><td>drivers/usb</td><td>int</td><td>Index for EHCI controller to use with usbdebug</td><td>
Some boards have multiple EHCI controllers with possibly only<br />
one having the Debug Port capability on an external USB port.<br />
<br />
Mapping of this index to PCI device functions is southbridge<br />
specific and mainboard level Kconfig should already provide<br />
a working default value here.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG_DEFAULT_PORT</td><td>drivers/usb</td><td>int</td><td>Default USB port to use as Debug Port</td><td>
Selects which physical USB port usbdebug dongle is connected to.<br />
Setting of 0 means to scan possible ports starting from 1.<br />
<br />
Intel platforms have hardwired the debug port location and this<br />
setting makes no difference there.<br />
<br />
Hence, if you select the correct port here, you can speed up<br />
your boot time. Which USB port number refers to which actual<br />
port on your mainboard (potentially also USB pin headers on<br />
your mainboard) is highly board-specific, and you'll likely<br />
have to find out by trial-and-error.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG_DONGLE_STD</td><td>drivers/usb</td><td>bool</td><td>USB gadget driver or Net20DC</td><td>
Net20DC, BeagleBone Black, Raspberry Pi Zero W<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG_DONGLE_BEAGLEBONE</td><td>drivers/usb</td><td>bool</td><td>BeagleBone (not BeagleBone Black)</td><td>
Use this to configure the USB hub on BeagleBone board.<br />
Do NOT select this for the BeagleBone Black.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG_DONGLE_FTDI_FT232H</td><td>drivers/usb</td><td>bool</td><td>FTDI FT232H UART</td><td>
Use this with FT232H usb-to-uart. Configuration is hard-coded<br />
to use 8n1, no flow control.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USBDEBUG_DONGLE_FTDI_FT232H_BAUD</td><td>drivers/usb</td><td>int</td><td>FTDI FT232H baud rate</td><td>
Select baud rate for FT232H in the range 733..12,000,000. Make<br />
sure that your receiving side supports the same setting and your<br />
connection works with it. Multiples of 115,200 seem to be a good<br />
choice, and EHCI debug usually can't saturate more than 576,000.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMMSTORE_V2</td><td>drivers/smmstore</td><td>bool</td><td>Use version 2 of SMMSTORE API</td><td>
Version 2 of SMMSTORE allows secure communication with SMM and<br />
makes no assumptions on the structure of the data stored within.<br />
It splits the store into chunks to allows fault tolerant writes.<br />
<br />
By using version 2 you cannot make use of software that expects<br />
a version 1 SMMSTORE.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMMSTORE_IN_CBFS</td><td>drivers/smmstore</td><td>bool</td><td></td><td>
Select this if you want to add an SMMSTORE region to a<br />
cbfsfile in a cbfs FMAP region<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SMMSTORE_SIZE</td><td>drivers/smmstore</td><td>hex</td><td>size of the SMMSTORE FMAP region</td><td>
Sets the size of the default SMMSTORE FMAP region.<br />
If using an UEFI payload, note that UEFI specifies at least 64K.<br />
The current implementation of SMMSTORE is append only, so until<br />
garbage collection is implemented it is better to set this to<br />
a rather large value.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CRB_TPM</td><td>drivers/crb</td><td>bool</td><td></td><td>
CRB TPM driver is enabled!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CRB_TPM_BASE_ADDRESS</td><td>drivers/crb</td><td>hex</td><td></td><td>
Base Address of the CRB TPM Command Structure<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_CRB_TPM</td><td>drivers/crb</td><td>bool</td><td></td><td>
Mainboard has Command Response Buffer support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPMI_KCS_REGISTER_SPACING</td><td>drivers/ipmi</td><td>int</td><td></td><td>
KCS status and command register IO port address spacing<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPMI_FRU_SINGLE_RW_SZ</td><td>drivers/ipmi</td><td>int</td><td></td><td>
The data size in a single IPMI FRU read/write command.<br />
IPMB messages are limited to 32-bytes total. When the<br />
data size is larger than this value, IPMI can complete<br />
reading/writing the data over multiple commands.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPMI_KCS_ROMSTAGE</td><td>drivers/ipmi</td><td>bool</td><td></td><td>
IPMI KCS support in romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BMC_KCS_BASE</td><td>drivers/ipmi</td><td>hex</td><td></td><td>
The PNP base address of BMC KCS. It must be equal to the<br />
pnp port value defined in devicetree for chip drivers/ipmi.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPMI_KCS_TIMEOUT_MS</td><td>drivers/ipmi</td><td>int</td><td></td><td>
The time unit is millisecond for each IPMI KCS transfer.<br />
IPMI spec v2.0 rev 1.1 Sec. 9.15, a five-second timeout or<br />
greater is recommended.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_IPMI_SUPERMICRO_OEM</td><td>drivers/ipmi</td><td>bool</td><td>Supermicro IPMI OEM BMC support</td><td>
Tested on X11SSH only. Different BMCs might not support these OEM<br />
commands.<br />
The following features are implemented:<br />
* Communicates the BIOS version to the BMC<br />
* Communicates the BIOS date to the BMC<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>UART_OVERRIDE_INPUT_CLOCK_DIVIDER</td><td>drivers/uart</td><td>bool</td><td></td><td>
Set to "y" when the platform overrides the uart_input_clock_divider<br />
routine.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UART_OVERRIDE_REFCLK</td><td>drivers/uart</td><td>bool</td><td></td><td>
Set to "y" when the platform overrides the uart_platform_refclk<br />
routine.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_UART_OXPCIE</td><td>drivers/uart</td><td>bool</td><td>Oxford OXPCIe952</td><td>
Support for Oxford OXPCIe952 serial port PCIe cards.<br />
Currently only devices with the vendor ID 0x1415 and device ID<br />
0xc158 or 0xc11b will work.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UART_USE_REFCLK_AS_INPUT_CLOCK</td><td>drivers/uart</td><td>bool</td><td></td><td>
Use uart_platform_refclk to specify the input clock value.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UART_PCI_ADDR</td><td>drivers/uart</td><td>hex</td><td>UART's PCI bus, device, function address</td><td>
Specify zero if the UART is connected to another bus type.<br />
For PCI based UARTs, build the value as:<br />
* 1 &lt;&lt; 31 - Valid bit, PCI UART in use<br />
* Bus &lt;&lt; 20<br />
* Device &lt;&lt; 15<br />
* Function &lt;&lt; 12<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>ELOG</td><td>drivers/elog</td><td>bool</td><td>Support for flash based event log</td><td>
Enable support for flash based event logging.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ELOG_CBMEM</td><td>drivers/elog</td><td>bool</td><td>Store a copy of ELOG in CBMEM</td><td>
This option will have ELOG store a copy of the flash event log<br />
in a CBMEM region and export that address in SMBIOS to the OS.<br />
This is useful if the ELOG location is not in memory mapped flash,<br />
but it means that events added at runtime via the SMI handler<br />
will not be reflected in the CBMEM copy of the log.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ELOG_GSMI</td><td>drivers/elog</td><td>bool</td><td>SMI interface to write and clear event log</td><td>
This interface is compatible with the linux kernel driver<br />
available with CONFIG_GOOGLE_GSMI and can be used to write<br />
kernel reset/shutdown messages to the event log.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ELOG_BOOT_COUNT</td><td>drivers/elog</td><td>bool</td><td>Maintain a monotonic boot number in CMOS</td><td>
Store a monotonic boot number in CMOS and provide an interface<br />
to read the current value and increment the counter.  This boot<br />
counter will be logged as part of the System Boot event.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ELOG_BOOT_COUNT_CMOS_OFFSET</td><td>drivers/elog</td><td>int</td><td>Offset in CMOS to store the boot count</td><td>
This value must be greater than 16 bytes so as not to interfere<br />
with the standard RTC region.  Requires 8 bytes.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CHROMEOS_CAMERA</td><td>drivers/camera</td><td>bool</td><td></td><td>
Camera with identifiers following Chrome OS Camera Info. The info is<br />
usually available on MIPI camera EEPROM for identifying correct<br />
drivers and config.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>OCP_DMI</td><td>drivers/ocp/dmi</td><td>bool</td><td></td><td>
It implements the SMBIOS IPMI FRU mapping table defined in<br />
https://www.opencompute.org/documents/facebook-xeon-motherboard-v31<br />
22.3 SMBIOS FRU mapping table<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVER_PARADE_PS8625</td><td>drivers/parade/ps8625</td><td>bool</td><td></td><td>
Parade ps8625 display port to lvds bridge<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVER_PARADE_PS8640</td><td>drivers/parade/ps8640</td><td>bool</td><td></td><td>
Parade PS8640 MIPI DSI to eDP Converter<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPI_TPM</td><td>drivers/spi/tpm</td><td>bool</td><td></td><td>
SPI TPM driver is enabled!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_SPI_TPM_CR50</td><td>drivers/spi/tpm</td><td>bool</td><td></td><td>
Board has a CR50 SPI TPM<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_SPI_TPM</td><td>drivers/spi/tpm</td><td>bool</td><td></td><td>
Board has SPI TPM support<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_EMULATION_QEMU_BOCHS</td><td>drivers/emulation/qemu</td><td>bool</td><td>bochs dispi interface vga driver</td><td>
VGA driver for qemu emulated vga cards supporting<br />
the bochs dispi interface.  This includes<br />
standard vga, vmware svga and qxl.  The default<br />
vga (cirrus) is *not* supported, so you have to<br />
pick another one explicitly via 'qemu -vga $card'.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_SX9310</td><td>drivers/i2c/sx9310</td><td>bool</td><td></td><td>
Board has a Semtech SX9310 proximity sensor.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_PCA9538</td><td>drivers/i2c/pca9538</td><td>bool</td><td></td><td>
Enable support for I2C I/O expander PCA9538.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_PTN3460</td><td>drivers/i2c/ptn3460</td><td>bool</td><td></td><td>
Enable support for external display bridge (eDP to LVDS) PTN3460.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_GPIO_MUX</td><td>drivers/i2c/gpiomux</td><td>bool</td><td></td><td>
When enabled, add identifiers in ACPI tables for GPIO based I2C multiplexer.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_NCT7802Y</td><td>drivers/i2c/nct7802y</td><td>bool</td><td></td><td>
The NCT7802Y by Nuvoton is a Hardware Monitoring IC.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>I2C_TPM</td><td>drivers/i2c/tpm</td><td>bool</td><td></td><td>
I2C TPM driver is enabled!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_I2C_TPM_ATMEL</td><td>drivers/i2c/tpm</td><td>bool</td><td></td><td>
Board has an Atmel I2C TPM support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_I2C_TPM_CR50</td><td>drivers/i2c/tpm</td><td>bool</td><td></td><td>
Board has a Cr50 I2C TPM support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_I2C_TPM_GENERIC</td><td>drivers/i2c/tpm</td><td>bool</td><td></td><td>
Board has a generic I2C TPM support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_LM96000</td><td>drivers/i2c/lm96000</td><td>bool</td><td></td><td>
Hardware-monitoring IC LM96000.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_DESIGNWARE</td><td>drivers/i2c/designware</td><td>bool</td><td></td><td>
Designware I2C support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ</td><td>drivers/i2c/designware</td><td>int</td><td></td><td>
The i2c ip block's clock.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_SX9324</td><td>drivers/i2c/sx9324</td><td>bool</td><td></td><td>
Board has a Semtech SX9324 proximity sensor.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_RTD2132</td><td>drivers/i2c/rtd2132</td><td>bool</td><td></td><td>
Enable support for Realtek RTD2132 DisplayPort to LVDS bridge chip.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_I2C_RX6110SA</td><td>drivers/i2c/rx6110sa</td><td>bool</td><td></td><td>
Enable support for external RTC chip RX6110 SA.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_WIFI_GENERIC</td><td>drivers/wifi/generic</td><td>bool</td><td></td><td>
When enabled, add identifiers in ACPI tables that are common<br />
to WiFi chipsets from multiple vendors.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_INTEL_WIFI</td><td>drivers/wifi/generic</td><td>bool</td><td>Support Intel PCI-e WiFi adapters</td><td>
When enabled, add identifiers in ACPI and SMBIOS tables to<br />
make OS drivers work with certain Intel PCI-e WiFi chipsets.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_SAR</td><td>drivers/wifi/generic</td><td>bool</td><td></td><td>
Enable it when wifi driver uses SAR configuration feature.<br />
VPD entry "wifi_sar" is read to get SAR settings, if its<br />
not found driver may look into CBFS for default settigs.<br />
WIFI_SAR_CBFS is option to enable CBFS lookup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>WIFI_SAR_CBFS</td><td>drivers/wifi/generic</td><td>bool</td><td>Enable SAR table addition to CBFS</td><td>
wifi driver would look for "wifi_sar" vpd key and load SAR settings from<br />
it, if the vpd key is not found then the driver tries to look for sar<br />
settings from CBFS with file name wifi_sar_defaults.hex.<br />
So OEM/ODM can override wifi sar with VPD.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DSAR_SET_NUM</td><td>drivers/wifi/generic</td><td>hex</td><td>Number of SAR sets when D-SAR is enabled</td><td>
There can be up to 3 optional SAR table sets.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_TI_SN65DSI86BRIDGE</td><td>drivers/ti/sn65dsi86bridge</td><td>bool</td><td></td><td>
TI SN65DSI86 eDP bridge driver<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVER_TI_TPS65090</td><td>drivers/ti/tps65090</td><td>bool</td><td></td><td>
TI TPS65090<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_USB_PCI_XHCI</td><td>drivers/usb/pci_xhci</td><td>None</td><td></td><td>
PCI driver that generates ACPI nodes for an xHCI compatible controller.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_HAS_LPC_TPM</td><td>drivers/pc80/tpm</td><td>bool</td><td></td><td>
Board has LPC TPM support<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_TIS_BASE_ADDRESS</td><td>drivers/pc80/tpm</td><td>hex</td><td></td><td>
This can be used to adjust the TPM memory base address.<br />
The default is specified by the TCG PC Client Specific TPM<br />
Interface Specification 1.2 and should not be changed unless<br />
the TPM being used does not conform to TPM TIS 1.2.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_PIRQ</td><td>drivers/pc80/tpm</td><td>hex</td><td></td><td>
This can be used to specify a PIRQ to use instead of SERIRQ,<br />
which is needed for SPI TPM interrupt support on x86.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VGA</td><td>drivers/pc80/vga</td><td>bool</td><td></td><td>
Include legacy VGA support code.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_PS2_KEYBOARD</td><td>drivers/pc80/pc</td><td>bool</td><td>PS/2 keyboard init</td><td>
Enable this option to initialize PS/2 keyboards found connected<br />
to the PS/2 port.<br />
<br />
Some payloads (eg, filo) require this option.  Other payloads<br />
(eg, GRUB 2, SeaBIOS, Linux) do not require it.<br />
Initializing a PS/2 keyboard can take several hundred milliseconds.<br />
<br />
If you know you will only use a payload which does not require<br />
this option, then you can say N here to speed up boot time.<br />
Otherwise say Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PS2K_EISAID</td><td>drivers/pc80/pc</td><td>string</td><td></td><td>
Mainboards can override the default to match vendor drivers and quirks.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PS2M_EISAID</td><td>drivers/pc80/pc</td><td>string</td><td></td><td>
Mainboards can override the default to match vendor drivers and quirks.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPMI_OCP</td><td>drivers/ipmi/ocp</td><td>bool</td><td></td><td>
This implements OCP specific IPMI command<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_INTEL_PMC</td><td>drivers/intel/pmc_mux</td><td>bool</td><td></td><td>
When enabled, driver/intel/pmc_mux will add support for mux<br />
configuration of USB Type-C ports via the SoC's muxes.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_DDI</td><td>drivers/intel/gma</td><td>bool</td><td></td><td>
helper functions for intel DDI operations<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_GMA_SSC_ALTERNATE_REF</td><td>drivers/intel/gma</td><td>bool</td><td></td><td>
Set when the SSC reference clock for LVDS runs at a different fre-<br />
quency than the general display reference clock.<br />
<br />
To be set by northbridge or mainboard Kconfig.  For most platforms,<br />
there is no choice, i.e. for i945 and gm45 the SSC reference always<br />
differs from the display reference clock (i945: 66Mhz SSC vs. 48MHz<br />
DREF; gm45: 100MHz SSC vs. 96Mhz DREF), for Arrandale and newer, it's<br />
the same frequency for SSC/non-SSC (120MHz).  The only, currently<br />
supported platform with a choice seems to be Pineview, where the<br />
alternative is 100MHz vs. the default 96MHz.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_GMA_SWSMISCI</td><td>drivers/intel/gma</td><td>bool</td><td></td><td>
Select this option for Atom-based platforms which use the SWSMISCI<br />
register (0xe0) rather than the SWSCI register (0xe8).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GFX_GMA_IGNORE_PRESENCE_STRAPS</td><td>drivers/intel/gma</td><td>bool</td><td></td><td>
libgfxinit uses the GPU presence straps to determine if a display port<br />
is present/enabled. Select this option if a board doesn't correctly implement<br />
these straps, causing libgfxinit to fail to detect an attached panel.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GFX_GMA_DYN_CPU</td><td>drivers/intel/gma</td><td>bool</td><td></td><td>
Activates runtime CPU detection in libgfxinit.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GFX_GMA_ANALOG_I2C_PORT</td><td>drivers/intel/gma</td><td>string</td><td></td><td>
Boards with a DVI-I connector share the I2C pins for both analog and<br />
digital displays. In that case, the EDID for a VGA display has to be<br />
read over the I2C interface of the coupled digital port.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_INTEL_DPTF</td><td>drivers/intel/dptf</td><td>bool</td><td></td><td>
When enabled, entries in the devicetree are used to generate<br />
Intel DPTF Tables at runtime in the SSDT.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DPTF_USE_EISA_HID</td><td>drivers/intel/dptf</td><td>bool</td><td></td><td>
Prior to Tiger Lake, all DPTF devices used 7-character EISA<br />
IDs. If selected, the 7-character _HIDs will be emitted,<br />
otherwise, it will use the "new" style, which are regular<br />
8-character _HIDs.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_INTEL_MIPI_CAMERA</td><td>drivers/intel/mipi_camera</td><td>bool</td><td></td><td>
MIPI CSI I2C camera SSDT generator. Generates SSDB and PWDB<br />
structures which are used by the Intel kernel drivers.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_INTEL_PTT</td><td>drivers/intel/ptt</td><td>bool</td><td></td><td>
Activate if your platform has Intel Platform Trust Technology like Intel iTPM and you want to use it.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_INTEL_ISH</td><td>drivers/intel/ish</td><td>bool</td><td></td><td>
When enabled, chip driver/intel/ish will publish information to the<br />
SSDT _DSD table for the ISH device.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PLATFORM_USES_FSP1_1</td><td>drivers/intel/fsp1_1</td><td>bool</td><td></td><td>
Does the code require the Intel Firmware Support Package?<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>drivers/intel/fsp1_1</td><td>(comment)</td><td></td><td>Intel FSP 1.1</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_FSP_BIN</td><td>drivers/intel/fsp1_1</td><td>bool</td><td>Add Intel FSP binary to flash image</td><td>
Select this option to add an Intel FSP binary to<br />
the resulting coreboot image.<br />
<br />
Note: Without this binary, coreboot builds relying on the FSP<br />
will not boot<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_FILE</td><td>drivers/intel/fsp1_1</td><td>string</td><td>Intel FSP binary path and filename</td><td>
The path and filename of the Intel FSP binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_LOC</td><td>drivers/intel/fsp1_1</td><td>hex</td><td>Intel FSP Binary location in CBFS</td><td>
The location in CBFS that the FSP is located. This must match the<br />
value that is set in the FSP binary.  If the FSP needs to be moved,<br />
rebase the FSP with Intel's BCT (tool).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_UPD_DATA</td><td>drivers/intel/fsp1_1</td><td>bool</td><td>Display UPD data</td><td>
Display the user specified product data prior to memory<br />
initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USE_GENERIC_FSP_CAR_INC</td><td>drivers/intel/fsp1_1</td><td>bool</td><td></td><td>
The chipset can select this to use a generic cache_as_ram.inc file<br />
that should be good for all FSP based platforms.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SKIP_FSP_CAR</td><td>drivers/intel/fsp1_1</td><td>bool</td><td></td><td>
Selected by platforms that implement their own CAR setup.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP1_1_DISPLAY_LOGO</td><td>drivers/intel/fsp1_1</td><td>bool</td><td>Enable logo</td><td>
Uses the FSP to display the boot logo. This method supports a<br />
BMP file only. The uncompressed size can be up to 1 MB.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PLATFORM_USES_FSP2_0</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Include FSP 2.0 wrappers and functionality<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PLATFORM_USES_FSP2_1</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Include FSP 2.1 wrappers and functionality.<br />
Feature added into FSP 2.1 specification that impacts coreboot is:<br />
1. Remove FSP stack switch and use the same stack with boot firmware<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PLATFORM_USES_FSP2_2</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Include FSP 2.2 wrappers and functionality.<br />
Features added into FSP 2.2 specification that impact coreboot are:<br />
1. Added multi-phase silicon initialization to increase the modularity of the<br />
FspSiliconInit() API<br />
2. FSP_INFO_HEADER changes to add FspMultiPhaseSiInitEntryOffset<br />
3. Added EnableMultiPhaseSiliconInit, bootloaders designed for FSP2.0/2.1 can disable<br />
the FspMultiPhaseSiInit() API and continue to use FspSiliconInit() without change.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_INTEL_FSP_REPO</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Select this, if the FSP binaries for the platform are public<br />
and available in 3rdparty/fsp/. When selecting this option, the<br />
platform must also set FSP_HEADER_PATH and FSP_FD_PATH correctly.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_USE_REPO</td><td>drivers/intel/fsp2_0</td><td>bool</td><td>Use binaries of the Intel FSP repository on GitHub</td><td>
Select this option to use the default FSP headers and binaries<br />
found in the IntelFsp GitHub repository at<br />
<br />
https://github.com/IntelFsp/FSP/<br />
<br />
If unsure, say Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_HEADER_PATH</td><td>drivers/intel/fsp2_0</td><td>string</td><td>Location of FSP headers</td><td>
Include directory with the FSP ABI header files.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ADD_FSP_BINARIES</td><td>drivers/intel/fsp2_0</td><td>bool</td><td>Add Intel FSP 2.0 binaries to CBFS</td><td>
Add the FSP-M and FSP-S binaries to CBFS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_FULL_FD</td><td>drivers/intel/fsp2_0</td><td>bool</td><td>Use a combined FSP FD file</td><td>
Use a combined FSP FD file instead of specifying individual, already split<br />
binaries and split the file at build-time.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_FD_PATH</td><td>drivers/intel/fsp2_0</td><td>string</td><td>Location of FSP FD file</td><td>
Path to the FSP FD file that contains the individual FSP-T, FSP-M<br />
and FSP-S binaries. The file gets split at build-time.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_T_FILE</td><td>drivers/intel/fsp2_0</td><td>string</td><td>Intel FSP-T (temp RAM init) binary path and filename</td><td>
The path and filename of the Intel FSP-T binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_FILE</td><td>drivers/intel/fsp2_0</td><td>string</td><td>Intel FSP-M (memory init) binary path and filename</td><td>
The path and filename of the Intel FSP-M binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_S_FILE</td><td>drivers/intel/fsp2_0</td><td>string</td><td>Intel FSP-S (silicon init) binary path and filename</td><td>
The path and filename of the Intel FSP-S binary for this platform.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_CAR</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Use FSP APIs to initialize &amp; Tear Down the Cache-As-Ram<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_T_RESERVED_SIZE</td><td>drivers/intel/fsp2_0</td><td>hex</td><td></td><td>
This is the size of the area reserved by FSP-T. This is not<br />
defined in the FSP specification but in the SOC integration<br />
guides.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_XIP</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Select this value when FSP-M is execute-in-place.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_T_XIP</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Select this value when FSP-T is execute-in-place.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_USES_CB_STACK</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Enable support for fsp to use same stack as coreboot.<br />
This option allows fsp to continue using coreboot stack<br />
without reinitializing stack pointer. This feature is<br />
supported Icelake onwards.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_TEMP_RAM_SIZE</td><td>drivers/intel/fsp2_0</td><td>hex</td><td></td><td>
The amount of memory coreboot reserves for the FSP to use. In the<br />
case of FSP 2.1 and newer that share the stack with coreboot instead<br />
of having its own stack, this is the amount of anticipated heap usage<br />
in CAR by FSP to setup HOB and needs to be the recommended value from<br />
the Platform FSP integration guide. In the case of the FSP having its<br />
own stack that will be placed in DRAM and not in CAR, this is the<br />
amount of memory the FSP needs for its stack and heap.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_PLATFORM_MEMORY_SETTINGS_VERSIONS</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
This is selected by SoC or mainboard to supply their own<br />
concept of a version for the memory settings respectively.<br />
This allows deployed systems to bump their version number<br />
with the same FSP which will trigger a retrain of the memory.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_PEIM_TO_PEIM_INTERFACE</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
This option allows SOC user to create specific PPI for Intel FSP<br />
usage, coreboot will provide required PPI structure definitions<br />
along with all APIs as per EFI specification. So far this feature<br />
is limited till EFI_PEI_MP_SERVICE_PPI and this option might be<br />
useful to add further PPI if required.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP2_0_DISPLAY_LOGO</td><td>drivers/intel/fsp2_0</td><td>bool</td><td>Enable logo</td><td>
Uses the FSP to display the boot logo. This method supports a<br />
BMP file only. The uncompressed size can be up to 1 MB. The logo can be compressed<br />
using LZMA.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_M_ADDR</td><td>drivers/intel/fsp2_0</td><td>hex</td><td></td><td>
The address FSP-M will be relocated to during build time<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_STATUS_GLOBAL_RESET_REQUIRED_3</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
FSP Reset Status code used for global reset as per FSP EAS v2.0 section 11.2.2<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_STATUS_GLOBAL_RESET_REQUIRED_4</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
FSP Reset Status code used for global reset as per FSP EAS v2.0 section 11.2.2<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_STATUS_GLOBAL_RESET_REQUIRED_5</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
FSP Reset Status code used for global reset as per FSP EAS v2.0 section 11.2.2<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_STATUS_GLOBAL_RESET_REQUIRED_6</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
FSP Reset Status code used for global reset as per FSP EAS v2.0 section 11.2.2<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_STATUS_GLOBAL_RESET_REQUIRED_7</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
FSP Reset Status code used for global reset as per FSP EAS v2.0 section 11.2.2<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_STATUS_GLOBAL_RESET_REQUIRED_8</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
FSP Reset Status code used for global reset as per FSP EAS v2.0 section 11.2.2<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_STATUS_GLOBAL_RESET</td><td>drivers/intel/fsp2_0</td><td>hex</td><td></td><td>
If global reset is supported by SoC then select the correct status value for global<br />
reset type from SoC Kconfig based on available Kconfig options<br />
FSP_STATUS_GLOBAL_RESET_REQUIRED_X. Default is unsupported.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SOC_INTEL_COMMON_FSP_RESET</td><td>drivers/intel/fsp2_0</td><td>bool</td><td></td><td>
Common code block to handle platform reset request raised by FSP. The FSP<br />
will use the FSP EAS v2.0 section 12.2.2 (OEM Status Code) to indicate that<br />
a reset is required.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_USES_MP_SERVICES_PPI</td><td>drivers/intel/fsp2_0/ppi</td><td>bool</td><td></td><td>
This option allows SoC user to create MP service PPI for Intel<br />
FSP usage, coreboot will provide EFI_PEI_MP_SERVICES_PPI structure<br />
definitions along with all APIs as per EDK2 specification. Intel FSP<br />
will use this PPI to run CPU feature programming on APs.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_SIL_3114</td><td>drivers/sil/3114</td><td>bool</td><td>Silicon Image SIL3114</td><td>
It sets PCI class to IDE compatible native mode, allowing<br />
SeaBIOS, FILO etc... to boot from it.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_GENESYSLOGIC_GL9755</td><td>drivers/genesyslogic/gl9755</td><td>bool</td><td>Genesys Logic GL9755</td><td>
GL9755 is a PCI Express Rev. 2.1 compliant card reader controller<br />
which integrates PCI Express PHY, UHS-II PHY, memory card access<br />
interface, regulators (3.3V-to-1.8V and 3.3V-to-1.2V) and card<br />
power switch.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_GFX_GENERIC</td><td>drivers/gfx/generic</td><td>bool</td><td></td><td>
Include support for generic graphics device in devicetree<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVER_MAXIM_MAX77686</td><td>drivers/maxim/max77686</td><td>bool</td><td></td><td>
Maxim MAX77686 power regulator<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_GENERIC_CBFS_SERIAL</td><td>drivers/generic/cbfs-serial</td><td>bool</td><td>Serial number in CBFS</td><td>
Enable this option to read the board serial number from a<br />
text file located in CBFS.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>DRIVERS_INTEL_USB4_RETIMER</td><td>drivers/intel/usb4/retimer</td><td>bool</td><td></td><td>
A retimer is a device that retransmits a fresh copy of the signal it<br />
receives, by doing CDR and retransmitting the data (i.e., it is<br />
protocol-aware). If your mainboard has a USB4 retimer (usually<br />
located close to the USB4 ports), then select this driver.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>FSP_USES_MP_SERVICES_PPI</td><td>drivers/intel/fsp2_0/ppi</td><td>bool</td><td></td><td>
This option allows SoC user to create MP service PPI for Intel<br />
FSP usage, coreboot will provide EFI_PEI_MP_SERVICES_PPI structure<br />
definitions along with all APIs as per EDK2 specification. Intel FSP<br />
will use this PPI to run CPU feature programming on APs.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>STORAGE_ERASE</td><td>commonlib/storage</td><td>bool</td><td>Support SD/MMC erase operations</td><td>
Select to enable SD/MMC erase oprations<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STORAGE_WRITE</td><td>commonlib/storage</td><td>bool</td><td>Support SD/MMC write operations</td><td>
Select to enable SD/MMC write oprations<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SD_MMC_DEBUG</td><td>commonlib/storage</td><td>bool</td><td>Debug SD/MMC card/devices operations</td><td>
Display overview of SD/MMC card/device operations<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SD_MMC_TRACE</td><td>commonlib/storage</td><td>bool</td><td>Trace SD/MMC card/device operations</td><td>
Display details of SD/MMC card/device operations<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SDHC_DEBUG</td><td>commonlib/storage</td><td>bool</td><td>Debug SD/MMC controller settings</td><td>
Display clock speed and bus width settings<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SDHC_TRACE</td><td>commonlib/storage</td><td>bool</td><td>Trace SD/MMC controller operations</td><td>
Display the operations performed by the SD/MMC controller<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SDHCI_ADMA_IN_BOOTBLOCK</td><td>commonlib/storage</td><td>bool</td><td></td><td>
Determine if bootblock is able to use ADMA2 or ADMA64<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SDHCI_ADMA_IN_ROMSTAGE</td><td>commonlib/storage</td><td>bool</td><td></td><td>
Determine if romstage is able to use ADMA2 or ADMA64<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SDHCI_ADMA_IN_VERSTAGE</td><td>commonlib/storage</td><td>bool</td><td></td><td>
Determine if verstage is able to use ADMA2 or ADMA64<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Security</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_VERIFICATION</td><td>lib.cbfs_verification</td><td>bool</td><td># TODO: make user selectable once it works</td><td>
Work in progress. Do not use (yet).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TOCTOU_SAFETY</td><td>lib.cbfs_verification</td><td>bool</td><td></td><td>
Work in progress. Not actually TOCTOU safe yet. Do not use.<br />
<br />
Design idea here is that mcache overflows in this mode are only legal<br />
for the RW CBFS, because it's relatively easy to retrieve the RW<br />
metadata hash from persistent vboot context at any time, but the RO<br />
metadata hash is lost after the bootblock is unloaded. This avoids the<br />
need to carry yet another piece forward through the stages. Mcache<br />
overflows are mostly a concern for RW updates (if an update adds more<br />
files than originally planned for), for the RO section it should<br />
always be possible to dimension the mcache correctly beforehand, so<br />
this should be an acceptable limitation.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Verified Boot (vboot)</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_LIB</td><td>security/vboot</td><td>bool</td><td></td><td>
Build and link the vboot library. Makes the vboot API accessible across<br />
all coreboot stages, without enabling vboot verification. For verification,<br />
please see the VBOOT option below.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT</td><td>security/vboot</td><td>bool</td><td>Verify firmware with vboot.</td><td>
Enabling VBOOT will use vboot to verify the components of the firmware<br />
(stages, payload, etc).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>security/vboot</td><td>(comment)</td><td></td><td>Anti-Rollback Protection disabled because mocking secdata is enabled.</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_SLOTS_RW_A</td><td>security/vboot</td><td>bool</td><td>Firmware RO + RW_A</td><td>
Have one update partition beside the RO partition.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_SLOTS_RW_AB</td><td>security/vboot</td><td>bool</td><td>Firmware RO + RW_A + RW_B</td><td>
Have two update partitions beside the RO partition.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_VBNV_CMOS</td><td>security/vboot</td><td>bool</td><td></td><td>
VBNV is stored in CMOS<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_VBNV_OFFSET</td><td>security/vboot</td><td>hex</td><td></td><td>
CMOS offset for VbNv data. This value must match cmos.layout<br />
in the mainboard directory, minus 14 bytes for the RTC.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_VBNV_CMOS_BACKUP_TO_FLASH</td><td>security/vboot</td><td>bool</td><td></td><td>
Vboot non-volatile storage data will be backed up from CMOS to flash<br />
and restored from flash if the CMOS is invalid due to power loss.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_VBNV_EC</td><td>security/vboot</td><td>bool</td><td></td><td>
VBNV is stored in EC<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_VBNV_FLASH</td><td>security/vboot</td><td>bool</td><td></td><td>
VBNV is stored in flash storage<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_STARTS_BEFORE_BOOTBLOCK</td><td>security/vboot</td><td>bool</td><td></td><td>
Firmware verification happens before the main processor is brought<br />
online.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_STARTS_IN_BOOTBLOCK</td><td>security/vboot</td><td>bool</td><td></td><td>
Firmware verification happens during the end of or right after the<br />
bootblock. This implies that a static VBOOT2_WORK() buffer must be<br />
allocated in memlayout.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_STARTS_IN_ROMSTAGE</td><td>security/vboot</td><td>bool</td><td></td><td>
Firmware verification happens during the end of romstage (after<br />
memory initialization). This implies that the vboot work buffer is<br />
in CBMEM from the start and doesn't need to be reserved in memlayout.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_MOCK_SECDATA</td><td>security/vboot</td><td>bool</td><td>Mock secdata for firmware verification</td><td>
Enabling VBOOT_MOCK_SECDATA will mock secdata for the firmware<br />
verification to avoid access to a secdata storage (typically TPM).<br />
All operations for a secdata storage will be successful. This option<br />
can be used during development when a TPM is not present or broken.<br />
THIS SHOULD NOT BE LEFT ON FOR PRODUCTION DEVICES.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_DISABLE_DEV_ON_RECOVERY</td><td>security/vboot</td><td>bool</td><td></td><td>
When this option is enabled, the Chrome OS device leaves the<br />
developer mode as soon as recovery request is detected. This is<br />
handy on embedded devices with limited input capabilities.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_SEPARATE_VERSTAGE</td><td>security/vboot</td><td>bool</td><td></td><td>
If this option is set, vboot verification runs in a standalone stage<br />
that is loaded from the bootblock and exits into romstage. If it is<br />
not set, the verification code is linked directly into the bootblock<br />
or the romstage and runs as part of that stage (cf. related options<br />
VBOOT_STARTS_IN_BOOTBLOCK/_ROMSTAGE and VBOOT_RETURN_FROM_VERSTAGE).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_RETURN_FROM_VERSTAGE</td><td>security/vboot</td><td>bool</td><td></td><td>
If this is set, the verstage returns back to the calling stage instead<br />
of exiting to the succeeding stage so that the verstage space can be<br />
reused by the succeeding stage. This is useful if a RAM space is too<br />
small to fit both the verstage and the succeeding stage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_MUST_REQUEST_DISPLAY</td><td>security/vboot</td><td>bool</td><td></td><td>
Set this option to indicate to vboot that this platform will skip its<br />
display initialization on a normal (non-recovery, non-developer) boot.<br />
Unless display is specifically requested, the video option ROM is not<br />
loaded, and any other native display initialization code is not run.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_ALWAYS_ENABLE_DISPLAY</td><td>security/vboot</td><td>bool</td><td>Force to always enable display</td><td>
Set this option to indicate to vboot that display should always be enabled.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_ALWAYS_ALLOW_UDC</td><td>security/vboot</td><td>bool</td><td>Always allow UDC</td><td>
This option allows UDC to be enabled regardless of the vboot state.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_HAS_REC_HASH_SPACE</td><td>security/vboot</td><td>bool</td><td></td><td>
Set this option to indicate to vboot that recovery data hash space<br />
is present in TPM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_LID_SWITCH</td><td>security/vboot</td><td>bool</td><td></td><td>
Whether this platform has a lid switch. If it does, vboot will not<br />
decrement try counters for boot failures if the lid is closed.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_WIPEOUT_SUPPORTED</td><td>security/vboot</td><td>bool</td><td></td><td>
When this option is enabled, the firmware provides the ability to<br />
signal the application the need for factory reset (a.k.a. wipe<br />
out) of the device<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_FWID_MODEL</td><td>security/vboot</td><td>string</td><td>Firmware ID model</td><td>
This is the first part of the FWID written to various regions of a<br />
vboot firmware image to identify its version.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_FWID_VERSION</td><td>security/vboot</td><td>string</td><td>Firmware ID version</td><td>
This is the second part of the FWID written to various regions of a<br />
vboot firmware image to identify its version.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_NO_BOARD_SUPPORT</td><td>security/vboot</td><td>bool</td><td>Allow the use of vboot without board support</td><td>
Enable weak functions for get_write_protect_state and<br />
get_recovery_mode_switch in order to proceed with refactoring<br />
of the vboot2 code base. Later on this code is removed and replaced<br />
by interfaces.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RO_REGION_ONLY</td><td>security/vboot</td><td>string</td><td>Additional files that should not be copied to RW</td><td>
Add a space delimited list of filenames that should only be in the<br />
RO section.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RW_REGION_ONLY</td><td>security/vboot</td><td>string</td><td></td><td>
Add a space delimited list of filenames that should only be in the<br />
RW sections.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RWA_REGION_ONLY</td><td>security/vboot</td><td>string</td><td></td><td>
Add a space-delimited list of filenames that should only be in the<br />
RW-A section.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RWB_REGION_ONLY</td><td>security/vboot</td><td>string</td><td></td><td>
Add a space-delimited list of filenames that should only be in the<br />
RW-B section.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_ENABLE_CBFS_FALLBACK</td><td>security/vboot</td><td>bool</td><td></td><td>
When this option is enabled cbfs_boot_locate will look for a file in the RO<br />
(COREBOOT) region if it isn't available in the active RW region.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_EARLY_EC_SYNC</td><td>security/vboot</td><td>bool</td><td></td><td>
Enables CrOS EC software sync in romstage, before memory training<br />
runs. This is useful mainly as a way to achieve full USB-PD<br />
negotiation earlier in the boot flow, as the EC will only do this once<br />
it has made the sysjump to its RW firmware. It should not<br />
significantly impact boot time, as this operation will be performed<br />
later in the boot flow if it is disabled here.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_EC_EFS</td><td>security/vboot</td><td>bool</td><td>Early firmware selection (EFS) EC</td><td>
CrosEC can support EFS: Early Firmware Selection. If it's enabled,<br />
software sync needs to also support it. This setting tells vboot to<br />
perform EFS software sync.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: GBB configuration</td></tr>
<tr bgcolor="#eeeeee">
<td>GBB_HWID</td><td>security/vboot</td><td>string</td><td>Hardware ID</td><td>
A hardware identifier for device. On Chrome OS this is used for auto<br />
update and recovery, and will be generated when manufacturing by the<br />
factory software, in a strictly defined format.<br />
Leave empty to get a test-only Chrome OS HWID v2 string generated.<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Vboot Keys</td></tr>
<tr bgcolor="#eeeeee">
<td>VBOOT_HASH_BLOCK_SIZE</td><td>security/vboot</td><td>hex</td><td></td><td>
Set the default hash size.  Generally 1k is reasonable, but in some<br />
cases it may improve hashing speed to increase the size.<br />
<br />
Note that this buffer is allocated in the stack.  Although the<br />
build should fail if the stack size is exceeded, it's something to<br />
be aware of when changing the size.<br />
<br />
</td></tr>


<tr bgcolor="#eeeeee">
<td>POWER_OFF_ON_CR50_UPDATE</td><td>security/tpm/tss/vendor/cr50</td><td>bool</td><td></td><td>
Power off machine while waiting for CR50 update to take effect.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CR50_USE_LONG_INTERRUPT_PULSES</td><td>security/tpm/tss/vendor/cr50</td><td>bool</td><td></td><td>
Whether to request longer interrupt pulses using Cr50 BOARD_CFG register.<br />
If the Cr50 firmware is too old, it will not be able to honor the request.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Trusted Platform Module</td></tr>
<tr bgcolor="#eeeeee">
<td>USER_TPM1</td><td>security/tpm</td><td>bool</td><td>1.2</td><td>
Enable this option to enable TPM 1.0 - 1.2 support in coreboot.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>USER_TPM2</td><td>security/tpm</td><td>bool</td><td>2.0</td><td>
Enable this option to enable TPM 2.0 support in coreboot.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_DEACTIVATE</td><td>security/tpm</td><td>bool</td><td>Deactivate TPM</td><td>
Deactivate TPM by issuing deactivate command.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_TPM</td><td>security/tpm</td><td>bool</td><td>Output verbose TPM debug messages</td><td>
This option enables additional TPM related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_RDRESP_NEED_DELAY</td><td>security/tpm</td><td>bool</td><td>Enable Delay Workaround for TPM</td><td>
Certain TPMs seem to need some delay when reading response<br />
to work around a race-condition-related issue, possibly<br />
caused by ill-programmed TPM firmware.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_STARTUP_IGNORE_POSTINIT</td><td>security/tpm</td><td>bool</td><td></td><td>
Select this to ignore POSTINIT INVALID return codes on TPM<br />
startup. This is useful on platforms where a previous stage<br />
issued a TPM startup. Examples of use cases are Intel TXT<br />
or VBOOT on the Intel Arrandale processor, which issues a<br />
CPU-only reset during the romstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_MEASURED_BOOT</td><td>security/tpm</td><td>bool</td><td>Enable Measured Boot</td><td>
Enables measured boot (experimental)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TPM_MEASURED_BOOT_RUNTIME_DATA</td><td>security/tpm</td><td>string</td><td>Runtime data whitelist</td><td>
Runtime data whitelist of cbfs filenames. Needs to be a<br />
space delimited list<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Memory initialization</td></tr>
<tr bgcolor="#eeeeee">
<td>PLATFORM_HAS_DRAM_CLEAR</td><td>security/memory</td><td>bool</td><td></td><td>
Selected by platforms that support clearing all DRAM<br />
after DRAM initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT</td><td>security/memory</td><td>bool</td><td>Always clear all DRAM on regular boot</td><td>
Always clear the DRAM after DRAM initialization regardless<br />
of additional security implementations in use.<br />
This increases boot time depending on the amount of DRAM<br />
installed.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>INTEL_TXT_BIOSACM_FILE</td><td>security/intel/txt</td><td>string</td><td>BIOS ACM file</td><td>
Intel TXT BIOS ACM file. This file can be obtained through privileged<br />
access to Intel resources. Or for some platforms found inside the<br />
blob repository.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_SINITACM_FILE</td><td>security/intel/txt</td><td>string</td><td>SINIT ACM file</td><td>
Intel TXT SINIT ACM file. This file can be obtained through privileged<br />
access to Intel resources. Or for some platforms found inside the<br />
blob repository.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_DPR_SIZE</td><td>security/intel/txt</td><td>int</td><td></td><td>
Specify the size the DPR region needs to have. On at least Haswell,<br />
the MRC does not have an input to specify the size of DPR, so this<br />
field is only used to check if the programmed size is large enough.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_TEST_BIOS_ACM_CALLING_CODE</td><td>security/intel/txt</td><td>bool</td><td>Test BIOS ACM calling code with NOP function</td><td>
Run a NOP function of the BIOS ACM to check that the ACM calling code<br />
is functioning properly. Use in pre-production environments only!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_LOGGING</td><td>security/intel/txt</td><td>bool</td><td>Enable verbose logging</td><td>
Print more TXT related debug output.<br />
Use in pre-production environments only!<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_BIOSACM_ALIGNMENT</td><td>security/intel/txt</td><td>hex</td><td></td><td>
Exceptions are Ivy and Sandy Bridge with 64 KiB and Purley with 256 KiB<br />
alignment size. If necessary, override from platform-specific Kconfig.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_SINIT_SIZE</td><td>security/intel/txt</td><td>hex</td><td></td><td>
This is the size that will be programmed in TXT_SINIT_SIZE.<br />
This needs to be at least the size of the SINIT ACM.<br />
This is platform dependent. For instance on CPX this has<br />
to be the ACM size + 64K.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_TXT_HEAP_SIZE</td><td>security/intel/txt</td><td>hex</td><td></td><td>
This is the size that will be programmed in TXT_HEAP_SIZE.<br />
This is platform dependent.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM</td><td>security/intel/stm</td><td>bool</td><td>Enable STM</td><td>
Enabling the STM will load a simple hypervisor into SMM that will<br />
restrict the actions of the SMI handler, which is the part of BIOS<br />
that functions in system management mode (SMM).  The kernel can<br />
configure the STM to prevent the SMI handler from accessing platform<br />
resources.<br />
The STM closes a vulnerability in Intel TXT (D-RTM)<br />
The SMI handler provides a list of platform resources that it<br />
requires access to the STM during STM startup, which the kernel<br />
cannot override.<br />
An additional capability, called STM-PE, provides a protected<br />
execution capability that allows modules to be executed without<br />
observation and interference. Examples of usage include kernel<br />
introspection and virtualized trusted platform module (vTPM).<br />
Requirement: SMM must be enabled and there must be sufficient room<br />
within the TSEG to fit the MSEG.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: SMI Transfer Monitor (STM)</td></tr>
<tr bgcolor="#eeeeee">
<td>MSEG_SIZE</td><td>security/intel/stm</td><td>hex</td><td>mseg size</td><td>
The MSEG_SIZE of 0x100000 assumes that:<br />
IED_REGION_SIZE   = 0x400000<br />
SMM_RESERVED_SIZE = 0x200000<br />
SMM_TSEG_SIZE     = 0x800000<br />
<br />
To use STM/PE, a larger MSEG_SIZE is necessary.  This can be<br />
done by either increasing SMM_TSEG_SIZE or reducing the<br />
IED_REGION_SIZE and/or SMM_RESERVED_SIZE or some combination<br />
of the three.<br />
NOTE: The authors experience is that these configuration<br />
parameters have to be changed at the soc Konfig for them to<br />
be applied.<br />
Minimum sizes:<br />
STM only - 0x100000 - Supports up to 38 processor threads<br />
- 0x200000 - Supports up to 102 processor threads<br />
STM/PE   - 0x300000+ depending on the amount of memory needed<br />
for the protected execution virtual<br />
machine (VM/PE)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM_STMPE_ENABLED</td><td>security/intel/stm</td><td>bool</td><td>STM/PE Enabled</td><td>
STM/PE provides for additional virtual machines in SMRAM<br />
that provides a protected execution environment for<br />
applications such as introspection, which need to be<br />
protected from malicious code.  More information can be<br />
found on the stmpe branch of<br />
https://review.coreboot.org/STM<br />
<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BIOS_RESOURCE_LIST_SIZE</td><td>security/intel/stm</td><td>hex</td><td>bios resource list size</td><td>
The BIOS resource list defines the resources that the<br />
SMI handler needs.  This list is created during the<br />
coreboot bootup.  Unless there has been a lot of elements<br />
added to this list, this value should not change.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM_BINARY_FILE</td><td>security/intel/stm</td><td>string</td><td>STM binary file</td><td>
Location of the STM binary file.  The default location is<br />
where the file will be located when coreboot builds<br />
the STM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM_HEAPSIZE</td><td>security/intel/stm</td><td>hex</td><td>stm heapsize</td><td>
The STM_HEAPSIZE defines the heap space that is available<br />
to the STM.  The default size assumes a MSEG_SIZE of 0x100000.<br />
For STM/PE this size should be a minimum of 0x246000.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM_TTYS0_BASE</td><td>security/intel/stm</td><td>hex</td><td>stm uart</td><td>
Defines the serial port for STM console output.  0x000 indicates<br />
no serial port.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM_CBMEM_CONSOLE</td><td>security/intel/stm</td><td>bool</td><td>STM cbmem console</td><td>
Places the STM console output into the cbmem.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM_CONSOLE_DEBUG</td><td>security/intel/stm</td><td>bool</td><td>Debug output</td><td>
"Produces all STM console output"<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>STM_CONSOLE_RELEASE</td><td>security/intel/stm</td><td>bool</td><td>Deactivate console output</td><td>
"No console output is produced"<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>INTEL_CBNT_SUPPORT</td><td>security/intel/cbnt</td><td>bool</td><td>Intel CBnT support</td><td>
Enables Intel Converged Bootguard and Trusted Execution Technology<br />
Support. This will enable one to add a Key Manifest (KM) and a Boot<br />
Policy Manifest (BPM) to the filesystem. It will also wrap a FIT around<br />
the firmware and update appropriate entries.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_CBNT_KEY_MANIFEST_BINARY</td><td>security/intel/cbnt</td><td>string</td><td>KM (Key Manifest) binary location</td><td>
Location of the Key Manifest (KM)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>INTEL_CBNT_BOOT_POLICY_MANIFEST_BINARY</td><td>security/intel/cbnt</td><td>string</td><td>BPM (Boot Policy Manifest) binary location</td><td>
Location of the Boot Policy Manifest (BPM)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_LOCK_CONTROLLER</td><td>security/lockdown</td><td>bool</td><td>Lock boot media using the controller</td><td>
Select this if you want the controller to lock specific regions.<br />
This only works on some platforms, please check the code or boot log.<br />
On Intel platforms for e.g. this will make use of the SPIBAR PRRs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_LOCK_CHIP</td><td>security/lockdown</td><td>bool</td><td>Lock boot media using the chip</td><td>
Select this if you want the chip to lock specific regions.<br />
This only works on some chips, please check the code or search the<br />
boot log for "BM-LOCKDOWN".<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_LOCK_WHOLE_RO</td><td>security/lockdown</td><td>bool</td><td>Write-protect the whole boot medium</td><td>
Select this if you want to write-protect the whole firmware boot<br />
medium.<br />
<br />
The locking will take place during the chipset lockdown.<br />
Chipset lockdown is platform specific und might be done unconditionally,<br />
when INTEL_CHIPSET_LOCKDOWN is set or has to be triggered later<br />
(e.g. by the payload or the OS).<br />
<br />
NOTE: If you trigger the chipset lockdown unconditionally,<br />
you won't be able to write to the whole flash chip using the<br />
internal controller any more.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_LOCK_WHOLE_NO_ACCESS</td><td>security/lockdown</td><td>bool</td><td>Read- and write-protect the whole boot medium</td><td>
Select this if you want to protect the firmware boot medium against<br />
all further accesses. On platforms that memory map a part of the<br />
boot medium the corresponding region is still readable.<br />
<br />
The locking will take place during the chipset lockdown.<br />
Chipset lockdown is platform specific und might be done unconditionally,<br />
when INTEL_CHIPSET_LOCKDOWN is set or has to be triggered later<br />
(e.g. by the payload or the OS).<br />
<br />
NOTE: If you trigger the chipset lockdown unconditionally,<br />
you won't be able to write to the whole flash chip using the<br />
internal controller any more.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_LOCK_WPRO_VBOOT_RO</td><td>security/lockdown</td><td>bool</td><td>Write-protect WP_RO FMAP region in boot medium</td><td>
Select this if you want to write-protect the WP_RO region as specified<br />
in the VBOOT FMAP. You will be able to write every region outside<br />
of WP_RO using the internal controller (eg. FW_MAIN_A/FW_MAIN_B).<br />
In case of BOOTMEDIA_LOCK_IN_VERSTAGE the locking will take place<br />
early, preventing locking of facilities used in ramstage, like the<br />
MRC cache. If not using BOOTMEDIA_LOCK_IN_VERSTAGE the chipset lockdown<br />
is either triggered by coreboot (when INTEL_CHIPSET_LOCKDOWN is set) or<br />
has to be triggered later (e.g. by the payload or the OS).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_LOCK_IN_VERSTAGE</td><td>security/lockdown</td><td>bool</td><td>Lock boot media down in verstage</td><td>
Select this if you want to write-protect the WP_RO region as soon as<br />
possible. This option prevents using write protecting facilities in<br />
ramstage, like the MRC cache for example.<br />
Use this option if you don't trust code running after verstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_SPI_LOCK_REBOOT</td><td>security/lockdown</td><td>bool</td><td>Lock SPI flash until next reboot</td><td>
The SPI chip is locked until power is removed and re-applied.<br />
Supported by Winbond parts.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_SPI_LOCK_PIN</td><td>security/lockdown</td><td>bool</td><td>Lock SPI flash using WP# pin</td><td>
The SPI chip is locked using a non-volatile configuration bit. Writes<br />
are only possible if the WP# is not asserted. Supported by Winbond<br />
and Macronix parts.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTMEDIA_SPI_LOCK_PERMANENT</td><td>security/lockdown</td><td>bool</td><td>Lock SPI flash permanently</td><td>
The SPI chip is permanently locked using a non-volatile configuration<br />
bit. No writes are ever possible again after we perform the lock.<br />
Supported by Winbond parts.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Eltan Security Settings</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Measured Boot (mboot)</td></tr>
<tr bgcolor="#eeeeee">
<td>VENDORCODE_ELTAN_MBOOT</td><td>vendorcode/eltan/security/mboot</td><td>bool</td><td>Measure firmware with mboot.</td><td>
Enabling MBOOT will use mboot to measure the components of the firmware<br />
(stages, payload, etc).<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Verified Boot (verified_boot)</td></tr>
<tr bgcolor="#eeeeee">
<td>VENDORCODE_ELTAN_VBOOT_USE_SHA512</td><td>vendorcode/eltan/security/verified_boot</td><td>bool</td><td>SHA512 hashes</td><td>
Use SHA512 for the vboot operations, this applies to the digest in<br />
the manifest and the manifest digest.<br />
<br />
</td></tr>



<tr bgcolor="#eeeeee">
<td>ACPI_AMD_HARDWARE_SLEEP_VALUES</td><td>acpi</td><td>None</td><td></td><td>
Provide common definitions for AMD hardware PM1_CNT register sleep<br />
values.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_CPU_STRING</td><td>acpi</td><td>string</td><td></td><td>
Sets the ACPI name string in the processor scope as written by<br />
the acpigen function. Default is \_SB.CPxx. Note that you need<br />
the \ escape character in the string.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_INTEL_HARDWARE_SLEEP_VALUES</td><td>acpi</td><td>string</td><td></td><td>
Provide common definitions for Intel hardware PM1_CNT register sleep<br />
values.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_SOC_NVS</td><td>acpi</td><td>bool</td><td></td><td>
Set to indicate &lt;soc/nvs.h&gt; exists for the platform with a definition<br />
for global_nvs.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_NO_PCAT_8259</td><td>acpi</td><td>bool</td><td></td><td>
Selected by platforms that don't expose a PC/AT 8259 PIC pair.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_ACPI_TABLES</td><td>acpi</td><td>bool</td><td></td><td>
This variable specifies whether a given board has ACPI table support.<br />
It is usually set in mainboard/*/Kconfig.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_LPIT</td><td>acpi</td><td>bool</td><td></td><td>
Selected by platforms that support and fill Intel Low Power Idle Table.<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_MEMORY_MAPPED</td><td>toplevel</td><td>bool</td><td></td><td>
Inform system if SPI is memory-mapped or not.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOT_DEVICE_SUPPORTS_WRITES</td><td>toplevel</td><td>bool</td><td></td><td>
Indicate that the platform has writable boot device<br />
support.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Console</td></tr>
<tr bgcolor="#eeeeee">
<td>BOOTBLOCK_CONSOLE</td><td>console</td><td>bool</td><td>Enable early (bootblock) console output.</td><td>
Use console during the bootblock if supported<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POSTCAR_CONSOLE</td><td>console</td><td>bool</td><td>Enable console output during postcar.</td><td>
Use console during the postcar if supported<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SQUELCH_EARLY_SMP</td><td>console</td><td>bool</td><td>Squelch AP CPUs from early console.</td><td>
When selected only the BSP CPU will output to early console.<br />
<br />
Console drivers have unpredictable behaviour if multiple threads<br />
attempt to share the same resources without a spinlock.<br />
<br />
If unsure, say Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL</td><td>console</td><td>bool</td><td>Serial port console output</td><td>
Send coreboot debug output to a serial port.<br />
<br />
The type of serial port driver selected based on your configuration is<br />
shown on the following menu line. Supporting multiple different types<br />
of UARTs in one build is not supported.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FIXED_UART_FOR_CONSOLE</td><td>console</td><td>bool</td><td></td><td>
Select to remove the prompt from UART_FOR_CONSOLE in case a<br />
specific UART has to be used (e.g. when the platform code<br />
performs dangerous configurations).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>console</td><td>(comment)</td><td></td><td>I/O mapped, 8250-compatible</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>console</td><td>(comment)</td><td></td><td>memory mapped, 8250-compatible</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>console</td><td>(comment)</td><td></td><td>device-specific UART</td></tr>
<tr bgcolor="#eeeeee">
<td>OVERRIDE_UART_FOR_CONSOLE</td><td>console</td><td>bool</td><td></td><td>
Set to "y" when the platform overrides the index of uart port by providing<br />
a get_uart_for_console routine.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UART_FOR_CONSOLE</td><td>console</td><td>int</td><td>Index for UART port to use for console</td><td>
Select an I/O port to use for serial console:<br />
0 = 0x3f8, 1 = 0x2f8, 2 = 0x3e8, 3 = 0x2e8<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TTYS0_BASE</td><td>console</td><td>hex</td><td></td><td>
Map the COM port number to the respective I/O port.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>console</td><td>(comment)</td><td></td><td>Serial port base address = 0x3f8</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>console</td><td>(comment)</td><td></td><td>Serial port base address = 0x2f8</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>console</td><td>(comment)</td><td></td><td>Serial port base address = 0x3e8</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>console</td><td>(comment)</td><td></td><td>Serial port base address = 0x2e8</td></tr>
<tr bgcolor="#eeeeee">
<td>UART_OVERRIDE_BAUDRATE</td><td>console</td><td>bool</td><td></td><td>
Set to "y" when the platform overrides the baudrate by providing<br />
a get_uart_baudrate routine.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_921600</td><td>console</td><td>bool</td><td>921600</td><td>
Set serial port Baud rate to 921600.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_460800</td><td>console</td><td>bool</td><td>460800</td><td>
Set serial port Baud rate to 460800.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_230400</td><td>console</td><td>bool</td><td>230400</td><td>
Set serial port Baud rate to 230400.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_115200</td><td>console</td><td>bool</td><td>115200</td><td>
Set serial port Baud rate to 115200.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_57600</td><td>console</td><td>bool</td><td>57600</td><td>
Set serial port Baud rate to 57600.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_38400</td><td>console</td><td>bool</td><td>38400</td><td>
Set serial port Baud rate to 38400.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_19200</td><td>console</td><td>bool</td><td>19200</td><td>
Set serial port Baud rate to 19200.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SERIAL_9600</td><td>console</td><td>bool</td><td>9600</td><td>
Set serial port Baud rate to 9600.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TTYS0_BAUD</td><td>console</td><td>int</td><td></td><td>
Map the Baud rates to an integer.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPKMODEM</td><td>console</td><td>bool</td><td>spkmodem (console on speaker) console output</td><td>
Send coreboot debug output through speaker<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_USB</td><td>console</td><td>bool</td><td>USB dongle console output</td><td>
Send coreboot debug output to USB.<br />
<br />
Configuration for USB hardware is under menu Generic Drivers.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_NE2K</td><td>console</td><td>bool</td><td>Network console over NE2000 compatible Ethernet adapter</td><td>
Send coreboot debug output to a Ethernet console, it works<br />
same way as Linux netconsole, packets are received to UDP<br />
port 6666 on IP/MAC specified with options bellow.<br />
Use following netcat command: nc -u -l -p 6666<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_NE2K_DST_MAC</td><td>console</td><td>string</td><td>Destination MAC address of remote system</td><td>
Type in either MAC address of logging system or MAC address<br />
of the router.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_NE2K_DST_IP</td><td>console</td><td>string</td><td>Destination IP of logging system</td><td>
This is IP address of the system running for example<br />
netcat command to dump the packets.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_NE2K_SRC_IP</td><td>console</td><td>string</td><td>IP address of coreboot system</td><td>
This is the IP of the coreboot system<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_NE2K_IO_PORT</td><td>console</td><td>hex</td><td>NE2000 adapter fixed IO port address</td><td>
This is the IO port address for the IO port<br />
on the card, please select some non-conflicting region,<br />
32 bytes of IO spaces will be used (and align on 32 bytes<br />
boundary, qemu needs broader align)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_CBMEM</td><td>console</td><td>bool</td><td>Send console output to a CBMEM buffer</td><td>
Enable this to save the console output in a CBMEM buffer. This would<br />
allow to see coreboot console output from Linux space.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_CBMEM_BUFFER_SIZE</td><td>console</td><td>hex</td><td>Room allocated for console output in CBMEM</td><td>
Space allocated for console output storage in CBMEM. The default<br />
value (128K or 0x20000 bytes) is large enough to accommodate<br />
even the BIOS_SPEW level.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_CBMEM_DUMP_TO_UART</td><td>console</td><td>bool</td><td>Dump CBMEM console on resets</td><td>
Enable this to have CBMEM console buffer contents dumped on the<br />
serial output in case serial console is disabled and the device<br />
resets itself while trying to boot the payload.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SPI_FLASH</td><td>console</td><td>bool</td><td>SPI Flash console output</td><td>
Send coreboot debug output to the SPI Flash in the FMAP CONSOLE area<br />
<br />
This option can cause premature wear on the SPI flash and should not<br />
be used as a normal means of debugging. It is only to be enabled and<br />
used when porting a new motherboard which has no other console<br />
available (no UART, no POST, no cbmem access(non bootable)). Since<br />
a non bootable machine will require the use of an external SPI Flash<br />
programmer, the developer can grab the console log at the same time.<br />
<br />
The flash console will not be erased on reboot, so once it is full,<br />
the flashconsole driver will stop writing to it. This is to avoid<br />
wear on the flash, and to avoid erasing sectors (which may freeze<br />
the SPI controller on skylake).<br />
<br />
The 'CONSOLE' area can be extracted from the FMAP with :<br />
cbfstool rom.bin read -r CONSOLE -f console.log<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SPI_FLASH_BUFFER_SIZE</td><td>console</td><td>hex</td><td>Room allocated for console output in FMAP</td><td>
Space allocated for console output storage in FMAP. The default<br />
value (128K or 0x20000 bytes) is large enough to accommodate<br />
even the BIOS_SPEW level.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_QEMU_DEBUGCON</td><td>console</td><td>bool</td><td>QEMU debug console output</td><td>
Send coreboot debug output to QEMU's isa-debugcon device:<br />
<br />
qemu-system-x86_64 \<br />
-chardev file,id=debugcon,path=/dir/file.log \<br />
-device isa-debugcon,iobase=0x402,chardev=debugcon<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EM100PRO_SPI_CONSOLE</td><td>console</td><td>bool</td><td>EM100Pro SPI debug console output</td><td>
Enable support for the debug console on the Dediprog EM100Pro.<br />
This is currently working only in ramstage due to how the spi<br />
drivers are written.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_SYSTEM76_EC</td><td>console</td><td>bool</td><td>System76 EC console output</td><td>
Send coreboot debug output to a System76 embedded controller.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_OVERRIDE_LOGLEVEL</td><td>console</td><td>bool</td><td></td><td>
Set to "y" when the platform overrides the loglevel by providing<br />
a get_console_loglevel routine.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_8</td><td>console</td><td>bool</td><td>8: SPEW</td><td>
Way too many details.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_7</td><td>console</td><td>bool</td><td>7: DEBUG</td><td>
Debug-level messages.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_6</td><td>console</td><td>bool</td><td>6: INFO</td><td>
Informational messages.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_5</td><td>console</td><td>bool</td><td>5: NOTICE</td><td>
Normal but significant conditions.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_4</td><td>console</td><td>bool</td><td>4: WARNING</td><td>
Warning conditions.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_3</td><td>console</td><td>bool</td><td>3: ERR</td><td>
Error conditions.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_2</td><td>console</td><td>bool</td><td>2: CRIT</td><td>
Critical conditions.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_1</td><td>console</td><td>bool</td><td>1: ALERT</td><td>
Action must be taken immediately.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL_0</td><td>console</td><td>bool</td><td>0: EMERG</td><td>
System is unusable.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEFAULT_CONSOLE_LOGLEVEL</td><td>console</td><td>int</td><td></td><td>
Map the log level config names to an integer.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CMOS_POST</td><td>console</td><td>bool</td><td>Store post codes in CMOS for debugging</td><td>
If enabled, coreboot will store post codes in CMOS and switch between<br />
two offsets on each boot so the last post code in the previous boot<br />
can be retrieved.  This uses 3 bytes of CMOS.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CMOS_POST_OFFSET</td><td>console</td><td>hex</td><td>Offset into CMOS to store POST codes</td><td>
If CMOS_POST is enabled then an offset into CMOS must be provided.<br />
If CONFIG_HAVE_OPTION_TABLE is enabled then it will use the value<br />
defined in the mainboard option table.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CONSOLE_POST</td><td>console</td><td>bool</td><td>Show POST codes on the debug console</td><td>
If enabled, coreboot will additionally print POST codes (which are<br />
usually displayed using a so-called "POST card" ISA/PCI/PCI-E<br />
device) on the debug console.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POST_IO</td><td>console</td><td>bool</td><td>Send POST codes to an IO port</td><td>
If enabled, POST codes will be written to an IO port.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POST_IO_PORT</td><td>console</td><td>hex</td><td>IO port for POST codes</td><td>
POST codes on x86 are typically written to the LPC bus on port<br />
0x80. However, it may be desirable to change the port number<br />
depending on the presence of coprocessors/microcontrollers or if the<br />
platform does not support IO in the conventional x86 manner.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_EARLY_BOOTBLOCK_POSTCODES</td><td>console</td><td>hex</td><td></td><td>
Some chipsets require that the routing for the port 80h POST<br />
code be configured before any POST codes are sent out.<br />
This can be done in the boot block, but there are a couple of<br />
POST codes that go out before the chipset's bootblock initialization<br />
can happen.  This option suppresses those POST codes.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>DISABLE_ACPI_HIBERNATE</td><td>toplevel</td><td>bool</td><td></td><td>
Removes S4 from the available sleepstates<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RESUME_PATH_SAME_AS_BOOT</td><td>toplevel</td><td>bool</td><td></td><td>
This option indicates that when a system resumes it takes the<br />
same path as a regular boot. e.g. an x86 system runs from the<br />
reset vector at 0xfffffff0 on both resume and warm/cold boot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_MONOTONIC_TIMER</td><td>toplevel</td><td>bool</td><td></td><td>
The board/chipset provides a monotonic timer.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GENERIC_UDELAY</td><td>toplevel</td><td>bool</td><td></td><td>
The board/chipset uses a generic udelay function utilizing the<br />
monotonic timer.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIMER_QUEUE</td><td>toplevel</td><td>bool</td><td></td><td>
Provide a timer queue for performing time-based callbacks.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COOP_MULTITASKING</td><td>toplevel</td><td>bool</td><td></td><td>
Cooperative multitasking allows callbacks to be multiplexed on the<br />
main thread of ramstage. With this enabled it allows for multiple<br />
execution paths to take place when they have udelay() calls within<br />
their code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NUM_THREADS</td><td>toplevel</td><td>int</td><td></td><td>
How many execution threads to cooperatively multitask with.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_OPTION_TABLE</td><td>toplevel</td><td>bool</td><td></td><td>
This variable specifies whether a given board has a cmos.layout<br />
file containing NVRAM/CMOS bit definitions.<br />
It defaults to 'n' but can be selected in mainboard/*/Kconfig.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GFXUMA</td><td>toplevel</td><td>bool</td><td></td><td>
Enable Unified Memory Architecture for graphics.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_MP_TABLE</td><td>toplevel</td><td>bool</td><td></td><td>
This variable specifies whether a given board has MP table support.<br />
It is usually set in mainboard/*/Kconfig.<br />
Whether or not the MP table is actually generated by coreboot<br />
is configurable by the user via GENERATE_MP_TABLE.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_PIRQ_TABLE</td><td>toplevel</td><td>bool</td><td></td><td>
This variable specifies whether a given board has PIRQ table support.<br />
It is usually set in mainboard/*/Kconfig.<br />
Whether or not the PIRQ table is actually generated by coreboot<br />
is configurable by the user via GENERATE_PIRQ_TABLE.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ACPI_NHLT</td><td>toplevel</td><td>bool</td><td></td><td>
Build support for NHLT (non HD Audio) ACPI table generation.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: System tables</td></tr>
<tr bgcolor="#eeeeee">
<td>GENERATE_MP_TABLE</td><td>toplevel</td><td>bool</td><td>Generate an MP table</td><td>
Generate an MP table (conforming to the Intel MultiProcessor<br />
specification 1.4) for this board.<br />
<br />
If unsure, say Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GENERATE_PIRQ_TABLE</td><td>toplevel</td><td>bool</td><td>Generate a PIRQ table</td><td>
Generate a PIRQ table for this board.<br />
<br />
If unsure, say Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GENERATE_SMBIOS_TABLES</td><td>toplevel</td><td>bool</td><td>Generate SMBIOS tables</td><td>
Generate SMBIOS tables for this board.<br />
<br />
If unsure, say Y.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_SERIAL_NUMBER</td><td>toplevel</td><td>string</td><td>SMBIOS Serial Number</td><td>
The Serial Number to store in SMBIOS structures.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_VERSION</td><td>toplevel</td><td>string</td><td>SMBIOS Version Number</td><td>
The Version Number to store in SMBIOS structures.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_SMBIOS_MANUFACTURER</td><td>toplevel</td><td>string</td><td>SMBIOS Manufacturer</td><td>
Override the default Manufacturer stored in SMBIOS structures.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_SMBIOS_PRODUCT_NAME</td><td>toplevel</td><td>string</td><td>SMBIOS Product name</td><td>
Override the default Product name stored in SMBIOS structures.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VPD_SMBIOS_VERSION</td><td>toplevel</td><td>bool</td><td>Populates SMBIOS type 0 version from the VPD_RO variable 'firmware_version'</td><td>
Selecting this option will read firmware_version from<br />
VPD_RO and override SMBIOS type 0 version. One special<br />
scenario of using this feature is to assign a BIOS version<br />
to a coreboot image without the need to rebuild from source.<br />
<br />
</td></tr>

<tr bgcolor="#6699dd">
<td colspan=5>Menu: Payload</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_NONE</td><td>payloads</td><td>bool</td><td>None</td><td>
Select this option if you want to create an "empty" coreboot<br />
ROM image for a certain mainboard, i.e. a coreboot ROM image<br />
which does not yet contain a payload.<br />
<br />
For such an image to be useful, you have to use 'cbfstool'<br />
to add a payload to the ROM image later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_ELF</td><td>payloads</td><td>bool</td><td>An ELF executable payload</td><td>
Select this option if you have a payload image (an ELF file)<br />
which coreboot should run as soon as the basic hardware<br />
initialization is completed.<br />
<br />
You will be able to specify the location and file name of the<br />
payload image later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_FIT</td><td>payloads</td><td>bool</td><td>A FIT payload</td><td>
Select this option if you have a payload image (a FIT file) which<br />
coreboot should run as soon as the basic hardware initialization<br />
is completed.<br />
<br />
You will be able to specify the location and file name of the<br />
payload image later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_DEPTHCHARGE</td><td>payloads/external/depthcharge.name</td><td>bool</td><td>Depthcharge</td><td>
Select this option if you want to build a coreboot image<br />
with a depthcharge payload.<br />
<br />
See https://coreboot.org/Payloads for more information.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_FILO</td><td>payloads/external/FILO.name</td><td>bool</td><td>FILO</td><td>
Select this option if you want to build a coreboot image<br />
with a FILO payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See https://coreboot.org/Payloads for more information.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_SEABIOS</td><td>payloads/external/SeaBIOS.name</td><td>bool</td><td>SeaBIOS</td><td>
Select this option if you want to build a coreboot image<br />
with a SeaBIOS payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See https://coreboot.org/Payloads for more information.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_TIANOCORE</td><td>payloads/external/tianocore.name</td><td>bool</td><td>Tianocore payload</td><td>
Select this option if you want to build a coreboot image<br />
with a Tianocore payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See https://coreboot.org/Payloads for more information.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_LINUX</td><td>payloads/external/linux.name</td><td>bool</td><td>A Linux payload</td><td>
Select this option if you have a Linux bzImage which coreboot<br />
should run as soon as the basic hardware initialization<br />
is completed.<br />
<br />
You will be able to specify the location and file name of the<br />
payload image later.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_YABITS</td><td>payloads/external/Yabits.name</td><td>bool</td><td>Yabits - Yet another UEFI Bootloader (Under Development)</td><td>
Yabits - yabits.github.io<br />
yabits is a pure UEFI coreboot payload. Compared with<br />
TianoCore, it is fast and lightweight. yabits is based on the<br />
part of Minoca OS. It can run GRUB2, Linux, OpenBSD, and other<br />
UEFI applications.<br />
<br />
It is still under the development and not ready for production.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_BOOTBOOT</td><td>payloads/external/BOOTBOOT.name</td><td>bool</td><td>BOOTBOOT</td><td>
Select this option if you want to build a coreboot image<br />
with a BOOTBOOT Protocol payload.<br />
<br />
See https://gitlab.com/bztsrc/bootboot for more information.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_LINUXBOOT</td><td>payloads/external/LinuxBoot.name</td><td>bool</td><td>LinuxBoot</td><td>
Select this option if you want to build a coreboot image<br />
with a LinuxBoot payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See https://coreboot.org/Payloads for more information.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_UBOOT</td><td>payloads/external/U-Boot.name</td><td>bool</td><td>U-Boot (Experimental)</td><td>
Select this option if you want to build a coreboot image<br />
with a U-Boot payload.<br />
<br />
See https://coreboot.org/Payloads and U-Boot's documentation<br />
at http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.x86<br />
for more information.<br />
<br />
</td></tr>
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_GRUB2</td><td>payloads/external/GRUB2.name</td><td>bool</td><td>GRUB2</td><td>
Select this option if you want to build a coreboot image<br />
with a GRUB2 payload. If you don't know what this is<br />
about, just leave it enabled.<br />
<br />
See https://coreboot.org/Payloads for more information.<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEPTHCHARGE_STABLE</td><td>payloads/external/depthcharge</td><td>bool</td><td>stable</td><td>
Latest stable version.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEPTHCHARGE_MASTER</td><td>payloads/external/depthcharge</td><td>bool</td><td>master</td><td>
Newest Depthcharge version.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEPTHCHARGE_REVISION</td><td>payloads/external/depthcharge</td><td>bool</td><td>git revision</td><td>
Select this option if you have a specific commit or branch that<br />
you want to use as the revision from which to build Depthcharge.<br />
<br />
You will be able to specify the name of a branch or a commit SHA<br />
later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEPTHCHARGE_REVISION_ID</td><td>payloads/external/depthcharge</td><td>string</td><td>Insert a commit's SHA-1 or a branch name</td><td>
The commit's SHA-1 or branch name of the revision to use.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAINBOARD_DEPTHCHARGE</td><td>payloads/external/depthcharge</td><td>string</td><td></td><td>
Override BOARD setting for depthcharge<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LP_DEFCONFIG_OVERRIDE</td><td>payloads/external/depthcharge</td><td>bool</td><td>Use default libpayload config</td><td>
The Depthcharge makefile looks for a file config.&lt;boardname&gt; in the<br />
libpayload/configs directory.  Say Y here to use the file defconfig<br />
instead.  This is can be a convenience for development purposes, or<br />
if the defaults in defconfig are sufficient for your system.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FILO_STABLE</td><td>payloads/external/FILO</td><td>bool</td><td>tested</td><td>
Tested FILO version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FILO_MASTER</td><td>payloads/external/FILO</td><td>bool</td><td>HEAD</td><td>
Newest FILO version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_STABLE</td><td>payloads/external/SeaBIOS</td><td>bool</td><td>1.14.0</td><td>
Stable SeaBIOS version<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_MASTER</td><td>payloads/external/SeaBIOS</td><td>bool</td><td>master</td><td>
Newest SeaBIOS version<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_REVISION</td><td>payloads/external/SeaBIOS</td><td>bool</td><td>git revision</td><td>
Select this option if you have a specific commit or branch<br />
that you want to use as the revision from which to<br />
build SeaBIOS.<br />
<br />
You will be able to specify the name of a branch or a commit id<br />
later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_REVISION_ID</td><td>payloads/external/SeaBIOS</td><td>string</td><td>Insert a commit's SHA-1 or a branch name</td><td>
The commit's SHA-1 or branch name of the revision to use.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_PS2_TIMEOUT</td><td>payloads/external/SeaBIOS</td><td>int</td><td>PS/2 keyboard controller initialization timeout (milliseconds)</td><td>
Some PS/2 keyboard controllers don't respond to commands immediately<br />
after powering on. This specifies how long SeaBIOS will wait for the<br />
keyboard controller to become ready before giving up.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_THREAD_OPTIONROMS</td><td>payloads/external/SeaBIOS</td><td>bool</td><td>Hardware init during option ROM execution</td><td>
Allow hardware init to run in parallel with optionrom execution.<br />
<br />
This can reduce boot time, but can cause some timing<br />
variations during option ROM code execution. It is not<br />
known if all option ROMs will behave properly with this option.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_HARDWARE_IRQ</td><td>payloads/external/SeaBIOS</td><td>bool</td><td>Hardware Interrupts</td><td>
Program and support hardware interrupts using the i8259<br />
programmable interrupt controller (PIC).  Deselected by<br />
boards which would otherwise hang at the boot menu (eg,<br />
google/rambi).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_VGA_COREBOOT</td><td>payloads/external/SeaBIOS</td><td>bool</td><td>Include generated option rom that implements legacy VGA BIOS compatibility</td><td>
coreboot can initialize the GPU of some mainboards.<br />
<br />
After initializing the GPU, the information about it can be passed to the payload.<br />
Provide an option rom that implements this legacy VGA BIOS compatibility requirement.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_CONFIGFILE</td><td>payloads/external/SeaBIOS</td><td>string</td><td>SeaBIOS config file</td><td>
This option allows a platform to set Kconfig options for a basic<br />
SeaBIOS payload.  In general, if the option is used, the default<br />
would be "$(top)/src/mainboard/$(MAINBOARDDIR)/config_seabios"<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_BOOTORDER_FILE</td><td>payloads/external/SeaBIOS</td><td>string</td><td>SeaBIOS bootorder file</td><td>
Add a SeaBIOS bootorder file.  From the wiki:<br />
"The bootorder file may be used to configure the boot up order. The file<br />
should be ASCII text and contain one line per boot method. The description<br />
of each boot method follows an Open Firmware device path format. SeaBIOS<br />
will attempt to boot from each item in the file - first line of the file<br />
first."<br />
<br />
See: https://www.coreboot.org/SeaBIOS#Configuring_boot_order<br />
<br />
If used, a typical value would be:<br />
$(top)/src/mainboard/$(MAINBOARDDIR)/bootorder<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_ADD_SERCON_PORT_FILE</td><td>payloads/external/SeaBIOS</td><td>bool</td><td>Add SeaBIOS sercon-port file to CBFS</td><td>
Select this option to enable SeaBIOS' VGA adapter emulation<br />
on serial port.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_SERCON_PORT_ADDR</td><td>payloads/external/SeaBIOS</td><td>hex</td><td>SeaBIOS sercon-port base address</td><td>
Set this field to the IO address of a serial port for SeaBIOS' VGA<br />
adapter emulation.<br />
<br />
By default primary console UART defined by TTYS0_BASE is used.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SEABIOS_DEBUG_LEVEL</td><td>payloads/external/SeaBIOS</td><td>int</td><td>SeaBIOS debug level (verbosity)</td><td>
The higher the number, the more verbose SeaBIOS will be. See the table<br />
below for the current values corresponding to various items as of SeaBIOS<br />
version 1.10.1. Set this value to -1 to use SeaBIOS' default.<br />
<br />
Output at various SeaBIOS log levels:<br />
level 0  - Logging disabled<br />
level 1  - Basic output, interrupts 5, 18h, 19h, 40h, SMP, PNP, PMM<br />
level 2  - AHCI, Floppy, Basic ps2, interrupts 11h, 12h, 14h, 17h<br />
level 3  - bootsplash, initializations, SeaBIOS VGA BIOS interrupts<br />
level 4  - BIOS tables, more optionrom<br />
level 5  - Extra bootsplash, more XHCI<br />
level 6  - ATA commands, extra optionrom<br />
level 7  - extra ps2 commands, more OHCI &amp; EHCI<br />
level 8  - extra malloc info, more AHCI<br />
level 9  - interrupts 15h, 16h, 1ah, APM, PCI, SMIs, PCIBIOS,<br />
USB-HID commands, SDcard commands, Floppy commands<br />
level 10 - interrupt 13h (Drives other than floppy)<br />
level 20 - interrupt 10h (Display)<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>payloads/external/SeaBIOS</td><td>(comment)</td><td></td><td>Using default SeaBIOS log level</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>payloads/external/SeaBIOS</td><td>(comment)</td><td></td><td>SeaBIOS logging disabled</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_FILE</td><td>payloads/external/tianocore</td><td>string</td><td>Tianocore binary</td><td>
The result of a corebootPkg build<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_FILE</td><td>payloads/external/tianocore</td><td>string</td><td>Tianocore payload</td><td>
Select which type of payload Tianocore will build (default is CorebootPayload)<br />
CorebootPayload: MrChromebox's customized version of Tianocore which works on most<br />
(all?) x86_64 devices<br />
UEFIPayload: Use upstream Tianocore payload from https://github.com/tianocore/edk2<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_COREBOOTPAYLOAD</td><td>payloads/external/tianocore</td><td>bool</td><td>CorebootPayload</td><td>
Select this option to build using MrChromebox's custom Tianocore tree<br />
i.e. a version of Tianocore that builds without any errors and just works.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_UEFIPAYLOAD</td><td>payloads/external/tianocore</td><td>bool</td><td>UEFIPayload</td><td>
Select this option if you want to use upstream EDK2 to build Tianocore.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_REVISION_ID</td><td>payloads/external/tianocore</td><td>string</td><td>Insert a commit's SHA-1 or a branch name</td><td>
The commit's SHA-1 or branch name of the revision to use. Choose "upstream/master"<br />
for master branch of Tianocore release on github.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_REVISION_ID</td><td>payloads/external/tianocore</td><td>string</td><td>Target architecture</td><td>
The Tianocore coreboot Payload Package binary can be<br />
built for either only IA32 or both X64 and IA32 architectures.<br />
Select which architecture(s) to build for; default is to build<br />
for both X64 and IA32.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_TARGET_IA32</td><td>payloads/external/tianocore</td><td>bool</td><td>IA32</td><td>
By selecting this option, the target architecture will be built<br />
for only IA32.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_TARGET_X64</td><td>payloads/external/tianocore</td><td>bool</td><td>X64</td><td>
By selecting this option, the target architecture will be built<br />
for X64 and IA32.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_TARGET_X64</td><td>payloads/external/tianocore</td><td>bool</td><td>Tianocore build</td><td>
Select whether to generate a debug or release build for<br />
Tianocore; default is to generate a release build.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_DEBUG</td><td>payloads/external/tianocore</td><td>bool</td><td>Generate Tianocore debug build</td><td>
Generate a debug build.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_RELEASE</td><td>payloads/external/tianocore</td><td>bool</td><td>Generate Tianocore release build</td><td>
Generate a release build.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_USE_8254_TIMER</td><td>payloads/external/tianocore</td><td>bool</td><td>TianoCore 8254 Timer</td><td>
Use 8254 Timer for legacy support.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_BOOTSPLASH_IMAGE</td><td>payloads/external/tianocore</td><td>bool</td><td>Use a custom bootsplash image</td><td>
Select this option if you have a bootsplash image that you would<br />
like to be used. If this option is not selected, the default<br />
coreboot logo (European Brown Hare) will used.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_BOOTSPLASH_FILE</td><td>payloads/external/tianocore</td><td>string</td><td>Tianocore Bootsplash path and filename</td><td>
The path and filename of the file to use as graphical bootsplash<br />
screen. The file format must be uncompressed BMP, and the file's<br />
resolution must be less than the native resolution of the display.<br />
<br />
If an absolute path is not given, the path will assumed to be<br />
relative to the coreboot root directory.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TIANOCORE_BOOT_TIMEOUT</td><td>payloads/external/tianocore</td><td>int</td><td></td><td>
The length of time in seconds for which the boot splash/menu prompt will be displayed.<br />
For boards with an internal display, the default value of 2s is generally sufficient.<br />
For boards without an internal display, a value of 5s is generally sufficient.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_FILE</td><td>payloads/external/linux</td><td>string</td><td>Linux path and filename</td><td>
The path and filename of the bzImage kernel to use as payload.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUX_COMMAND_LINE</td><td>payloads/external/linux</td><td>string</td><td>Linux command line</td><td>
A command line to add to the Linux kernel.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUX_INITRD</td><td>payloads/external/linux</td><td>string</td><td>Linux initrd</td><td>
An initrd image to add to the Linux kernel.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABITS_STABLE</td><td>payloads/external/Yabits</td><td>bool</td><td>Stable</td><td>
Stable Yabits version.<br />
<br />
For reproducible builds, this option must be selected.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABITS_MASTER</td><td>payloads/external/Yabits</td><td>bool</td><td>Master</td><td>
Newest version.<br />
<br />
This option will fetch the newest version of the Yabits code,<br />
updating as new changes are committed.  This makes the build<br />
non-reproducible, as it can fetch different code each time.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABITS_REVISION</td><td>payloads/external/Yabits</td><td>bool</td><td>git revision</td><td>
Select this option if you have a specific commit or branch<br />
that you want to use as the revision from which to<br />
build Yabits.  Using a branch name makes the build<br />
non-reproducible, as it can fetch different code as the<br />
branch changes.<br />
<br />
You will be able to specify the name of a branch or a commit id<br />
later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>YABITS_REVISION_ID</td><td>payloads/external/Yabits</td><td>string</td><td>Insert a commit's SHA-1 or a branch name</td><td>
The commit's SHA-1 or branch name of the revision to use.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_X86_64</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>x86_64</td><td>
AMD64 kernel and initramfs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_X86</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>x86</td><td>
X86 kernel and initramfs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_ARM64</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>arm64</td><td>
AARCH64 kernel and initramfs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_RISCV</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>RISC-V</td><td>
RISC-V kernel and initramfs<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>payloads/external/LinuxBoot</td><td>(comment)</td><td></td><td>Linux kernel</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>payloads/external/LinuxBoot</td><td>(comment)</td><td></td><td>parse linux crosscompiler with: LINUXBOOT_CROSS_COMPILE</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_PATH</td><td>payloads/external/LinuxBoot</td><td>string</td><td>Kernel release</td><td>
Choose the kernel release.<br />
<br />
Select 'custom' if your want to define the kernel version.<br />
For more information about the current 'mainline', 'stable' or 'longterm'<br />
version, visit: https://www.kernel.org/<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_MAINLINE</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>mainline</td><td>
Mainline kernel version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_STABLE</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>stable</td><td>
Stable kernel version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_LONGTERM</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>longterm</td><td>
Longterm (LTS) kernel version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_CUSTOM</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>custom</td><td>
Custom kernel version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_CUSTOM_VERSION</td><td>payloads/external/LinuxBoot</td><td>string</td><td>kernel version</td><td>
Choose the Linux kernel version number. (x.x.x)<br />
Release candidate kernels (rc) are currently are not supported.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_ARCH_DEFAULT_CONFIG</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>Default architecture configuration</td><td>
This option will use the default configuration for the<br />
selected architecture.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_KERNEL_CONFIGFILE</td><td>payloads/external/LinuxBoot</td><td>string</td><td>Config file path</td><td>
Path to the kernel configuration file.<br />
<br />
Note: this can be a defconfig file or a complete .config file.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUX_COMMAND_LINE</td><td>payloads/external/LinuxBoot</td><td>string</td><td>Kernel command-line</td><td>
Add your own kernel command-line arguments.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>payloads/external/LinuxBoot</td><td>(comment)</td><td></td><td>Linux initramfs</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>u-root</td><td>
Enable u-root linuxboot mode.<br />
See http://u-root.tk/ for more information.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT_CUSTOM</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>custom</td><td>
choose a custom u-root branch<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT_MASTER</td><td>payloads/external/LinuxBoot</td><td>bool</td><td>master</td><td>
Latest u-root version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT_VERSION</td><td>payloads/external/LinuxBoot</td><td>string</td><td>Build format</td><td>
u-root build format (e.g. bb or source). (default "bb")<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT_FILES</td><td>payloads/external/LinuxBoot</td><td>string</td><td>Add files to u-root base</td><td>
Additional files, directories, and binaries (with their ldd dependencies) to add to archive.<br />
Can be speficified multiple times.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT_INITCMD</td><td>payloads/external/LinuxBoot</td><td>string</td><td>Init target</td><td>
Symlink target for /init.<br />
Can be an absolute path or a u-root command name. (default "init")<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT_SHELL</td><td>payloads/external/LinuxBoot</td><td>string</td><td>default shell</td><td>
Default shell.<br />
Can be an absolute path or a u-root command name. (default "elvish")<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>LINUXBOOT_UROOT_COMMANDS</td><td>payloads/external/LinuxBoot</td><td>string</td><td>U-root commands</td><td>
List of additional modules to include,<br />
separated by space. (default "coreboot-app")<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UBOOT_STABLE</td><td>payloads/external/U-Boot</td><td>bool</td><td>v2019.4</td><td>
Stable U-Boot version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>UBOOT_MASTER</td><td>payloads/external/U-Boot</td><td>bool</td><td>master</td><td>
Newest U-Boot version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_CONFIGFILE</td><td>payloads/external/U-Boot</td><td>string</td><td>U-Boot config file</td><td>
This option allows a platform to set Kconfig options for a basic<br />
U-Boot payload.  In general, if the option is used, the default<br />
would be "$(top)/src/mainboard/$(MAINBOARDDIR)/config_uboot"<br />
for a config stored in the coreboot mainboard directory, or<br />
"$(project_dir)/configs/coreboot-x86_defconfig" to use a config<br />
from the U-Boot config directory<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GRUB2_STABLE</td><td>payloads/external/GRUB2</td><td>bool</td><td>2.04</td><td>
Stable GRUB2 version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GRUB2_MASTER</td><td>payloads/external/GRUB2</td><td>bool</td><td>HEAD</td><td>
Newest GRUB2 version<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GRUB2_REVISION</td><td>payloads/external/GRUB2</td><td>bool</td><td>git revision</td><td>
Select this option if you have a specific commit or branch<br />
that you want to use as the revision from which to<br />
build GRUB2.<br />
<br />
You will be able to specify the name of a branch or a commit id<br />
later.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GRUB2_REVISION_ID</td><td>payloads/external/GRUB2</td><td>string</td><td>Insert a commit's SHA-1 or a branch name</td><td>
The commit's SHA-1 or branch name of the revision to use.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GRUB2_EXTRA_MODULES</td><td>payloads/external/GRUB2</td><td>string</td><td>Extra modules to include in GRUB image</td><td>
Space-separated list of additional modules to include. Few common<br />
ones:<br />
* bsd for *BSD<br />
* png/jpg for PNG/JPG images<br />
* gfxmenu for graphical menus (you'll need a theme as well)<br />
* gfxterm_background for setting background<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GRUB2_INCLUDE_RUNTIME_CONFIG_FILE</td><td>payloads/external/GRUB2</td><td>bool</td><td>Include GRUB2 runtime config file into ROM image</td><td>
The GRUB2 payload reads its runtime configuration file from etc/grub.cfg<br />
stored in the CBFS on the flash ROM chip. Without that, it’ll just drop<br />
into a rescue shell.<br />
<br />
This configuration may need to be coreboot specific.<br />
<br />
Select this option, if you want to include the GRUB2 runtime<br />
configuration file into CBFS as `etc/grub.cfg` automatically.<br />
<br />
You will be able to specify the path of the configuration file later.<br />
<br />
Without this option you would need to add this file manually with<br />
build/cbfstool build/coreboot.rom add -f grub.cfg -n etc/grub.cfg -t raw<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GRUB2_RUNTIME_CONFIG_FILE</td><td>payloads/external/GRUB2</td><td>string</td><td>Path of grub.cfg</td><td>
The path of the GRUB2 runtime configuration file to be added to CBFS.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: PXE Options</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_ROM</td><td>payloads/external/iPXE</td><td>bool</td><td>Add an existing PXE ROM image</td><td>
Select this option if you have a PXE ROM image that you would<br />
like to add to your ROM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>BUILD_IPXE</td><td>payloads/external/iPXE</td><td>bool</td><td>Build and add an iPXE ROM</td><td>
Select this option to fetch and build a ROM from the iPXE project.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPXE_STABLE</td><td>payloads/external/iPXE</td><td>bool</td><td>2019.3</td><td>
iPXE uses a rolling release with no stable version, for<br />
reproducibility, use the last commit of a given month as the<br />
'stable' version.<br />
This is iPXE from the end of March, 2019.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>IPXE_MASTER</td><td>payloads/external/iPXE</td><td>bool</td><td>master</td><td>
Newest iPXE version.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_ROM_FILE</td><td>payloads/external/iPXE</td><td>string</td><td>PXE ROM filename</td><td>
The path and filename of the file to use as PXE ROM.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_ROM_ID</td><td>payloads/external/iPXE</td><td>string</td><td>network card PCI IDs</td><td>
The comma-separated PCI vendor and device ID that would associate<br />
your PXE ROM to your network card.<br />
<br />
Example: 10ec,8168<br />
<br />
In the above example 10ec is the PCI vendor ID (in hex, but without<br />
the "0x" prefix) and 8168 specifies the PCI device ID of the<br />
network card (also in hex, without "0x" prefix).<br />
<br />
Under GNU/Linux you can run `lspci -nn` to list the IDs of your PCI devices.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_SERIAL_CONSOLE</td><td>payloads/external/iPXE</td><td>bool</td><td>Enable iPXE serial console</td><td>
Enable/disable iPXE serial console. Since SeaBIOS supports serial<br />
console this option might be helpful to avoid duplicated output.<br />
<br />
Unselect to let only SeaBIOS handle printing output.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_NO_PROMPT</td><td>payloads/external/iPXE</td><td>bool</td><td>Do not show prompt to boot from PXE</td><td>
Don't wait for the user to press Ctrl-B.<br />
The PXE still can be run as it shows up in SeaBIOS's payload list.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_ADD_SCRIPT</td><td>payloads/external/iPXE</td><td>bool</td><td>Embed an iPXE script for automated provisioning</td><td>
Enable to embed a script that is run instead of an iPXE shell.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_SCRIPT</td><td>payloads/external/iPXE</td><td>string</td><td>Embedded iPXE script path and filename</td><td>
Path to a script that is embedded into the iPXE binary.<br />
Example: startup.ipxe<br />
<br />
Uses the ipxe script instead showing the prompt:<br />
"Press Ctrl-B to start iPXE..."<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PXE_HAS_HTTPS</td><td>payloads/external/iPXE</td><td>bool</td><td>Enable HTTPS protocol</td><td>
Enable HTTPS protocol, which allows you to encrypt all communication<br />
with a web server and to verify the server's identity<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>PAYLOAD_FILE</td><td>payloads</td><td>string</td><td>Payload path and filename</td><td>
The path and filename of the ELF executable file to use as payload.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_FILE</td><td>payloads</td><td>string</td><td>Payload compression algorithm</td><td>
Choose the compression algorithm for the chosen payloads.<br />
You can choose between None, LZMA, or LZ4.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPRESSED_PAYLOAD_NONE</td><td>payloads</td><td>bool</td><td>Use no compression for payloads</td><td>
Do not compress the payload.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPRESSED_PAYLOAD_LZMA</td><td>payloads</td><td>bool</td><td>Use LZMA compression for payloads</td><td>
In order to reduce the size payloads take up in the ROM chip<br />
coreboot can compress them using the LZMA algorithm.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPRESSED_PAYLOAD_LZ4</td><td>payloads</td><td>bool</td><td>Use LZ4 compression for payloads</td><td>
In order to reduce the size payloads take up in the ROM chip<br />
coreboot can compress them using the LZ4 algorithm.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_OPTIONS</td><td>payloads</td><td>string</td><td></td><td>
Additional cbfstool options for the payload<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_IS_FLAT_BINARY</td><td>payloads</td><td>string</td><td></td><td>
Add the payload to cbfs as a flat binary type instead of as an<br />
elf payload<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>PAYLOAD_FIT_SUPPORT</td><td>payloads</td><td>bool</td><td>FIT support</td><td>
Select this option if your payload is of type FIT.<br />
Enables FIT parser and devicetree patching. The FIT is non<br />
self-extracting and needs to have a compatible compression format.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>COMPRESS_SECONDARY_PAYLOAD</td><td>payloads</td><td>bool</td><td>Use LZMA compression for secondary payloads</td><td>
In order to reduce the size secondary payloads take up in the<br />
ROM chip they can be compressed using the LZMA algorithm.<br />
<br />
</td></tr>
<tr bgcolor="#6699dd">
<td colspan=5>Menu: Secondary Payloads</td></tr>
<tr bgcolor="#eeeeee">
<td>COREINFO_SECONDARY_PAYLOAD</td><td>payloads</td><td>bool</td><td>Load coreinfo as a secondary payload</td><td>
coreinfo can be loaded as a secondary payload under SeaBIOS, GRUB,<br />
or any other payload that can load additional payloads.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MEMTEST_SECONDARY_PAYLOAD</td><td>payloads</td><td>bool</td><td>Load Memtest86+ as a secondary payload</td><td>
Memtest86+ can be loaded as a secondary payload under SeaBIOS, GRUB,<br />
or any other payload that can load additional payloads.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NVRAMCUI_SECONDARY_PAYLOAD</td><td>payloads</td><td>bool</td><td>Load nvramcui as a secondary payload</td><td>
nvramcui can be loaded as a secondary payload under SeaBIOS, GRUB,<br />
or any other payload that can load additional payloads.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>TINT_SECONDARY_PAYLOAD</td><td>payloads</td><td>bool</td><td>Load tint as a secondary payload</td><td>
tint can be loaded as a secondary payload under SeaBIOS, GRUB,<br />
or any other payload that can load additional payloads.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MEMTEST_STABLE</td><td>payloads/external/Memtest86Plus.secondary</td><td>bool</td><td>Stable</td><td>
Stable Memtest86+ version.<br />
<br />
For reproducible builds, this option must be selected.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MEMTEST_MASTER</td><td>payloads/external/Memtest86Plus.secondary</td><td>bool</td><td>Master</td><td>
Newest Memtest86+ version.<br />
<br />
This option will fetch the newest version of the Memtest86+ code,<br />
updating as new changes are committed.  This makes the build<br />
non-reproducible, as it can fetch different code each time.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MEMTEST_REVISION</td><td>payloads/external/Memtest86Plus.secondary</td><td>bool</td><td>git revision</td><td>
Select this option if you have a specific commit or branch<br />
that you want to use as the revision from which to<br />
build Memtest86+.  This makes the build<br />
non-reproducible, as it can fetch different code each time.<br />
<br />
You will be able to specify the name of a branch or a commit id<br />
later.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MEMTEST_REVISION_ID</td><td>payloads/external/Memtest86Plus.secondary</td><td>string</td><td>Insert a commit's SHA-1 or a branch name</td><td>
The commit's SHA-1 or branch name of the revision to use.<br />
<br />
</td></tr>


<tr bgcolor="#6699dd">
<td colspan=5>Menu: Debugging</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>CPU Debug Settings</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>BLOB Debug Settings</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_FSP_CALLS_AND_STATUS</td><td>drivers/intel/fsp2_0.debug_blob</td><td>bool</td><td>Display the FSP calls and status</td><td>
Display the FSP call entry point and parameters prior to calling FSP<br />
and display the status upon return from FSP.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_FSP_HEADER</td><td>drivers/intel/fsp2_0.debug_blob</td><td>bool</td><td>Display the FSP header</td><td>
Display the FSP header information when the FSP file is found.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_HOBS</td><td>drivers/intel/fsp2_0.debug_blob</td><td>bool</td><td>Display the hand-off-blocks</td><td>
Display the FSP HOBs which are provided for coreboot.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_UPD_DATA</td><td>drivers/intel/fsp2_0.debug_blob</td><td>bool</td><td>Display UPD data</td><td>
Display the user specified product data prior to memory<br />
initialization.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>VERIFY_HOBS</td><td>drivers/intel/fsp2_0.debug_blob</td><td>bool</td><td>Verify the FSP hand-off-blocks</td><td>
Verify that the HOBs required by coreboot are returned by FSP and<br />
that the resource HOBs are in the correct order and position.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DISPLAY_FSP_VERSION_INFO</td><td>drivers/intel/fsp2_0.debug_blob</td><td>bool</td><td>Display Firmware Ingredient Version Information</td><td>
Select this option to display Firmware version information.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td></td><td>toplevel</td><td>(comment)</td><td></td><td>General Debug Settings</td></tr>
<tr bgcolor="#eeeeee">
<td>GDB_STUB</td><td>toplevel</td><td>bool</td><td>GDB debugging support</td><td>
If enabled, you will be able to set breakpoints for gdb debugging.<br />
See src/arch/x86/lib/c_start.S for details.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GDB_WAIT</td><td>toplevel</td><td>bool</td><td>Wait for a GDB connection in the ramstage</td><td>
If enabled, coreboot will wait for a GDB connection in the ramstage.<br />
<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FATAL_ASSERTS</td><td>toplevel</td><td>bool</td><td>Halt when hitting a BUG() or assertion error</td><td>
If enabled, coreboot will call hlt() on a BUG() or failed ASSERT().<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_CBFS</td><td>toplevel</td><td>bool</td><td>Output verbose CBFS debug messages</td><td>
This option enables additional CBFS related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_RAM_SETUP</td><td>toplevel</td><td>bool</td><td>Output verbose RAM init debug messages</td><td>
This option enables additional RAM init related debug messages.<br />
It is recommended to enable this when debugging issues on your<br />
board which might be RAM init related.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_PIRQ</td><td>toplevel</td><td>bool</td><td>Check PIRQ table consistency</td><td>
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_SMBUS</td><td>toplevel</td><td>bool</td><td>Output verbose SMBus debug messages</td><td>
This option enables additional SMBus (and SPD) debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_SMI</td><td>toplevel</td><td>bool</td><td>Output verbose SMI debug messages</td><td>
This option enables additional SMI related debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_MALLOC</td><td>toplevel</td><td>bool</td><td>Output verbose malloc debug messages</td><td>
This option enables additional malloc related debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_RESOURCES</td><td>toplevel</td><td>bool</td><td>Output verbose PCI MEM and IO resource debug messages</td><td>
This option enables additional PCI memory and IO debug messages.<br />
Note: This option will increase the size of the coreboot image.<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_CONSOLE_INIT</td><td>toplevel</td><td>bool</td><td>Debug console initialisation code</td><td>
With this option printk()'s are attempted before console hardware<br />
initialisation has been completed. Your mileage may vary.<br />
<br />
Typically you will need to modify source in console_hw_init() such<br />
that a working console appears before the one you want to debug.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>REALMODE_DEBUG</td><td>toplevel</td><td>bool</td><td>Enable debug messages for option ROM execution</td><td>
This option enables additional x86emu related debug messages.<br />
<br />
Note: This option will increase the time to emulate a ROM.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG</td><td>toplevel</td><td>bool</td><td>Output verbose x86emu debug messages</td><td>
This option enables additional x86emu related debug messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_JMP</td><td>toplevel</td><td>bool</td><td>Trace JMP/RETF</td><td>
Print information about JMP and RETF opcodes from x86emu.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_TRACE</td><td>toplevel</td><td>bool</td><td>Trace all opcodes</td><td>
Print _all_ opcodes that are executed by x86emu.<br />
<br />
WARNING: This will produce a LOT of output and take a long time.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_PNP</td><td>toplevel</td><td>bool</td><td>Log Plug&amp;Play accesses</td><td>
Print Plug And Play accesses made by option ROMs.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_DISK</td><td>toplevel</td><td>bool</td><td>Log Disk I/O</td><td>
Print Disk I/O related messages.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_PMM</td><td>toplevel</td><td>bool</td><td>Log PMM</td><td>
Print messages related to POST Memory Manager (PMM).<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_VBE</td><td>toplevel</td><td>bool</td><td>Debug VESA BIOS Extensions</td><td>
Print messages related to VESA BIOS Extension (VBE) functions.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_INT10</td><td>toplevel</td><td>bool</td><td>Redirect INT10 output to console</td><td>
Let INT10 (i.e. character output) calls print messages to debug output.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_INTERRUPTS</td><td>toplevel</td><td>bool</td><td>Log intXX calls</td><td>
Print messages related to interrupt handling.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_CHECK_VMEM_ACCESS</td><td>toplevel</td><td>bool</td><td>Log special memory accesses</td><td>
Print messages related to accesses to certain areas of the virtual<br />
memory (e.g. BDA (BIOS Data Area) or interrupt vectors)<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_MEM</td><td>toplevel</td><td>bool</td><td>Log all memory accesses</td><td>
Print memory accesses made by option ROM.<br />
Note: This also includes accesses to fetch instructions.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_IO</td><td>toplevel</td><td>bool</td><td>Log IO accesses</td><td>
Print I/O accesses made by option ROM.<br />
<br />
Note: This option will increase the size of the coreboot image.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>X86EMU_DEBUG_TIMINGS</td><td>toplevel</td><td>bool</td><td>Output timing information</td><td>
Print timing information needed by i915tool.<br />
<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_SPI_FLASH</td><td>toplevel</td><td>bool</td><td>Output verbose SPI flash debug messages</td><td>
This option enables additional SPI flash related debug messages.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_INTEL_ME</td><td>toplevel</td><td>bool</td><td>Verbose logging for Intel Management Engine</td><td>
Enable verbose logging for Intel Management Engine driver that<br />
is present on Intel 6-series chipsets.<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_FUNC</td><td>toplevel</td><td>bool</td><td>Enable function entry and exit reporting macros</td><td>
This option enables additional function entry and exit debug messages<br />
for select functions.<br />
Note: This option will increase the size of the coreboot image.<br />
If unsure, say N.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_COVERAGE</td><td>toplevel</td><td>bool</td><td>Debug code coverage</td><td>
If enabled, the code coverage hooks in coreboot will output some<br />
information about the coverage data that is dumped.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_BOOT_STATE</td><td>toplevel</td><td>bool</td><td>Debug boot state machine</td><td>
Control debugging of the boot state machine.  When selected displays<br />
the state boundaries in ramstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DEBUG_ADA_CODE</td><td>toplevel</td><td>bool</td><td>Compile debug code in Ada sources</td><td>
Add the compiler switch `-gnata` to compile code guarded by<br />
`pragma Debug`.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_EM100_SUPPORT</td><td>toplevel</td><td>bool</td><td>Platform can support the Dediprog EM100 SPI emulator</td><td>
This is enabled by platforms which can support using the EM100.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EM100</td><td>toplevel</td><td>bool</td><td>Configure image for EM100 usage</td><td>
The Dediprog EM100 SPI emulator allows fast loading of new SPI images<br />
over USB. However it only supports a maximum SPI clock of 20MHz and<br />
single data output. Enable this option to use a 20MHz SPI clock and<br />
disable "Dual Output Fast Read" Support.<br />
<br />
On AMD platforms this changes the SPI speed at run-time if the<br />
mainboard code supports this. On supported Intel platforms this works<br />
by changing the settings in the descriptor.bin file.<br />
<br />
</td></tr>

<tr bgcolor="#eeeeee">
<td>MISSING_BOARD_RESET</td><td>lib</td><td>bool</td><td></td><td>
Selected by boards that don't provide a do_board_reset()<br />
implementation. This activates a stub that logs the missing<br />
board reset and halts execution.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAMSTAGE_ADA</td><td>lib</td><td>bool</td><td></td><td>
Selected by features that use Ada code in ramstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RAMSTAGE_LIBHWBASE</td><td>lib</td><td>bool</td><td></td><td>
Selected by features that require `libhwbase` in ramstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>FLATTENED_DEVICE_TREE</td><td>lib</td><td>bool</td><td></td><td>
Selected by features that require to parse and manipulate a flattened<br />
devicetree in ramstage.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>HAVE_SPD_IN_CBFS</td><td>lib</td><td>bool</td><td></td><td>
If enabled, add support for adding spd.hex files in cbfs as spd.bin<br />
and locating it runtime to load SPD.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DIMM_MAX</td><td>lib</td><td>int</td><td></td><td>
Total number of memory DIMM slots available on motherboard.<br />
It is multiplication of number of channel to number of DIMMs per<br />
channel<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>DIMM_SPD_SIZE</td><td>lib</td><td>int</td><td></td><td>
Total SPD size that will be used for DIMM.<br />
Ex: DDR3 256, DDR4 512.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPD_CACHE_IN_FMAP</td><td>lib</td><td>bool</td><td></td><td>
Enables capability to cache DIMM SPDs in a dedicated FMAP region<br />
to speed loading of SPD data. Currently requires board-level<br />
romstage implementation to read/write/utilize cached SPD data.<br />
When the default FMAP is used, will create a region named RW_SPD_CACHE<br />
to store the cached SPD data.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>SPD_CACHE_FMAP_NAME</td><td>lib</td><td>string</td><td></td><td>
Name of the FMAP region created in the default FMAP to cache SPD data.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_FMAP_CACHE</td><td>lib</td><td>bool</td><td></td><td>
If your platform really doesn't want to use an FMAP cache (e.g. due to<br />
space constraints), you can select this to disable warnings and save<br />
a bit more code.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>ESPI_DEBUG</td><td>lib</td><td>bool</td><td></td><td>
This option enables eSPI library helper functions for displaying debug<br />
information.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_CBFS_MCACHE</td><td>lib</td><td>bool</td><td></td><td>
Disables the CBFS metadata cache. This means that your platform does<br />
not need to provide a CBFS_MCACHE section in memlayout and can save<br />
the associated CAR/SRAM size. In that case every single CBFS file<br />
lookup must re-read the same CBFS directory entries from flash to find<br />
the respective file.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>CBFS_MCACHE_RW_PERCENTAGE</td><td>lib</td><td>int</td><td></td><td>
The amount of the CBFS_MCACHE area that's used for the RW CBFS, in<br />
percent from 0 to 100. The remaining area will be used for the RO<br />
CBFS. Default is an even 50/50 split. When VBOOT is disabled, this<br />
will automatically be 0 (meaning the whole MCACHE is used for RO).<br />
<br />
</td></tr>
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_BUTTON_DEFAULT_ENABLE</td><td>toplevel</td><td>bool</td><td></td><td>
Select when the board has a power button which can optionally be<br />
disabled by the user.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_BUTTON_DEFAULT_DISABLE</td><td>toplevel</td><td>bool</td><td></td><td>
Select when the board has a power button which can optionally be<br />
enabled by the user, e.g. when the board ships with a jumper over<br />
the power switch contacts.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_BUTTON_FORCE_ENABLE</td><td>toplevel</td><td>bool</td><td></td><td>
Select when the board requires that the power button is always<br />
enabled.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_BUTTON_FORCE_DISABLE</td><td>toplevel</td><td>bool</td><td></td><td>
Select when the board requires that the power button is always<br />
disabled, e.g. when it has been hardwired to ground.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>POWER_BUTTON_IS_OPTIONAL</td><td>toplevel</td><td>bool</td><td></td><td>
Internal option that controls ENABLE_POWER_BUTTON visibility.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>REG_SCRIPT</td><td>toplevel</td><td>bool</td><td></td><td>
Internal option that controls whether we compile in register scripts.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MAX_REBOOT_CNT</td><td>toplevel</td><td>int</td><td></td><td>
Internal option that sets the maximum number of bootblock executions allowed<br />
with the normal image enabled before assuming the normal image is defective<br />
and switching to the fallback image.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>NO_XIP_EARLY_STAGES</td><td>toplevel</td><td>bool</td><td></td><td>
Identify if early stages are eXecute-In-Place(XIP).<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>EARLY_CBMEM_LIST</td><td>toplevel</td><td>bool</td><td></td><td>
Enable display of CBMEM during romstage and postcar.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>RELOCATABLE_MODULES</td><td>toplevel</td><td>bool</td><td></td><td>
If RELOCATABLE_MODULES is selected then support is enabled for<br />
building relocatable modules in the RAM stage. Those modules can be<br />
loaded anywhere and all the relocations are handled automatically.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>GENERIC_GPIO_LIB</td><td>toplevel</td><td>bool</td><td></td><td>
If enabled, compile the generic GPIO library. A "generic" GPIO<br />
implies configurability usually found on SoCs, particularly the<br />
ability to control internal pull resistors.<br />
<br />
</td></tr>
<tr bgcolor="#eeeeee">
<td>MEMLAYOUT_LD_FILE</td><td>toplevel</td><td>string</td><td></td><td>
This variable allows SoC/mainboard to supply in a custom linker file<br />
if required. This determines the linker file used for all the stages<br />
(bootblock, romstage, verstage, ramstage, postcar) in<br />
src/arch/${ARCH}/Makefile.inc.<br />
<br />
</td></tr>
</table>