So that mk2rbc will just read from the file instead
of searching the source tree for makefiles.
Bug: 213508006
Test: m RBC_BOARD_CONFIG=1 nothing
Change-Id: I6b7e2aa000ad9861173c58cc06f6d49c9c11a0a7
There are 2 choices to build system_dlkm.img for
the system_dlkm partition for Android T launch
devices and must choose one.
1. Use kernel prebuilt system_dlkm.img
- BOARD_PREBUILT_SYSTEM_DLKM_IMAGE to point image
2. Build from kernel prebuilt system_dlkm_staging
- PRODUCT_BUILD_SYSTEM_DLKM_IMAGE
Both requires: BOARD_SYSTEM_DLKM_PARTITION_SIZE and
must be 64MB or higher in size (enforced via vts).
Bug: 200082547
Test: TH
Test: atest vts_system_dlkm_partition_test
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Change-Id: I83435123bd8aa3d04ab8a8b650a95fbab0bc49f2
This ramdisk used to be in boot.img, and is now placed into this new
init_boot.img instead.
This new image is used for a new init parition to seperate Android
platform artifacts from the kernel artifacts in boot.img.
Test: boot Cuttlefish
Bug: 203698939
Change-Id: Iaaf82486259979ab728730ce72a4e847ae005c18
Otherwise it gets a different value when using starlark
board config, causing the ninja files to differ.
Bug: 201700692
Test: ./build/bazel/ci/rbc_regression_test.sh -b aosp_crosshatch_car-userdebug
Change-Id: I55870f031b779202db720f10d7d502f9d868e1f6
Passing variables via a makefile instead of
rblf_cli / rblf_env allows us to give them correct
types while converting the makefile to starlark,
as opposed to the variables always being strings
when given via rblf_cli / rblf_env.
This also allows us to remove some hand-converted
starlark code.
Bug: 201700692
Test: ./out/soong/rbcrun ./build/make/tests/run.rbc
Change-Id: I58c4f20b29171c14e5ae759beb26a849426f6961
These variables' values show up in the command line
of certain build commands, so they need to be stable
to have stable ninja files.
The starlark board configuration strips these variables,
causing a discrepency between the starlark and make
versions of board configuration.
Bug: 201700692
Test: ./build/bazel/ci/rbc_regression_test.sh beagle_x15-userdebug
Change-Id: Id053435409821a3fe5997c07610ef835e0c83112
mk2rbc has a few predefined variables that can't be
set in the product/board config makefiles, unless they're
set to their predefined values. Exclude these variables
from the board config input variables so that they don't
conflict.
Bug: 201700692
Test: m RBC_BOARD_CONFIG=1 mainline_system_x86_64-userdebug (ninja files differ still but this fixes a compilation error)
Change-Id: Idc11b2c5029d28116236b289ad1f09afaaf83cc3
The main issue with board configuration up till this
cl was that it didn't have access to the product configuration
variables. Pass those in by dumping the make variables to a
temporary file, which is then converted to RBC, loaded,
and passed to the starlark board config..
Bug: 201700692
Test: build/bazel/ci/rbc_product_config.sh -pb sdk_phone_x86_64-userdebug
Change-Id: I9a4946b970ca43c5b5f53a6c507ad2c1a2eca61e
This reverts commit a2a5db4466.
Reason for revert: original change was obsoleted by
I3161e42b00a93177a1a4cb3b22da2218d294b7a7
Bug: 202129499
Test: Presubmit; change should be noop
Change-Id: Ib7be1ed73dbf08758276666f8ce35ed9cbf18a36
* changes:
Add generic board-agnostic pre-built pvmfw.img
Add framework for building the pvmfw.img partition
Stop assuming that pvmfw.img can only be pre-built
Rename the BOARD_PVMFWIMG_PARTITION_SIZE variable to follow the format
used by all other partitions: BOARD_$(name)IMAGE_PARTITION_SIZE. Note
that all boards using that variable should have been updated to also
define the new version, by now.
Define the new variable as board read-only, as done for other
partitions.
Bug: 199717422
Test: m ${ANDROID_PRODUCT_OUT}/pvmfw.img
Change-Id: I5664c903db6388458e906e996115b695220932ca
Adapt the variables necessary for building pvmfw.img by following what
was done for other Android partitions and introducing:
- PRODUCT_BUILD_PVMFW_IMAGE
- BUILDING_PVMFW_IMAGE
- BUILT_PVMFWIMAGE_TARGET
Replace the manual 'cp' by the more common 'copy-one-file'.
Bug: 199831815
Test: m ${ANDROID_PRODUCT_OUT}/pvmfw.img # with TARGET_PKVM_ENABLED=true
Change-Id: I5e4bbcbdbf4b96281ee54631938f097e9744883c
Introduce the BOARD_USES_PVMFWIMAGE variable, similarly to all other
partitions, and use it where appropriate (in particular, where the
soon-to-be incorrect assumption that pvmfw.img could only be a pre-built
board image was made).
Bug: 199717422
Test: m ${ANDROID_PRODUCT_OUT}/pvmfw.img # with TARGET_PKVM_ENABLED=true
Change-Id: I8f4faa78c741d29b473303b521834387dbd48cd1
This does largely the same thing as in product configuration,
it converts the board makefiles and evaluates them in place
of an $(include).
Bug: 201700692
Test: Temporarily replace the ifndef RBC_BOARD_CONFIG with RBC_PRODUCT_CONFIG,
then ./build/bazel/ci/rbc_product_config.sh aosp_arm64-userdebug
Change-Id: I91c3dd6b91cf6bfeb18a5fff95d53b7a2c113c57
Add PRODUCT variables
PRODUCT_BUILD_DEBUG_BOOT_IMAGE
PRODUCT_BUILD_DEBUG_VENDOR_BOOT_IMAGE
as toggles to enable/disable building boot-debug & vendor_boot-debug.
Bug: 200945738
Test: m bootimage_debug
Change-Id: Ic032b8594f776f911d7b6345a97d64fed930d890
Those boot-debug-*.img is used with `repack_bootimg` for a
vendor_boot-debug.img in VTS setup. It is not for GKI boot.img
release.
https://source.android.com/compatibility/vts/vts-on-gsi#repacking
Renames boot-debug-*.img to boot-with-debug-ramdisk-*.img to
avoid confusion with the official GKI boot.img release.
Bug: 200878300
Test: `lunch gsi_arm64-user` then `make bootimage_debug`
Change-Id: Ia1f6ba847d5b7409fb7a8534432484d2aa972494
make.
Avoids TARGET_FLATTEN_APEX lying about it, so we can trust it in
scripts, e.g. in art/build/apex/runtests.sh.
Test: banchan com.android.art; art/build/apex/runtests.sh
Bug: 179900989
Change-Id: I5d3226047e51a51ee76de2cbfad050e200568655
Devices using GKI architecture will use a prebuilt boot.img.
However, we should still sign this prebuilt boot.img with
device-specific AVB keys.
Steps to test the CL.
1. In a device BoardConfig.mk:
# Uses a prebuilt boot.img
TARGET_NO_KERNEL := true
BOARD_PREBUILT_BOOTIMAGE := device/google/redbull/boot.img
# Enable chained vbmeta for the boot image.
# The following can be absent, where the hash descriptor of the
# 'boot' partition will be stored then signed in vbmeta.img instead.
BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2
2. `make bootimage`, then `avbtool info_image --image $OUT/boot.img`,
checks the image is re-signed with a device-specific key
3. `make dist` to generate out/dist/TF.zip
4. `unzip out/dist/TF.zip IMAGES/boot.img`
5. `avbtool info_image --image out/dist/IMAGES/boot.img`,
checks the image is re-signed with a device-specific key
6. `sign_target_files_apks \
--avb_boot_key=external/avb/test/data/testkey_rsa8192.pem \
--avb_boot_algorithm=SHA256_RSA8192 \
--avb_boot_extra_args="--prop test:sign" \
./out/dist/*-target_files-eng.*.zip signed.zip`, resign the TF.zip
7. `unzip signed.zip IMAGES/boot.img`, then use `avbtool info_image` to
check the boot.img is re-signed with the --avb_boot_key in step 6.
Bug: 188485657
Test: above steps
Change-Id: I7ee8b3ffe6a86aaca34bbb7a8898a97b3f8bd801
Currently the debug ramdisk resources might be under / or
/first_stage_ramdisk of the ramdisk, and is determined by
some BOARD variables, e.g., BOARD_USES_RECOVERY_AS_BOOT,
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT, etc.
To make a generic boot-debug.img that can work on both devices,
let's move the debug resources always under / of the ramdisk.
Bug: 186082603
Test: boot a device with boot-debug.img
Test: boot a device with vendor_boot-debug.img
Change-Id: I55dc8ff322f6b97e2d6dc1a4ee5935e863f2f835
If BOARD_BOOT_HEADER_VERSION >= 4,
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is true and
BOARD_INCLUDE_RECOVERY_RAMDISK_IN_VENDOR_BOOT is true, then build
recovery as a standalone ramdisk fragment in vendor_boot image.
The recovery ramdisk would be a vendor ramdisk fragment packaged in
vendor_boot, whose ramdisk_name is "recovery" and ramdisk_type is
"VENDOR_RAMDISK_TYPE_RECOVERY".
Bootloader can omit loading the recovery ramdisk during normal boot to
optimize the size of the initramfs.
Bug: 183395459
Test: Presubmit
Test: Modify BoardConfig of CF and m dist. Verify the vendor_boot.img
with unpack_bootimg.
Test: Strip the vendor_boot of the recovery ramdisk, and verify that CF
can boot to normal boot without the recovery ramdisk.
Change-Id: I6e9a2781ec87aece10d4844fa18bbe9a7b4674e6
Add more checks around BOARD_BOOT_HEADER_VERSION in board_config.mk.
Refactor generation logic of vendor_boot ramdisk fragments.
Consolidate initialization and validation check to its own section.
Adjust some variable names and initialization sequence so the follow-up
change can land more cleanly.
Rename variable name "dir" so that it don't collide with the Makefile
function "$(dir ...)".
Bug: 183395459
Test: Presubmit; Change should be no-op with respect to build artifacts.
Test: Modify BoardConfig of CF and m dist. Verify the vendor_boot.img
with unpack_bootimg.
Change-Id: I8785c40dd9f87f3797a56ada93e65939d27d0e9b
This reverts commit ccfea17fb7.
Reason for revert: Original bug was resolved by updating branch config
Change-Id: I2327092261a2147fa8f2be3d878db04228e65511
For consistency with android-11 GKI boot-debug.img, we should
put debug resources under the 'fisrt_stage_ramdisk' dir. This is
needed for devices with `androidboot.force_normal_boot=1` in the
kernel cmdline, where init will chroot into /fisrt_stage_ramdisk.
For devices without force_normal_boot, they still can use their
vendor_boot-debug.img for debugging purpose.
Bug: 183670217
Test: `make bootimage_debug`, then use unpack_bootimg and
`lz4 -d -c ramdisk | toybox cpio -i` to unpack the ramdisk
for inspection.
Change-Id: I0a79440dafd091141a1203a2c2c7be5bc1bfc836
This change doesn't change the condition for building super_empty.img,
it just add a toggle PRODUCT_BUILD_SUPER_EMPTY_IMAGE that product
makefiles can use to skip building super_empty.img.
Products that don't use super_empty at all, for example GSI, can set
this option to ensure the super_empty.img is not built.
Bug: 183068624
Test: "m dist" on GSI and check the build artifacts under OUT and DIST
directories, and check the contents of *-img-*.zip
Change-Id: I54943952873d2d297fd9d18cbe14742bc12ae9c6
The 'bootconfig' kernel cmdline parameter needs to exist for the kernel
to search for bootconfig.
If BOARD_BOOTCONFIG contains anything, then add the parameter to the
kernel cmdline.
Test: Boot cuttlefish and verify /proc/cmdline has 'bootconfig' after
removing it from cuttlefish BoardConfig.mk
Bug: 173815685
Change-Id: I112a2a8e02ba7265c5547d9244298e07f26985ba
Gather all BOARD_BOOTCONFIG parameters.
Create vendor-bootconfig.img with parameters seperated by newlines. Pass
that file to mkbootimg as --vendor_bootconfig to add it to the
vendor_boot.img.
Test: Add BOARD_BOOTCONFIG parameters in cuttlefish .mk file
Check vendor-bootconfig.img for expected output
Verify expected vendor_boot.img format with:
unpack_bootimg --boot_image vendor_boot.img
Test: Update Cuttlefish bootloader to handle the new vendor_boot.img and
check /proc/bootconfig for the expexted parameters.
Bug: 173815685
Change-Id: Iaa9b71b4bc64375777a5353396e83bb2beb25c47
Add support for partitioning the vendor_boot kernel modules into
multiple vendor ramdisk fragments. The partition granularity is kernel
module directory. This mechanism builds upon the existing
BOARD_KERNEL_MODULE_DIRS mechanism. For example, say we have three
kernel module directories:
BOARD_KERNEL_MODULE_DIRS := foo bar baz
We can then define a vendor ramdisk fragment:
BOARD_MKBOOTIMG_ARGS += --header_version 4
BOARD_VENDOR_RAMDISK_FRAGMENTS := dlkm_foobar
And let said ramdisk to contain the DLKM directories "foo" and "bar":
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.KERNEL_MODULE_DIRS := foo bar
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.MKBOOTIMG_ARGS := <mkbootimg args>
The built vendor_boot image would contain two ramdisks.
The first one being the "default" ramdisk, which contains DLKM directory
"baz" and the rest of the files that get's installed to
$(TARGET_VENDOR_RAMDISK_OUT).
The second one is the "dlkm_foobar" ramdisk, which contains the two DLKM
directories.
Design doc: go/vendor-boot-v4
Bug: 162864255
Test: Modify BoardConfig.mk to have a product build v4 vendor_boot
Test: Use unpack_bootimg to verify the vendor_boot image
Test: Teach a bootloader how to handle v4 boot image, flash boot &
vendor_boot and boot device
Change-Id: Ibb1bbd7ebe36430c55ec6c4818c1d3888a319089
Not setting TARGET_ARCH is ok if TARGET_ARCH_SUITE is set instead. Skip
certain TARGET_ARCH-specific steps of the config:
- don't run the 'select' steps to figure out cpu flags
- don't generate dexopt config for TARGET_ARCH
Bug: 174315599
Test: lunch <product that sets TARGET_ARCH_SUITE but not TARGET_ARCH>
Change-Id: I74a9e71d0cc5c7f74d3b10b1c8bb89682c096d7c
Add a new TARGET_ARCH_SUITE which, when set to 'mainline_sdk' or 'ndk',
sets `Aml_abis: true` in soong.variables.
This is required to enable removing the custom soong.variables that
are being maintained for the ndk and mainline sdk builds.
Bug: 174315599
Test: TARGET_ARCH_SUITE=mainline-sdk m nothing; inspect soong.variables
(ditto for ndk)
Change-Id: Ib651a637457310270840d721cdccf50bede3ee58
Allows for adding comments between variable definitions. This matches
the style in product.mk
Test: m nothing
Change-Id: Icc1e3d635a885000c49371997a55001739c02587
This allows system-only builds (which disable vendor images) to inherit
from device makefiles that normally place GSI AVB keys on vendor boot.
Bug: 175594737
Test: lunch system-only build, m, observe warning not failure
Change-Id: Ib6c199d0a47b3b3be2143241d83ab586966cfd1e
Raise build error when PRODUCT_ENFORCE_INTER_PARTITION_JAVA_SDK_LIBRARY
is true while BOARD_VNDK_VERSION is not set because
PRODUCT_ENFORCE_INTER_PARTITION_JAVA_SDK_LIBRARY doesn't have any
meaning in that case.
Test: m nothing
Bug: 168180538
Change-Id: Ied2f99763a7cce7674ad50867403a66b18968071
The debug vendor boot image needs to include the debug ramdisk in order
to retain adb root. So make sure this still happens when recovery is
moved to the the vendor boot image.
Bug: 172510680
Test: verify adb root when using vendor_boot-debug.img
Change-Id: I20fe27635dd33e4d8a59e873e704891de223204b
If BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES is defined,
in target files, instead of rebuilding the boot image, copy the boot
image already built in $OUT to target files package directly so that
they are the same package.
Define BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES for aosp_arm64.
The GKI APEX is built using the boot image in $OUT. If the boot image in
$OUT is different from the boot image in target files, aka the generic
boot image we release, the GKI APEX we built is invalid.
If another device needs to copy $OUT/boot.img to target files, it can
define BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES.
Fixes: 172682114
Test: lunch aosp_arm64 &&
Change-Id: I10fc7a5aa36e976dbeaf25434239687455bba061