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

439 lines
12 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"
kconfig: move CONFIG_USE_PRIVATE_LIBGCC to Kconfig The private libgcc is supported only on ARM, MIPS, PowerPC, SH, x86. Those architectures should "select" HAVE_PRIVATE_LIBGCC and CONFIG_USE_PRIVATE_LIBGCC should depend on it. Currently, this option is enabled on Tegra boards and x86 architecture. Move the definition from header files to Kconfig. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com>
2014-10-23 16:30:43 +00:00
config USE_PRIVATE_LIBGCC
default y
sandbox: Move CONFIG_SYS_VSNPRINTF to Kconfig Move this over to Kconfig and tidy up. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-06 20:19:02 +00:00
config SYS_VSNPRINTF
default y
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"
default VENDOR_COREBOOT
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: 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"
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"
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
menu "Display"
config FRAMEBUFFER_SET_VESA_MODE
prompt "Set framebuffer graphics resolution"
bool
help
Set VESA/native framebuffer mode (needed for bootsplash and graphical framebuffer console)
choice
prompt "framebuffer graphics resolution"
default FRAMEBUFFER_VESA_MODE_117
depends on FRAMEBUFFER_SET_VESA_MODE
help
This option sets the resolution used for the coreboot framebuffer (and
bootsplash screen).
config FRAMEBUFFER_VESA_MODE_100
bool "640x400 256-color"
config FRAMEBUFFER_VESA_MODE_101
bool "640x480 256-color"
config FRAMEBUFFER_VESA_MODE_102
bool "800x600 16-color"
config FRAMEBUFFER_VESA_MODE_103
bool "800x600 256-color"
config FRAMEBUFFER_VESA_MODE_104
bool "1024x768 16-color"
config FRAMEBUFFER_VESA_MODE_105
bool "1024x7686 256-color"
config FRAMEBUFFER_VESA_MODE_106
bool "1280x1024 16-color"
config FRAMEBUFFER_VESA_MODE_107
bool "1280x1024 256-color"
config FRAMEBUFFER_VESA_MODE_108
bool "80x60 text"
config FRAMEBUFFER_VESA_MODE_109
bool "132x25 text"
config FRAMEBUFFER_VESA_MODE_10A
bool "132x43 text"
config FRAMEBUFFER_VESA_MODE_10B
bool "132x50 text"
config FRAMEBUFFER_VESA_MODE_10C
bool "132x60 text"
config FRAMEBUFFER_VESA_MODE_10D
bool "320x200 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_10E
bool "320x200 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_10F
bool "320x200 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_110
bool "640x480 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_111
bool "640x480 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_112
bool "640x480 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_113
bool "800x600 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_114
bool "800x600 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_115
bool "800x600 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_116
bool "1024x768 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_117
bool "1024x768 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_118
bool "1024x768 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_119
bool "1280x1024 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_11A
bool "1280x1024 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_11B
bool "1280x1024 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_USER
bool "Manually select VESA mode"
endchoice
# Map the config names to an integer (KB).
config FRAMEBUFFER_VESA_MODE
prompt "VESA mode" if FRAMEBUFFER_VESA_MODE_USER
hex
default 0x100 if FRAMEBUFFER_VESA_MODE_100
default 0x101 if FRAMEBUFFER_VESA_MODE_101
default 0x102 if FRAMEBUFFER_VESA_MODE_102
default 0x103 if FRAMEBUFFER_VESA_MODE_103
default 0x104 if FRAMEBUFFER_VESA_MODE_104
default 0x105 if FRAMEBUFFER_VESA_MODE_105
default 0x106 if FRAMEBUFFER_VESA_MODE_106
default 0x107 if FRAMEBUFFER_VESA_MODE_107
default 0x108 if FRAMEBUFFER_VESA_MODE_108
default 0x109 if FRAMEBUFFER_VESA_MODE_109
default 0x10A if FRAMEBUFFER_VESA_MODE_10A
default 0x10B if FRAMEBUFFER_VESA_MODE_10B
default 0x10C if FRAMEBUFFER_VESA_MODE_10C
default 0x10D if FRAMEBUFFER_VESA_MODE_10D
default 0x10E if FRAMEBUFFER_VESA_MODE_10E
default 0x10F if FRAMEBUFFER_VESA_MODE_10F
default 0x110 if FRAMEBUFFER_VESA_MODE_110
default 0x111 if FRAMEBUFFER_VESA_MODE_111
default 0x112 if FRAMEBUFFER_VESA_MODE_112
default 0x113 if FRAMEBUFFER_VESA_MODE_113
default 0x114 if FRAMEBUFFER_VESA_MODE_114
default 0x115 if FRAMEBUFFER_VESA_MODE_115
default 0x116 if FRAMEBUFFER_VESA_MODE_116
default 0x117 if FRAMEBUFFER_VESA_MODE_117
default 0x118 if FRAMEBUFFER_VESA_MODE_118
default 0x119 if FRAMEBUFFER_VESA_MODE_119
default 0x11A if FRAMEBUFFER_VESA_MODE_11A
default 0x11B if FRAMEBUFFER_VESA_MODE_11B
default 0x117 if FRAMEBUFFER_VESA_MODE_USER
endmenu
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
default 0x2000000
help
Stack top address which is used in FspInit after DRAM is ready and
CAR is disabled.
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.
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: Move CONFIG_BOOTSTAGE to Kconfig Move CONFIG_BOOT_STAGE and its associated options to Kconfig. Adjust existing users and code. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-03-03 00:04:37 +00:00
config BOOTSTAGE
default y
config BOOTSTAGE_REPORT
default y
config CMD_BOOTSTAGE
default y
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