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
* GCC was deprecated awhile ago, the large majority
of devices should now be using this. Clang should
be opt out as opposed to opt in.
Change-Id: Ie388aff8eca189663f2f615f7d059e47eaf2dce3
* Make it consistent with the rest of the targets
Signed-off-by: Jarl-Penguin <jarlpenguin@outlook.com>
Change-Id: I869d3d8570b4deb2f1e019efa975526a528ca3e7
The check for official builds now only affects the case where a prebuilt
kernel was actually used, not the case where a device builds a kernel
from source as normal.
The check has also been turned around so that it only fails the build if
it's actually an official build, not an unofficial one.
Change-Id: I1280b16b90589742c2abe7f3f6f5975a3aaeea03
* TARGET_FORCE_PREBUILT_KERNEL should be useful when you don't have ready kernel sources (OEM releasing broken sources or releasing them lately)
* It lets you use kernel sources for userspace generated headers (generated_kernel_headers) while keeping using prebuilt kernel
* Keep in mind that generated kernel headers may not align with the ABI of kernel you're including
* This commit also partially revert commit a836d79, where TARGET_KERNEL_SOURCE would have been unset if TARGET_PREBUILT_KERNEL was defined (we already check in kernel.mk if kernel sources are present anyway)
Change-Id: I84acae890dabb5b9dbd48143ad58f6420c0cef75
Mini documentation:
List the names of boot modules in BOOT_KERNEL_MODULES to add them
to vendor_boot.
All modules still end up in their primary location (normally
vendor/lib/modules). Boot modules will be kept here as duplicates.
The list of boot modules is then depmod'ed and copied to the
vendor ramdisk.
The file modules.load is created from
BOARD_$(IMAGE)_KERNEL_MODULES_LOAD as the ordered list of modules
to be loaded form that location, either parsed by a modprobe script
or by init itself (only boot modules)
When using vendor_boot modules, vendor/lib/modules/modules.load
should list all modules but boot modules.
Also don't clear the output directory, because one might want to
push a modules.blocklist there.
Change-Id: I89a4aad42a6585a572812f1d7e89f5d78931e1e6
* We're having a race with the kernel module build and vendor.img
generation, and sometimes when vendor.img wins it won't include
any modules in the image, which leads to all sorts of breakage
Change-Id: I2cdde96530aa8e47351cace76352788cde631058
- The goal of specifying kernel image name was to whether kernel needs
appended dtb or not, which is not something required if the kernel is
prebuilt
Ref:
[0]: Commit edc1cebc2f
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
Change-Id: I6b43756a2eac59729a67b5f80dac112f8b6bcc5b
* The new refactored function doesn't work with shell expanded
variables, like our $$modules.
* This is the _easy_ fix.
A proper fix would imply generating the module list into a make variable
from the shell variable, but with kati that looks unfeasable (to me...)
Change-Id: I8198c62fa93ad94d4b9bf7175fe5eea452c243ea
* A simple "make kernel" or incremental system build
always triggers a complete kernel recompilation,
even though the kernel sources were unchanged
* The reason is because .additional_config is always
considered new and invalidates the .config file,
forcing the kernel to rebuild itself every time
* Instead, prevent the /dev/null and KERNEL_OBJ dependencies
having irrelevant timestamp changes with an empty variable
* Command "make kernel" takes 3 seconds versus 40s before
Change-Id: I3b583077b7ef5873eebde3e4b0e790f5d7587ed3
Signed-off-by: Adrian DC <radian.dc@gmail.com>
