Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-06 13:14:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/x86/Kconfig

1072 lines
33 KiB
Text
Raw Normal View History

kconfig: add board Kconfig and defconfig files This commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig set CONFIG macros to the appropriate values for each board - configs/${TARGET_BOARD}_defconfig default setting of each board (This commit was automatically generated by a conversion script based on boards.cfg) In Linux Kernel, defconfig files are located under arch/${ARCH}/configs/ directory. It works in Linux Kernel since ARCH is always given from the command line for cross compile. But in U-Boot, ARCH is not given from the command line. Which means we cannot know ARCH until the board configuration is done. That is why all the "*_defconfig" files should be gathered into a single directory ./configs/. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-30 05:08:14 +00:00
menu "x86 architecture"
depends on X86
config SYS_ARCH
default "x86"
x86: Add Kconfig options to build 64-bit U-Boot Add a new CONFIG_X86_64 option which will eventually cause U-Boot to be built as a 64-bit application, with SPL doing the 16/32-bit init. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:43 +00:00
choice
prompt "Run U-Boot in 32/64-bit mode"
default X86_RUN_32BIT
help
U-Boot can be built as a 32-bit binary which runs in 32-bit mode
even on 64-bit machines. In this case SPL is not used, and U-Boot
runs directly from the reset vector (via 16-bit start-up).
Alternatively it can be run as a 64-bit binary, thus requiring a
64-bit machine. In this case SPL runs in 32-bit mode (via 16-bit
start-up) then jumps to U-Boot in 64-bit mode.
For now, 32-bit mode is recommended, as 64-bit is still
experimental and is missing a lot of features.
config X86_RUN_32BIT
bool "32-bit"
help
Build U-Boot as a 32-bit binary with no SPL. This is the currently
supported normal setup. U-Boot will stay in 32-bit mode even on
64-bit machines. When booting a 64-bit kernel, U-Boot will switch
to 64-bit just before starting the kernel. Only the bottom 4GB of
memory can be accessed through normal means, although
arch_phys_memset() can be used for basic access to other memory.
config X86_RUN_64BIT
bool "64-bit"
select X86_64
select SPL
select SPL_SEPARATE_BSS
help
Build U-Boot as a 64-bit binary with a 32-bit SPL. This is
experimental and many features are missing. U-Boot SPL starts up,
runs through the 16-bit and 32-bit init, then switches to 64-bit
mode and jumps to U-Boot proper.
endchoice
config X86_64
bool
config SPL_X86_64
bool
depends on SPL
kconfig: add board Kconfig and defconfig files This commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig set CONFIG macros to the appropriate values for each board - configs/${TARGET_BOARD}_defconfig default setting of each board (This commit was automatically generated by a conversion script based on boards.cfg) In Linux Kernel, defconfig files are located under arch/${ARCH}/configs/ directory. It works in Linux Kernel since ARCH is always given from the command line for cross compile. But in U-Boot, ARCH is not given from the command line. Which means we cannot know ARCH until the board configuration is done. That is why all the "*_defconfig" files should be gathered into a single directory ./configs/. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-30 05:08:14 +00:00
choice
x86: Kconfig: Divide the target selection to vendor/model Let arch/x86/Kconfig prompt board vendor first, then select the board model under that vendor. This way arch/x86/Kconfig only needs concern board vendor and leave the supported target list to board/<vendor>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:24 +00:00
prompt "Mainboard vendor"
x86: Make QEMU the default vendor Now that we have QEMU support, make it the default vendor in the 'make menuconfig' screen. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-05-07 13:34:09 +00:00
default VENDOR_EMULATION
kconfig: add board Kconfig and defconfig files This commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig set CONFIG macros to the appropriate values for each board - configs/${TARGET_BOARD}_defconfig default setting of each board (This commit was automatically generated by a conversion script based on boards.cfg) In Linux Kernel, defconfig files are located under arch/${ARCH}/configs/ directory. It works in Linux Kernel since ARCH is always given from the command line for cross compile. But in U-Boot, ARCH is not given from the command line. Which means we cannot know ARCH until the board configuration is done. That is why all the "*_defconfig" files should be gathered into a single directory ./configs/. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-30 05:08:14 +00:00
x86: Add Advantech SOM-DB5800/SOM-6867 support Add support for Advantech SOM-DB5800 with the SOM-6867 installed. This is very similar to conga-qeval20-qa3-e3845 in that there is a reference carrier board (SOM-DB5800) with a Baytrail based SoM (SOM-6867) installed. Currently supported: - 2x UART (From ITE EC on SOM-6867) routed to COM3/4 connectors on SOM-DB5800. - 4x USB 2.0 (EHCI) - Video - SATA - Ethernet - PCIe - Realtek ALC892 HD Audio Pad configuration for HDA_RSTB, HDA_SYNC, HDA_CLK, HDA_SDO HDA_SDI0 is set in DT to enable HD Audio codec. Pin defaults for codec pin complexs are not changed. Not supported: - Winbond Super I/O (Must be disabled with jumpers on SOM-DB8500) - USB 3.0 (XHCI) - TPM Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-06-21 17:07:33 +00:00
config VENDOR_ADVANTECH
bool "advantech"
x86: Add congatec conga-QA3/E3845-4G (Bay Trail) support This patch adds support for the congatec conga-QA3/E3845-4G eMMC8 SoM, installed on the congatec Qseven 2.0 evaluation carrier board (conga-QEVAL). Its port is very similar to the MinnowboardMAX port and also uses the Intel FSP as described in doc/README.x86. Currently supported are the following interfaces / devices: - UART (via Winbond legacy SuperIO chip on carrier board) - Ethernet (PCIe Intel I210 / E1000) - SPI including SPI NOR as boot-device - USB 2.0 - SATA via U-Boot SCSI IF - eMMC - Video (HDMI output @ 800x600) - PCIe Not supported yet is: - I2C - USB 3.0 Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-16 07:48:21 +00:00
config VENDOR_CONGATEC
bool "congatec"
x86: Kconfig: Divide the target selection to vendor/model Let arch/x86/Kconfig prompt board vendor first, then select the board model under that vendor. This way arch/x86/Kconfig only needs concern board vendor and leave the supported target list to board/<vendor>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:24 +00:00
config VENDOR_COREBOOT
bool "coreboot"
x86: Add support for Intel Minnowboard Max This is a relatively low-cost x86 board in a small form factor. The main peripherals are uSD, USB, HDMI, Ethernet and SATA. It uses an Atom 3800 series CPU. So far only the dual core 2GB variant is supported. This uses the existing FSP support. Binary blobs are required to make this board work. The microcode update is included as a patch (all 3000 lines of it). Change-Id: I0088c47fe87cf08ae635b343d32c332269062156 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:47 +00:00
x86: Add DFI BT700 BayTrail board support This patch adds support for the DFI BayTrail BT700 QSeven SoM installed on the DFI Q7X-151 baseboard. The baseboard is equipped with the Nuvoton NCT6102D Super IO chip providing the UART as console. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-08-15 11:50:49 +00:00
config VENDOR_DFI
bool "dfi"
x86: Add support for U-Boot as an EFI application Add the required x86 glue code. This includes the initial start-up, relocation and jumping to efi_main(). We also need to avoid fiddling with interrupts. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-04 18:33:46 +00:00
config VENDOR_EFI
bool "efi"
x86: Support QEMU x86 targets This commit introduces the initial U-Boot support for QEMU x86 targets. U-Boot can boot from coreboot as a payload, or directly without coreboot. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Merged in patch 'x86: qemu: Add CMD_NET to qemu-x86_defconfig https://patchwork.ozlabs.org/patch/479745/
2015-05-07 13:34:08 +00:00
config VENDOR_EMULATION
bool "emulation"
x86: Kconfig: Divide the target selection to vendor/model Let arch/x86/Kconfig prompt board vendor first, then select the board model under that vendor. This way arch/x86/Kconfig only needs concern board vendor and leave the supported target list to board/<vendor>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:24 +00:00
config VENDOR_GOOGLE
bool "Google"
x86: Add support for Intel Minnowboard Max This is a relatively low-cost x86 board in a small form factor. The main peripherals are uSD, USB, HDMI, Ethernet and SATA. It uses an Atom 3800 series CPU. So far only the dual core 2GB variant is supported. This uses the existing FSP support. Binary blobs are required to make this board work. The microcode update is included as a patch (all 3000 lines of it). Change-Id: I0088c47fe87cf08ae635b343d32c332269062156 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:47 +00:00
x86: Kconfig: Divide the target selection to vendor/model Let arch/x86/Kconfig prompt board vendor first, then select the board model under that vendor. This way arch/x86/Kconfig only needs concern board vendor and leave the supported target list to board/<vendor>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:24 +00:00
config VENDOR_INTEL
bool "Intel"
x86: Enable the Intel quark/galileo build Make the Intel quark/galileo support avaiable in Kconfig and Makefile. With this patch, we can generate u-boot.rom for Intel galileo board. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
2015-02-02 14:35:29 +00:00
kconfig: add board Kconfig and defconfig files This commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig set CONFIG macros to the appropriate values for each board - configs/${TARGET_BOARD}_defconfig default setting of each board (This commit was automatically generated by a conversion script based on boards.cfg) In Linux Kernel, defconfig files are located under arch/${ARCH}/configs/ directory. It works in Linux Kernel since ARCH is always given from the command line for cross compile. But in U-Boot, ARCH is not given from the command line. Which means we cannot know ARCH until the board configuration is done. That is why all the "*_defconfig" files should be gathered into a single directory ./configs/. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-30 05:08:14 +00:00
endchoice
x86: Introduce INTEL_MID quirk option Intel Mobile Internet Device (MID) platforms have special treatment in some cases, such as CPU enumeration or boot parameters configuration. Besides that several drivers are specifically developed for the IP blocks found on Intel MID platforms. Those drivers will be dependent to this option. Here we introduce specific quirk option for such cases. It is supposed to be selected by Intel MID platform boards, for example, Intel Edison. Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-17 13:48:58 +00:00
# subarchitectures-specific options below
config INTEL_MID
bool "Intel MID platform support"
x86: Add SCU IPC driver for Intel MID platforms Intel MID platforms have few microcontrollers inside SoC, one of them is so called System Controller Unit (SCU). Here is the driver to communicate with microcontroller. Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Simon Glass <sjg@chromium.org>
2017-04-01 13:21:33 +00:00
select REGMAP
select SYSCON
x86: Introduce INTEL_MID quirk option Intel Mobile Internet Device (MID) platforms have special treatment in some cases, such as CPU enumeration or boot parameters configuration. Besides that several drivers are specifically developed for the IP blocks found on Intel MID platforms. Those drivers will be dependent to this option. Here we introduce specific quirk option for such cases. It is supposed to be selected by Intel MID platform boards, for example, Intel Edison. Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-02-17 13:48:58 +00:00
help
Select to build a U-Boot capable of supporting Intel MID
(Mobile Internet Device) platform systems which do not have
the PCI legacy interfaces.
If you are building for a PC class system say N here.
Intel MID platforms are based on an Intel processor and
chipset which consume less power than most of the x86
derivatives.
x86: Kconfig: Divide the target selection to vendor/model Let arch/x86/Kconfig prompt board vendor first, then select the board model under that vendor. This way arch/x86/Kconfig only needs concern board vendor and leave the supported target list to board/<vendor>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:24 +00:00
# board-specific options below
x86: Add Advantech SOM-DB5800/SOM-6867 support Add support for Advantech SOM-DB5800 with the SOM-6867 installed. This is very similar to conga-qeval20-qa3-e3845 in that there is a reference carrier board (SOM-DB5800) with a Baytrail based SoM (SOM-6867) installed. Currently supported: - 2x UART (From ITE EC on SOM-6867) routed to COM3/4 connectors on SOM-DB5800. - 4x USB 2.0 (EHCI) - Video - SATA - Ethernet - PCIe - Realtek ALC892 HD Audio Pad configuration for HDA_RSTB, HDA_SYNC, HDA_CLK, HDA_SDO HDA_SDI0 is set in DT to enable HD Audio codec. Pin defaults for codec pin complexs are not changed. Not supported: - Winbond Super I/O (Must be disabled with jumpers on SOM-DB8500) - USB 3.0 (XHCI) - TPM Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-06-21 17:07:33 +00:00
source "board/advantech/Kconfig"
x86: Add congatec conga-QA3/E3845-4G (Bay Trail) support This patch adds support for the congatec conga-QA3/E3845-4G eMMC8 SoM, installed on the congatec Qseven 2.0 evaluation carrier board (conga-QEVAL). Its port is very similar to the MinnowboardMAX port and also uses the Intel FSP as described in doc/README.x86. Currently supported are the following interfaces / devices: - UART (via Winbond legacy SuperIO chip on carrier board) - Ethernet (PCIe Intel I210 / E1000) - SPI including SPI NOR as boot-device - USB 2.0 - SATA via U-Boot SCSI IF - eMMC - Video (HDMI output @ 800x600) - PCIe Not supported yet is: - I2C - USB 3.0 Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-16 07:48:21 +00:00
source "board/congatec/Kconfig"
x86: Kconfig: Divide the target selection to vendor/model Let arch/x86/Kconfig prompt board vendor first, then select the board model under that vendor. This way arch/x86/Kconfig only needs concern board vendor and leave the supported target list to board/<vendor>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:24 +00:00
source "board/coreboot/Kconfig"
x86: Add DFI BT700 BayTrail board support This patch adds support for the DFI BayTrail BT700 QSeven SoM installed on the DFI Q7X-151 baseboard. The baseboard is equipped with the Nuvoton NCT6102D Super IO chip providing the UART as console. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-08-15 11:50:49 +00:00
source "board/dfi/Kconfig"
x86: Add EFI board code Add support for the efi-x86 board, which supports running U-Boot as an EFI 32-bit application. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-04 18:33:47 +00:00
source "board/efi/Kconfig"
x86: Support QEMU x86 targets This commit introduces the initial U-Boot support for QEMU x86 targets. U-Boot can boot from coreboot as a payload, or directly without coreboot. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Merged in patch 'x86: qemu: Add CMD_NET to qemu-x86_defconfig https://patchwork.ozlabs.org/patch/479745/
2015-05-07 13:34:08 +00:00
source "board/emulation/Kconfig"
x86: Kconfig: Divide the target selection to vendor/model Let arch/x86/Kconfig prompt board vendor first, then select the board model under that vendor. This way arch/x86/Kconfig only needs concern board vendor and leave the supported target list to board/<vendor>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:24 +00:00
source "board/google/Kconfig"
source "board/intel/Kconfig"
x86: Kconfig: Move platform options forward Move platform-specific options under in arch/x86/Kconfig forward right after the board-specific options but before any architecture-specific options. When it comes to the same Kconfig option, board-specific one takes take the highest precedence, then platform-specific one, and finally architecture-specific one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:25 +00:00
# platform-specific options below
x86: apl: Add Kconfig and Makefile Add basic plumbing to allow Apollo Lake support to be used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-09 00:40:17 +00:00
source "arch/x86/cpu/apollolake/Kconfig"
x86: Kconfig: Move platform options forward Move platform-specific options under in arch/x86/Kconfig forward right after the board-specific options but before any architecture-specific options. When it comes to the same Kconfig option, board-specific one takes take the highest precedence, then platform-specific one, and finally architecture-specific one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:25 +00:00
source "arch/x86/cpu/baytrail/Kconfig"
x86: Add Intel Braswell SoC support This adds initial Intel Braswell SoC support. It uses Intel FSP to initialize the chipset. Similar to its predecessor BayTrail, there are some work to do to enable the legacy UART integrated in the Braswell SoC. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-16 05:41:58 +00:00
source "arch/x86/cpu/braswell/Kconfig"
x86: Add basic support for broadwell This adds the broadwell architecture, with the CPU driver and some useful header files. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:18 +00:00
source "arch/x86/cpu/broadwell/Kconfig"
x86: Kconfig: Move platform options forward Move platform-specific options under in arch/x86/Kconfig forward right after the board-specific options but before any architecture-specific options. When it comes to the same Kconfig option, board-specific one takes take the highest precedence, then platform-specific one, and finally architecture-specific one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:25 +00:00
source "arch/x86/cpu/coreboot/Kconfig"
source "arch/x86/cpu/ivybridge/Kconfig"
x86: efi: Refactor the directory of EFI app and payload support At present the EFI application and payload support codes in the x86 directory is distributed in a hybrid way. For example, the Kconfig options for both app and payload are in arch/x86/lib/efi/Kconfig, but the source codes in the same directory get built only for CONFIG_EFI_STUB. This refactors the codes by consolidating all the EFI support codes into arch/x86/cpu/efi, just like other x86 targets. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-06-12 15:36:16 +00:00
source "arch/x86/cpu/efi/Kconfig"
x86: Support QEMU x86 targets This commit introduces the initial U-Boot support for QEMU x86 targets. U-Boot can boot from coreboot as a payload, or directly without coreboot. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Merged in patch 'x86: qemu: Add CMD_NET to qemu-x86_defconfig https://patchwork.ozlabs.org/patch/479745/
2015-05-07 13:34:08 +00:00
source "arch/x86/cpu/qemu/Kconfig"
x86: Kconfig: Move platform options forward Move platform-specific options under in arch/x86/Kconfig forward right after the board-specific options but before any architecture-specific options. When it comes to the same Kconfig option, board-specific one takes take the highest precedence, then platform-specific one, and finally architecture-specific one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:25 +00:00
source "arch/x86/cpu/quark/Kconfig"
source "arch/x86/cpu/queensbay/Kconfig"
x86: Add new slimbootloader CPU type This slimbootloader CPU type is to enable U-Boot as a payload which runs on top of Slim Bootloader (https://github.com/slimbootloader). The Slim Bootloader is designed with multi-stage architecture for the execution from reset vector to OS booting, and supports QEMU, Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP (https://github.com/IntelFsp) for silicon initialization including CAR and memory initialization. The Slim Bootloader generates new HOB (Hand Off Block) which are serial port info, memory map info, performance data info and so on, and passes it to a Payload. U-Boot as a payload will use these HOB information for basic initialization such as serial console. As an initial commit, - Add CONFIG_SYS_SLIMBOOTLOADER to enable slimbootloader CPU type - Add new arch/x86/cpu/slimbootloader directory with minimum codes - Get hob_list pointer from Slim Bootloader Signed-off-by: Aiden Park <aiden.park@intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-08-03 08:30:12 +00:00
source "arch/x86/cpu/slimbootloader/Kconfig"
x86: Add Intel Tangier support Add Intel Tangier SoC support. Intel Tangier SoC is a core part of Intel Merrifield platform. For example, Intel Edison board is based on such platform. The patch is based on work done by the following people (in alphabetical order): Aiden Park <aiden.park@intel.com> Dukjoon Jeon <dukjoon.jeon@intel.com> eric.park <eric.park@intel.com> Fabien Chereau <fabien.chereau@intel.com> Scott D Phillips <scott.d.phillips@intel.com> Sebastien Colleur <sebastienx.colleur@intel.com> Steve Sakoman <steve.sakoman@intel.com> Vincent Tinelli <vincent.tinelli@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2017-07-06 11:41:52 +00:00
source "arch/x86/cpu/tangier/Kconfig"
x86: Kconfig: Move platform options forward Move platform-specific options under in arch/x86/Kconfig forward right after the board-specific options but before any architecture-specific options. When it comes to the same Kconfig option, board-specific one takes take the highest precedence, then platform-specific one, and finally architecture-specific one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:25 +00:00
# architecture-specific options below
dm: Rename disk uclass to ahci This started as 'ahci' and was renamed to 'disk' during code review. But it seems that this is too generic. Now that we have a 'blk' uclass, we can use that as the generic piece, and revert to ahci for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-01 17:35:52 +00:00
config AHCI
default y
dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to Kconfig Move this option to Kconfig and update all boards. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-11 23:32:59 +00:00
config SYS_MALLOC_F_LEN
default 0x800
x86: chromebook_link: Implement CAR support (cache as RAM) Add support for CAR so that we have memory to use prior to DRAM init. On link there is a total of 128KB of CAR available, although some is used for the memory reference code. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:10 +00:00
config RAMBASE
hex
default 0x100000
config XIP_ROM_SIZE
hex
x86: Hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected When CONFIG_X86_RESET_VECTOR is not selected, specifying the ROM chip size is meaningless, hence hide it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-01-06 14:14:16 +00:00
depends on X86_RESET_VECTOR
x86: Correct XIP_ROM_SIZE This should default to the size of the ROM for faster execution before relocation. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-01 23:17:54 +00:00
default ROM_SIZE
x86: chromebook_link: Implement CAR support (cache as RAM) Add support for CAR so that we have memory to use prior to DRAM init. On link there is a total of 128KB of CAR available, although some is used for the memory reference code. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:10 +00:00
config CPU_ADDR_BITS
int
default 36
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
config HPET_ADDRESS
hex
default 0xfed00000 if !HPET_ADDRESS_OVERRIDE
config SMM_TSEG
bool
default n
config SMM_TSEG_SIZE
hex
x86: Move CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig Convert CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig options so that we can remove them from board configuration file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-01-06 14:14:15 +00:00
config X86_RESET_VECTOR
bool
default n
pylibfdt: compile pylibfdt only when dtoc/binman is necessary Currently, pylibfdt is always compiled if swig is installed on your machine. It is really annoying because most of targets (excepts x86, sunxi, rockchip) do not use dtoc or binman. "checkbinman" and "checkdtoc" are wrong. It is odd that the final build stage checks if we have built necessary tools. If your platform depends on dtoc/binman, you must be able to build pylibfdt. If swig is not installed, it should fail immediately. I added PYLIBFDT, DTOC, BINMAN entries to Kconfig. They should be property select:ed by platforms that need them. Kbuild will descend into scripts/dtc/pylibfdt/ only when CONFIG_PYLIBFDT is enabled. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-10-17 04:42:44 +00:00
select BINMAN
x86: Move CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig Convert CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig options so that we can remove them from board configuration file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-01-06 14:14:15 +00:00
x86: Kconfig: Add location options for 16/32-bit init At present all 16/32-bit init is controlled by CONFIG_X86_RESET_VECTOR. If this is enabled, then U-Boot is the 'first' boot loader and handles execution from the reset vector through to U-Boot's command prompt. If it is not enabled then U-Boot starts at the 32-bit entry and skips most of its init, assuming that the previous boot loader has done this already. With the move to suport 64-bit operation, we have more cases to consider. The 16-bit and 32-bit init may be in SPL rather than in U-Boot proper. Add Kconfig options which control the location of the 16-bit and the 32-bit init. These are not intended to be user-setting except for experimentation. Their values should be determined by whether 64-bit U-Boot is used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:44 +00:00
# The following options control where the 16-bit and 32-bit init lies
# If SPL is enabled then it normally holds this init code, and U-Boot proper
# is normally a 64-bit build.
#
# The 16-bit init refers to the reset vector and the small amount of code to
# get the processor into 32-bit mode. It may be in SPL or in U-Boot proper,
# or missing altogether if U-Boot is started from EFI or coreboot.
#
# The 32-bit init refers to processor init, running binary blobs including
# FSP, setting up interrupts and anything else that needs to be done in
# 32-bit code. It is normally in the same place as 16-bit init if that is
# enabled (i.e. they are both in SPL, or both in U-Boot proper).
config X86_16BIT_INIT
bool
depends on X86_RESET_VECTOR
default y if X86_RESET_VECTOR && !SPL
help
This is enabled when 16-bit init is in U-Boot proper
config SPL_X86_16BIT_INIT
bool
depends on X86_RESET_VECTOR
x86: Support booting with TPL Some boards want to use TPL as the first phase of U-Boot. This allows selection of A or B SPL phases, thus allowing the memory init to be upgraded in the field. Add a new Kconfig option for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:46 +00:00
default y if X86_RESET_VECTOR && SPL && !TPL
x86: Kconfig: Add location options for 16/32-bit init At present all 16/32-bit init is controlled by CONFIG_X86_RESET_VECTOR. If this is enabled, then U-Boot is the 'first' boot loader and handles execution from the reset vector through to U-Boot's command prompt. If it is not enabled then U-Boot starts at the 32-bit entry and skips most of its init, assuming that the previous boot loader has done this already. With the move to suport 64-bit operation, we have more cases to consider. The 16-bit and 32-bit init may be in SPL rather than in U-Boot proper. Add Kconfig options which control the location of the 16-bit and the 32-bit init. These are not intended to be user-setting except for experimentation. Their values should be determined by whether 64-bit U-Boot is used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:44 +00:00
help
This is enabled when 16-bit init is in SPL
x86: Support booting with TPL Some boards want to use TPL as the first phase of U-Boot. This allows selection of A or B SPL phases, thus allowing the memory init to be upgraded in the field. Add a new Kconfig option for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:58:46 +00:00
config TPL_X86_16BIT_INIT
bool
depends on X86_RESET_VECTOR
default y if X86_RESET_VECTOR && TPL
help
This is enabled when 16-bit init is in TPL
x86: Kconfig: Add location options for 16/32-bit init At present all 16/32-bit init is controlled by CONFIG_X86_RESET_VECTOR. If this is enabled, then U-Boot is the 'first' boot loader and handles execution from the reset vector through to U-Boot's command prompt. If it is not enabled then U-Boot starts at the 32-bit entry and skips most of its init, assuming that the previous boot loader has done this already. With the move to suport 64-bit operation, we have more cases to consider. The 16-bit and 32-bit init may be in SPL rather than in U-Boot proper. Add Kconfig options which control the location of the 16-bit and the 32-bit init. These are not intended to be user-setting except for experimentation. Their values should be determined by whether 64-bit U-Boot is used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:03:44 +00:00
config X86_32BIT_INIT
bool
depends on X86_RESET_VECTOR
default y if X86_RESET_VECTOR && !SPL
help
This is enabled when 32-bit init is in U-Boot proper
config SPL_X86_32BIT_INIT
bool
depends on X86_RESET_VECTOR
default y if X86_RESET_VECTOR && SPL
help
This is enabled when 32-bit init is in SPL
x86: Introduce USE_EARLY_BOARD_INIT option Introduce USE_EARLY_BOARD_INIT option and select it by the actual users. Cc: George McCollister <george.mccollister@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Aiden Park <aiden.park@intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-08-20 10:02:20 +00:00
config USE_EARLY_BOARD_INIT
bool
x86: Add Kconfig options to be used by arch/x86/cpu/config.mk Add RESET_SEG_START, RESET_SEG_SIZE and RESET_VEC_LOC Kconfig options and make arch/x86/cpu/config.mk use these options. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Andrew Bradford <andrew.bradford@kodakalaris.com> Tested-by: Simon Glass <sjg@chromium.org>
2015-06-07 03:33:12 +00:00
config RESET_SEG_START
hex
depends on X86_RESET_VECTOR
default 0xffff0000
config RESET_VEC_LOC
hex
depends on X86_RESET_VECTOR
default 0xfffffff0
x86: Move CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig Convert CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig options so that we can remove them from board configuration file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-01-06 14:14:15 +00:00
config SYS_X86_START16
hex
depends on X86_RESET_VECTOR
default 0xfffff800
x86: Add an option to include a FIT Many Intel SoCs require a FIT in order to boot properly. Add an option to include this and enable it by default. This term can be confused with FIT (Flat Image Tree) in U-Boot so the CONFIG option has to include 'X86'. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:24 +00:00
config HAVE_X86_FIT
bool
help
Enable inclusion of an Intel Firmware Interface Table (FIT) into the
image. This table is supposed to point to microcode and the like. So
far it is just a fixed table with the minimum set of headers, so that
it is actually present.
x86: make LOAD_FROM_32_BIT visible for platforms This option is useful not only for development, but for the platforms where U-Boot is run from custom ROM bootloader. For example, Intel Edison is that board. Make this option visible that platforms can select it if needed. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-02-05 13:52:00 +00:00
config X86_LOAD_FROM_32_BIT
bool "Boot from a 32-bit program"
help
Define this to boot U-Boot from a 32-bit program which sets
the GDT differently. This can be used to boot directly from
any stage of coreboot, for example, bypassing the normal
payload-loading feature.
x86: Make ROM_SIZE configurable in Kconfig Currently the ROM_SIZE is hardcoded to 8MB in arch/x86/Kconfig. This will not be the case when adding additional board support. Hence we make ROM_SIZE configurable (512KB/1MB/2MB/4MB/8MB/16MB) and have the board Kconfig file select the default ROM_SIZE. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-12-12 13:05:19 +00:00
config BOARD_ROMSIZE_KB_512
bool
config BOARD_ROMSIZE_KB_1024
bool
config BOARD_ROMSIZE_KB_2048
bool
config BOARD_ROMSIZE_KB_4096
bool
config BOARD_ROMSIZE_KB_8192
bool
config BOARD_ROMSIZE_KB_16384
bool
choice
prompt "ROM chip size"
x86: Hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected When CONFIG_X86_RESET_VECTOR is not selected, specifying the ROM chip size is meaningless, hence hide it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-01-06 14:14:16 +00:00
depends on X86_RESET_VECTOR
x86: Make ROM_SIZE configurable in Kconfig Currently the ROM_SIZE is hardcoded to 8MB in arch/x86/Kconfig. This will not be the case when adding additional board support. Hence we make ROM_SIZE configurable (512KB/1MB/2MB/4MB/8MB/16MB) and have the board Kconfig file select the default ROM_SIZE. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-12-12 13:05:19 +00:00
default UBOOT_ROMSIZE_KB_512 if BOARD_ROMSIZE_KB_512
default UBOOT_ROMSIZE_KB_1024 if BOARD_ROMSIZE_KB_1024
default UBOOT_ROMSIZE_KB_2048 if BOARD_ROMSIZE_KB_2048
default UBOOT_ROMSIZE_KB_4096 if BOARD_ROMSIZE_KB_4096
default UBOOT_ROMSIZE_KB_8192 if BOARD_ROMSIZE_KB_8192
default UBOOT_ROMSIZE_KB_16384 if BOARD_ROMSIZE_KB_16384
help
Select the size of the ROM chip you intend to flash U-Boot on.
The build system will take care of creating a u-boot.rom file
of the matching size.
config UBOOT_ROMSIZE_KB_512
bool "512 KB"
help
Choose this option if you have a 512 KB ROM chip.
config UBOOT_ROMSIZE_KB_1024
bool "1024 KB (1 MB)"
help
Choose this option if you have a 1024 KB (1 MB) ROM chip.
config UBOOT_ROMSIZE_KB_2048
bool "2048 KB (2 MB)"
help
Choose this option if you have a 2048 KB (2 MB) ROM chip.
config UBOOT_ROMSIZE_KB_4096
bool "4096 KB (4 MB)"
help
Choose this option if you have a 4096 KB (4 MB) ROM chip.
config UBOOT_ROMSIZE_KB_8192
bool "8192 KB (8 MB)"
help
Choose this option if you have a 8192 KB (8 MB) ROM chip.
config UBOOT_ROMSIZE_KB_16384
bool "16384 KB (16 MB)"
help
Choose this option if you have a 16384 KB (16 MB) ROM chip.
endchoice
# Map the config names to an integer (KB).
config UBOOT_ROMSIZE_KB
int
default 512 if UBOOT_ROMSIZE_KB_512
default 1024 if UBOOT_ROMSIZE_KB_1024
default 2048 if UBOOT_ROMSIZE_KB_2048
default 4096 if UBOOT_ROMSIZE_KB_4096
default 8192 if UBOOT_ROMSIZE_KB_8192
default 16384 if UBOOT_ROMSIZE_KB_16384
# Map the config names to a hex value (bytes).
x86: Build a .rom file which can be flashed to an x86 machine On x86 machines U-Boot needs to be added to a large ROM image which is then flashed onto the target board. The ROM has a particular format so it makes sense for U-Boot to build this image automatically. Unfortunately it relies on binary blobs so we cannot require this for the default build as yet. Create a u-boot.rom output file for this purpose. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:08 +00:00
config ROM_SIZE
hex
x86: Make ROM_SIZE configurable in Kconfig Currently the ROM_SIZE is hardcoded to 8MB in arch/x86/Kconfig. This will not be the case when adding additional board support. Hence we make ROM_SIZE configurable (512KB/1MB/2MB/4MB/8MB/16MB) and have the board Kconfig file select the default ROM_SIZE. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-12-12 13:05:19 +00:00
default 0x80000 if UBOOT_ROMSIZE_KB_512
default 0x100000 if UBOOT_ROMSIZE_KB_1024
default 0x200000 if UBOOT_ROMSIZE_KB_2048
default 0x400000 if UBOOT_ROMSIZE_KB_4096
default 0x800000 if UBOOT_ROMSIZE_KB_8192
default 0xc00000 if UBOOT_ROMSIZE_KB_12288
default 0x1000000 if UBOOT_ROMSIZE_KB_16384
x86: Build a .rom file which can be flashed to an x86 machine On x86 machines U-Boot needs to be added to a large ROM image which is then flashed onto the target board. The ROM has a particular format so it makes sense for U-Boot to build this image automatically. Unfortunately it relies on binary blobs so we cannot require this for the default build as yet. Create a u-boot.rom output file for this purpose. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:08 +00:00
config HAVE_INTEL_ME
bool "Platform requires Intel Management Engine"
help
Newer higher-end devices have an Intel Management Engine (ME)
which is a very large binary blob (typically 1.5MB) which is
required for the platform to work. This enforces a particular
SPI flash format. You will need to supply the me.bin file in
your board directory.
x86: ivybridge: Implement SDRAM init Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:28 +00:00
config X86_RAMTEST
bool "Perform a simple RAM test after SDRAM initialisation"
help
If there is something wrong with SDRAM then the platform will
often crash within U-Boot or the kernel. This option enables a
very simple RAM test that quickly checks whether the SDRAM seems
to work correctly. It is not exhaustive but can save time by
detecting obvious failures.
x86: Kconfig: Add options to configure the descriptor.bin / me.bin filenames This introduces two Kconfig options to enable board specific filenames for the Intel binary blobs to be used to generate the SPI flash image. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-03-30 10:58:10 +00:00
config FLASH_DESCRIPTOR_FILE
string "Flash descriptor binary filename"
x86: fsp: Add FSP2 base support Add support for some important configuration options and FSP memory init. The memory init uses swizzle tables from the device tree. Support for the FSP_S binary is also included. Bootstage timing is used for both FSP_M and FSP_S and memory-mapped SPI reads. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:18 +00:00
depends on HAVE_INTEL_ME || FSP_VERSION2
x86: Kconfig: Add options to configure the descriptor.bin / me.bin filenames This introduces two Kconfig options to enable board specific filenames for the Intel binary blobs to be used to generate the SPI flash image. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-03-30 10:58:10 +00:00
default "descriptor.bin"
help
The filename of the file to use as flash descriptor in the
board directory.
config INTEL_ME_FILE
string "Intel Management Engine binary filename"
depends on HAVE_INTEL_ME
default "me.bin"
help
The filename of the file to use as Intel Management Engine in the
board directory.
x86: Add new slimbootloader CPU type This slimbootloader CPU type is to enable U-Boot as a payload which runs on top of Slim Bootloader (https://github.com/slimbootloader). The Slim Bootloader is designed with multi-stage architecture for the execution from reset vector to OS booting, and supports QEMU, Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP (https://github.com/IntelFsp) for silicon initialization including CAR and memory initialization. The Slim Bootloader generates new HOB (Hand Off Block) which are serial port info, memory map info, performance data info and so on, and passes it to a Payload. U-Boot as a payload will use these HOB information for basic initialization such as serial console. As an initial commit, - Add CONFIG_SYS_SLIMBOOTLOADER to enable slimbootloader CPU type - Add new arch/x86/cpu/slimbootloader directory with minimum codes - Get hob_list pointer from Slim Bootloader Signed-off-by: Aiden Park <aiden.park@intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-08-03 08:30:12 +00:00
config USE_HOB
bool "Use HOB (Hand-Off Block)"
help
Select this option to access HOB (Hand-Off Block) data structures
and parse HOBs. This HOB infra structure can be reused with
different solutions across different platforms.
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
config HAVE_FSP
bool "Add an Firmware Support Package binary"
x86: Handle running as EFI payload When U-Boot runs as an EFI payload it needs to avoid setting up the CPU again. Also U-Boot currently does not handle interrupts for many devices, so run with interrupts disabled. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-04 18:34:00 +00:00
depends on !EFI
x86: Add new slimbootloader CPU type This slimbootloader CPU type is to enable U-Boot as a payload which runs on top of Slim Bootloader (https://github.com/slimbootloader). The Slim Bootloader is designed with multi-stage architecture for the execution from reset vector to OS booting, and supports QEMU, Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP (https://github.com/IntelFsp) for silicon initialization including CAR and memory initialization. The Slim Bootloader generates new HOB (Hand Off Block) which are serial port info, memory map info, performance data info and so on, and passes it to a Payload. U-Boot as a payload will use these HOB information for basic initialization such as serial console. As an initial commit, - Add CONFIG_SYS_SLIMBOOTLOADER to enable slimbootloader CPU type - Add new arch/x86/cpu/slimbootloader directory with minimum codes - Get hob_list pointer from Slim Bootloader Signed-off-by: Aiden Park <aiden.park@intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-08-03 08:30:12 +00:00
select USE_HOB
x86: Change how selection of ROMs works Most x86 boards build a u-boot.rom which is programmed into SPI flash. But this is not unique to x86. For example some rockchip boards can also boot from SPI flash. Also, at least on x86, binary blobs are sadly quite common. It is not possible to build a functional image without them, and U-Boot needs to know this at build time. Introduce a new CONFIG_HAS_ROM option which selects whether u-boot.rom is built and a new CONFIG_ROM_NEEDS_BLOBS option to indicate whether binary blobs are also needed. If they are not needed, it is safe to build the ROM always. Otherwise we still require the BUILD_ROM environment variable. For now this affects only x86, but future patches will enable this for rockchip too. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-07-19 19:55:52 +00:00
select HAS_ROM
select ROM_NEEDS_BLOBS
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
help
Select this option to add an Firmware Support Package binary to
the resulting U-Boot image. It is a binary blob which U-Boot uses
to set up SDRAM and other chipset specific initialization.
Note: Without this binary U-Boot will not be able to set up its
SDRAM so will not boot.
x86: Change condition for using CAR At present we assume that CAR (Cache-as-RAM) is used if HOBs (Hand-off blocks) are not, since HOBs typically indicate that an FSP is in use, and FSPs handle the CAR init. However this is a bit indirect, and for FSP2 machines which use their own CAR implementation (such as apollolake) but use the FSP for other functions, the logic is wrong. To fix this, add a dedicated Kconfig option to indicate when CAR is used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fix a typo in the commit message] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:11:43 +00:00
config USE_CAR
bool "Use Cache-As-RAM (CAR) to get temporary RAM at start-up"
default y if !HAVE_FSP
help
Select this option if your board uses CAR init code, typically in a
car.S file, to get some initial memory for code execution. This is
common with Intel CPUs which don't use FSP.
x86: Rename existing FSP code to fsp1 Since there is now a new version of the FSP and it is incompatible with the existing version, move the code into an fsp1 directory. This will allow us to put FSP v2 code into an fsp2 directory. Add a Kconfig which defines which version is in use. Some of the code in this new fsp1/ directory is generic across both FSPv1 and FSPv2. Future patches will address this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:00:11 +00:00
choice
prompt "FSP version"
depends on HAVE_FSP
default FSP_VERSION1
help
Selects the FSP version to use. Intel has published several versions
of the FSP External Architecture Specification and this allows
selection of the version number used by a particular SoC.
config FSP_VERSION1
bool "FSP version 1.x"
help
This covers versions 1.0 and 1.1a. See here for details:
https://github.com/IntelFsp/fsp/wiki
config FSP_VERSION2
bool "FSP version 2.x"
help
This covers versions 2.0 and 2.1. See here for details:
https://github.com/IntelFsp/fsp/wiki
endchoice
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
config FSP_FILE
string "Firmware Support Package binary filename"
x86: Update Kconfig options for FSP1 Many of the Kconfig options do not apply to FSP2. Update them to use the FSP_VERSION1 condition instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:14 +00:00
depends on FSP_VERSION1
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
default "fsp.bin"
help
The filename of the file to use as Firmware Support Package binary
in the board directory.
config FSP_ADDR
hex "Firmware Support Package binary location"
x86: Update Kconfig options for FSP1 Many of the Kconfig options do not apply to FSP2. Update them to use the FSP_VERSION1 condition instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:14 +00:00
depends on FSP_VERSION1
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
default 0xfffc0000
help
FSP is not Position Independent Code (PIC) and the whole FSP has to
be rebased if it is placed at a location which is different from the
perferred base address specified during the FSP build. Use Intel's
Binary Configuration Tool (BCT) to do the rebase.
The default base address of 0xfffc0000 indicates that the binary must
be located at offset 0xc0000 from the beginning of a 1MB flash device.
x86: fsp: Add FSP2 base support Add support for some important configuration options and FSP memory init. The memory init uses swizzle tables from the device tree. Support for the FSP_S binary is also included. Bootstage timing is used for both FSP_M and FSP_S and memory-mapped SPI reads. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:18 +00:00
if FSP_VERSION2
config FSP_FILE_T
string "Firmware Support Package binary filename (Temp RAM)"
default "fsp_t.bin"
help
The filename of the file to use for the temporary-RAM init phase from
the Firmware Support Package binary. Put this in the board directory.
It is used to set up an initial area of RAM which can be used for the
stack and other purposes, while bringing up the main system DRAM.
config FSP_ADDR_T
hex "Firmware Support Package binary location (Temp RAM)"
default 0xffff8000
help
FSP is not Position-Independent Code (PIC) and FSP components have to
be rebased if placed at a location which is different from the
perferred base address specified during the FSP build. Use Intel's
Binary Configuration Tool (BCT) to do the rebase.
config FSP_FILE_M
string "Firmware Support Package binary filename (Memory Init)"
default "fsp_m.bin"
help
The filename of the file to use for the RAM init phase from the
Firmware Support Package binary. Put this in the board directory.
It is used to set up the main system DRAM and runs in SPL, once
temporary RAM (CAR) is working.
config FSP_FILE_S
string "Firmware Support Package binary filename (Silicon Init)"
default "fsp_s.bin"
help
The filename of the file to use for the Silicon init phase from the
Firmware Support Package binary. Put this in the board directory.
It is used to set up the silicon to work correctly and must be
executed after DRAM is running.
config IFWI_INPUT_FILE
string "Filename containing FIT (Firmware Interface Table) with IFWI"
default "fitimage.bin"
help
The IFWI is obtained by running a tool on this file to extract the
IFWI. Put this in the board directory. The IFWI contains U-Boot TPL,
microcode and other internal items.
endif
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
config FSP_TEMP_RAM_ADDR
hex
x86: Update Kconfig options for FSP1 Many of the Kconfig options do not apply to FSP2. Update them to use the FSP_VERSION1 condition instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:14 +00:00
depends on FSP_VERSION1
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
default 0x2000000
help
x86: fsp: Add comments about U-Boot entering start.S twice Add some comments in start.S for the fact that with FSP U-Boot actually enters the code twice. Also change to use fsp_init() and fsp_continue for accuracy. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-20 13:40:20 +00:00
Stack top address which is used in fsp_init() after DRAM is ready and
x86: Allow FSP Kconfig settings for all x86 While queensbay is the first chip with these settings, others will want to use them too. Make them common. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:41 +00:00
CAR is disabled.
x86: fsp: Enlarge the size of malloc() pool before relocation After fsp_init() returns, the stack has already been switched to a place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR. Enlarge the size of malloc() pool before relocation since we have plenty of memory now. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-20 13:40:19 +00:00
config FSP_SYS_MALLOC_F_LEN
hex
x86: Update Kconfig options for FSP1 Many of the Kconfig options do not apply to FSP2. Update them to use the FSP_VERSION1 condition instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:14 +00:00
depends on FSP_VERSION1
x86: fsp: Enlarge the size of malloc() pool before relocation After fsp_init() returns, the stack has already been switched to a place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR. Enlarge the size of malloc() pool before relocation since we have plenty of memory now. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-20 13:40:19 +00:00
default 0x100000
help
Additional size of malloc() pool before relocation.
x86: fsp: Introduce CONFIG_FSP_USE_UPD Kconfig option Not every FSP supports UPD, thus we introduce a Kconfig option CONFIG_FSP_USE_UPD and use it to wrap these common UPD handling codes in fsp_support.c. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-12-11 06:03:01 +00:00
config FSP_USE_UPD
bool
x86: Update Kconfig options for FSP1 Many of the Kconfig options do not apply to FSP2. Update them to use the FSP_VERSION1 condition instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:14 +00:00
depends on FSP_VERSION1
x86: fsp: Introduce CONFIG_FSP_USE_UPD Kconfig option Not every FSP supports UPD, thus we introduce a Kconfig option CONFIG_FSP_USE_UPD and use it to wrap these common UPD handling codes in fsp_support.c. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2015-12-11 06:03:01 +00:00
default y
help
Most FSPs use UPD data region for some FSP customization. But there
are still some FSPs that might not even have UPD. For such FSPs,
override this to n in their platform Kconfig files.
x86: fsp: Make sure HOB list is not overwritten by U-Boot Intel IvyBridge FSP seems to be buggy that it does not report memory used by FSP itself as reserved in the resource descriptor HOB. The FSP specification does not describe how resource descriptor HOBs are generated by the FSP to describe what memory regions. It looks newer FSPs like Queensbay and BayTrail do not have such issue. This causes U-Boot relocation overwrites the important boot service data which is used by FSP, and the subsequent call to fsp_notify() will fail. To resolve this, we find out the lowest memory base address allocated by FSP for the boot service data when walking through the HOB list in fsp_get_usable_lowmem_top(). Check whether the memory top address is below the FSP HOB list, and if not, use the lowest memory base address allocated by FSP as the memory top address. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on link (ivybridge non-FSP) Tested-by: Simon Glass <sjg@chromium.org>
2016-02-17 08:16:23 +00:00
config FSP_BROKEN_HOB
bool
x86: Update Kconfig options for FSP1 Many of the Kconfig options do not apply to FSP2. Update them to use the FSP_VERSION1 condition instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:57:14 +00:00
depends on FSP_VERSION1
x86: fsp: Make sure HOB list is not overwritten by U-Boot Intel IvyBridge FSP seems to be buggy that it does not report memory used by FSP itself as reserved in the resource descriptor HOB. The FSP specification does not describe how resource descriptor HOBs are generated by the FSP to describe what memory regions. It looks newer FSPs like Queensbay and BayTrail do not have such issue. This causes U-Boot relocation overwrites the important boot service data which is used by FSP, and the subsequent call to fsp_notify() will fail. To resolve this, we find out the lowest memory base address allocated by FSP for the boot service data when walking through the HOB list in fsp_get_usable_lowmem_top(). Check whether the memory top address is below the FSP HOB list, and if not, use the lowest memory base address allocated by FSP as the memory top address. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on link (ivybridge non-FSP) Tested-by: Simon Glass <sjg@chromium.org>
2016-02-17 08:16:23 +00:00
help
Indicate some buggy FSPs that does not report memory used by FSP
itself as reserved in the resource descriptor HOB. Select this to
tell U-Boot to do some additional work to ensure U-Boot relocation
do not overwrite the important boot service data which is used by
FSP, otherwise the subsequent call to fsp_notify() will fail.
x86: Add ENABLE_MRC_CACHE Kconfig option Create a Kconfig option for enabling MRC cache. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-12 04:37:35 +00:00
config ENABLE_MRC_CACHE
bool "Enable MRC cache"
depends on !EFI && !SYS_COREBOOT
help
Enable this feature to cause MRC data to be cached in NV storage
to be used for speeding up boot time on future reboots and/or
power cycles.
x86: Add some notes for MRC cache with Intel FSP MRC cache relies on Intel FSP to produce a special GUID that contains the MRC cache data. Add such information in the CONFIG_ENABLE_MRC_CACHE help entry. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-05-22 08:45:27 +00:00
For platforms that use Intel FSP for the memory initialization,
please check FSP output HOB via U-Boot command 'fsp hob' to see
x86: Rename existing FSP code to fsp1 Since there is now a new version of the FSP and it is incompatible with the existing version, move the code into an fsp1 directory. This will allow us to put FSP v2 code into an fsp2 directory. Add a Kconfig which defines which version is in use. Some of the code in this new fsp1/ directory is generic across both FSPv1 and FSPv2. Future patches will address this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-09-25 14:00:11 +00:00
if there is FSP_NON_VOLATILE_STORAGE_HOB_GUID (asm/fsp1/fsp_hob.h).
Fix spelling of available. Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
2019-05-03 22:28:37 +00:00
If such GUID does not exist, MRC cache is not available on such
x86: Add some notes for MRC cache with Intel FSP MRC cache relies on Intel FSP to produce a special GUID that contains the MRC cache data. Add such information in the CONFIG_ENABLE_MRC_CACHE help entry. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-05-22 08:45:27 +00:00
platform (eg: Intel Queensbay), which means selecting this option
here does not make any difference.
x86: Move common MRC Kconfig options to the common file At present the MRC options are private to ivybridge. Other Intel CPUs also use these settings. Move them to a common place. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:08 +00:00
config HAVE_MRC
bool "Add a System Agent binary"
x86: Change how selection of ROMs works Most x86 boards build a u-boot.rom which is programmed into SPI flash. But this is not unique to x86. For example some rockchip boards can also boot from SPI flash. Also, at least on x86, binary blobs are sadly quite common. It is not possible to build a functional image without them, and U-Boot needs to know this at build time. Introduce a new CONFIG_HAS_ROM option which selects whether u-boot.rom is built and a new CONFIG_ROM_NEEDS_BLOBS option to indicate whether binary blobs are also needed. If they are not needed, it is safe to build the ROM always. Otherwise we still require the BUILD_ROM environment variable. For now this affects only x86, but future patches will enable this for rockchip too. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-07-19 19:55:52 +00:00
select HAS_ROM
select ROM_NEEDS_BLOBS
x86: Move common MRC Kconfig options to the common file At present the MRC options are private to ivybridge. Other Intel CPUs also use these settings. Move them to a common place. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:08 +00:00
depends on !HAVE_FSP
help
Select this option to add a System Agent binary to
the resulting U-Boot image. MRC stands for Memory Reference Code.
It is a binary blob which U-Boot uses to set up SDRAM.
Note: Without this binary U-Boot will not be able to set up its
SDRAM so will not boot.
config CACHE_MRC_BIN
bool
depends on HAVE_MRC
default n
help
Enable caching for the memory reference code binary. This uses an
MTRR (memory type range register) to turn on caching for the section
of SPI flash that contains the memory reference code. This makes
SDRAM init run faster.
config CACHE_MRC_SIZE_KB
int
depends on HAVE_MRC
default 512
help
Sets the size of the cached area for the memory reference code.
This ends at the end of SPI flash (address 0xffffffff) and is
measured in KB. Typically this is set to 512, providing for 0.5MB
of cached space.
config DCACHE_RAM_BASE
hex
depends on HAVE_MRC
help
Sets the base of the data cache area in memory space. This is the
start address of the cache-as-RAM (CAR) area and the address varies
depending on the CPU. Once CAR is set up, read/write memory becomes
available at this address and can be used temporarily until SDRAM
is working.
config DCACHE_RAM_SIZE
hex
depends on HAVE_MRC
default 0x40000
help
Sets the total size of the data cache area in memory space. This
sets the size of the cache-as-RAM (CAR) area. Note that much of the
CAR space is required by the MRC. The CAR space available to U-Boot
is normally at the start and typically extends to 1/4 or 1/2 of the
available size.
config DCACHE_RAM_MRC_VAR_SIZE
hex
depends on HAVE_MRC
help
This is the amount of CAR (Cache as RAM) reserved for use by the
memory reference code. This depends on the implementation of the
memory reference code and must be set correctly or the board will
not boot.
x86: Add support for running Intel reference code Intel has invented yet another binary blob which firmware is required to run. This is run after SDRAM is ready. It is linked to load at a particular address, typically 0, but is a relocatable ELF so can be moved if required. Add support for this in the build system. The file should be placed in the board directory, and called refcode.elf. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:16 +00:00
config HAVE_REFCODE
bool "Add a Reference Code binary"
help
Select this option to add a Reference Code binary to the resulting
U-Boot image. This is an Intel binary blob that handles system
initialisation, in this case the PCH and System Agent.
Note: Without this binary (on platforms that need it such as
broadwell) U-Boot will be missing some critical setup steps.
Various peripherals may fail to work.
x86: Disable microcode section for FSP2 At present we don't support loading microcode with FSP2. The correct way to do this is by adding it to the FIT. For now, disable including microcode in the image. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:26 +00:00
config HAVE_MICROCODE
x86: chromebook_panther: Correct the image layout This board does not have microcode but at present that is not supported by Kconfig nor the binman image layout. Fix both of these. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-19 19:56:17 +00:00
bool "Board requires a microcode binary"
x86: Disable microcode section for FSP2 At present we don't support loading microcode with FSP2. The correct way to do this is by adding it to the FIT. For now, disable including microcode in the image. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:26 +00:00
default y if !FSP_VERSION2
x86: chromebook_panther: Correct the image layout This board does not have microcode but at present that is not supported by Kconfig nor the binman image layout. Fix both of these. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-19 19:56:17 +00:00
help
Enable this if the board requires microcode to be loaded on boot.
Typically this is handed by the FSP for modern boards, but for
some older boards, it must be programmed by U-Boot, and that form
part of the image.
x86: Disable microcode section for FSP2 At present we don't support loading microcode with FSP2. The correct way to do this is by adding it to the FIT. For now, disable including microcode in the image. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:26 +00:00
x86: Add multi-processor init Most modern x86 CPUs include more than one CPU core. The OS normally requires that these 'Application Processors' (APs) be brought up by the boot loader. Add the required support to U-Boot to init additional APs. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-04-30 04:25:59 +00:00
config SMP
bool "Enable Symmetric Multiprocessing"
default n
help
Enable use of more than one CPU in U-Boot and the Operating System
when loaded. Each CPU will be started up and information can be
obtained using the 'cpu' command. If this option is disabled, then
only one CPU will be enabled regardless of the number of CPUs
available.
x86: mp: Support APs waiting for instructions At present the APs (non-boot CPUs) are inited once and then parked ready for the OS to use them. However in some cases we want to send new requests through, such as to change MTRRs and keep them consistent across CPUs. Change the last state of the flight plan to go into a wait loop, accepting instructions from the main CPU. Drop cpu_map since it is not used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17 14:48:16 +00:00
config SMP_AP_WORK
bool
depends on SMP
help
Allow APs to do other work after initialisation instead of going
to sleep.
x86: kconfig: Fix minor nits in MAX_CPUS Move MAX_CPUS definition after SMP so that it shows below SMP in the menuconfig. Also replace the leading spaces in the MAX_CPUS section with tabs to conform coding standard. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-06-12 06:52:23 +00:00
config MAX_CPUS
int "Maximum number of CPUs permitted"
depends on SMP
default 4
help
When using multi-CPU chips it is possible for U-Boot to start up
more than one CPU. The stack memory used by all of these CPUs is
pre-allocated so at present U-Boot wants to know the maximum
number of CPUs that may be present. Set this to at least as high
as the number of CPUs in your system (it uses about 4KB of RAM for
each CPU).
x86: Add multi-processor init Most modern x86 CPUs include more than one CPU core. The OS normally requires that these 'Application Processors' (APs) be brought up by the boot loader. Add the required support to U-Boot to init additional APs. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-04-30 04:25:59 +00:00
config AP_STACK_SIZE
hex
x86: kconfig: Make MAX_CPUS and AP_STACK_SIZE depend on SMP MAX_CPUS and AP_STACK_SIZE are only meaningful when SMP is on. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-06-12 06:52:22 +00:00
depends on SMP
x86: Add multi-processor init Most modern x86 CPUs include more than one CPU core. The OS normally requires that these 'Application Processors' (APs) be brought up by the boot loader. Add the required support to U-Boot to init additional APs. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-04-30 04:25:59 +00:00
default 0x1000
help
Each additional CPU started by U-Boot requires its own stack. This
option sets the stack size used by each CPU and directly affects
the memory used by this initialisation process. Typically 4KB is
enough space.
x86: Convert CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED to Kconfig This converts CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED to a Kconfig option. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2017-08-17 08:10:42 +00:00
config CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED
bool
help
This option indicates that the turbo mode setting is not package
scoped. i.e. turbo_enable() needs to be called on not just the
bootstrap processor (BSP).
x86: Move VGA option rom macros to Kconfig Move X86_OPTION_ROM_FILE & X86_OPTION_ROM_ADDR to arch/x86/Kconfig and rename them to VGA_BIOS_FILE & VGA_BIOS_ADDR which depend on HAVE_VGA_BIOS. The new names are consistent with other x86 binary blob options like HAVE_FSP/FSP_FILE/FSP_ADDR. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-06 08:31:33 +00:00
config HAVE_VGA_BIOS
bool "Add a VGA BIOS image"
help
Select this option if you have a VGA BIOS image that you would
like to add to your ROM.
config VGA_BIOS_FILE
string "VGA BIOS image filename"
depends on HAVE_VGA_BIOS
default "vga.bin"
help
The filename of the VGA BIOS image in the board directory.
config VGA_BIOS_ADDR
hex "VGA BIOS image location"
depends on HAVE_VGA_BIOS
default 0xfff90000
help
The location of VGA BIOS image in the SPI flash. For example, base
address of 0xfff90000 indicates that the image will be put at offset
0x90000 from the beginning of a 1MB flash device.
x86: Add Video BIOS Table (VBT) related Kconfig options This adds Kconfig options for Video BIOS Table which is normally required if you are using an Intel FSP firmware that is complaint with spec 1.1 or later to initialize the integrated graphics device. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-16 05:41:53 +00:00
config HAVE_VBT
bool "Add a Video BIOS Table (VBT) image"
x86: fsp: Add FSP2 base support Add support for some important configuration options and FSP memory init. The memory init uses swizzle tables from the device tree. Support for the FSP_S binary is also included. Bootstage timing is used for both FSP_M and FSP_S and memory-mapped SPI reads. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:18 +00:00
depends on HAVE_FSP
x86: Add Video BIOS Table (VBT) related Kconfig options This adds Kconfig options for Video BIOS Table which is normally required if you are using an Intel FSP firmware that is complaint with spec 1.1 or later to initialize the integrated graphics device. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-16 05:41:53 +00:00
help
Select this option if you have a Video BIOS Table (VBT) image that
you would like to add to your ROM. This is normally required if you
are using an Intel FSP firmware that is complaint with spec 1.1 or
later to initialize the integrated graphics device (IGD).
Video BIOS Table, or VBT, provides platform and board specific
configuration information to the driver that is not discoverable
or available through other means. By other means the most used
method here is to read EDID table from the attached monitor, over
Display Data Channel (DDC) using two pin I2C serial interface. VBT
configuration is related to display hardware and is available via
the ACPI OpRegion or, on older systems, in the PCI ROM (Option ROM).
config VBT_FILE
string "Video BIOS Table (VBT) image filename"
depends on HAVE_VBT
default "vbt.bin"
help
The filename of the file to use as Video BIOS Table (VBT) image
in the board directory.
config VBT_ADDR
hex "Video BIOS Table (VBT) image location"
depends on HAVE_VBT
default 0xfff90000
help
The location of Video BIOS Table (VBT) image in the SPI flash. For
example, base address of 0xfff90000 indicates that the image will
be put at offset 0x90000 from the beginning of a 1MB flash device.
x86: dm: video: Add a framebuffer driver that utilizes VBT When a VBT is given to an FSP that supports graphics initialization, the FSP will produce a graphics info HOB that contains all necessary information for the linear frame buffer of the integrated graphics device. This adds a DM video driver for it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-16 05:41:56 +00:00
config VIDEO_FSP
bool "Enable FSP framebuffer driver support"
depends on HAVE_VBT && DM_VIDEO
help
Turn on this option to enable a framebuffer driver when U-Boot is
using Video BIOS Table (VBT) image for FSP firmware to initialize
the integrated graphics device.
x86: Make table address selectable Some firmwares might have another window for generated tables. So, introduce two configuration options to select start address and maximum length for the generated tables. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-07-28 17:02:15 +00:00
config ROM_TABLE_ADDR
hex
default 0xf0000
help
All x86 tables happen to like the address range from 0x0f0000
to 0x100000. We use 0xf0000 as the starting address to store
those tables, including PIRQ routing table, Multi-Processor
table and ACPI table.
config ROM_TABLE_SIZE
hex
default 0x10000
x86: itss: Add a Kconfig option to enable/disable ITSS driver Add a Kconfig option to support enabling/disabling the inclusion of the ITSS driver depending on the platform. Atuomatically select the ITSS driver when building for Apollo Lake. Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: squashed in http://patchwork.ozlabs.org/patch/1232761/] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-03 13:06:45 +00:00
config HAVE_ITSS
bool "Enable ITSS"
help
Select this to include the driver for the Interrupt Timer
Subsystem (ITSS) which is found on several Intel devices.
x86: Move P2SB from Apollo Lake to a more generic location The Primary to Sideband Bridge (P2SB) is not specific to Apollo Lake, so move its driver to a common location within arch/x86. Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-04 08:04:56 +00:00
config HAVE_P2SB
bool "Enable P2SB"
x86: p2sb: make P2SB driver depend on P2SB uclass Currently it is possible to select the P2SB driver without selecting the P2SB uclass, which can't work. Fix this by adding a "depends on" in Kconfig. Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-01 11:37:24 +00:00
depends on P2SB
x86: Move P2SB from Apollo Lake to a more generic location The Primary to Sideband Bridge (P2SB) is not specific to Apollo Lake, so move its driver to a common location within arch/x86. Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-04 08:04:56 +00:00
help
Select this to include the driver for the Primary to
Sideband Bridge (P2SB) which is found on several Intel
devices.
x86: Support platform PIRQ routing On x86 boards, platform chipset receives up to four different interrupt signals from PCI devices (INTA/B/C/D), which in turn will be routed to chipset internal PIRQ lines then routed to 8259 PIC finally if configuring the whole system to work under the so-called PIC mode (in contrast to symmetric IO mode which uses IOAPIC). We add two major APIs to aid this, one for routing PIRQ and the other one for generating a PIRQ routing table. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 10:10:05 +00:00
menu "System tables"
x86: kconfig: Hide "System tables" for coreboot When booting as a coreboot payload, we don't need write any configuration tables as coreboot does that for us. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-13 07:29:13 +00:00
depends on !EFI && !SYS_COREBOOT
x86: Support platform PIRQ routing On x86 boards, platform chipset receives up to four different interrupt signals from PCI devices (INTA/B/C/D), which in turn will be routed to chipset internal PIRQ lines then routed to 8259 PIC finally if configuring the whole system to work under the so-called PIC mode (in contrast to symmetric IO mode which uses IOAPIC). We add two major APIs to aid this, one for routing PIRQ and the other one for generating a PIRQ routing table. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 10:10:05 +00:00
config GENERATE_PIRQ_TABLE
bool "Generate a PIRQ table"
default n
help
Generate a PIRQ routing table for this board. The PIRQ routing table
is generated by U-Boot in the system memory from 0xf0000 to 0xfffff
at every 16-byte boundary with a PCI IRQ routing signature ("$PIR").
It specifies the interrupt router information as well how all the PCI
devices' interrupt pins are wired to PIRQs.
x86: Add support for the Simple Firmware Interface (SFI) This provides a way of passing information to Linux without requiring the full ACPI horror. Provide a rudimentary implementation sufficient to be recognised and parsed by Linux. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-04-29 02:25:10 +00:00
config GENERATE_SFI_TABLE
bool "Generate a SFI (Simple Firmware Interface) table"
help
The Simple Firmware Interface (SFI) provides a lightweight method
for platform firmware to pass information to the operating system
via static tables in memory. Kernel SFI support is required to
boot on SFI-only platforms. If you have ACPI tables then these are
used instead.
U-Boot writes this table in write_sfi_table() just before booting
the OS.
For more information, see http://simplefirmware.org
x86: Generate a valid MultiProcessor (MP) table Implement write_mp_table() to create a minimal working MP table. This includes an MP floating table, a configuration table header and all of the 5 base configuration table entries. The I/O interrupt assignment table entry is created based on the same information used in the creation of PIRQ routing table from device tree. A check duplicated entry logic is applied to prevent writing multiple I/O interrupt entries with the same information. Use a Kconfig option GENERATE_MP_TABLE to tell U-Boot whether we need actually write the MP table at the F seg, just like we did for PIRQ routing and SFI tables. With MP table existence, linux kernel will switch to I/O APIC and local APIC to process all the peripheral interrupts instead of 8259 PICs. This takes full advantage of the multicore hardware and the SMP kernel. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-06-23 04:18:52 +00:00
config GENERATE_MP_TABLE
bool "Generate an MP (Multi-Processor) table"
default n
help
Generate an MP (Multi-Processor) table for this board. The MP table
provides a way for the operating system to support for symmetric
multiprocessing as well as symmetric I/O interrupt handling with
the local APIC and I/O APIC.
x86: Generate a valid ACPI table Implement write_acpi_table() to create a minimal working ACPI table. This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT ACPI table entries. Use a Kconfig option GENERATE_ACPI_TABLE to tell U-Boot whether we need actually write the APCI table just like we did for PIRQ routing, MP table and SFI tables. With ACPI table existence, linux kernel gets control of power management, thermal management, configuration management and monitoring in hardware. Signed-off-by: Saket Sinha <saket.sinha89@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tidied up whitespace and aligned some tabs: Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-22 06:50:55 +00:00
config GENERATE_ACPI_TABLE
bool "Generate an ACPI (Advanced Configuration and Power Interface) table"
default n
x86: qemu: split qfw command interface and qfw core This patch splits qfw command interface and qfw core function into two files, and introduces a new Kconfig option (CONFIG_QFW) for qfw core. Now when qfw command interface is enabled, it will automatically select qfw core. This patch also makes the ACPI table generation select CONFIG_QFW. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-05-23 02:37:14 +00:00
select QFW if QEMU
x86: Generate a valid ACPI table Implement write_acpi_table() to create a minimal working ACPI table. This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT ACPI table entries. Use a Kconfig option GENERATE_ACPI_TABLE to tell U-Boot whether we need actually write the APCI table just like we did for PIRQ routing, MP table and SFI tables. With ACPI table existence, linux kernel gets control of power management, thermal management, configuration management and monitoring in hardware. Signed-off-by: Saket Sinha <saket.sinha89@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tidied up whitespace and aligned some tabs: Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-22 06:50:55 +00:00
help
The Advanced Configuration and Power Interface (ACPI) specification
provides an open standard for device configuration and management
by the operating system. It defines platform-independent interfaces
for configuration and power management monitoring.
x86: acpi: Support external GNVS tables At present U-Boot puts a magic number in the ASL for the GNVS table and searches for it later. Add a Kconfig option to use a different approach, where the ASL files declare the table as an external symbol. U-Boot can then put it wherever it likes, without any magic numbers or searching. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-22 18:44:53 +00:00
config ACPI_GNVS_EXTERNAL
bool
help
Put the GNVS (Global Non-Volatile Sleeping) table separate from the
DSDT and add a pointer to the table from the DSDT. This allows
U-Boot to better control the address of the GNVS.
x86: Support platform PIRQ routing On x86 boards, platform chipset receives up to four different interrupt signals from PCI devices (INTA/B/C/D), which in turn will be routed to chipset internal PIRQ lines then routed to 8259 PIC finally if configuring the whole system to work under the so-called PIC mode (in contrast to symmetric IO mode which uses IOAPIC). We add two major APIs to aid this, one for routing PIRQ and the other one for generating a PIRQ routing table. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 10:10:05 +00:00
endmenu
x86: acpi: Add Kconfig option and header file for ACPI resume This introduces a Kconfig option for ACPI S3 resume, as well as a header file to include anything related to ACPI S3 resume. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:28 +00:00
config HAVE_ACPI_RESUME
bool "Enable ACPI S3 resume"
x86: Fix ACPI resume dependency to MRC cache In an S3 resume path, MRC cache is mandatory. Enforce the dependency in the Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-10-19 01:20:55 +00:00
select ENABLE_MRC_CACHE
x86: acpi: Add Kconfig option and header file for ACPI resume This introduces a Kconfig option for ACPI S3 resume, as well as a header file to include anything related to ACPI S3 resume. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:28 +00:00
help
Select this to enable ACPI S3 resume. S3 is an ACPI-defined sleeping
state where all system context is lost except system memory. U-Boot
is responsible for restoring the machine state as it was before sleep.
It needs restore the memory controller, without overwriting memory
which is not marked as reserved. For the peripherals which lose their
registers, U-Boot needs to write the original value. When everything
is done, U-Boot needs to find out the wakeup vector provided by OSes
and jump there.
x86: pci: Allow conditionally run VGA rom in S3 Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can bypass executing VGA roms in S3. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:46 +00:00
config S3_VGA_ROM_RUN
bool "Re-run VGA option ROMs on S3 resume"
depends on HAVE_ACPI_RESUME
help
Execute VGA option ROMs in U-Boot when resuming from S3. Normally
this is needed when graphics console is being used in the kernel.
Turning it off can reduce some resume time, but be aware that your
graphics console won't work without VGA options ROMs. Set it to N
if your kernel is only on a serial console.
x86: rename CONFIG_STACK_SIZE Configuration variables should have the same meaning independent of the architecture. x86 and ARM both use CONFIG_STACK_SIZE: * x86: U-Boot's runtime stack size during reboot * ARM: max stack size that can be used by U-Boot Rename the x86 configuration variable to CONFIG_STACK_SIZE_REBOOT Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-07-29 10:31:17 +00:00
config STACK_SIZE_RESUME
x86: fsp: Mark memory used by U-Boot as reserved in the E820 table for S3 U-Boot itself as well as everything that is consumed by U-Boot (like heap, stack, dtb, etc) needs to be reserved and reported in the E820 table when S3 resume is on. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:34 +00:00
hex
depends on HAVE_ACPI_RESUME
default 0x1000
help
Estimated U-Boot's runtime stack size that needs to be reserved
during an ACPI S3 resume.
x86: Support platform PIRQ routing On x86 boards, platform chipset receives up to four different interrupt signals from PCI devices (INTA/B/C/D), which in turn will be routed to chipset internal PIRQ lines then routed to 8259 PIC finally if configuring the whole system to work under the so-called PIC mode (in contrast to symmetric IO mode which uses IOAPIC). We add two major APIs to aid this, one for routing PIRQ and the other one for generating a PIRQ routing table. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 10:10:05 +00:00
config MAX_PIRQ_LINKS
int
default 8
help
This variable specifies the number of PIRQ interrupt links which are
routable. On most older chipsets, this is 4, PIRQA through PIRQD.
Some newer chipsets offer more than four links, commonly up to PIRQH.
config IRQ_SLOT_COUNT
int
default 128
help
U-Boot can support up to 254 IRQ slot info in the PIRQ routing table
which in turns forms a table of exact 4KiB. The default value 128
should be enough for most boards. If this does not fit your board,
change it according to your needs.
x86: Rename MMCONF_BASE_ADDRESS and make it common across x86 This setting will be used by more than just ivybridge so make it common. Also rename it to PCIE_ECAM_BASE which is a more descriptive name. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:33 +00:00
config PCIE_ECAM_BASE
hex
x86: Use tab instead of space to indent in PCIE_ECAM_BASE Space is used before 'default' in PCIE_ECAM_BASE in arch/x86/Kconfig so it looks misaligned. Replace the space with tab to indent. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-02-02 13:25:09 +00:00
default 0xe0000000
x86: Rename MMCONF_BASE_ADDRESS and make it common across x86 This setting will be used by more than just ivybridge so make it common. Also rename it to PCIE_ECAM_BASE which is a more descriptive name. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:33 +00:00
help
This is the memory-mapped address of PCI configuration space, which
is only available through the Enhanced Configuration Access
Mechanism (ECAM) with PCI Express. It can be set up almost
anywhere. Before it is set up, it is possible to access PCI
configuration space through I/O access, but memory access is more
convenient. Using this, PCI can be scanned and configured. This
should be set to a region that does not conflict with memory
assigned to PCI devices - i.e. the memory and prefetch regions, as
passed to pci_set_region().
x86: Reserve PCIe ECAM address range in the E820 table We should mark PCIe ECAM address range in the E820 table as reserved otherwise kernel will not attempt to use ECAM. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-22 08:21:15 +00:00
config PCIE_ECAM_SIZE
hex
default 0x10000000
help
This is the size of memory-mapped address of PCI configuration space,
which is only available through the Enhanced Configuration Access
Mechanism (ECAM) with PCI Express. Each bus consumes 1 MiB memory,
so a default 0x10000000 size covers all of the 256 buses which is the
maximum number of PCI buses as defined by the PCI specification.
x86: Move CONFIG_8259_PIC and CONFIG_8254_TIMER to Kconfig Add Kconfig options for 8259 and 8254. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-23 02:13:31 +00:00
config I8259_PIC
x86: kconfig: Allow board defconfig file to disable 8259 and APIC At present the Kconfig options (CONFIG_I8259_PIC and CONFIG_APIC) do not include a prompt message, which makes it impossible to be disabled from a board defconfig file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-30 03:57:22 +00:00
bool "Enable Intel 8259 compatible interrupt controller"
x86: Move CONFIG_8259_PIC and CONFIG_8254_TIMER to Kconfig Add Kconfig options for 8259 and 8254. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-23 02:13:31 +00:00
default y
help
Intel 8259 ISA compatible chipset incorporates two 8259 (master and
slave) interrupt controllers. Include this to have U-Boot set up
the interrupt correctly.
x86: make the LAPIC / IOAPIC construct switchable with Kconfig There are still systems running which do not have any LAPIC or even IOAPIC. Responsible MSRs for those do not exist and the systems are crashing on trying to setup LAPIC. This commit makes the APIC stuff able to switch off for those boards which dont' have an LAPIC / IOAPIC. Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-11-18 22:19:43 +00:00
config APIC
x86: kconfig: Allow board defconfig file to disable 8259 and APIC At present the Kconfig options (CONFIG_I8259_PIC and CONFIG_APIC) do not include a prompt message, which makes it impossible to be disabled from a board defconfig file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-30 03:57:22 +00:00
bool "Enable Intel Advanced Programmable Interrupt Controller"
x86: make the LAPIC / IOAPIC construct switchable with Kconfig There are still systems running which do not have any LAPIC or even IOAPIC. Responsible MSRs for those do not exist and the systems are crashing on trying to setup LAPIC. This commit makes the APIC stuff able to switch off for those boards which dont' have an LAPIC / IOAPIC. Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-11-18 22:19:43 +00:00
default y
help
The (A)dvanced (P)rogrammable (I)nterrupt (C)ontroller is responsible
for catching interrupts and distributing them to one or more CPU
cores. In most cases there are some LAPICs (local) for each core and
one I/O APIC. This conjunction is found on most modern x86 systems.
x86: Conditionally build the pinctrl_ich6 driver The pinctrl_ich6 driver is currently unconditionally built for all x86 boards. Let's use a Kconfig option to control the build. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-06-10 13:25:01 +00:00
config PINCTRL_ICH6
bool
help
Intel ICH6 compatible chipset pinctrl driver. It needs to work
together with the ICH6 compatible gpio driver.
x86: Move CONFIG_8259_PIC and CONFIG_8254_TIMER to Kconfig Add Kconfig options for 8259 and 8254. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-23 02:13:31 +00:00
config I8254_TIMER
bool
default y
help
Intel 8254 timer contains three counters which have fixed uses.
Include this to have U-Boot set up the timer correctly.
x86: Support booting SeaBIOS SeaBIOS is an open source implementation of a 16-bit x86 BIOS. It can run in an emulator or natively on x86 hardware with the use of coreboot. With SeaBIOS's help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS. As U-Boot, we have to manually create a table where SeaBIOS gets system information (eg: E820) from. The table unfortunately has to follow the coreboot table format as SeaBIOS currently supports booting as a coreboot payload. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-02-29 07:54:50 +00:00
config SEABIOS
bool "Support booting SeaBIOS"
help
SeaBIOS is an open source implementation of a 16-bit X86 BIOS.
It can run in an emulator or natively on X86 hardware with the use
of coreboot/U-Boot. By turning on this option, U-Boot prepares
all the configuration tables that are necessary to boot SeaBIOS.
Check http://www.seabios.org/SeaBIOS for details.
x86: Prepare configuration tables in dedicated high memory region Currently when CONFIG_SEABIOS is on, U-Boot allocates configuration tables via normal malloc(). To simplify, use a dedicated memory region which is reserved on the stack before relocation for this purpose. Add functions for reserve and malloc. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-05-11 14:44:59 +00:00
config HIGH_TABLE_SIZE
hex "Size of configuration tables which reside in high memory"
default 0x10000
depends on SEABIOS
help
SeaBIOS itself resides in E seg and F seg, where U-Boot puts all
configuration tables like PIRQ/MP/ACPI. To avoid conflicts, U-Boot
puts a copy of configuration tables in high memory region which
is reserved on the stack before relocation. The region size is
determined by this option.
Increse it if the default size does not fit the board's needs.
This is most likely due to a large ACPI DSDT table is used.
x86: Add support for newer CAR schemes Newer Intel SoCs have different ways of setting up cache-as-ram (CAR). Add support for these along with suitable configuration options. To make the code cleaner, adjust a few definitions in processor.h so that they can be used from assembler. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:25 +00:00
config INTEL_CAR_CQOS
bool "Support Intel Cache Quality of Service"
help
Cache Quality of Service allows more fine-grained control of cache
usage. As result, it is possible to set up a portion of L2 cache for
CAR and use the remainder for actual caching.
#
# Each bit in QOS mask controls this many bytes. This is calculated as:
# (CACHE_WAYS / CACHE_BITS_PER_MASK) * CACHE_LINE_SIZE * CACHE_SETS
#
config CACHE_QOS_SIZE_PER_BIT
hex
depends on INTEL_CAR_CQOS
default 0x20000 # 128 KB
x86: Add an option to control the position of U-Boot The existing work-around for positioning U-Boot in the ROM when it actually runs from RAM still exists and there is not obvious way to change this. Add a proper Kconfig option to handle this case. This also adds a new bool property to indicate whether CONFIG_SYS_TEXT_BASE exists. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:29 +00:00
config X86_OFFSET_U_BOOT
hex "Offset of U-Boot in ROM image"
depends on HAVE_SYS_TEXT_BASE
default SYS_TEXT_BASE
x86: Add an option to control the position of SPL For Apollo Lake SPL is run from CAR (cache-as-RAM) which is in a different location from where SPL must be placed in ROM. In other words, although SPL runs before SDRAM is set up, it is not execute-in-place (XIP). Add a Kconfig option for the ROM position. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-07 04:42:30 +00:00
config X86_OFFSET_SPL
hex "Offset of SPL in ROM image"
depends on SPL && X86
default SPL_TEXT_BASE
x86: Add support for ACPI general-purpose events ACPI GPEs are used to signal interrupts from peripherals that are accessed via ACPI. In U-Boot these are modelled as interrupts using a separate interrupt controller. Configuration is via the device tree. Add a simple driver for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-06 16:55:01 +00:00
config ACPI_GPE
bool "Support ACPI general-purpose events"
help
Enable a driver for ACPI GPEs to allow peripherals to send interrupts
via ACPI to the OS. In U-Boot this is only used when U-Boot itself
needs access to these interrupts. This can happen when it uses a
peripheral that is set up to use GPEs and so cannot use the normal
GPIO mechanism for polling an input.
See https://queue.acm.org/blogposting.cfm?id=18977 for more info
config SPL_ACPI_GPE
bool "Support ACPI general-purpose events in SPL"
help
Enable a driver for ACPI GPEs to allow peripherals to send interrupts
via ACPI to the OS. In U-Boot this is only used when U-Boot itself
needs access to these interrupts. This can happen when it uses a
peripheral that is set up to use GPEs and so cannot use the normal
GPIO mechanism for polling an input.
See https://queue.acm.org/blogposting.cfm?id=18977 for more info
config TPL_ACPI_GPE
bool "Support ACPI general-purpose events in TPL"
help
Enable a driver for ACPI GPEs to allow peripherals to send interrupts
via ACPI to the OS. In U-Boot this is only used when U-Boot itself
needs access to these interrupts. This can happen when it uses a
peripheral that is set up to use GPEs and so cannot use the normal
GPIO mechanism for polling an input.
See https://queue.acm.org/blogposting.cfm?id=18977 for more info
x86: Add a config for the systemagent PCIEX regions size Add a way to specify the required size for this region. This is used when generating ACPI tables. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-22 18:44:51 +00:00
config SA_PCIEX_LENGTH
hex
default 0x10000000 if (PCIEX_LENGTH_256MB)
default 0x8000000 if (PCIEX_LENGTH_128MB)
default 0x4000000 if (PCIEX_LENGTH_64MB)
default 0x10000000
help
This option allows you to select length of PCIEX region.
config PCIEX_LENGTH_256MB
bool
config PCIEX_LENGTH_128MB
bool
config PCIEX_LENGTH_64MB
bool
x86: Select advanced Intel code only if allowed At present most of the Intel-specific code is built on all devices, even those which don't have software support for the features provided there. This means that any board can enable CONFIG_INTEL_ACPIGEN even if it does not have the required features. Add a new INTEL_SOC option to control this access. This must be selected by SoCs that can support the required features. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fixed a typo in arch/x86/Kconfig] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-23 10:35:42 +00:00
config INTEL_SOC
bool
help
This is enabled on Intel SoCs that can support various advanced
features such as power management (requiring asm/arch/pm.h), system
agent (asm/arch/systemagent.h) and an I/O map for ACPI
(asm/arch/iomap.h).
This cannot be selected in a defconfig file. It must be enabled by a
'select' in the SoC's Kconfig.
if INTEL_SOC
x86: Move INTEL_ACPIGEN to arch/x86 This option is better placed in the x86 code since it is not generic enough to be in the core code. Move it. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fixed a typo in arch/x86/Kconfig] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-23 10:35:41 +00:00
config INTEL_ACPIGEN
bool "Support ACPI table generation for Intel SoCs"
depends on ACPIGEN
help
This option adds some functions used for programmatic generation of
ACPI tables on Intel SoCs. This provides features for writing CPU
information such as P states and T stages. Also included is a way
to create a GNVS table and set it up.
x86: apl: Support writing the IntelGraphicsMem table This table is needed by the Linux graphics driver to handle graphics correctly. Write it to ACPI. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-22 18:45:03 +00:00
config INTEL_GMA_ACPI
bool "Generate ACPI table for Intel GMA graphics"
help
The Intel GMA graphics driver in Linux expects an ACPI table
which describes the layout of the registers and the display
connected to the device. Enable this option to create this
table so that graphics works correctly.
x86: acpi: Add a common routine to write WiFi info Intel WiFi chips can use a common routine to write the information needed by linux. Add an implementation of this. Enable it for coral. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-22 18:45:04 +00:00
config INTEL_GENERIC_WIFI
bool "Enable generation of ACPI tables for Intel WiFi"
help
Select this option to provide code to a build generic WiFi ACPI table
for Intel WiFi devices. This is not a WiFi driver and offers no
network functionality. It is only here to generate the ACPI tables
required by Linux.
x86: Support Atom SoCs using SWSMISCI rather than the SWSCI Some Atom SoCs use SWSMISCI for SMI control. Add a Kconfig to select this. It is used on Apollo Lake. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-22 18:45:15 +00:00
config INTEL_GMA_SWSMISCI
bool
help
Select this option for Atom-based platforms which use the SWSMISCI
register (0xe0) rather than the SWSCI register (0xe8).
x86: Select advanced Intel code only if allowed At present most of the Intel-specific code is built on all devices, even those which don't have software support for the features provided there. This means that any board can enable CONFIG_INTEL_ACPIGEN even if it does not have the required features. Add a new INTEL_SOC option to control this access. This must be selected by SoCs that can support the required features. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fixed a typo in arch/x86/Kconfig] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2021-02-23 10:35:42 +00:00
endif # INTEL_SOC
x86: Move coreboot sysinfo parsing into generic x86 code It is useful to be able to parse coreboot tables on any x86 build which is booted from coreboot. Add a new Kconfig option to enable this feature and move the code so it can be used on any board, if enabled. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-15 05:00:21 +00:00
config COREBOOT_SYSINFO
bool "Support reading coreboot sysinfo"
default y if SYS_COREBOOT
help
Select this option to read the coreboot sysinfo table on start-up,
if present. This is written by coreboot before it exits and provides
various pieces of information about the running system, including
display, memory and build information. It is stored in
struct sysinfo_t after parsing by get_coreboot_info().
config SPL_COREBOOT_SYSINFO
bool "Support reading coreboot sysinfo"
depends on SPL
default y if COREBOOT_SYSINFO
help
Select this option to read the coreboot sysinfo table in SPL,
if present. This is written by coreboot before it exits and provides
various pieces of information about the running system, including
display, memory and build information. It is stored in
struct sysinfo_t after parsing by get_coreboot_info().
kconfig: add board Kconfig and defconfig files This commit adds: - arch/${ARCH}/Kconfig provide a menu to select target boards - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig set CONFIG macros to the appropriate values for each board - configs/${TARGET_BOARD}_defconfig default setting of each board (This commit was automatically generated by a conversion script based on boards.cfg) In Linux Kernel, defconfig files are located under arch/${ARCH}/configs/ directory. It works in Linux Kernel since ARCH is always given from the command line for cross compile. But in U-Boot, ARCH is not given from the command line. Which means we cannot know ARCH until the board configuration is done. That is why all the "*_defconfig" files should be gathered into a single directory ./configs/. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-30 05:08:14 +00:00
endmenu
Reference in a new issue Copy permalink