tequilaOS/platform_vendor_tequila
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_vendor_tequila/build/tasks/kernel.mk

309 lines
15 KiB
Makefile
Raw Normal View History

Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
# Copyright (C) 2012 The CyanogenMod Project
vendor: we are now LineageOS * Change necessary bits to support our project move Change-Id: I085470d448a243cc9d60b4ce920dee52086f64cd
2016-12-19 18:22:55 +01:00
# (C) 2017 The LineageOS Project
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# Android makefile to build kernel as a part of Android Build
#
# Configuration
# =============
#
# These config vars are usually set in BoardConfig.mk:
#
# TARGET_KERNEL_CONFIG = Kernel defconfig
# TARGET_KERNEL_VARIANT_CONFIG = Variant defconfig, optional
# TARGET_KERNEL_SELINUX_CONFIG = SELinux defconfig, optional
# TARGET_KERNEL_ADDITIONAL_CONFIG = Additional defconfig, optional
#
tasks: kernel: Add support for Clang kernel builds Add support for compiling kernels with Clang as intoduced on android-4.4 In order to compile with clang, you must set TARGET_KERNEL_CLANG_COMPILE. If you wish to specify a specific clang version, also set TARGET_KERNEL_CLANG_VERSION, but if that is not set, the build system will default to the latest version of clang available in prebuilts/clang Change-Id: I79dc1dca9758a930f2f5ba1754b5d8de114af900 Signed-off-by: Joe Maples <joe@frap129.org>
2017-11-27 16:09:38 +01:00
# TARGET_KERNEL_CLANG_COMPILE = Compile kernel with clang, defaults to false
#
# TARGET_KERNEL_CLANG_VERSION = Clang prebuilts version, optional, defaults to clang-stable
#
# TARGET_KERNEL_CLANG_PATH = Clang prebuilts path, optional
#
kernel: clean up this madness * WARNING: this intentionally breaks the build on devices who are not setting BOARD_KERNEL_IMAGE_NAME and are still setting TARGET_USES_UNCOMPRESSED_KERNEL or TARGET_KERNEL_APPEND_DTB * The logic here is insanity and if all of this can be done by simply setting BOARD_KERNEL_IMAGE_NAME, why have all this extra cruft? * Use cases: - Set a kernel image name without "-dtb" on the end, you get a kernel. Nothing more. - Set a kernel image name with "-dtb" on the end, you get an kernel with an appended dt. - Set a kernel image name without "-dtb" on the end, and set BOARD_KERNEL_SEPARATED_DT. You get a kernel and a separated dt.img. - Set a kernel image name with "-dtb" on the end, and set BOARD_KERNEL_SEPARATED_DT. You're crazy. Change-Id: I5c3fc6eb727255684278ff562c0ee3faa7124b6b
2017-01-24 22:46:13 +01:00
# BOARD_KERNEL_IMAGE_NAME = Built image name
# for ARM use: zImage
# for ARM64 use: Image.gz
# for uncompressed use: Image
# If using an appended DT, append '-dtb'
# to the end of the image name.
# For example, for ARM devices,
# use zImage-dtb instead of zImage.
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
#
tasks: kernel: Add support for Clang kernel builds Add support for compiling kernels with Clang as intoduced on android-4.4 In order to compile with clang, you must set TARGET_KERNEL_CLANG_COMPILE. If you wish to specify a specific clang version, also set TARGET_KERNEL_CLANG_VERSION, but if that is not set, the build system will default to the latest version of clang available in prebuilts/clang Change-Id: I79dc1dca9758a930f2f5ba1754b5d8de114af900 Signed-off-by: Joe Maples <joe@frap129.org>
2017-11-27 16:09:38 +01:00
# KERNEL_CC = The C Compiler used. This is automatically set based
# on whether the clang version is set, optional.
#
# KERNEL_CLANG_TRIPLE = Target triple for clang (e.g. aarch64-linux-gnu-)
# defaults to arm-linux-gnu- for arm
# aarch64-linux-gnu- for arm64
# x86_64-linux-gnu- for x86
#
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
# NEED_KERNEL_MODULE_ROOT = Optional, if true, install kernel
kernel: Allow installing modules on system Change-Id: Id4386cd37645dc9e9253410e0b2093cd2e6b04dc
2018-07-11 00:35:33 +02:00
# modules in root instead of vendor
# NEED_KERNEL_MODULE_SYSTEM = Optional, if true, install kernel
# modules in system instead of vendor
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
kernel: don't build for TARGET_NO_KERNEL targets Change-Id: I14ad45c06922c0775e0574ddbcfcdc33353af465
2017-12-08 20:46:30 +01:00
ifneq ($(TARGET_NO_KERNEL),true)
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
## Externally influenced variables
KERNEL_SRC := $(TARGET_KERNEL_SOURCE)
# kernel configuration - mandatory
KERNEL_DEFCONFIG := $(TARGET_KERNEL_CONFIG)
VARIANT_DEFCONFIG := $(TARGET_KERNEL_VARIANT_CONFIG)
SELINUX_DEFCONFIG := $(TARGET_KERNEL_SELINUX_CONFIG)
## Internal variables
KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ
KERNEL_CONFIG := $(KERNEL_OUT)/.config
ifeq ($(KERNEL_ARCH),x86_64)
KERNEL_DEFCONFIG_ARCH := x86
else
KERNEL_DEFCONFIG_ARCH := $(KERNEL_ARCH)
endif
KERNEL_DEFCONFIG_SRC := $(KERNEL_SRC)/arch/$(KERNEL_DEFCONFIG_ARCH)/configs/$(KERNEL_DEFCONFIG)
kernel: clean up this madness * WARNING: this intentionally breaks the build on devices who are not setting BOARD_KERNEL_IMAGE_NAME and are still setting TARGET_USES_UNCOMPRESSED_KERNEL or TARGET_KERNEL_APPEND_DTB * The logic here is insanity and if all of this can be done by simply setting BOARD_KERNEL_IMAGE_NAME, why have all this extra cruft? * Use cases: - Set a kernel image name without "-dtb" on the end, you get a kernel. Nothing more. - Set a kernel image name with "-dtb" on the end, you get an kernel with an appended dt. - Set a kernel image name without "-dtb" on the end, and set BOARD_KERNEL_SEPARATED_DT. You get a kernel and a separated dt.img. - Set a kernel image name with "-dtb" on the end, and set BOARD_KERNEL_SEPARATED_DT. You're crazy. Change-Id: I5c3fc6eb727255684278ff562c0ee3faa7124b6b
2017-01-24 22:46:13 +01:00
ifeq ($(BOARD_KERNEL_IMAGE_NAME),)
$(error BOARD_KERNEL_IMAGE_NAME not defined.)
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
endif
kernel: clean up this madness * WARNING: this intentionally breaks the build on devices who are not setting BOARD_KERNEL_IMAGE_NAME and are still setting TARGET_USES_UNCOMPRESSED_KERNEL or TARGET_KERNEL_APPEND_DTB * The logic here is insanity and if all of this can be done by simply setting BOARD_KERNEL_IMAGE_NAME, why have all this extra cruft? * Use cases: - Set a kernel image name without "-dtb" on the end, you get a kernel. Nothing more. - Set a kernel image name with "-dtb" on the end, you get an kernel with an appended dt. - Set a kernel image name without "-dtb" on the end, and set BOARD_KERNEL_SEPARATED_DT. You get a kernel and a separated dt.img. - Set a kernel image name with "-dtb" on the end, and set BOARD_KERNEL_SEPARATED_DT. You're crazy. Change-Id: I5c3fc6eb727255684278ff562c0ee3faa7124b6b
2017-01-24 22:46:13 +01:00
TARGET_PREBUILT_INT_KERNEL := $(KERNEL_OUT)/arch/$(KERNEL_ARCH)/boot/$(BOARD_KERNEL_IMAGE_NAME)
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
ifneq ($(TARGET_KERNEL_ADDITIONAL_CONFIG),)
KERNEL_ADDITIONAL_CONFIG := $(TARGET_KERNEL_ADDITIONAL_CONFIG)
KERNEL_ADDITIONAL_CONFIG_SRC := $(KERNEL_SRC)/arch/$(KERNEL_ARCH)/configs/$(KERNEL_ADDITIONAL_CONFIG)
ifeq ("$(wildcard $(KERNEL_ADDITIONAL_CONFIG_SRC))","")
$(warning TARGET_KERNEL_ADDITIONAL_CONFIG '$(TARGET_KERNEL_ADDITIONAL_CONFIG)' doesn't exist)
KERNEL_ADDITIONAL_CONFIG_SRC := /dev/null
endif
else
KERNEL_ADDITIONAL_CONFIG_SRC := /dev/null
endif
ifeq "$(wildcard $(KERNEL_SRC) )" ""
ifneq ($(TARGET_PREBUILT_KERNEL),)
HAS_PREBUILT_KERNEL := true
NEEDS_KERNEL_COPY := true
else
$(foreach cf,$(PRODUCT_COPY_FILES), \
$(eval _src := $(call word-colon,1,$(cf))) \
$(eval _dest := $(call word-colon,2,$(cf))) \
$(ifeq kernel,$(_dest), \
$(eval HAS_PREBUILT_KERNEL := true)))
endif
ifneq ($(HAS_PREBUILT_KERNEL),)
$(warning ***************************************************************)
$(warning * Using prebuilt kernel binary instead of source *)
$(warning * THIS IS DEPRECATED, AND WILL BE DISCONTINUED *)
$(warning * Please configure your device to download the kernel *)
$(warning * source repository to $(KERNEL_SRC))
$(warning * for more information *)
$(warning ***************************************************************)
FULL_KERNEL_BUILD := false
KERNEL_BIN := $(TARGET_PREBUILT_KERNEL)
else
$(warning ***************************************************************)
$(warning * *)
$(warning * No kernel source found, and no fallback prebuilt defined. *)
$(warning * Please make sure your device is properly configured to *)
$(warning * download the kernel repository to $(KERNEL_SRC))
$(warning * and add the TARGET_KERNEL_CONFIG variable to BoardConfig.mk *)
$(warning * *)
$(warning * As an alternative, define the TARGET_PREBUILT_KERNEL *)
$(warning * variable with the path to the prebuilt binary kernel image *)
$(warning * in your BoardConfig.mk file *)
$(warning * *)
$(warning ***************************************************************)
$(error "NO KERNEL")
endif
else
NEEDS_KERNEL_COPY := true
ifeq ($(TARGET_KERNEL_CONFIG),)
$(warning **********************************************************)
$(warning * Kernel source found, but no configuration was defined *)
$(warning * Please add the TARGET_KERNEL_CONFIG variable to your *)
$(warning * BoardConfig.mk file *)
$(warning **********************************************************)
# $(error "NO KERNEL CONFIG")
else
#$(info Kernel source found, building it)
FULL_KERNEL_BUILD := true
KERNEL_BIN := $(TARGET_PREBUILT_INT_KERNEL)
endif
endif
ifeq ($(FULL_KERNEL_BUILD),true)
ifeq ($(NEED_KERNEL_MODULE_ROOT),true)
KERNEL_MODULES_INSTALL := root
KERNEL_MODULES_OUT := $(TARGET_ROOT_OUT)/lib/modules
kernel: Handle kernel modules correctly Place kernel module output in the correct location. Perform depmod steps (copied from build-image-kernel-modules function in build/make/core/Makefile). See: https://source.android.com/devices/architecture/kernel/modular-kernels Change-Id: I6e70012a5c1acdb276f9bee0d57631d2805f71ea
2017-12-04 08:59:48 +01:00
KERNEL_DEPMOD_STAGING_DIR := $(call intermediates-dir-for,PACKAGING,depmod_recovery)
KERNEL_MODULE_MOUNTPOINT :=
kernel: Allow installing modules on system Change-Id: Id4386cd37645dc9e9253410e0b2093cd2e6b04dc
2018-07-11 00:35:33 +02:00
else ifeq ($(NEED_KERNEL_MODULE_SYSTEM),true)
KERNEL_MODULES_INSTALL := $(TARGET_COPY_OUT_SYSTEM)
KERNEL_MODULES_OUT := $(TARGET_OUT)/lib/modules
KERNEL_DEPMOD_STAGING_DIR := $(call intermediates-dir-for,PACKAGING,depmod_system)
KERNEL_MODULE_MOUNTPOINT := system
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
else
kernel: Handle kernel modules correctly Place kernel module output in the correct location. Perform depmod steps (copied from build-image-kernel-modules function in build/make/core/Makefile). See: https://source.android.com/devices/architecture/kernel/modular-kernels Change-Id: I6e70012a5c1acdb276f9bee0d57631d2805f71ea
2017-12-04 08:59:48 +01:00
KERNEL_MODULES_INSTALL := $(TARGET_COPY_OUT_VENDOR)
KERNEL_MODULES_OUT := $(TARGET_OUT_VENDOR)/lib/modules
KERNEL_DEPMOD_STAGING_DIR := $(call intermediates-dir-for,PACKAGING,depmod_vendor)
KERNEL_MODULE_MOUNTPOINT := vendor
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
endif
tasks: kernel: Add support for Clang kernel builds Add support for compiling kernels with Clang as intoduced on android-4.4 In order to compile with clang, you must set TARGET_KERNEL_CLANG_COMPILE. If you wish to specify a specific clang version, also set TARGET_KERNEL_CLANG_VERSION, but if that is not set, the build system will default to the latest version of clang available in prebuilts/clang Change-Id: I79dc1dca9758a930f2f5ba1754b5d8de114af900 Signed-off-by: Joe Maples <joe@frap129.org>
2017-11-27 16:09:38 +01:00
ifeq ($(TARGET_KERNEL_CLANG_COMPILE),true)
ifneq ($(TARGET_KERNEL_CLANG_VERSION),)
# Find the clang-* directory containing the specified version
kernel: Remove ANDROID_BUILD_TOP This is no longer used in Pie, so just get the top dir of the build system and use that. Change-Id: I4bc416e471ddeb9810960f4ddcd647b20aa531c2
2018-08-07 07:01:29 +02:00
KERNEL_CLANG_VERSION := $(shell find $(BUILD_TOP)/prebuilts/clang/host/$(HOST_OS)-x86/ -name AndroidVersion.txt -exec grep -l $(TARGET_KERNEL_CLANG_VERSION) "{}" \; | sed -e 's|/AndroidVersion.txt$$||g;s|^.*/||g')
tasks: kernel: Add support for Clang kernel builds Add support for compiling kernels with Clang as intoduced on android-4.4 In order to compile with clang, you must set TARGET_KERNEL_CLANG_COMPILE. If you wish to specify a specific clang version, also set TARGET_KERNEL_CLANG_VERSION, but if that is not set, the build system will default to the latest version of clang available in prebuilts/clang Change-Id: I79dc1dca9758a930f2f5ba1754b5d8de114af900 Signed-off-by: Joe Maples <joe@frap129.org>
2017-11-27 16:09:38 +01:00
else
build: kernel: Use LLVM_PREBUILTS_VERSION if no version is specified Some ROMs may want to track Google's master branch, which has Clang 6 and 7 toolchains available, as it gets rid of some hacks in the kernel source. Unfortunately, with the current default choosing logic, the latest one would be chosen, which it shouldn't be. Use the variable set in build/make/core/clang/versions.mk, as that's what was intended. Change-Id: I607c7f750f62caabee4cdccea67846feb7f632fa Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-04-12 01:23:19 +02:00
# Use the default version of clang if TARGET_KERNEL_CLANG_VERSION hasn't been set by the device config
KERNEL_CLANG_VERSION := $(LLVM_PREBUILTS_VERSION)
tasks: kernel: Add support for Clang kernel builds Add support for compiling kernels with Clang as intoduced on android-4.4 In order to compile with clang, you must set TARGET_KERNEL_CLANG_COMPILE. If you wish to specify a specific clang version, also set TARGET_KERNEL_CLANG_VERSION, but if that is not set, the build system will default to the latest version of clang available in prebuilts/clang Change-Id: I79dc1dca9758a930f2f5ba1754b5d8de114af900 Signed-off-by: Joe Maples <joe@frap129.org>
2017-11-27 16:09:38 +01:00
endif
kernel: Remove ANDROID_BUILD_TOP This is no longer used in Pie, so just get the top dir of the build system and use that. Change-Id: I4bc416e471ddeb9810960f4ddcd647b20aa531c2
2018-08-07 07:01:29 +02:00
TARGET_KERNEL_CLANG_PATH ?= $(BUILD_TOP)/prebuilts/clang/host/$(HOST_OS)-x86/$(KERNEL_CLANG_VERSION)/bin
tasks: kernel: Add support for Clang kernel builds Add support for compiling kernels with Clang as intoduced on android-4.4 In order to compile with clang, you must set TARGET_KERNEL_CLANG_COMPILE. If you wish to specify a specific clang version, also set TARGET_KERNEL_CLANG_VERSION, but if that is not set, the build system will default to the latest version of clang available in prebuilts/clang Change-Id: I79dc1dca9758a930f2f5ba1754b5d8de114af900 Signed-off-by: Joe Maples <joe@frap129.org>
2017-11-27 16:09:38 +01:00
ifeq ($(KERNEL_ARCH),arm64)
KERNEL_CLANG_TRIPLE ?= CLANG_TRIPLE=aarch64-linux-gnu-
else ifeq ($(KERNEL_ARCH),arm)
KERNEL_CLANG_TRIPLE ?= CLANG_TRIPLE=arm-linux-gnu-
else ifeq ($(KERNEL_ARCH),x86)
KERNEL_CLANG_TRIPLE ?= CLANG_TRIPLE=x86_64-linux-gnu-
endif
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
PATH_OVERRIDE := PATH=$(TARGET_KERNEL_CLANG_PATH):$$PATH LD_LIBRARY_PATH=$(BUILD_TOP)/prebuilts/clang/host/$(HOST_OS)-x86/$(KERNEL_CLANG_VERSION)/lib64:$$LD_LIBRARY_PATH
kernel: fix ccache variable sanitation for clang builds * When using "?=", expansion doesn't happen right away, so the ccache variable is sanitized before KERNEL_CC gets expanded and no ccache is ever used for clang builds. * With ":=", expansion happens immediately. So let's manually check if KERNEL_CC is already set somewhere else to determine whether or not we should set it ourselves using ":=". Change-Id: I8a61767606a4f3d4c6ba88c68b10fd2e11783406
2018-02-19 05:13:05 +01:00
ifeq ($(KERNEL_CC),)
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
KERNEL_CC := CC="$(CCACHE_BIN) clang"
kernel: fix ccache variable sanitation for clang builds * When using "?=", expansion doesn't happen right away, so the ccache variable is sanitized before KERNEL_CC gets expanded and no ccache is ever used for clang builds. * With ":=", expansion happens immediately. So let's manually check if KERNEL_CC is already set somewhere else to determine whether or not we should set it ourselves using ":=". Change-Id: I8a61767606a4f3d4c6ba88c68b10fd2e11783406
2018-02-19 05:13:05 +01:00
endif
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
endif
ifeq ($(TARGET_KERNEL_MODULES),)
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
TARGET_KERNEL_MODULES := INSTALLED_KERNEL_MODULES
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
endif
KERNEL_ADDITIONAL_CONFIG_OUT := $(KERNEL_OUT)/.additional_config
.PHONY: force_additional_config
$(KERNEL_ADDITIONAL_CONFIG_OUT): force_additional_config
$(hide) cmp -s $(KERNEL_ADDITIONAL_CONFIG_SRC) $@ || cp $(KERNEL_ADDITIONAL_CONFIG_SRC) $@;
lineage: build: kernel: Rework kernel header logic The existing kernel header logic has several issues: * It does not depend on the actual kernel headers, so it does not detect actual kernel header changes. * It does depend on the kernel config, which should not be used to generate (user space) kernel headers. The end result is that kernel headers aren't properly regenerated when needed, and spuriously regenerated when not needed. Additionally, the kernel header rebuild mucks around with the kernel config, which is unneccesary and fraught with danger. Rewrite the kernel header dependency and generation logic as follows: * Use the dependency file $(KERNEL_OUT)/.headers_install_deps to manage dependencies on the actual kernel header files which are exported to user space (and the top level kernel Makefile, which is used to generate version.h). The dependency file is exactly the same as what GCC would output for a C/C++ dependency with the M/MM flags. * Conditionally include the dependency file to detect when headers should be (re)generated. * Introduce the phony target INSTALLED_KERNEL_HEADERS for modules to declare a dependency on kernel headers. Additionally: * Get rid of TARGET_KERNEL_HEADER_ARCH and KERNEL_HEADER_DEFCONFIG. * Get rid of KERNEL_OUT_STAMP and move commands to the appropriate places in the rules. * Fail the build when $(KERNEL_OUT)/usr is mentioned in a dependency. Note a separate commit to build/core/binary.mk will provide a migration path and a suitable deprecation warning. * Declare the kernel*config targets phony. Change-Id: I8b46f4ea1c622d8e73cca5157be96ec09d42ebb3
2017-11-09 21:02:33 +01:00
$(KERNEL_CONFIG): $(KERNEL_DEFCONFIG_SRC) $(KERNEL_ADDITIONAL_CONFIG_OUT)
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
@echo "Building Kernel Config"
lineage: build: kernel: Rework kernel header logic The existing kernel header logic has several issues: * It does not depend on the actual kernel headers, so it does not detect actual kernel header changes. * It does depend on the kernel config, which should not be used to generate (user space) kernel headers. The end result is that kernel headers aren't properly regenerated when needed, and spuriously regenerated when not needed. Additionally, the kernel header rebuild mucks around with the kernel config, which is unneccesary and fraught with danger. Rewrite the kernel header dependency and generation logic as follows: * Use the dependency file $(KERNEL_OUT)/.headers_install_deps to manage dependencies on the actual kernel header files which are exported to user space (and the top level kernel Makefile, which is used to generate version.h). The dependency file is exactly the same as what GCC would output for a C/C++ dependency with the M/MM flags. * Conditionally include the dependency file to detect when headers should be (re)generated. * Introduce the phony target INSTALLED_KERNEL_HEADERS for modules to declare a dependency on kernel headers. Additionally: * Get rid of TARGET_KERNEL_HEADER_ARCH and KERNEL_HEADER_DEFCONFIG. * Get rid of KERNEL_OUT_STAMP and move commands to the appropriate places in the rules. * Fail the build when $(KERNEL_OUT)/usr is mentioned in a dependency. Note a separate commit to build/core/binary.mk will provide a migration path and a suitable deprecation warning. * Declare the kernel*config targets phony. Change-Id: I8b46f4ea1c622d8e73cca5157be96ec09d42ebb3
2017-11-09 21:02:33 +01:00
$(hide) mkdir -p $(KERNEL_OUT)
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) VARIANT_DEFCONFIG=$(VARIANT_DEFCONFIG) SELINUX_DEFCONFIG=$(SELINUX_DEFCONFIG) $(KERNEL_DEFCONFIG)
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
$(hide) if [ ! -z "$(KERNEL_CONFIG_OVERRIDE)" ]; then \
echo "Overriding kernel config with '$(KERNEL_CONFIG_OVERRIDE)'"; \
echo $(KERNEL_CONFIG_OVERRIDE) >> $(KERNEL_OUT)/.config; \
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) oldconfig; fi
Always create a kernel defconfig build artifact It's just easier having it always built for you (and it really takes no time). Change-Id: If183cef50b1de0bf228e27bab77607df71350345
2016-10-01 18:56:52 +02:00
# Create defconfig build artifact
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(hide) $(PATH_OVERRIDE) $(MAKE) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) savedefconfig
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
$(hide) if [ ! -z "$(KERNEL_ADDITIONAL_CONFIG)" ]; then \
echo "Using additional config '$(KERNEL_ADDITIONAL_CONFIG)'"; \
$(KERNEL_SRC)/scripts/kconfig/merge_config.sh -m -O $(KERNEL_OUT) $(KERNEL_OUT)/.config $(KERNEL_SRC)/arch/$(KERNEL_ARCH)/configs/$(KERNEL_ADDITIONAL_CONFIG); \
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) KCONFIG_ALLCONFIG=$(KERNEL_OUT)/.config alldefconfig; fi
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
lineage: build: kernel: Rework kernel header logic The existing kernel header logic has several issues: * It does not depend on the actual kernel headers, so it does not detect actual kernel header changes. * It does depend on the kernel config, which should not be used to generate (user space) kernel headers. The end result is that kernel headers aren't properly regenerated when needed, and spuriously regenerated when not needed. Additionally, the kernel header rebuild mucks around with the kernel config, which is unneccesary and fraught with danger. Rewrite the kernel header dependency and generation logic as follows: * Use the dependency file $(KERNEL_OUT)/.headers_install_deps to manage dependencies on the actual kernel header files which are exported to user space (and the top level kernel Makefile, which is used to generate version.h). The dependency file is exactly the same as what GCC would output for a C/C++ dependency with the M/MM flags. * Conditionally include the dependency file to detect when headers should be (re)generated. * Introduce the phony target INSTALLED_KERNEL_HEADERS for modules to declare a dependency on kernel headers. Additionally: * Get rid of TARGET_KERNEL_HEADER_ARCH and KERNEL_HEADER_DEFCONFIG. * Get rid of KERNEL_OUT_STAMP and move commands to the appropriate places in the rules. * Fail the build when $(KERNEL_OUT)/usr is mentioned in a dependency. Note a separate commit to build/core/binary.mk will provide a migration path and a suitable deprecation warning. * Declare the kernel*config targets phony. Change-Id: I8b46f4ea1c622d8e73cca5157be96ec09d42ebb3
2017-11-09 21:02:33 +01:00
.PHONY: TARGET_KERNEL_BINARIES
TARGET_KERNEL_BINARIES: $(KERNEL_CONFIG)
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
@echo "Building Kernel"
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) $(BOARD_KERNEL_IMAGE_NAME)
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
$(hide) if grep -q '^CONFIG_OF=y' $(KERNEL_CONFIG); then \
echo "Building DTBs"; \
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) dtbs; \
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
fi
kernel: Detect kernel module usage better * Check for any actual kernel modules, rather than just the presence of kernel modules being enabled as a kernel feature. Change-Id: I6b7e82d5c59dd57621d9f9e2d1fd606997790d1c
2019-02-10 06:05:01 +01:00
$(hide) if grep -q '=m' $(KERNEL_CONFIG); then \
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
echo "Building Kernel Modules"; \
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) modules; \
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
fi
.PHONY: INSTALLED_KERNEL_MODULES
Fix kernel build failure on some devices and build hosts Change-Id: Ib6ba53994b4e04503ee4636a6aaab9c0bc3f676c
2018-01-13 01:19:27 +01:00
INSTALLED_KERNEL_MODULES: depmod-host
kernel: Move kernel module dir cleanup/creation to module install target * The directories used by the kernel module install rules are performed as part of the rules in the kernel build itself. This is likely a leftover from before kernel module install was separated. Change-Id: Iee2f73a0f8e0f274b1c2931ba57277ff14d7f5cc
2019-02-10 00:23:18 +01:00
$(hide) rm -rf $(KERNEL_MODULES_OUT)
$(hide) mkdir -p $(KERNEL_MODULES_OUT)
$(hide) rm -rf $(KERNEL_DEPMOD_STAGING_DIR)
kernel: Detect kernel module usage better * Check for any actual kernel modules, rather than just the presence of kernel modules being enabled as a kernel feature. Change-Id: I6b7e82d5c59dd57621d9f9e2d1fd606997790d1c
2019-02-10 06:05:01 +01:00
$(hide) if grep -q '=m' $(KERNEL_CONFIG); then \
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
echo "Installing Kernel Modules"; \
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) INSTALL_MOD_PATH=../../$(KERNEL_MODULES_INSTALL) modules_install && \
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
mofile=$$(find $(KERNEL_MODULES_OUT) -type f -name modules.order) && \
mpath=$$(dirname $$mofile) && \
for f in $$(find $$mpath/kernel -type f -name '*.ko'); do \
$(KERNEL_TOOLCHAIN_PATH)strip --strip-unneeded $$f; \
mv $$f $(KERNEL_MODULES_OUT); \
done && \
kernel: Handle kernel modules correctly Place kernel module output in the correct location. Perform depmod steps (copied from build-image-kernel-modules function in build/make/core/Makefile). See: https://source.android.com/devices/architecture/kernel/modular-kernels Change-Id: I6e70012a5c1acdb276f9bee0d57631d2805f71ea
2017-12-04 08:59:48 +01:00
rm -rf $$mpath && \
mkdir -p $(KERNEL_DEPMOD_STAGING_DIR)/lib/modules/0.0/$(KERNEL_MODULE_MOUNTPOINT)/lib/modules && \
find $(KERNEL_MODULES_OUT) -name *.ko -exec cp {} $(KERNEL_DEPMOD_STAGING_DIR)/lib/modules/0.0/$(KERNEL_MODULE_MOUNTPOINT)/lib/modules \; && \
$(DEPMOD) -b $(KERNEL_DEPMOD_STAGING_DIR) 0.0 && \
sed -e 's/\(.*modules.*\):/\/\1:/g' -e 's/ \([^ ]*modules[^ ]*\)/ \/\1/g' $(KERNEL_DEPMOD_STAGING_DIR)/lib/modules/0.0/modules.dep > $(KERNEL_MODULES_OUT)/modules.dep; \
lineage: build: kernel: Rework kernel module logic The existing kernel module logic does not detect failed kernel module builds. This is because the module build logic is a long shell chain that invokes make macros which are not intended to be used in this way. The essense of the issue is that we get a shell chain that looks like: cmd && cmd && var=value; cmd && var=value; cmd; The shell breaks this into three separate commands. The first builds the modules. The other two are the macro invocations. So the result of the command is the result of the last macro invocation, which will always succeed even if the modules fail to build. The issue is made worse by the existing build rule conflating the built kernel modules and the installed kernel modules. Fix this by reducing the built kernel module command to a single shell command and creating a separate target INSTALLED_KERNEL_MODULES. Any kernel module build failure will show up properly. The commands for INSTALLED_KERNEL_MODULES do not invoke any macros and should avoid the issue described above. Finally, this also removes the fake target no-external-modules and unifies the install logic for in-tree and out-of-tree modules. Change-Id: I3d13056e217e1e937c8c3a345032682ffc394bca
2017-11-10 01:00:18 +01:00
fi
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
$(TARGET_KERNEL_MODULES): TARGET_KERNEL_BINARIES
$(TARGET_PREBUILT_INT_KERNEL): $(TARGET_KERNEL_MODULES)
lineage: build: kernel: Rework kernel header logic The existing kernel header logic has several issues: * It does not depend on the actual kernel headers, so it does not detect actual kernel header changes. * It does depend on the kernel config, which should not be used to generate (user space) kernel headers. The end result is that kernel headers aren't properly regenerated when needed, and spuriously regenerated when not needed. Additionally, the kernel header rebuild mucks around with the kernel config, which is unneccesary and fraught with danger. Rewrite the kernel header dependency and generation logic as follows: * Use the dependency file $(KERNEL_OUT)/.headers_install_deps to manage dependencies on the actual kernel header files which are exported to user space (and the top level kernel Makefile, which is used to generate version.h). The dependency file is exactly the same as what GCC would output for a C/C++ dependency with the M/MM flags. * Conditionally include the dependency file to detect when headers should be (re)generated. * Introduce the phony target INSTALLED_KERNEL_HEADERS for modules to declare a dependency on kernel headers. Additionally: * Get rid of TARGET_KERNEL_HEADER_ARCH and KERNEL_HEADER_DEFCONFIG. * Get rid of KERNEL_OUT_STAMP and move commands to the appropriate places in the rules. * Fail the build when $(KERNEL_OUT)/usr is mentioned in a dependency. Note a separate commit to build/core/binary.mk will provide a migration path and a suitable deprecation warning. * Declare the kernel*config targets phony. Change-Id: I8b46f4ea1c622d8e73cca5157be96ec09d42ebb3
2017-11-09 21:02:33 +01:00
.PHONY: kerneltags
kerneltags: $(KERNEL_CONFIG)
$(hide) mkdir -p $(KERNEL_OUT)
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) tags
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
kernel: Remove kernel{x}config * They haven't been working since ninja build was introduced Change-Id: Icb51412b7a70cdec7f077a6d3d56f7720188bcb0
2018-10-06 21:12:10 +02:00
.PHONY: kernelsavedefconfig alldefconfig
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
lineage: build: kernel: Rework kernel header logic The existing kernel header logic has several issues: * It does not depend on the actual kernel headers, so it does not detect actual kernel header changes. * It does depend on the kernel config, which should not be used to generate (user space) kernel headers. The end result is that kernel headers aren't properly regenerated when needed, and spuriously regenerated when not needed. Additionally, the kernel header rebuild mucks around with the kernel config, which is unneccesary and fraught with danger. Rewrite the kernel header dependency and generation logic as follows: * Use the dependency file $(KERNEL_OUT)/.headers_install_deps to manage dependencies on the actual kernel header files which are exported to user space (and the top level kernel Makefile, which is used to generate version.h). The dependency file is exactly the same as what GCC would output for a C/C++ dependency with the M/MM flags. * Conditionally include the dependency file to detect when headers should be (re)generated. * Introduce the phony target INSTALLED_KERNEL_HEADERS for modules to declare a dependency on kernel headers. Additionally: * Get rid of TARGET_KERNEL_HEADER_ARCH and KERNEL_HEADER_DEFCONFIG. * Get rid of KERNEL_OUT_STAMP and move commands to the appropriate places in the rules. * Fail the build when $(KERNEL_OUT)/usr is mentioned in a dependency. Note a separate commit to build/core/binary.mk will provide a migration path and a suitable deprecation warning. * Declare the kernel*config targets phony. Change-Id: I8b46f4ea1c622d8e73cca5157be96ec09d42ebb3
2017-11-09 21:02:33 +01:00
kernelsavedefconfig:
$(hide) mkdir -p $(KERNEL_OUT)
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) $(KERNEL_DEFCONFIG)
kernel: Add savedefconfig target * Add a build target to simply regenerate the kernel minimal defconfig and copy it to the kernel source Change-Id: I04be945eb6dae3042c236785328c7c9995d42e49
2017-07-12 19:56:35 +02:00
env KCONFIG_NOTIMESTAMP=true \
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) savedefconfig
kernel: Add savedefconfig target * Add a build target to simply regenerate the kernel minimal defconfig and copy it to the kernel source Change-Id: I04be945eb6dae3042c236785328c7c9995d42e49
2017-07-12 19:56:35 +02:00
cp $(KERNEL_OUT)/defconfig $(KERNEL_DEFCONFIG_SRC)
lineage: build: kernel: Rework kernel header logic The existing kernel header logic has several issues: * It does not depend on the actual kernel headers, so it does not detect actual kernel header changes. * It does depend on the kernel config, which should not be used to generate (user space) kernel headers. The end result is that kernel headers aren't properly regenerated when needed, and spuriously regenerated when not needed. Additionally, the kernel header rebuild mucks around with the kernel config, which is unneccesary and fraught with danger. Rewrite the kernel header dependency and generation logic as follows: * Use the dependency file $(KERNEL_OUT)/.headers_install_deps to manage dependencies on the actual kernel header files which are exported to user space (and the top level kernel Makefile, which is used to generate version.h). The dependency file is exactly the same as what GCC would output for a C/C++ dependency with the M/MM flags. * Conditionally include the dependency file to detect when headers should be (re)generated. * Introduce the phony target INSTALLED_KERNEL_HEADERS for modules to declare a dependency on kernel headers. Additionally: * Get rid of TARGET_KERNEL_HEADER_ARCH and KERNEL_HEADER_DEFCONFIG. * Get rid of KERNEL_OUT_STAMP and move commands to the appropriate places in the rules. * Fail the build when $(KERNEL_OUT)/usr is mentioned in a dependency. Note a separate commit to build/core/binary.mk will provide a migration path and a suitable deprecation warning. * Declare the kernel*config targets phony. Change-Id: I8b46f4ea1c622d8e73cca5157be96ec09d42ebb3
2017-11-09 21:02:33 +01:00
alldefconfig:
$(hide) mkdir -p $(KERNEL_OUT)
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
env KCONFIG_NOTIMESTAMP=true \
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) -C $(KERNEL_SRC) O=$(KERNEL_OUT) ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) alldefconfig
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
kernel: Allow building dtbo.img taimen uses the dtbo.img as an DTB Overlay in order to use the same defconfig for both, taimen and wahoo. The dtbo.img is built with "make dtbo.img". Allow automatically building it when setting TARGET_NEEDS_DTBOIMAGE to true, or by manually calling make dtboimage. Thanks to luca020400 for help with the kernel.mk logic [raymanfx] Add AVB hash footer support Change-Id: Iaddafaa98e3e84880462a2c35b899e3fea21e161
2017-11-25 16:52:17 +01:00
TARGET_PREBUILT_DTBO = $(PRODUCT_OUT)/dtbo/arch/$(KERNEL_ARCH)/boot/dtbo.img
$(TARGET_PREBUILT_DTBO): $(AVBTOOL)
echo -e ${CL_GRN}"Building DTBO.img"${CL_RST}
kernel.mk: Support kernels that use LTO Google added support for LTO + CFI in the Pixel 3 kernel, which requires not only Clang but a couple of additional binaries, namely llvm-ar and llvm-dis for IR generation. Google expects these binaries to be in PATH according to their definitions and the build.config.common file: https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/Makefile#637 https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.31/build.config.common However, kernel.mk does not add the LLVM bin directory to PATH so the build fails because the binaries can't be found. We could add LLVM_AR and LLVM_DIS to the make commands like CC and CROSS_COMPILE; however, adding the bin directory to PATH is a more sustainable solution as Google might require new binaries in the future. Additionally, LTO needs access to the LLVMgold library so it needs to be available in LD_LIBRARY_PATH. Add a PATH_OVERRIDE variable that will set up PATH and LD_LIBRARY_PATH with the bin and lib64 folders from the requested LLVM toolchain respectively when building with Clang. This won't affect kernels that don't use LTO like Wahoo. Change-Id: Ib16fa0d3180de2f96accb2f7648b07a017f8f98b Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
2018-10-22 04:07:47 +02:00
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(PRODUCT_OUT)/dtbo ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) $(KERNEL_DEFCONFIG)
$(PATH_OVERRIDE) $(MAKE) $(KERNEL_MAKE_FLAGS) -C $(KERNEL_SRC) O=$(PRODUCT_OUT)/dtbo ARCH=$(KERNEL_ARCH) $(KERNEL_CROSS_COMPILE) $(KERNEL_CLANG_TRIPLE) $(KERNEL_CC) dtbo.img
kernel: Allow building dtbo.img taimen uses the dtbo.img as an DTB Overlay in order to use the same defconfig for both, taimen and wahoo. The dtbo.img is built with "make dtbo.img". Allow automatically building it when setting TARGET_NEEDS_DTBOIMAGE to true, or by manually calling make dtboimage. Thanks to luca020400 for help with the kernel.mk logic [raymanfx] Add AVB hash footer support Change-Id: Iaddafaa98e3e84880462a2c35b899e3fea21e161
2017-11-25 16:52:17 +01:00
$(AVBTOOL) add_hash_footer \
--image $@ \
--partition_size $(BOARD_DTBOIMG_PARTITION_SIZE) \
--partition_name dtbo $(INTERNAL_AVB_DTBO_SIGNING_ARGS) \
$(BOARD_AVB_DTBO_ADD_HASH_FOOTER_ARGS)
kernel: Move full kernel build guard flag below all targets * The Pixel DTBO generation step should also be guarded by the full kernel build flag. Change-Id: I06d230b1b32ad9d974f90bfe6ae82008f4454d83
2019-02-10 21:12:50 +01:00
endif # FULL_KERNEL_BUILD
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
## Install it
ifeq ($(NEEDS_KERNEL_COPY),true)
file := $(INSTALLED_KERNEL_TARGET)
ALL_PREBUILT += $(file)
$(file) : $(KERNEL_BIN) | $(ACP)
$(transform-prebuilt-to-target)
ALL_PREBUILT += $(INSTALLED_KERNEL_TARGET)
endif
kernel: Allow building dtbo.img taimen uses the dtbo.img as an DTB Overlay in order to use the same defconfig for both, taimen and wahoo. The dtbo.img is built with "make dtbo.img". Allow automatically building it when setting TARGET_NEEDS_DTBOIMAGE to true, or by manually calling make dtboimage. Thanks to luca020400 for help with the kernel.mk logic [raymanfx] Add AVB hash footer support Change-Id: Iaddafaa98e3e84880462a2c35b899e3fea21e161
2017-11-25 16:52:17 +01:00
ifeq ($(TARGET_NEEDS_DTBOIMAGE),true)
file := $(INSTALLED_DTBOIMAGE_TARGET)
ALL_PREBUILT += $(file)
$(file) : $(TARGET_PREBUILT_DTBO) | $(ACP)
$(transform-prebuilt-to-target)
ALL_PREBUILT += $(INSTALLED_DTBOIMAGE_TARGET)
endif
Import CM build additions Change-Id: Id1eb902129754e61dfcc2b5d95c3a75172ff0c5e
2016-08-26 00:12:08 +02:00
.PHONY: kernel
kernel: $(INSTALLED_KERNEL_TARGET)
kernel: don't build for TARGET_NO_KERNEL targets Change-Id: I14ad45c06922c0775e0574ddbcfcdc33353af465
2017-12-08 20:46:30 +01:00
kernel: Allow building dtbo.img taimen uses the dtbo.img as an DTB Overlay in order to use the same defconfig for both, taimen and wahoo. The dtbo.img is built with "make dtbo.img". Allow automatically building it when setting TARGET_NEEDS_DTBOIMAGE to true, or by manually calling make dtboimage. Thanks to luca020400 for help with the kernel.mk logic [raymanfx] Add AVB hash footer support Change-Id: Iaddafaa98e3e84880462a2c35b899e3fea21e161
2017-11-25 16:52:17 +01:00
.PHONY: dtbo
dtbo: $(INSTALLED_DTBOIMAGE_TARGET)
kernel: don't build for TARGET_NO_KERNEL targets Change-Id: I14ad45c06922c0775e0574ddbcfcdc33353af465
2017-12-08 20:46:30 +01:00
endif # TARGET_NO_KERNEL
Reference in a new issue Copy permalink