leandrof/u-boot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
dd59211046
u-boot/arch/x86/Kconfig

333 lines
9.4 KiB
Plaintext
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"
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: 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: 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: 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
source "board/coreboot/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
source "arch/x86/cpu/baytrail/Kconfig"
source "arch/x86/cpu/coreboot/Kconfig"
source "arch/x86/cpu/ivybridge/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"
# architecture-specific options below
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
config SYS_X86_START16
hex
depends on X86_RESET_VECTOR
default 0xfffff800
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: Add vesa mode configuration options Add Kconfig options to allow selection of a vesa mode on x86 machines. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:30 +00:00
config MARK_GRAPHICS_MEM_WRCOMB
x86: Kconfig: MARK_GRAPHICS_MEM_WRCOMB cosmetics Remove the ending period of the MARK_GRAPHICS_MEM_WRCOMB option. Also fix the indention of its help text. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:26 +00:00
bool "Mark graphics memory as write-combining"
x86: Add vesa mode configuration options Add Kconfig options to allow selection of a vesa mode on x86 machines. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:30 +00:00
default n
help
x86: Kconfig: MARK_GRAPHICS_MEM_WRCOMB cosmetics Remove the ending period of the MARK_GRAPHICS_MEM_WRCOMB option. Also fix the indention of its help text. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-27 15:22:26 +00:00
The graphics performance may increase if the graphics
memory is set as write-combining cache type. This option
enables marking the graphics memory as write-combining.
x86: Add vesa mode configuration options Add Kconfig options to allow selection of a vesa mode on x86 machines. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:30 +00:00
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"
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.
config FSP_FILE
string "Firmware Support Package binary filename"
depends on HAVE_FSP
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"
depends on HAVE_FSP
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.
config FSP_TEMP_RAM_ADDR
hex
x86: kconfig: Make FSP_TEMP_RAM_ADDR depend on HAVE_FSP FSP_TEMP_RAM_ADDR should only be visible when HAVE_FSP is on. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-06-01 13:07:23 +00:00
depends on HAVE_FSP
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
Stack top address which is used in FspInit after DRAM is ready and
CAR is disabled.
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 MAX_CPUS
int "Maximum number of CPUs permitted"
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).
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.
config AP_STACK_SIZE
hex
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: Allow overriding TSC_FREQ_IN_MHZ We should allow the value of TSC_FREQ_IN_MHZ to be overridden by the one in arch/cpu/<xxx>/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-02-05 15:42:20 +00:00
config TSC_CALIBRATION_BYPASS
bool "Bypass Time-Stamp Counter (TSC) calibration"
default n
help
By default U-Boot automatically calibrates Time-Stamp Counter (TSC)
running frequency via Model-Specific Register (MSR) and Programmable
Interval Timer (PIT). If the calibration does not work on your board,
select this option and provide a hardcoded TSC running frequency with
CONFIG_TSC_FREQ_IN_MHZ below.
Normally this option should be turned on in a simulation environment
like qemu.
config TSC_FREQ_IN_MHZ
int "Time-Stamp Counter (TSC) running frequency in MHz"
depends on TSC_CALIBRATION_BYPASS
default 1000
help
The running frequency in MHz of Time-Stamp Counter (TSC).
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"
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: 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
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().
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 New Issue Copy Permalink