coreboot-kgpe-d16/payloads/libpayload/Config.in

595 lines
14 KiB
Plaintext
Raw Normal View History

##
## This file is part of the libpayload project.
##
## 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 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.
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 CHROMEOS
bool "ChromeOS specific features"
default n
help
Enable ChromeOS specific features.
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_MIPS
bool "MIPS"
help
Support the MIPS architecture
endchoice
config MEMMAP_RAM_ONLY
bool "Only consider RAM entries in memory map for further processing"
default n
config MULTIBOOT
bool "Multiboot header support"
depends on ARCH_X86
default y
endmenu
menu "Standard Libraries"
config LIBC
bool "Enable C library support"
default y
config CURSES
bool "Build a curses library"
default y
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
config CBFS
bool "CBFS support"
default y
help
CBFS is the archive format of coreboot
config LZMA
bool "LZMA decoder"
default y
help
LZMA decoder implementation, usable eg. by CBFS,
but also externally.
endmenu
menu "Console Options"
config SKIP_CONSOLE_INIT
bool "Skip initializing the consoles at startup"
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, 16450, 16550, 16550A compatible serial port driver"
depends on SERIAL_CONSOLE
default y if ARCH_X86
default n if !ARCH_X86
config S5P_SERIAL_CONSOLE
bool "Exynos SOC, S5P compatible serial port driver"
depends on SERIAL_CONSOLE
default n
serial: Combine Tegra and Rockchip UARTs to generic 8250_mmio32 We have two drivers for a 100%-identical peripheral right now, mostly because we couldn't come up with a good common name for it back when we checked it in. That seems like a pretty silly reason in the long run. Both Tegra and Rockchip SoCs contain UARTs that use the common 8250 register interface (at least for the very basic byte-per-byte transmit and receive parts we care about), memory-mapped with a 32-bit register stride. This patch combines them to a single 8250_mmio32 driver (which also fixes a problem when booting Rockchip without serial enabled, since that driver forgot to check for serial initialization when registering its console drivers). The register accesses are done using readl/writel (as Rockchip did before), since the registers are documented as 32-bit length (with top 24 bits RAZ/WI), although the Tegra SoC doesn't enforce APB accesses to have the full word length. Also fixed checkpatch stuff. A day may come when we can also merge this driver into the (completely different, with more complicated features and #ifdefs) 8250 driver for x86 (which has MMIO support for 8-bit register stride only), both here and in coreboot. But it is not this day. This day I just want to get rid of a 99% identical file without expending too much effort. BUG=None TEST=Booted on Veyron_Pinky and Nyan_Blaze with and without serial enabled, both worked fine (although Veyron has another kernel issue). Change-Id: I85c004a75cc5aa7cb40098002d3e00a62c1c5f2d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e7959c19356d2922aa414866016540ad9ee2ffa8 Original-Change-Id: Ib84d00f52ff2c48398c75f77f6a245e658ffdeb9 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/225102 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9387 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-10-22 23:12:50 +02:00
config 8250_MMIO32_SERIAL_CONSOLE
bool "Memory-mapped 8250-compatible serial port driver with 32-bit regs"
depends on SERIAL_CONSOLE
default n
config IPQ806X_SERIAL_CONSOLE
bool "IPQ806x SOC compatible serial port driver"
depends on SERIAL_CONSOLE
default n
config BG4CD_SERIAL_CONSOLE
bool "Serial port driver for Marvell's BG4CD"
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
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 n
help
Say Y here if coreboot switched to a graphics mode and
your payload wants to use it.
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
endmenu
menu "Drivers"
config PCI
bool "Support for PCI devices"
depends on ARCH_X86 # for now
default y
config NVRAM
bool "Support for reading/writing NVRAM bytes"
depends on ARCH_X86 # for now
default y
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
config STORAGE
bool "Support for storage devices"
default y
help
Select this option if you want support for storage devices (like
hard drives, memory sticks or optical drives).
config STORAGE_64BIT_LBA
bool "Use 64-bit integers to address sectors"
depends on STORAGE
default n
help
If this is selected, sectors will be addressed by an 64-bit integer.
Select this to support LBA-48 for ATA drives.
config STORAGE_ATA
bool "Support ATA drives (i.e. hard drives)"
depends on STORAGE
default y
help
Select this option if you want support for ATA storage devices
(i.e. hard drives).
config STORAGE_ATAPI
bool "Support ATAPI drives (i.e. optical drives)"
depends on STORAGE
default y
select STORAGE_ATA
help
Select this option if you want support for ATAPI storage devices
(i.e. optical drives like CD or DVD drives).
config STORAGE_AHCI
bool "Support for AHCI host controllers"
depends on STORAGE && (STORAGE_ATA || STORAGE_ATAPI) && PCI
default y
help
Select this option if you want support for SATA controllers in
AHCI mode.
config STORAGE_AHCI_ONLY_TESTED
bool "Only enable tested controllers"
depends on STORAGE_AHCI
default y
help
If this option is selected only AHCI controllers which are known
to work will be used.
config TIMER_RDTSC
bool
default y
depends on ARCH_X86
choice
prompt "Timer driver"
default TIMER_NONE
depends on !ARCH_X86
config TIMER_NONE
bool "None"
help
The timer driver is provided by the payload itself.
config TIMER_MCT
bool "Exynos MCT"
config TIMER_TEGRA_1US
bool "Tegra 1us"
config TIMER_IPQ806X
bool "Timer for ipq806x platforms"
config TIMER_RK
bool "Timer for Rockchip"
config TIMER_BG4CD
bool "Marvell BG4CD"
config TIMER_CYGNUS
bool "Timer for Cygnus"
config TIMER_IMG_PISTACHIO
bool "Timer for IMG Pistachio"
config TIMER_MTK
bool "Timer for MediaTek MT8173"
endchoice
config TIMER_MCT_HZ
int "Exynos MCT frequency"
depends on TIMER_MCT
default 24000000
config TIMER_MCT_ADDRESS
hex "Exynos MCT base address"
depends on TIMER_MCT
default 0x101c0000
config TIMER_RK_ADDRESS
hex "Rockchip timer base address"
depends on TIMER_RK
default 0xff810020
config TIMER_TEGRA_1US_ADDRESS
hex "Tegra u1s timer base address"
depends on TIMER_TEGRA_1US
default 0x60005010
config IPQ806X_TIMER_FREQ
int "Hardware timer frequency"
default 32000
depends on TIMER_IPQ806X
help
IPQ hardware presently provides a single timer running at 32KHz, a
finer granulariry timer is available but is not yet enabled.
config IPQ806X_TIMER_REG
hex "Timer register address"
default 0x0200A008
depends on TIMER_IPQ806X
help
Address of the register to read a free running timer value.
config IPROC_PERIPH_GLB_TIM_REG_BASE
hex "Cygnus timer base address"
depends on TIMER_CYGNUS
default 0x19020200
config TIMER_MTK_HZ
int "MediaTek GPT frequency"
depends on TIMER_MTK
default 13000000
help
Clock frequency of MediaTek General Purpose Timer.
config TIMER_MTK_ADDRESS
hex "MTK GPT register address"
depends on TIMER_MTK
default 0x10008048
help
Address of GPT4's counter register to read the FREERUN-mode timer value.
config USB
bool "USB Support"
default n
config USB_UHCI
bool "Support for USB UHCI controllers"
depends on USB && ARCH_X86
help
Select this option if you are going to use USB 1.1 on an Intel based
system.
config USB_OHCI
bool "Support for USB OHCI controllers"
depends on USB
help
Select this option if you are going to use USB 1.1 on a non-Intel based
system.
config USB_EHCI
bool "Support for USB EHCI controllers"
depends on USB
help
Select this option if you want to use USB 2.0
config USB_XHCI
bool "Support for USB xHCI controllers"
depends on USB
help
Select this option if you want to use USB 3.0
NOTE: This option is not (fully) implemented yet
libpayload: usb: Support MTK xHCI host controller 1. There is a mis-understanding to calculate the value of TD Size in Normal TRB. For MTK's xHCI controller it defines a number of packets that remain to be transferred for a TD after processing all Max packets in all previous TRBs, that means don't include the current TRB's. 2. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK architecture defines some extra SW scheduling parameters for HW. According to these parameters provided by SW, the xHC can easily decide whether a synchronous endpoint should be scheduled in a specific uFrame. The extra SW scheduling parameters are put into reserved DWs in Slot and Endpoint Context. But in coreboot synchronous transfer can be ignored, so only two fields are set to a default value 1 to support bulk and interrupt transfers, and others are set to zero. 3. For control transfer, it is better to read back doorbell register or add a memory barrier after ringing the doorbell to flush posted write. Otherwise the first command will be aborted on MTK's xHCI controller. 4. Before send commands to a port, the Port Power in PORTSC register should be set to 1 on MTK's xHCI so a hook function of enable_port in generic_hub_ops_t struct is provided. Change-Id: Ie8878b50c048907ebf939b3f6657535a54877fde Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 738609c11f16264c6e6429d478b2040cb391fe41 Original-Change-Id: Id9156892699e2e42a166c77fbf6690049abe953b Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265362 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Reviewed-on: http://review.coreboot.org/10389 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-07 09:36:04 +02:00
config USB_XHCI_MTK_QUIRK
bool "Support for USB xHCI controllers on MTK SoC"
depends on USB_XHCI
help
Select this option if you want to use USB 3.0 on MTK platform.
config USB_DWC2
bool "Support for USB DesignWare HCD controllers"
depends on USB && !USB_HID
help
Select this option if you want to use DesignWare USB 2.0 host controller
config USB_HID
bool "Support for USB keyboards"
depends on USB
default y
help
Select this option if you want to use devices complying to the
USB HID (Human Interface Device) standard. Such devices are for
example keyboards and mice. Currently only keyboards are supported.
Say Y here unless you know exactly what you are doing.
config USB_HUB
bool "Support for USB hubs"
depends on USB
default y
help
Select this option if you want to compile in support for USB hubs.
Say Y here unless you know exactly what you are doing.
config USB_EHCI_HOSTPC_ROOT_HUB_TT
bool "Support for USB EHCI ROOT HUB that has TT"
depends on USB_EHCI
default n
help
Select this option if USB EHCI root hub supports TT (Transaction
Translator).
To support this TT feature we read port-speed from non-standard
register HOSTPC (offset 84h of Operational Register base).
config USB_MSC
bool "Support for USB storage"
depends on USB
default y
help
Select this option if you want to compile in support for USB mass
storage devices (USB memory sticks, hard drives, CDROM/DVD drives)
Say Y here unless you know exactly what you are doing.
config USB_GEN_HUB
bool
default n if (!USB_HUB && !USB_XHCI)
default y if (USB_HUB || USB_XHCI)
config USB_PCI
bool "Auto-scan PCI bus for USB host controllers"
depends on USB
default y if ARCH_X86
default n
config UDC
bool "USB device mode support"
default n
help
Select this option to add support for running as
a USB device.
config UDC_CI
bool "ChipIdea driver for USB device mode"
depends on UDC
default n
help
Select this option to add the driver for ChipIdea
USB device controller.
endmenu
menu "Debugging"
depends on DEVELOPER
config DEBUG_MALLOC
bool "Debug memory allocator"
depends on USB
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
# Whether the target system has an IO address space.
config IO_ADDRESS_SPACE
default n
bool
source "arch/Config.in"