This can happen when an out of tree module target uses a matching module
name from the base kernel. This causes two problems:
1) Depmod gets confused and only pulls symbols from one of the modules
2) Copying the modules to modules_out is not entirely deterministic and
is based on the first variant to be returned by find, meaning that
the variant that gets copied to the device could change build to
build.
To avoid these issues, fail the build if this happens and force the
build target to only generate one copy of each module name.
Change-Id: I2e47ba4e142054feabaa1ab80fbbe0332fd84a62
Original commit incorrectly added kernel as a dep to the vendor ramdisk
for this path, when instead the dep should be added to the boot ramdisk.
Change-Id: I25a42d403fe2ddb0538b08c2dd8f761eae960810
This makes sure that $OUT contains images for all partitions.
Test: breakfast tangorpro && m bacon && ls $OUT/vendor_boot.img
Change-Id: Ia59a1fb7d9d1054040453ff2e7954ea6d7c61fde
TARGET_EXTERNAL_KERNEL_MODULES variable is used for the list of modules,
same as the existing functionality, but is invoked if ':kbuild' is
appended to a module name
Existing external module build calls make in the module directory, which
is a standalone module build. The module makefile may chain to kbuild,
but that depends on the module. This addition invokes the kernel build
system, passing the module directory via the M= param, which is the
kernel standard for building out of tree modules.
Change-Id: I38a582952f79f7155cdbf8a5975cf23074bbdab0
Android supports loading modules from the boot ramdisk in the case of
vendor ramdisk not existing.
Change-Id: Ide1255b2c37ee262c8a4181d5eb0e380d0488edc
Do not allow module load lists to contain unexistent kernel modules
and bail out if that's the case, informing that the list must be
corrected.
The lists can be formed including the full module path and with or
without the file extension, like shown below:
kernel/drivers/watchdog/softdog.ko
kernel/net/wireless/cfg80211.ko
kernel/net/mac80211/mac80211.ko
or simply:
softdog.ko
cfg80211.ko
mac80211.ko
or ultimately:
softdog
cfg80211
mac80211
Either way, the newly generated modules.load file will now only
contain the module name without the extension, which is inline with
modules.alias and modules.blocklist.
Change-Id: I969274f7edf249c98ca241e37b6e41a921d36908
Before:
mka bootimage
qcacld failed to compile, but boot.img is generated
After:
mka bootimage
qcacld failed to compile and no boot.img is generated
Commit fadfdbf introduced the idea of building external modules,
but it didn't account for the scenario where compilation could fail
while the boot.img is still being built.
Fix this by properly stopping the build process as soon as the external
module fails to compile.
Change-Id: Ifed28825f8e4b78d304fe62a47908e208edfb886
Commit 47931c1 introduced GKI modules handling with the assumption
that using BOARD_SYSTEM_KERNEL_MODULES would still work in Android 14,
but turns out that it conflicts with build/make/core rules.
Change-Id: I9167940c08b8420be254c52698f1faa2e3e7f793
* This was missed in bdfc913935
* Aligns the variable name for vendor_kernel_boot modules with AOSP
Change-Id: I8d59f7b5d62e29a0484ca36fadcb74acab4f1859
This fixes the following warnings:
13:04:54 Disallowed PATH tool "pahole" used: []string{"pahole", "--version"}
13:04:54 See https://android.googlesource.com/platform/build/+/master/Changes.md#PATH_Tools for more information.
"pahole" is not allowed to be used. See https://android.googlesource.com/platform/build/+/master/Changes.md#PATH_Tools for more information.
/home/bgcngm/android/lineage/kernel/oneplus/sm8550/scripts/pahole-flags.sh: 12: [: Illegal number:
/home/bgcngm/android/lineage/kernel/oneplus/sm8550/scripts/pahole-flags.sh: 16: [: Illegal number:
/home/bgcngm/android/lineage/kernel/oneplus/sm8550/scripts/pahole-flags.sh: 20: [: Illegal number:
Change-Id: Ice2a3753301a7b7782037fd35544e2831b258650
On some devices too many .dtb files are generated. Instead of taking
all of them, allow to only take selected .dtb files for the final
DTB image.
Example: Motorola Edge 40 Pro (rtwo, sm8550) generates the following:
obj/DTB_OBJ/out/kaka-rumi.dtb
obj/DTB_OBJ/out/kalama-rtwo-base-kalama-rtwo-evb1-overlay.dtb
obj/DTB_OBJ/out/kalama-rtwo-base-kalama-rtwo-evt1-overlay.dtb
obj/DTB_OBJ/out/kalama-rtwo-base-kalama-rtwo-na-vzw-evt2-overlay.dtb
obj/DTB_OBJ/out/kalama-rtwo-base-kalama-rtwo-prc-dvt1b-overlay.dtb
obj/DTB_OBJ/out/kalama-rtwo-base-kalama-rtwo-prc-pvt-overlay.dtb
obj/DTB_OBJ/out/kalama-rtwo-base-kalama-rtwo-row-dvt1b-overlay.dtb
obj/DTB_OBJ/out/kalama-rtwo-base.dtb
obj/DTB_OBJ/out/kalama-v2-rtwo-base-kalama-rtwo-evb1-overlay.dtb
obj/DTB_OBJ/out/kalama-v2-rtwo-base-kalama-rtwo-evt1-overlay.dtb
obj/DTB_OBJ/out/kalama-v2-rtwo-base-kalama-rtwo-na-vzw-evt2-overlay.dtb
obj/DTB_OBJ/out/kalama-v2-rtwo-base-kalama-rtwo-prc-dvt1b-overlay.dtb
obj/DTB_OBJ/out/kalama-v2-rtwo-base-kalama-rtwo-prc-pvt-overlay.dtb
obj/DTB_OBJ/out/kalama-v2-rtwo-base-kalama-rtwo-row-dvt1b-overlay.dtb
obj/DTB_OBJ/out/kalama-v2-rtwo-base.dtb
with only kalama-rtwo-base.dtb and kalama-v2-rtwo-base.dtb needed.
Disabling compilation of the other kalama.dtb isn't possible, as this
would also disable the compilation of the needed .dtbo files.
Because they are earlier in alphabetical order, and the matching
board ids, the bootloader ends up selecting those, instead of the
correct ones. This results in USB (and possible other things) to
not work.
Change-Id: I486b6ec538a3e4906b5b8aa5ecb355b480b60de7
It can be the case where OEM/ODM decided to put the main DTBOs
outside vendor/qcom (e.g. vendor/oplus). Support such usecase
by generically allowing all .dtbo files found in all first-level
subdirs to be moved to base DTB folder.
Change-Id: I154d401b560535d1fa8cd7ed4965dd34a4cf75f2
All devices lauching with Android 13 (and above) must include
a system_dlkm partition, where GKI modules should reside.
Android 13 build system only supports providing prebuilt modules,
by pointing BOARD_SYSTEM_DLKM_SRC to the modules source folder.
Google will introduce BOARD_SYSTEM_KERNEL_MODULES for Android 14,
so take a step forward and use that macro to exclude the listed
modules from the usual vendor DLKM partition and place them into
the GKI module partition.
Note that the GKI modules are placed into lib/modules/androidX-Y.Z,
as defined by Google and observed in system_dlkm_modprobe script.
Change-Id: I2b1644479788cb5c9568cac738202b1d55fc28d7
Gets rid of the following from clang -v:
```
Found HIP installation: /opt/rocm, version 5.4.22804
```
Change-Id: Ic58b3fb2dd67d345372bec7f5d2cf023ed2fb34d
The kernel tries to define the LINUX_COMPILER macro from the output
of `$(CC) -v | grep ' version '`, but in clang that might produce
more than one line containing ' version ' when CUDA is installed:
```
Android (8490178, based on r450784d) clang version 14.0.6
Found CUDA installation: /usr/local/cuda, version 11.0
```
That causes the macro to expand into multiple lines, upsetting the
compiler that cannot find the ending double quote.
In upstream linux this is fixed from v5.8
Change-Id: Icde4253e989df1cbbefc0ce98f437d16822fc93b
android11-5.4 kernel can fully compile with LLVM with a few cherrypicks
from android12-5.4 and android12-5.10
Change-Id: Ib71935d284ad78f1c23d039c15bfc5e0314a19eb
* Boot Image header v2 demands a DTB be passed by default.
* We don't /need/ one at all, as we have and use a dedicated
DTB partition.
* Signing hates trying to find dtb.img anywhere for some magical
reason, so cheat and introduce a flag to include a blank one.
Change-Id: I889ce3815476a55829870b30de1b9210283a79ae
(cherry picked from commit fa16b42ddd1eb341f201b8d810c717ea12afe1cb)
* Remove KERNEL_LD from kernel.mk, we simply set LD in BoardConfigKernel
* Add llvm-ar in path allowlist (used by LTO)
Change-Id: I76addb6f9d8d413edb1832dba23082ffb6d5ebc3
Fixes:
error: unable to open output file
'arch/arm64/boot/dts/google/devices/bluejay/google-base/.gs101-b0.dtb.dts.tmp':
'No such file or directory'
Change-Id: I457062e46062fb3553421d196b432de7d06a49ad
vendor_boot v4 supports packaging multiple "fragmented" vendor ramdisks.
A secondary can be used to store the kernel modules instead of storing
them in the "normal" vendor_ramdisk.
Test: Create a vendor_boot with source built kernel/modules,
gs101 still boots.
Change-Id: Ic295ccf201c2593e08b9559ae28f80c70a7eb341
On some devices we might want to build just the *.dtb files
that we actually need instead of the every dtb that exists.
Change-Id: Id7a152499d4ee1dd08f79d34cc34bfe959313515
* Currently, because DTC_EXT make flag is in the
kernel task the only way to override it is to
have TARGET_KERNEL_ADDITIONAL_FLAGS come after.
Change-Id: If62ed979581dc07eafd4628ce2b2d799388d3704
This reverts commit caa3bddf00.
Reason for revert: Breaks pixel dtbo.img build, since kernel depends on
mkdtimg. Add it back so it gets compiled and kernel can pick it up.
Change-Id: I2b9fd0b2b35e0cf2f908516b10f65399780d5c30
* AOSP build system is not aware of dtb(o) source update, and thus
won't rebuild the images, results in outdated artifact.
* Convert DTB(O)_OUT to make targets and make the images depend on them
to address the issue. This makes AOSP build system be aware of
their timestamp changes and re-execute recipes depending on them.
Finally, it's up to kernel's build system to decide actions to take.
Test: m dtb(o)image and observe dtb(o).img get rebuilt
Change-Id: I197e7d2d3e013ded0e555fc22bb6a1200d40df9c
Commit 8ac7d31 introduced this issue.
Test: run `m recoveryimage` and verify that recovery
image is now built.
Change-Id: Iffdd8112db2ba1baff28db7ee4c340dbb5ebd917
Commit 8ac7d31 introduced this issue.
Test: run `m installclean && m bootimage` and observe that
kernel image is built.
Change-Id: I41eb7cd2e5108bae8f4c40c0f9a300a8a3cc95a7
* Since some time you can specify multiple configs when you prepare .config and they'll get merged to main one
* To use it inline:
TARGET_KERNEL_CONFIG := main_defconfig fragment1.config fragment2.config ...
* TARGET_KERNEL_ADDITIONAL_CONFIG has been nuked since it's superseed by this new logic
* kernelsavedefconfig will only use the base defconfig
Change-Id: I479c762a9235ed0ef6fcdc79b53e084d5e2d78a6
