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

347 lines
9.3 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
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
prompt "Target select"
config TARGET_COREBOOT
bool "Support coreboot"
x86: Add chromebook_link board This board is a 'bare' version of the existing 'link 'board. It does not require coreboot to run, but is intended to start directly from the reset vector. This initial commit has place holders for a wide range of features. These will be added in follow-on patches and series. So far it cannot be booted as there is no ROM image produced, but it does build without errors. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:07 +00:00
help
This target is used for running U-Boot on top of Coreboot. In
this case Coreboot does the early inititalisation, and U-Boot
takes over once the RAM, video and CPU are fully running.
U-Boot is loaded as a fallback payload from Coreboot, in
Coreboot terminology. This method was used for the Chromebook
Pixel when launched.
config TARGET_CHROMEBOOK_LINK
bool "Support Chromebook link"
help
This is the Chromebook Pixel released in 2013. It uses an Intel
i5 Ivybridge which is a die-shrink of Sandybridge, with 4GB of
SDRAM. It has a Panther Point platform controller hub, PCIe
WiFi and Bluetooth. It also includes a 720p webcam, USB SD
reader, microphone and speakers, display port and 32GB SATA
solid state drive. There is a Chrome OS EC connected on LPC,
and it provides a 2560x1700 high resolution touch-enabled LCD
display.
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 queensbay and crownbay Kconfig files Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-12-17 07:50:40 +00:00
config TARGET_CROWNBAY
bool "Support Intel Crown Bay CRB"
help
This is the Intel Crown Bay Customer Reference Board. It contains
the Intel Atom Processor E6xx populated on the COM Express module
with 1GB DDR2 soldered down memory and a carrier board with the
Intel Platform Controller Hub EG20T, other system components and
peripheral connectors for PCIe/SATA/USB/LAN/SD/UART/Audio/LVDS.
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: 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: 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: 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"
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
bool "Mark graphics memory as write-combining."
default n
help
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.
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 a hardcoded TSC frequency provided by Kconfig By default U-Boot automatically calibrates TSC running frequency via MSR and PIT. The calibration may not work on every x86 processor, so a new Kconfig option CONFIG_TSC_CALIBRATION_BYPASS is introduced to allow bypassing the calibration and assign a hardcoded TSC frequency CONFIG_TSC_FREQ_IN_MHZ. Normally the bypass should be turned on in a simulation environment like qemu. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-01-06 14:14:14 +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: Add chromebook_link board This board is a 'bare' version of the existing 'link 'board. It does not require coreboot to run, but is intended to start directly from the reset vector. This initial commit has place holders for a wide range of features. These will be added in follow-on patches and series. So far it cannot be booted as there is no ROM image produced, but it does build without errors. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:07 +00:00
source "arch/x86/cpu/ivybridge/Kconfig"
x86: Add queensbay and crownbay Kconfig files Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-12-17 07:50:40 +00:00
source "arch/x86/cpu/queensbay/Kconfig"
x86: Rename chromebook-x86 to coreboot Rename this vendor since it is intended to be used on any platform where coreboot runs at reset and then loads U-Boot. So far it is only tested on link. When other boards are supported it is likely that we will need to move to multiple board names, all under the 'coreboot' vendor. So while it would be possible to remove the vendor for now, that would be short-sighted. Suggested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:29 +00:00
source "board/coreboot/coreboot/Kconfig"
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 chromebook_link board This board is a 'bare' version of the existing 'link 'board. It does not require coreboot to run, but is intended to start directly from the reset vector. This initial commit has place holders for a wide range of features. These will be added in follow-on patches and series. So far it cannot be booted as there is no ROM image produced, but it does build without errors. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-13 05:42:07 +00:00
source "board/google/chromebook_link/Kconfig"
x86: Add queensbay and crownbay Kconfig files Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-12-17 07:50:40 +00:00
source "board/intel/crownbay/Kconfig"
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