kumquat-buildroot/linux/Config.in

467 lines
14 KiB
Plaintext
Raw Normal View History

menu "Kernel"
config BR2_LINUX_KERNEL
bool "Linux Kernel"
select BR2_PACKAGE_HOST_IMAGEMAGICK if BR2_LINUX_KERNEL_CUSTOM_LOGO_PATH != ""
help
Enable this option if you want to build a Linux kernel for
your embedded device
if BR2_LINUX_KERNEL
# Packages that need to have a kernel with support for loadable modules,
# but do not use the kernel-modules infrastructure, should select that
# option.
config BR2_LINUX_NEEDS_MODULES
bool
#
# Version selection. We provide the choice between:
#
# 1. A single fairly recent stable kernel version
# 2. A custom stable version
# 3. A custom tarball
# 4. A set of custom repository locations
#
choice
prompt "Kernel version"
config BR2_LINUX_KERNEL_LATEST_VERSION
bool "Latest version (5.4)"
config BR2_LINUX_KERNEL_LATEST_CIP_VERSION
bool "Latest CIP SLTS version (4.19.98-cip19)"
help
CIP launched in the spring of 2016 to address the needs of
organizations in industries such as power generation and
distribution, water, oil and gas, transportation, building
automation and more for reliable and secure Linux-based
embedded systems that can be sustained over a period of
10 to as many as 60 years.
The project's goal is to provide an open source base layer
of industrial-grade software that permits the use and
implementation of software building blocks that meet
these requirements.
The CIP community plans to maintain 4.4 for security and
bug fixes for more than 10 years.
https://www.cip-project.org
config BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION
bool "Latest CIP RT SLTS version (4.19.98-cip19-rt7)"
help
Same as the CIP version, but this is the PREEMPT_RT realtime
variant.
The CIP community plans to maintain 4.19 for security and
bug fixes for more than 10 years.
https://www.cip-project.org
config BR2_LINUX_KERNEL_CUSTOM_VERSION
bool "Custom version"
help
This option allows to use a specific official version from
kernel.org, like 2.6.x, 2.6.x.y, 3.x.y, ...
Note: you cannot use this option to select a _longterm_ 2.6
kernel, because these kernels are not located at the standard
URL at kernel.org. Instead, select "Custom tarball" and
specify the right URL directly.
config BR2_LINUX_KERNEL_CUSTOM_TARBALL
bool "Custom tarball"
help
This option allows to specify a URL pointing to a kernel
source tarball. This URL can use any protocol recognized by
Buildroot, like http://, ftp://, file:// or scp://.
When pointing to a local tarball using file://, you may want
to use a make variable like $(TOPDIR) to reference the root of
the Buildroot tree.
config BR2_LINUX_KERNEL_CUSTOM_GIT
bool "Custom Git repository"
help
This option allows Buildroot to get the Linux kernel source
code from a Git repository.
config BR2_LINUX_KERNEL_CUSTOM_HG
bool "Custom Mercurial repository"
help
This option allows Buildroot to get the Linux kernel source
code from a Mercurial repository.
config BR2_LINUX_KERNEL_CUSTOM_SVN
bool "Custom Subversion repository"
help
This option allows Buildroot to get the Linux kernel source
code from a Subversion repository.
endchoice
config BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE
string "Kernel version"
depends on BR2_LINUX_KERNEL_CUSTOM_VERSION
config BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION
string "URL of custom kernel tarball"
depends on BR2_LINUX_KERNEL_CUSTOM_TARBALL
if BR2_LINUX_KERNEL_CUSTOM_GIT || BR2_LINUX_KERNEL_CUSTOM_HG || BR2_LINUX_KERNEL_CUSTOM_SVN
config BR2_LINUX_KERNEL_CUSTOM_REPO_URL
string "URL of custom repository"
default BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL \
if BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL != "" # legacy
config BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION
string "Custom repository version"
default BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION \
if BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION != "" # legacy
help
Revision to use in the typical format used by
Git/Mercurial/Subversion E.G. a sha id, a tag, branch, ..
endif
config BR2_LINUX_KERNEL_VERSION
string
default "5.4.17" if BR2_LINUX_KERNEL_LATEST_VERSION
default "4.19.98-cip19" if BR2_LINUX_KERNEL_LATEST_CIP_VERSION
default "4.19.98-cip19-rt7" if BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION
default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE \
if BR2_LINUX_KERNEL_CUSTOM_VERSION
default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
default BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION \
if BR2_LINUX_KERNEL_CUSTOM_GIT || BR2_LINUX_KERNEL_CUSTOM_HG || BR2_LINUX_KERNEL_CUSTOM_SVN
#
# Patch selection
#
config BR2_LINUX_KERNEL_PATCH
string "Custom kernel patches"
help
A space-separated list of patches to apply to the
kernel. Each patch can be described as an URL, a local file
path, or a directory. In the case of a directory, all files
matching *.patch in the directory will be applied.
#
# Configuration selection
#
choice
prompt "Kernel configuration"
default BR2_LINUX_KERNEL_USE_DEFCONFIG
config BR2_LINUX_KERNEL_USE_DEFCONFIG
bool "Using an in-tree defconfig file"
config BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG
bool "Use the architecture default configuration"
help
This option will use the default configuration for the
selected architecture. I.e, it is equivalent to running
"make ARCH=<foo> defconfig". This is useful on architectures
that have a single defconfig file, such as ARM64.
config BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG
bool "Using a custom (def)config file"
endchoice
config BR2_LINUX_KERNEL_DEFCONFIG
string "Defconfig name"
depends on BR2_LINUX_KERNEL_USE_DEFCONFIG
help
Name of the kernel defconfig file to use, without the
trailing _defconfig. The defconfig is located in
arch/<arch>/configs in the kernel tree.
config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
string "Configuration file path"
depends on BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG
help
Path to the kernel configuration file
Note: this can be a defconfig file or a complete .config file,
which can later be saved back with make
linux-update-(def)config.
config BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES
string "Additional configuration fragment files"
help
A space-separated list of kernel configuration fragment files,
that will be merged to the main kernel configuration file.
config BR2_LINUX_KERNEL_CUSTOM_LOGO_PATH
string "Custom boot logo file path"
help
Use a custom Linux framebuffer boot logo.
Custom logo should be in PNG or JPEG format, it will be
converted to the linux kernel format (224 colors only)
and copied over the original logo file.
#
# Binary format
#
choice
prompt "Kernel binary format"
default BR2_LINUX_KERNEL_ZIMAGE if BR2_arm || BR2_armeb
config BR2_LINUX_KERNEL_UIMAGE
bool "uImage"
depends on BR2_arc || BR2_arm || BR2_armeb || \
BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le || \
BR2_sh || BR2_mips || BR2_mipsel || \
BR2_mips64 || BR2_mips64el || BR2_xtensa
select BR2_PACKAGE_HOST_UBOOT_TOOLS
config BR2_LINUX_KERNEL_APPENDED_UIMAGE
bool "uImage with appended DT"
depends on BR2_arm || BR2_armeb
select BR2_LINUX_KERNEL_DTS_SUPPORT
select BR2_LINUX_KERNEL_APPENDED_DTB
select BR2_PACKAGE_HOST_UBOOT_TOOLS
config BR2_LINUX_KERNEL_BZIMAGE
bool "bzImage"
depends on BR2_i386 || BR2_x86_64
config BR2_LINUX_KERNEL_ZIMAGE
bool "zImage"
depends on BR2_arm || BR2_armeb || BR2_powerpc || \
BR2_powerpc64 || BR2_powerpc64le || BR2_sparc || \
BR2_sh || BR2_xtensa
config BR2_LINUX_KERNEL_ZIMAGE_EPAPR
bool "zImage.epapr"
depends on BR2_powerpc64 || BR2_powerpc64le
config BR2_LINUX_KERNEL_APPENDED_ZIMAGE
bool "zImage with appended DT"
depends on BR2_arm || BR2_armeb
select BR2_LINUX_KERNEL_DTS_SUPPORT
select BR2_LINUX_KERNEL_APPENDED_DTB
config BR2_LINUX_KERNEL_CUIMAGE
bool "cuImage"
depends on BR2_powerpc
select BR2_PACKAGE_HOST_UBOOT_TOOLS
select BR2_LINUX_KERNEL_DTS_SUPPORT
select BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT
config BR2_LINUX_KERNEL_SIMPLEIMAGE
bool "simpleImage"
depends on BR2_microblaze
select BR2_PACKAGE_HOST_UBOOT_TOOLS
select BR2_LINUX_KERNEL_DTS_SUPPORT
select BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT
config BR2_LINUX_KERNEL_IMAGE
bool "Image"
depends on BR2_aarch64 || BR2_riscv
config BR2_LINUX_KERNEL_LINUX_BIN
bool "linux.bin"
depends on BR2_microblaze
select BR2_PACKAGE_HOST_UBOOT_TOOLS
config BR2_LINUX_KERNEL_VMLINUX_BIN
bool "vmlinux.bin"
depends on BR2_mips || BR2_mipsel || BR2_sh
config BR2_LINUX_KERNEL_VMLINUX
bool "vmlinux"
config BR2_LINUX_KERNEL_VMLINUZ
bool "vmlinuz"
depends on BR2_mips || BR2_mipsel
config BR2_LINUX_KERNEL_VMLINUZ_BIN
bool "vmlinuz.bin"
depends on BR2_mips || BR2_mipsel
config BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM
bool "custom target"
help
For certain cases a board-specific target image must be
used. For example, on powerPC where the OpenFirmware
description is attached in a board-specific kernel image
target like 'cuImage.mpc8379_rdb'.
Select this option and specify the make target in "Kernel
image target name".
endchoice
#
# Kernel compression format
#
choice
prompt "Kernel compression format"
help
This selection will just ensure that the correct host tools
are built. The actual compression for the kernel should be
selected in the kernel configuration menu.
config BR2_LINUX_KERNEL_GZIP
bool "gzip compression"
config BR2_LINUX_KERNEL_LZ4
bool "lz4 compression"
config BR2_LINUX_KERNEL_LZMA
bool "lzma compression"
config BR2_LINUX_KERNEL_LZO
bool "lzo compression"
config BR2_LINUX_KERNEL_XZ
bool "xz compression"
endchoice
config BR2_LINUX_KERNEL_IMAGE_TARGET_NAME
string "Kernel image target name"
depends on BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM
help
Specify the kernel make target to build the kernel that you
need.
config BR2_LINUX_KERNEL_IMAGE_NAME
string "Kernel image name"
depends on BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM
help
The filename of the kernel image, if it is different from the
make target (above). Only Xtensa uses a filename different
from the make target. Defaults to
BR2_LINUX_KERNEL_IMAGE_TARGET_NAME.
If unsure, leave it empty.
config BR2_LINUX_KERNEL_UIMAGE_LOADADDR
string "load address (for 3.7+ multi-platform image)"
depends on BR2_arm || BR2_armeb
depends on BR2_LINUX_KERNEL_UIMAGE || BR2_LINUX_KERNEL_APPENDED_UIMAGE
help
If your ARM system's Linux kernel is configured with the new
(3.7+) multi-architecture support (CONFIG_ARCH_MULTIPLATFORM=y
in your kernel config), then it is necessary to specify a
kernel load address when building the uImage. This should be a
hexadecimal string beginning with 0x, for example: 0x00008000.
If unsure, let this option empty.
config BR2_LINUX_KERNEL_DTS_SUPPORT
bool "Build a Device Tree Blob (DTB)"
help
Compile one or more device tree sources into device tree
blobs.
Select the dts files to compile in the options below.
if BR2_LINUX_KERNEL_DTS_SUPPORT
# We have mainly three cases when it comes to device tree support:
# 1) We don't want any support at all. Then the ..DTS_SUPPORT
# variable won't be set
# 2) We want device tree support, so we need the user to enter the
# device tree name or the path to the custom device he uses, but
# the kernel abstracts this from us and only build an image that
# looks like a regular kernel image. In this case, we only need
# to derive the kernel image name from the given device tree
# name, and all the rest is as usual
# 3) We want device tree support, but the kernel requires us to
# build the device tree blob separately. In this case, some
# more logic will be needed.
# The variable below address the second case, were you only want
# limited actions from buildroot.
config BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT
linux: make BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT public Currently the BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT option is only available to be selected by another config option. This option controls if the Linux build system should build the DTB itself, or if buildroot explicitly calls the Linux Makefile like "make something.dtb". My use case: I want to build an OpenRISC image with a custom device tree file. OpenRISC does not support appended DTBs, and I'm not using a bootloader, but link everything into a single kernel (vmlinux) image. The kernel option CONFIG_OPENRISC_BUILTIN_DTB allows me to specify a dtb file, which is typically located in the kernel source tree in arch/openrisc/boot/dts/NAME.dts. Since my dts file is not part of the upstream kernel, I have two options: either patch the kernel to include the DTS file, and then specify it using the CONFIG_OPENRISC_BUILTIN_DTB option. Or use buildroot's BR2_LINUX_KERNEL_CUSTOM_DTS_PATH config option to copy any DTS file to the kernel source tree, and then specify this file with CONFIG_OPENRISC_BUILTIN_DTB as before. However, the second option also requries the buildroot option BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT to be set, otherwise I end up with a "make -C kerneldir NAME.dts" call, which doesn't work (no such target exists). Currently the BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT option exists, but it's not visible/available. Simply making it available solves the problem for me nicely. Signed-off-by: Philipp Wagner <mail@philipp-wagner.com> [Arnout: add help text] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2018-11-16 16:45:01 +01:00
bool "DTB is built by kernel itself"
help
Normally, the device tree(s) to be built have to be passed
explicitly to the kernel build system. For some binary
formats, however, the kernel build system links in the
device tree directly in the kernel binary. Select this option
if you have such a kernel binary format.
config BR2_LINUX_KERNEL_APPENDED_DTB
bool
config BR2_LINUX_KERNEL_INTREE_DTS_NAME
string "In-tree Device Tree Source file names"
help
Name of in-tree device tree source file, without
the trailing .dts. You can provide a list of
dts files to build, separated by spaces.
config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
string "Out-of-tree Device Tree Source file paths"
help
Path to to out-of-tree device tree source files.
You can provide a list of dts paths to copy and
build, separated by spaces.
config BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT
bool "Build Device Tree with overlay support"
help
If enabled, pass the "-@" option to dtc, such that
symbols are generated in the compiled Device Tree.
Choose this option to support Device Tree overlays
on the target system.
endif
config BR2_LINUX_KERNEL_INSTALL_TARGET
bool "Install kernel image to /boot in target"
depends on !BR2_TARGET_ROOTFS_INITRAMFS
help
Select this option to have the kernel image installed to
/boot in the target root filesystem, as is typically done on
x86/x86_64 systems.
Note that this option also installs the Device Tree Blobs to
/boot if DTBs have been generated by the kernel build
process.
config BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL
bool "Needs host OpenSSL"
help
Some Linux kernel configuration options (such as
CONFIG_SYSTEM_TRUSTED_KEYRING) require building a host
program called extract-cert, which itself needs
OpenSSL. Enabling this option will ensure host-openssl gets
built before the Linux kernel.
Enable this option if you get a Linux kernel build failure
such as "scripts/extract-cert.c:21:25: fatal error:
openssl/bio.h: No such file or directory".
config BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF
bool "Needs host libelf"
help
Some Linux kernel configuration options (such as
CONFIG_UNWINDER_ORC) require building a host program that
needs libelf. Enabling this option will ensure host-elfutils
(which provides libelf) gets built before the Linux kernel.
Enable this option if you get a Linux kernel build failure
such as "Cannot generate ORC metadata for
CONFIG_UNWINDER_ORC=y, please install libelf-dev,
libelf-devel or elfutils-libelf-devel".
# Linux extensions
source "linux/Config.ext.in"
# Linux tools
linux/tools: make it a real, separate package The kernel source tree also contains the sources for various userland tools, of which cpupower, perf or selftests. Currently, we have support for building those tools as part of the kernel build procedure. This looked the correct thing to do so far, because, well, they *are* part of the kernel source tree and some really have to be the same version as the kernel that will run. However, this is causing quite a non-trivial-to-break circular dependency in some configurations. For example, this defconfig fails to build (similar to the one reported by Paul): BR2_arm=y BR2_cortex_a7=y BR2_ARM_FPU_NEON_VFPV4=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f" BR2_LINUX_KERNEL_DEFCONFIG="bcm2709" BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y BR2_PACKAGE_CRYPTODEV=y BR2_PACKAGE_OPENSSL=y BR2_PACKAGE_LIBCURL=y This causes a circular dependency, as explained by Thomas: - When libcurl is enabled, systemd depends on it - When OpenSSL is enabled, obviously, will use it for SSL support - When cryptodev-linux is enabled, OpenSSL will depend on it to use crypto accelerators supported in the kernel via cryptodev-linux. - cryptodev-linux being a kernel module, it depends on linux - linux by itself (the kernel) does not depend on pciutils, but the linux tool "cpupower" (managed in linux-tool-cpupower) depends on pciutils - pciutils depends on udev when available - udev is provided by systemd. And indeed, during the build, we can see that make warns (it's only reported as a *warning*, not as an actual error): [...] make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured <- cryptodev-linux dependency dropped. >>> openssl 1.0.2h Downloading [...] So the build fails later on, when openssl is actually built: eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory compilation terminated. <builtin>: recipe for target 'eng_cryptodev.o' failed Furthermore, graph-depends also detects the circular dependency, but treats it as a hard-error: Recursion detected for : cryptodev-linux which is a dependency of: openssl which is a dependency of: libcurl which is a dependency of: systemd which is a dependency of: udev which is a dependency of: pciutils which is a dependency of: linux which is a dependency of: cryptodev-linux Makefile:738: recipe for target 'graph-depends' failed Of course, there is no way to break the loop without losing functionality in either one of the involved packages *and* keep our infrastructure and packages as-is. The only solution is to break the loop at the linux-tools level, by moving them away into their own package, so that the linux package will no longer have the opportunity to depend on another package via a dependency of one the tools. All three linux tools are thus moved away to their own package. The package infrastructure only knows of three types of packages: those in package/ , in boot/ , in toolchain/ and the one in linux/ . So we create that new linux-tools package in package/ so that we don't have to fiddle with yet another special case in the infra. Still, we want its configure options to appear in the kernel's sub-menu. So, we make it a prompt-less package, with only the tools visible as options of that package, but without the usual dependency on their master symbol; they only depend on the Linux kernel. Furthermore, because the kernel is such a huge pile of code, we would not be very happy to extract it a second time just for the sake of a few tools. We can't extract only the tools/ sub-directory from the kernel source either, because some tools have hard-coded path to includes from the kernel (arch and stuff). Instead, we just use the linux source tree as our own build tree, and ensure the linux tree is extracted and patched before linux-tools is configured and built. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Paul Ashford <paul.ashford@zurria.co.uk> [Thomas: - fix typo #(@D) -> $(@D) - fix the inclusion of the per-tool .mk files.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
source "package/linux-tools/Config.in"
endif # BR2_LINUX_KERNEL
endmenu