* 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
As md5 is not considered as secure since some time, and sha256 is
industry standard, lets switch over here too.
Change-Id: I22015be20126a4348affa5ef97e2c28fbd7b4717
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>
It was removed accidentally in commit fe00ea9.
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
Change-Id: Icadd7b17b3a732fc2c8aa14f1e4dbd4bc66eb7f9
* Remove the separate dtbo.mk task and merge it
in kernel.mk
* Merge in-kernel and separated DTBO image generation
Change-Id: I2cae84095cbd3d68abbe1899a9cae34c8a1e5fc9
* This makes it use the latest source built dtc instead of the prebuilt,
which is too old for coral/4.14
* Would be best to have it use the in-kernel DTC though,
as that should always work for that particular kernel.
* When OUT_DIR_COMMON_BASE isn't set, this path is relative (i.e. out/),
so append $(KERNEL_BUILD_OUT_PREFIX) to account for that.
Change-Id: I6ffe72a2fb061ee81b385f31f4acf682876b27c8
* On devices using vendor_overlay it could be useful
to be able to re-name the installed modules to
match the ones in vendor
-> An example is QCOM techpack where default module
name in kernel doesn't match installed module
name
Change-Id: If9458bca06218aeb8c91283057c083d909bf5104
* We are no longer providing our own root access solution
as of 17.0, as PermissionHub has largely replaced the
functionallity of Privacy Guard, which this feature
was housed in.
* We do still have a baked in ADB root solution that can
be enabled in developer settings (see topic:ten-adbroot
on Gerrit).
* This DOES NOT mean we will be providing support for other
root solutions.
Change-Id: Iecf92e3c8f91304ed998e0260d09a8048dc44d82
If the prebuilt directory is set, then the AOSP commands get activated,
which will conflict with ours, so just disable ours if the prebuilt
directory is set.
Change-Id: Ia998ea3d1a2d3403d0261cecae12d8a5c4f689ec
* 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
