This expects a few build variables to be set:
* TARGET_KERNEL_PLATFORM_TARGET: The base target name. For example,
'tegra' will indicate that the dist target is tegra_dist, abi is
tegra_abi, etc.
* TARGET_KERNEL_VERSION: Used to determine the kernel checkout path. For
example, a value of 6.6 will expect the kernel platform repo to be
checked out to $BUILD_TOP/../kernel-6.6.
* TARGET_KERNEL_SOURCE: Relative to the top of the kernel platform
checkout, the path to the kernel build rules. For example,
vendor/nvidia/tegra.
* BOARD_KERNEL_IMAGE_NAME: The kernel image to use. For example, Image.
Using the examples above, this will run bazel in the kernel-6.6
directory on the target //vendor/nvidia/tegra:tegra_dist, then source
the output from $OUT/tegra/dist, with the prebuilt kernel image being
Image.
Change-Id: If96e96dffa2c0bfd9bd824bb3d8064eb861c9d00
This has been unused for a long time and any users that mistakenly use
this should migrate to defconfig fragments.
Change-Id: I70f1aa82e3adcbf85b11e8685f188d0eadfff2e3
... but sets SYSTEM_KERNEL_MODULES
build/make lets BOARD_SYSTEM_KERNEL_MODULES_LOAD default to false
when it's unset.
Change-Id: I581da33bf0321f171aa6a20bdb023e1ee824cb18
For targets that uses mainline kernel, the kernel tree usually only
contains configs on top of the upstream repository.
In such case, if we put the configs in elsewhere, we can simply just
track the upstream kernel repo, without needing to import configs.
Example usage:
TARGET_KERNEL_CONFIG_EXT := \
$(COMMON_PATH)/kconfig/platform_defconfig \
$(COMMON_PATH)/kconfig/common-addons.config
TARGET_KERNEL_CONFIG_EXT += \
$(DEVICE_PATH)/kconfig/device.config
Change-Id: Ibafd0afa7ec06df643ba290a6149a4f0781d67fb
* Allow wildcard pattern
* Support searching in specified directory
* Add variable that accepts a list of such patterns
Change-Id: I35da8ed19447b4ab69142152d7dc8e60bc55bf14
It has been noticed that sm8750 no longer puts GKI modules in the
subdirectory. Moreover, this seems to be something specific to QCOM,
so guard it as such.
Change-Id: Iac9c895c9c1eef06b2e4ce75bd7c5c2aa356fbb1
Currently there is a limit of 500 changes per page, giving us only
those when repopicking a query. By observing the "_more_changes" field
in the response and adding the "start" parameter to the query we can
do pagination and return all changes
Test: repopick -p -Q "branch:lineage-23.0"
Result before: 500 changes
Result after: 1094 changes (correct count as of time of commit)
Change-Id: I00304bc2c87b75cef89a26838da3dd1b1f0e65db
Needed for KERNEL_CLANG_VERSION if TARGET_KERNEL_CLANG_VERSION hasn't been set by the device config
It's boring to change it on each Google change ...
Change-Id: I1d682611cbf6c60d7ae6227b0b5afde591adf471
How-to:
1. Build and install cuttlefish packages by following [1]
2. Build LineageOS image and hosttar
```
source build/envsetup.sh
breakfast cf_phone_x86_64
m hosttar updatepackage
```
3. Extract LineageOS image and hosttar
```
mkdir lineage-cvd
cd lineage-cvd
unzip <LineageOS tree>/out/target/product/vsoc_x86_64/lineage_cf_phone_x86_64-img.zip
tar xzvf <LineageOS tree>/out/host/linux-x86/cvd-host_package.tar.gz
```
4. Run it
```
HOME=$PWD ./bin/launch_cvd
```
5. Open https://127.0.0.1:8443 in browser, and enjoy
[1]: https://github.com/google/android-cuttlefish?tab=readme-ov-file#debian-packages
Change-Id: I7d69db7be99d250f02d7e76fd398ebf5c2ca7c5f
Some DTBOs might use symbols from other DTBOs and require them to be
applied before them.
Sort them based on the __symbols__ and __fixups__ nodes, by creating a
dependency graph.
Change-Id: I40acf5da6b673b636a91f75ae3f3c634f2b5c505
This depends on a kernel headers tarball path being passed in
TARGET_PREBUILT_KERNEL_HEADERS, in the style that the kleaf kernel
platform build generates.
Change-Id: Ib82659fa44ef221e73d0d129daafbaae6bad87a2
Some OEMs add their own properties to avoid merging incompatible
overlays for different devices with the same QCOM soc.
Change-Id: Ic5b38a122173d8e9ecc1f0f399411cb37acf3150
For targets that uses mainline kernel, the kernel tree usually only
contains configs on top of the upstream repository.
In such case, if we put the configs in elsewhere, we can simply just
track the upstream kernel repo, without needing to import configs.
Example usage:
TARGET_KERNEL_CONFIG_EXT := \
$(COMMON_PATH)/kconfig/platform_defconfig \
$(COMMON_PATH)/kconfig/common-addons.config
TARGET_KERNEL_CONFIG_EXT += \
$(DEVICE_PATH)/kconfig/device.config
Change-Id: I021ffb76d0c0612343cff7b5c81541c2b88ef7e6
* Many Qualcomm targets that uses boot header v0 or v1
have the DTBs appended to the end of kernel image.
* In downstream msm kernels up to msm-4.19, Appending DTBs
is handled in the kernel tree. However, on msm-5.4 and
newer msm kernels, and on mainline kernel, This is not
supported.
* Normally, DTB processing depends on how the bootloader
loads it and should not be handled in the kernel tree,
so we handle it here.
* Instead of appending all DTBs by default, Get the list of
DTBs that needs to be included from a variable, so that
we don't need to modify dts Makefile to exclude unwanted
DTBs, and we could also ensure the DTBs are appended in
a specific order.
Change-Id: I603d1ebac5ee808bad045b85f9868d572d52cb80
Originally, BOARD_RECOVERY_RAMDISK_KERNEL_MODULES_LOAD was used, but
BOARD_RECOVERY_KERNEL_MODULES_LOAD is what build/make uses. Use the
proper variable by default and if it's not set, use the old variable.
Change-Id: I3522e4782ae56f67e49b234236fbb86c8ec65b92
