coreboot-kgpe-d16/payloads/libpayload/Kconfig

503 lines
13 KiB
Plaintext
Raw Normal View History

##
##
## Copyright (C) 2008 Advanced Micro Devices, Inc.
## Copyright (C) 2008 coresystems GmbH
##
## Redistribution and use in source and binary forms, with or without
## modification, are permitted provided that the following conditions
## are met:
## 1. Redistributions of source code must retain the above copyright
## notice, this list of conditions and the following disclaimer.
## 2. Redistributions in binary form must reproduce the above copyright
## notice, this list of conditions and the following disclaimer in the
## documentation and/or other materials provided with the distribution.
## 3. The name of the author may not be used to endorse or promote products
## derived from this software without specific prior written permission.
##
## THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
## ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
## ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
## FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
## DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
## OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
## HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
## LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
## OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
## SUCH DAMAGE.
##
mainmenu "Libpayload Configuration"
menu "Generic Options"
libpayload: Introduce new Kconfig to explicitly allow GPL code There have been leaks of GPL code into libpayload for a while now, for new features or improvements that require third party code with no adequate alternative among BSD-licensed software. It seems silly and counter-productive to keep holding back features and performance improvements from libpayload for a use-case (proprietary payloads) that doesn't even seem to be implemented anywhere to date. Open-source payloads should not need to suffer to appease commercial ones. Instead, this patch introduces a new Kconfig option to explicitly allow inclusion of GPL code. It will use Kconfig dependencies and/or Makefile rules to ensure that no GPL code can end up in the final payload if that option is unset, allowing proprietary payloads to keep working with the existing BSD-licensed feature set. New features and patches (that are sufficiently separate and self-contained to allow guarding through this config option) can choose whether to import GPL code, and need to depend on this option if they do. Also clean up all (known) existing uses of GPL code to depend on the new option, add some recent third-party imports to the LICENSES file, and relicense the selfboot.c files to BSD with permission of the author. BUG=chrome-os-partner:24957 TEST=Compiled Falco and Nyan_Big both with and without the new option, disassembled output binaries to ensure that memcpy() looks as expected. Original-Change-Id: I6e3a75b1a8e46291c75a876844c7a01f7d3f2a0e Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/203513 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit d8e5a9fdf583b5ac861f34baea6a16c4d8536512) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I446fef028264c793b946dd9f765e446bf708b4db Reviewed-on: http://review.coreboot.org/8118 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-06-11 23:16:35 +02:00
config GPL
bool "GPLv2-licensed Options"
default y if CHROMEOS
libpayload: Introduce new Kconfig to explicitly allow GPL code There have been leaks of GPL code into libpayload for a while now, for new features or improvements that require third party code with no adequate alternative among BSD-licensed software. It seems silly and counter-productive to keep holding back features and performance improvements from libpayload for a use-case (proprietary payloads) that doesn't even seem to be implemented anywhere to date. Open-source payloads should not need to suffer to appease commercial ones. Instead, this patch introduces a new Kconfig option to explicitly allow inclusion of GPL code. It will use Kconfig dependencies and/or Makefile rules to ensure that no GPL code can end up in the final payload if that option is unset, allowing proprietary payloads to keep working with the existing BSD-licensed feature set. New features and patches (that are sufficiently separate and self-contained to allow guarding through this config option) can choose whether to import GPL code, and need to depend on this option if they do. Also clean up all (known) existing uses of GPL code to depend on the new option, add some recent third-party imports to the LICENSES file, and relicense the selfboot.c files to BSD with permission of the author. BUG=chrome-os-partner:24957 TEST=Compiled Falco and Nyan_Big both with and without the new option, disassembled output binaries to ensure that memcpy() looks as expected. Original-Change-Id: I6e3a75b1a8e46291c75a876844c7a01f7d3f2a0e Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/203513 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit d8e5a9fdf583b5ac861f34baea6a16c4d8536512) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I446fef028264c793b946dd9f765e446bf708b4db Reviewed-on: http://review.coreboot.org/8118 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-06-11 23:16:35 +02:00
default n
help
Prompt for options that will build code licensed under the GNU General
Public License (version 2). This will subject the whole payload to the
terms of this license (including its provision to release all sources,
please see the LICENSE_GPL file for details).
config EXPERIMENTAL
bool "Experimental Options"
default n
help
Prompt for experimental functionality. Attention: This is not likely
to work without problems
config DEVELOPER
bool "Developer Options"
default n
help
Prompt for developer options. These options are only interesting for
libpayload developers.
config CHROMEOS
bool "ChromeOS Options"
default n
help
Select configuration defaults appropriate for ChromeOS boards.
choice
prompt "Compiler to use"
default COMPILER_GCC
help
This option allows you to select the compiler.
config COMPILER_GCC
bool "GCC"
help
Use the GNU Compiler Collection (GCC).
config COMPILER_LLVM_CLANG
bool "LLVM/clang"
help
Use LLVM/clang.
endchoice
libpayload: Add support for link time optimization Link time optimization is a technique for whole-program optimization. Instead of doing code generation during compilation, the compiler saves its intermediate representation to the object files. During the final linking step, it will then merge all the object files together and perform optimizations on the entire program. This can often reduce the final binary size, but also may increase the total compilation time. This patch introduces a Kconfig option for enabling link time optimization in libpayload. Since libpayload does no linking of its own, its LTO archive files will contain only IR and no generated code. Downstream projects will need to use LTO-aware tools when manipulating the archives (eg. gcc-ar and gcc-nm), but otherwise do not need to use LTO themselves -- the compiler will recognize which files are LTO and which are not, so enabling this option should mostly be "drop in". For example, when building coreinfo.elf using tinycurses libpayload: binary size compilation time default 114 KiB 11.49s LTO 95 KiB 10.36s In this case the total compilation time was actually shorter -- despite the final linking step taking longer, this was offset by the shorter compilation times for each individual file (since there is no code gen until the very end). Change-Id: I048f2ff6298ed0d891098942e1e8b29d35487b91 Signed-off-by: Jacob Garber <jgarber1@ualberta.ca> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38291 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-10-03 02:55:07 +02:00
config LTO
bool "Use link time optimization (LTO)"
default n
depends on COMPILER_GCC
help
Compile with link time optimization. This can often decrease the
final binary size, but may increase compilation time.
libpayload: Add remote GDB support This patch adds the ability to attach a GDB host through the UART to a running payload. Libpayload implements a small stub that can parse and respond to the GDB remote protocol and provide the required primitives (reading/writing registers/memory, etc.) to allow GDB to control execution. The goal of this implementation is to be as small and uninvasive as possible. It implements only the minimum amount of primitives required, and relies on GDB's impressive workaround capabilities (such as emulating breakpoints by temporarily replacing instructions) for the more complicated features. This way, a relatively tiny amount of code on the firmware side opens a vast range of capabilities to the user, not just in debugging but also in remote-controlling the firmware to change its behavior (e.g. through GDBs ability to modify variables and call functions). By default, a system with the REMOTEGDB Kconfig will only trap into GDB when executing halt() (including the calls from die_if(), assert(), and exception handlers). In addition, payloads can manually call gdb_enter() if desired. It will print a final "Ready for GDB connection." on the serial, detach the normal serial output driver and wait for the commands that GDB starts sending on attach. Based on original implementation by Gabe Black <gabeblack@chromium.org>. BUG=chrome-os-partner:18390 TEST=Boot a GDB enabled image in recovery mode (or get it to hit a halt()), close your terminal, execute '<toolchain>-gdb --symbols /build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory ~/trunk/src/third_party/coreboot/payloads/libpayload --directory ~/trunk/src/platform/depthcharge --directory ~/trunk/src/platform/vboot_reference --ex "target remote <cpu_uart_pty>"' and behold the magic. (You can also SIGSTOP your terminal's parent shell and the terminal itself, and SIGCONT them in reverse order after GDB exits. More convenient wrapper tools to do all this automatically coming soon.) Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/202563 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b Reviewed-on: http://review.coreboot.org/8119 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-05-15 20:57:38 +02:00
config REMOTEGDB
bool "Remote GDB stub"
default n
depends on GPL
help
Enable Remote GDB debugging support.
config MEMMAP_RAM_ONLY
bool "Only consider RAM entries in memory map for further processing"
default n
endmenu
menu "Architecture Options"
choice
prompt "Target Architecture"
default ARCH_X86
ARM: Generalize armv7 as arm. There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)
2013-10-01 08:00:33 +02:00
config ARCH_ARM
bool "ARM"
help
ARM: Generalize armv7 as arm. There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)
2013-10-01 08:00:33 +02:00
Support the ARM architecture
config ARCH_X86
bool "x86"
help
Support the x86 architecture
config ARCH_ARM64
bool "ARM64"
help
Support the ARM64 architecture
config ARCH_MOCK
bool "Mock architecture (for unit tests)"
help
This enables the mock architecture (for unit tests) that is intended
to be used for testing purposes, to either test payloads or libpayload itself.
It provides necessary headers, but requires mocking (providing implementation
for) arch-specific functions.
endchoice
config MULTIBOOT
bool "Multiboot header support"
depends on ARCH_X86
default y if !CHROMEOS
config HEAP_SIZE
int "Heap size"
default 131072
help
This is the heap size (malloc'able size) available
to the payload.
If unsure, set to 131072 (128K)
config STACK_SIZE
int "Stack size"
default 16384
help
This is the stack size available to the payload.
If unsure, set to 16384 (16K)
config BASE_ADDRESS
hex "Base address"
default 0x04000000 if ARCH_ARM
default 0x80100000 if ARCH_ARM64
default 0x00100000 if ARCH_X86
default 0x00000000 if ARCH_MOCK
help
This is the base address for the payload.
If unsure, set to 0x00100000 on x86,
0x04000000 on ARM or 0x80100000 on ARM64.
endmenu
config USE_MARCH_586
bool "Use march=586 qualifier to build"
default n
depends on ARCH_X86
help
Allow a platform or processor to select to be compiled using
the '-march=i586' option instead of the typical '-march=i686'
menu "Standard Libraries"
config LIBC
bool "Enable C library support"
default y
config CURSES
bool "Build a curses library"
default y if !CHROMEOS
choice
prompt "Curses implementation"
default PDCURSES
depends on CURSES
config TINYCURSES
bool "TinyCurses"
help
TinyCurses was the first curses implementation for libpayload.
It features low memory consumption, static allocation of larger
data structures (so few or no memory allocation calls) and a
reduced feature set.
config PDCURSES
bool "PDCurses"
help
libpayload's PDCurses port provides a full features curses
implementation, including libpanel, libmenu and libform (which
are taken from ncurses).
It requires more system resources, in particularily heap memory.
endchoice
source "libcbfs/Kconfig"
config LZMA
bool "LZMA decoder"
default y
help
LZMA decoder implementation, usable eg. by CBFS,
but also externally.
libpayload: Add LZ4 decompression algorithm This patch adds support for the LZ4 decompression algorithm to libpayload. It's what all the cool kids are using for decompression these days and has many interesting advantages over LZMA (and everything else I know of): blazing fast decompression (20(!) times faster than LZMA, twice as fast as LZO on my Cortex-A72), no memory requirements on decompression, and possibly in-place decompression support. It pays for that with a lower compression ratio (about 50% larger compressed size than LZMA, 10% larger than LZO for an ARM64 Linux kernel binary), but the boot time math still works in its favor for our IO speeds. This patch only adds the raw decompression functions for use by external payloads, we can later try integrating them in CBFS. It copies the decompression code itself unmodified from the upstream LZ4 library at github.com/Cyan4973/lz4 which will hopefully make it easy to update. The frame format parsing is reimplemented since the upstream version looks unnecessarily complex and unreadable for our needs. BRANCH=smaug BUG=chrome-os-partner:32184 TEST=With other patches, booted ARM64 kernel that got compressed from 15M to 5.1M and decompresses in 44ms. Change-Id: I65bdc4b2b19bd51c7b7e17a4e4b79da301a2a014 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f8a1fc996d5b0234d07f567fa8163d0f802d5144 Original-Change-Id: I15c0620da05561ade2552b15ffdf6bb3afd7eb26 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/282743 Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10845 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-30 19:30:30 +02:00
config LZ4
bool "LZ4 decoder"
default y
help
Decoder implementation for the LZ4 compression algorithm.
Adds standalone functions (CBFS support coming soon).
source "vboot/Kconfig"
endmenu
menu "Console Options"
config SKIP_CONSOLE_INIT
bool "Skip initializing the consoles at startup"
default y if CHROMEOS
default n
help
Normally, libpayload will initialize console input/output on startup
before the payload itself gets control. This option disables that
behavior and leaves console initialization up to the payload.
config CBMEM_CONSOLE
bool "Send output to the in memory CBMEM console"
default y
config SERIAL_CONSOLE
bool "See output on the serial port console"
default y
2013-09-27 01:13:08 +02:00
config 8250_SERIAL_CONSOLE
bool "8250-compatible serial port driver (including IO and MMIO)"
2013-09-27 01:13:08 +02:00
depends on SERIAL_CONSOLE
default y if ARCH_X86
config S5P_SERIAL_CONSOLE
bool "Exynos SOC, S5P compatible serial port driver"
depends on SERIAL_CONSOLE
default n
config IPQ806X_SERIAL_CONSOLE
bool "IPQ806x SOC compatible serial port driver"
depends on SERIAL_CONSOLE
default n
config IPQ40XX_SERIAL_CONSOLE
bool "IPQ40xx SOC compatible serial port driver"
depends on SERIAL_CONSOLE
default n
config QCS405_SERIAL_CONSOLE
bool "QCS405 SOC compatible serial port driver"
depends on SERIAL_CONSOLE
default n
config QUALCOMM_QUPV3_SERIAL_CONSOLE
bool "Qualcomm QUPV3 serial port driver"
depends on SERIAL_CONSOLE
default n
config PL011_SERIAL_CONSOLE
bool "PL011 compatible serial port driver"
depends on 8250_SERIAL_CONSOLE
default n
config SERIAL_IOBASE
2013-09-27 01:13:08 +02:00
## This default is currently not used on non-x86 systems.
hex "Default I/O base for the serial port (default 0x3f8)"
depends on SERIAL_CONSOLE && ARCH_X86
default 0x3f8
config SERIAL_SET_SPEED
bool "Override the serial console baud rate"
default n
depends on SERIAL_CONSOLE
config SERIAL_BAUD_RATE
int "Serial console baud rate (default 115200)"
depends on SERIAL_SET_SPEED
default 115200
config SERIAL_ACS_FALLBACK
bool "Use plain ASCII characters for ACS"
default n
depends on SERIAL_CONSOLE
help
The alternate character set (ACS) is used for drawing lines and
displaying a couple of other special graphics characters. The
ACS characters generally look good on screen, but can be difficult
to cut and paste from a terminal window to a text editor.
Say 'y' here if you want to always use plain ASCII characters to
approximate the appearance of ACS characters on the serial port
console.
config VIDEO_CONSOLE
bool "See output on a video console"
default y
config VGA_VIDEO_CONSOLE
bool "VGA video console driver"
depends on ARCH_X86 && VIDEO_CONSOLE
default y if !CHROMEOS
config GEODELX_VIDEO_CONSOLE
bool "Geode LX video console driver"
depends on ARCH_X86 && VIDEO_CONSOLE
default n
config COREBOOT_VIDEO_CONSOLE
bool "coreboot video console driver"
depends on VIDEO_CONSOLE && !GEODELX_VIDEO_CONSOLE
default y if CHROMEOS
default n
help
Say Y here if coreboot switched to a graphics mode and
your payload wants to use it.
config COREBOOT_VIDEO_CENTERED
bool "Center a classic 80x25 console on bigger screens"
depends on COREBOOT_VIDEO_CONSOLE
help
Say 'y' here if your payload is hardcoded to a 80x25 console. Otherwise
its output would look squeezed into the upper-left corner of the screen.
config FONT_SCALE_FACTOR
int "Scale factor for the included font"
depends on GEODELX_VIDEO_CONSOLE || COREBOOT_VIDEO_CONSOLE
default 0
help
By default (value of 0), the scale factor is automatically
calculated to ensure at least 130 columns (when possible).
config CBGFX_FAST_RESAMPLE
bool "CBGFX: use faster (less pretty) image scaling"
default n
help
When payloads use the CBGFX library to draw .BMPs on the screen,
they will be resampled with an anti-aliasing filter to scale to the
requested output size. The default implementation should normally be
fast enough, but if desired this option can make it about 50-100%
faster at the cost of quality. (It changes the 'a' parameter in the
Lanczos resampling algorithm from 3 to 2.)
Only affects .BMPs that aren't already provided at the right size.
config PC_I8042
bool "A common PC i8042 driver"
default y if PC_KEYBOARD || PC_MOUSE
default n
help
To be used by PC_KEYBOARD and PC_MOUSE.
config PC_MOUSE
bool "Allow input from a PC mouse"
default n if CHROMEOS
default y if ARCH_X86 # uses IO
default n
help
PS/2 mouse driver on top of PC_I8042.
config PC_KEYBOARD
bool "Allow input from a PC keyboard"
default y if ARCH_X86 # uses IO
default n
config PC_KEYBOARD_LAYOUT_US
bool "English (US) keyboard layout"
depends on PC_KEYBOARD
default y
config PC_KEYBOARD_LAYOUT_DE
bool "German keyboard layout"
depends on PC_KEYBOARD
default n
config PC_KEYBOARD_TRANSLATION
bool "Enable or Disable translation in PC keyboard set 2 on exit"
depends on PC_KEYBOARD
default y
endmenu
menu "Drivers"
config PCI
bool "Support for PCI devices"
default y if ARCH_X86
default n
config PCI_IO_OPS
bool "Support for PCI devices with port IO"
depends on PCI && IO_ADDRESS_SPACE
default y if ARCH_X86
default n
config PCIE_MEDIATEK
bool "Support for PCIe devices on MediaTek platforms"
depends on PCI && !PCI_IO_OPS
default n
config NVRAM
bool "Support for reading/writing NVRAM bytes"
depends on ARCH_X86 # for now
default y
config MOUSE_CURSOR
bool "Support for mouse cursor handling"
default y if PC_MOUSE
default n
help
Provides a common interface for various mouse cursor drivers.
* Supports up to 32 buttons.
* Supports 3 axis mice.
* Applies simple cursor acceleration.
* Allows to set cursor acceleration and cursor speed.
config RTC_PORT_EXTENDED_VIA
bool "Extended RTC ports are 0x74/0x75"
default n
help
For recent chipsets with 256 NVRAM bytes, you have to access the
upper 128 bytes (128-255) using two different I/O ports,
usually 0x72/0x73.
On some chipsets this can be a different set of ports, though.
The VIA VT8237R for example only recognizes the ports 0x74/0x75
for accessing the high 128 NVRAM bytes (as seems to be the case for
multiple VIA chipsets).
If you want to read or write CMOS bytes on computers with one of
these chipsets, say 'y' here.
config SPEAKER
bool "Support for PC speaker"
depends on ARCH_X86
default y if !CHROMEOS
source "drivers/timer/Kconfig"
source "drivers/storage/Kconfig"
source "drivers/usb/Kconfig"
endmenu
menu "Debugging"
depends on DEVELOPER
config DEBUG_MALLOC
bool "Debug memory allocator"
default n
help
Select this option if you want to debug the memory allocator. This
option logs all uses of the following functions:
void free(void *ptr);
void *malloc(size_t size);
void *calloc(size_t nmemb, size_t size);
void *realloc(void *ptr, size_t size);
void *memalign(size_t align, size_t size);
Say N here unless you are debugging memory allocator problems.
endmenu
config BIG_ENDIAN
default n
bool
config LITTLE_ENDIAN
default n
bool
config IO_ADDRESS_SPACE
default n
bool
help
This option is turned on if the target system has a separate
IO address space. This is typically only the case on x86.
source "arch/arm/Kconfig"
source "arch/arm64/Kconfig"
source "arch/x86/Kconfig"
source "arch/mock/Kconfig"