* Also remove the lz4c fallback. We're providing an lz4
binary that works, so it shouldn't ever have to fall back
to lz4c.
Change-Id: I5b1346c55dc97daec13e087c501840628a7265e8
Our build/make changes break incremenetal builds with prebuilt dtb dir
(see discussion here: https://android-review.googlesource.com/c/platform/build/+/1134337/1/core/Makefile )
Instead of using the AOSP recipe, just define our own and use it by not defining
BOARD_PREBUILT_DTBIMAGE_DIR
Change-Id: If579b1670db447557b6f76ca79ecec22661c4080
Previously, this would be a full compile prefix
(e.g. prebuilts/gcc/.../bin/aarch64-linux-gnu-). Since we're adding
this to PATH, it only needs to be prebuilts/gcc/.../bin.
Also remove the extra /bin/ added by kernel.mk.
Change-Id: If2490729128c0243c61de646f6c8e19a15c8dc1c
* Fold module installation into kernel image recipe.
* Specify make argument to strip modules on installation instead of
explicitly invoking the strip tool.
* Remove support of TARGET_KERNEL_MODULES, it's a phony target thus
we're not allowed to depend on it per Android 10 restriction. It
has been useless for years anyway.
* Apply minor clean-ups.
Change-Id: I288af1b2f741f524c2ef49554e15cb91c3115209
The kernel make command is executed in the build root. Without absolute
out paths, kernel out start with "out/" meaning it would be created in
the kernel source. Add BUILD_ROOT to the argument to ensure it's always
made in the actual out/ dir.
Change-Id: I425134a893d4d5c9f31efccaf75e153b5462b76c
* This fixes dirty boot image rebuilding on devices
with CONFIG_LOCALVERSION_AUTO=y and any driver
set to =m.
* Basically appending `cat include/config/kernel.release`
to modules path makes sure that our find does not
return old modules which would make cp fail with
'cp: will not overwrite just-created' message.
Change-Id: Ifb79d33b95d7671d8b2d6633644c8b8290d1f442
Currently we handle the DTBO images from start to finish, including
AVB footers, and just drop them in $(PRODUCT_OUT)/dtbo.img when done.
While this works for the most part, we are limited in what we can do
with the DTBO images. For example non-A/B device recovery images must
have a copy of the DTBO image appended to recovery (see AOSP docs:
https://source.android.com/devices/bootloader/recovery-image ). This
means that we need to pass the pre-AVB dtbo image into
BOARD_PREBUILT_DTBOIMAGE in order to let the AOSP build system handle it.
This commit reworks the way the DTBO images are built, placing them at
$(PRODUCT_OUT)/dtbo-pre.img instead and setting BOARD_PREBUILT_DTBOIMAGE
to that path so the AOSP build system can pick the images up and sign
them and append to recovery (for applicable devices).
Change-Id: I8819d7cd92ba298de67dbc7f6b321917ba8524f1
* Call the build system's build-image-kernel-modules function instead of
redefining all of it inline ourselves.
Change-Id: Ifc4bd3c452393389a14174f4cc29a8f7ef064b93
* Check for any actual kernel modules, rather than just the presence of
kernel modules being enabled as a kernel feature.
Change-Id: I6b7e82d5c59dd57621d9f9e2d1fd606997790d1c
* 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
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#637https://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>
*) This has been deprecated by the bp mobule
generated_kernel_headers.
*) To build with kernel headers, do this:
LOCAL_HEADER_LIBRARIES += generated_kernel_headers
Or for soong targets:
header_libs: [ "generated_kernel_headers" ],
Change-Id: Idad445709f0ee0ec11b41b40123b14976a0052ad
Kernel source settings should always come at BoardConfig population
time so things that use the variable later don't end up pointing to
an empty or wrong variable.
The following is also squashed in:
Author: Christopher N. Hesse <raymanfx@gmail.com>
Date: Fri Aug 10 00:23:54 2018 +0200
tasks: kernel: Honor prebuilt kernel flag
For devices that want to use a prebuilt kernel, TARGET_KERNEL_SOURCE
would still be set to TARGET_AUTO_KDIR, meaning the build system would
still try to build the kernel if TARGET_AUTO_KDIR was present.
Setting TARGET_PREBUILT_KERNEL indicates this is not wanted, so don't
attempt to do it.
Change-Id: Ic79b3ac1b9c946fd258ada43dce2b08bb74ea0d9
Change-Id: If046b86ff0d18c76898e90295be873a8379f678a
Google added a 32-bit vDSO to the Wahoo and Marlin kernels on Android P,
requiring a 32-bit toolchain to compile/link, and the build fails when
it is not provided.
Change-Id: I700e66a417ed431c31d82fc950f5e5acd07ab281
Recent devices (e.g. Pixel 2XL aka taimen) do not define any "system"
partition in their fstab, so a plain "mount /system" fails.
Furthermore, trying to get the entry from /etc/recovery.fstab also fails
because the partitions have slot suffixes (e.g. system_a).
So for these devices, we need to figure out the active slot, mount the
system partition (which really contains the whole root) and lastly mount
the actual system partition from the rootfs.
Change-Id: Ibb73a82896c1f6ce6af9c334b8d0908a183913b9
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>
If for whatever reason we need a prebuilt DT image,
it has to end up in target files for the signing slave.
Change BOARD_KERNEL_PREBUILT_DT to hold the path of the
prebuilt DT image, if it's going to be used.
Change-Id: I8042d347d271da5c3963824777d399bbc4229aa9
* 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
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
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
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>
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
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
* 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
