When building vendor_boot v4 with multiple vendor ramdisks, pass the
name of each ramdisk to mkbootimg.
Bug: 177882072
Test: Modify a device BoardConfig and verify the built vendor_boot.img
with unpack_bootimg
Change-Id: I679d277aa88f1e10678d2f74b579e4140536e267
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
* Prerequisites: external/f2fs-tools: sload compression support
* Must work with corresponding changes in system/extras repository
* If Board config does not change, it falls back to old behavior,
i.e. no compression for the system partition
* Kernel f2fs compression support is a prerequisite if the Board config
enables the compression (see below)
* Necessary board config change
(e.g. device/<vendor>/<product>/BoardConfig-common.mk)
BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE := f2fs
BOARD_SYSTEMIMAGE_PARTITION_RESERVED_SIZE := 200000000
BOARD_SYSTEMIMAGE_FILE_SYSTEM_COMPRESS := true
BOARD_SYSTEMIMAGE_F2FS_SLOAD_COMPRESS_FLAGS := <sload compress sub-options>
Setting BOARD_SYSTEMIMAGE_FILE_SYSTEM_COMPRESS to true enables both the
compression support when the initial empty file system be made (mkfs.f2fs)
and the compression flag (-c) when the system image files be side-loaded
by sload.
Sload compress sub-options (i.e. options other than -c) will be provided
by BOARD_SYSTEMIMAGE_F2FS_SLOAD_COMPRESS_FLAGS. If it is not given, or
is empty, the default sub-options will be used
Please refer to the sload.f2fs manual page.
Setting BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE to f2fs is trivially necessary.
* File system table (fstab), notably the file 'fstab.hardware', should
also changed:
- The file type must be changed to f2fs
- Perhaps also other f2fs-specific options
Bug: 170918499
Test: Pixel4a userdebug build (from build id 6918751)
Signed-off-by: Robin Hsu <robinhsu@google.com>
Change-Id: Id9d67b5cb35dc806e06ff1320e89114abc996a28
It was in the middle of some other logic in main.mk
Put it in Makefile instead next to the other "information" dist txt
files.
Test: make and diff certificate_violation_modules.txt
Change-Id: I5b73a0f89ccf3de69e7608a0568d2b4b6f37e98c
Protected KVM relies on protected VM firmware (pvmfw) to bootstrap the
trust in protected VMs. This firmware is AVB protected and stored in the
pvmfw partition.
Test: build a target with BOARD_PREBUILT_PVMFWIMAGE set, saw the image
included in the product files and used avbtool to check the footer
and vbmeta.img details.
Bug: 171280178
Change-Id: I4d6a1819f307c77ca60c0dd3dff39ee28cece4f6
This is needed after
commit 21c34f78e8
which starts calling host_init_verifier in merge_target_files,
a binary in releasetools.
Test: m otatools
Change-Id: Iee762de9fd6f890b5cc26ee5507da2f3f284fc14
Files are copied into the recovery installation directory by a rule
that runs rsync. The previous logic tried to avoid racing with the
rsync rule by depending on the final packaged recovery image, but
if BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is set then
INSTALLED_RECOVERYIMAGE_TARGET is left empty and no dependency was
added. Depend on the timestamp file used as the output of the rule
that runs rsync instead.
Test: query dependencies of installed-files-recovery.txt
Fixes: 173772240
Change-Id: I5ec77a6933e3a83fe4e4819e0e246017d824d8a5
List of stub libraries from system (and bionic APEX) is currently
managed in static file. This change generates the list at build time and
adds to the system config so linkerconfig can use it.
Bug: 172889962
Test: Build cuttlefish and confirmed list is generated in
/system/etc/linker.config.pb
Change-Id: Idd5a93442f398dd8e88c767c694ddae64d1bb713
Add installed-files-vendor-ramdisk.txt build artifact, so that it is
easy to see what files landed on the vendor ramdisk.
Test: clean build, inspect installed-files-vendor-ramdisk.txt
Change-Id: Ie84d06dc968ad972ab2bfa79db4d1839ba09e09f
check_vintf now accepts a file that contains the full kernel
release string as the first half of --kernel. Use it.
With this patch, BOARD_KERNEL_VERSION can be a full kernel release
string like 5.4.42-something, or 5.4.42-android12-0-something.
The content of target_files/META/kernel_version.txt also contains the
full kernel release, not just the kernel version.
Bug: 161317193
Test: m check-vintf-all
Change-Id: I3b52639f557532077894d9356c745c16b41dd91c
check_vintf now accept a path to a file that contains the kernel
version string. Use it.
Test: m check-vintf-all and manual inspect
Bug: 161317193
Change-Id: I4812c93f352686d73c5832d59e43a297d93e67a2
Currently we support skip building vbmeta.img when
PRODUCT_BUILD_VBMETA_IMAGE is set to false, which is used
when generating a system-only or vendor-only build artifacts.
However, when using `make dist` to build target files,
vbmeta.img is still generated. This change fixes this by
passing the related info to misc_info.txt for the release
tool to skip building vbmeta.img when necessary.
To make this happen, a device config should:
1. Set PRODUCT_BUILD_VBMETA_IMAGE := false
2. Remove 'vbmeta' from AB_OTA_PARTITIONS:
AB_OTA_PARTITIONS += \
boot \
system \
- vbmeta \
dtbo \
product \
system_ext \
vbmeta_system
Bug: 161659370
Test: `make dist` and checks the target file does not include vbmeta.img
Change-Id: Iddca9fe0b171a50a80e5a88aa462e118f18a7e6f
This reverts commit 78b55b2244.
Reason for revert: Replaced by Ib99aca13d4d:
ANDROID: GKI: build in a kernel command line of "rw"
Prebuilt is checked in at Ie34b5b017:
Update kernel to builds 6964541
Fixes: 171512004
Test: TH
Change-Id: I2aec88cc22483a6b3a671fc664d465624a14e5b0
Cuttlefish doesn't support updating the vendor partition. So we change
ota_from_target_files to only generate updates for partitions in
BOARD_PARTIAL_OTA_UPDATE_PARTITIONS_LIST. This CL puts the prop in
misc_info.txt, which will be read by ota scrips
Bug: 171999375
Test: mm -j
Change-Id: I4d9c97c717cb73806f95684b3bc81ef285ccbb8b
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
Add phony target check-elf-prebuilt-product-copy-files that asserts
PRODUCT_COPY_FILES doesn't have ELF prebuilts.
This helps triage PCF ELF errors by providing a convenient target to
check / list all errors.
Bug: 140560012
Bug: 156534160
Test: lunch aosp_cf_x86_phone
Test: m USE_NDK_TRANSLATION_BINARY=true \
check-elf-prebuilt-product-copy-files -k
Change-Id: Ic7fa43c10b0c30b3b1d9b7c2fae75cc6ea4a3513
* changes:
Mount generic ramdisk as readwrite.
Do not put GENERIC_KERNEL_CMDLINE in recovery image.
Move common code out of the conditional.
Remove device-specific bits if recovery_as_boot
Do not assume GKI just with vendor_boot.
With this change, first stage init can prepare and move
resources to accomodate devices with and without a dedicated
recovery partition.
Test: build with and without recovery partition, and manually inspect
Bug: 171512004
Change-Id: I7bd61f74c16ee77f3f05dc208e0f3cfe81e302b0
The GENERIC_KERNEL_CMDLINE should only be in the generic boot image.
If device uses recovery-as-boot, it never uses generic boot image
because on devices with generic boot image, recovery resources are
moved to vendor_boot instead.
Bug: 171512004
Test: builds
Change-Id: Ia84e604a8ded28af39c7f1861ff5d3b3af55849f
On legacy devices (launched with R and below), if device:
- has a vendor_boot partition, and
- uses recovery_as_boot
Then, when building the recovery/boot partition, the
device-specific bits, including dtb/kernel base/pagesize should
be moved to vendor_boot.
Previously, it is incorrectly assumed that A/B => recovery_as_boot.
In reality, we do have A/B devices with a dedicated recovery partition.
Note that for devices that uses GKI (BOARD_USES_GENERIC_KERNEL_IMAGE),
recovery_as_boot is never set to true. Instead, recovery resources
are moved to vendor_boot. On these devices, the conditional
'vendor_boot && recovery-as-boot' is always false. Hence:
- If the device has a dedicated recovery partition, it should use V3 header,
and dtb/base/pagesize won't be in recovery header.
- If device does not have a dedicated recovery partition, the recovery
image won't be built.
Test: builds
Change-Id: I0db2af20470cbe8a21044a984cccf264590aaccf
This change ensures changes to GENERIC_KERNEL_CMDLINE only affects
devices that explicitly says it uses GKI/generic boot image.
In details, if the device has vendor_boot, but does not explicitly
specify that it uses GKI/generic boot image, do not include
GENERIC_KERNEL_CMDLINE in boot. boot cmdline is left empty
in this case.
The old logic:
- If device uses GKI *OR* has vendor_boot:
boot uses GENERIC_KERNEL_CMDLINE, and do not include kernel base
and pagesize.
- If device has vendor_boot, INTERNAL_KERNEL_CMDLINE, kernel base
and pagesize goes in vendor_boot.
- If device does not use GKI nor have vendor_boot:
boot uses INTERNAL_KERNEL_CMDLINE, and includes kernel base and
pagesize.
The new logic:
- If using GKI, boot uses GENERIC_KERNEL_CMDLINE. Remove kernel base
and pagesize because they are device-specific.
- If not using GKI:
- If building vendor_boot, INTERNAL_KERNEL_CMDLINE, base and
pagesize goes in vendor_boot; boot does not have cmdline, base or
pagesize.
- Otherwise, put them in boot
Comparison of the code before and after:
- If device uses GKI,
- For boot partition:
- cmdline continues to be GENERIC_KERNEL_CMDLINE
- kernel base and pagesize continues to be excluded
- For vendor_boot partition:
- cmdline continues to be INTERNAL_KERNEL_CMDLINE
- kernel base and pagesize continues to be included
- If device does not use GKI:
- If device has a vendor_boot partition:
- For boot partition:
* cmdline changes from GENERIC_KERNEL_CMDLINE to empty
- kernel base and pagesize continues to be excluded
- For vendor_boot partition:
- cmdline continues to be INTERNAL_KERNEL_CMDLINE
- kernel base and pagesize continues to be included
- If device does not have a vendor_boot partition:
- For boot partition:
- cmdline continues to be INTERNAL_KERNEL_CMDLINE
- kernel base and pagesize continues to be included
Test: builds
Bug: 171512004
Change-Id: I4feac435698f43ac299b430bff66147057865a62
Many partners have asked for platform support of system-only update.
So we config cuttlefish as an example to support the partial ota
updates. Also make such package available on the build server.
This allows continuous test to ensure the e2e update flow is working.
Bug: 170921953
Test: generate & apply a partial update, check output in presubmit
Change-Id: I79d0abeb1b2be18e6ff88f0455b6de6540a37794
If recovery resources are moved to vendor_boot, it also means
there's no recovery image to install. Don't build
recovery-resource.dat in this case.
Test: builds with cuttlefish with GKI
Bug: 156098440
Change-Id: I86db08d2dede6af644afadac54ff8beb853f4933
This reverts commit 8197702d73.
Test: lunch cf_x86_auto && m check-vintf-all
Reason for revert: auto targets fixed in the same topic
Change-Id: I193416a4d0718e5790eb54e5c0674edc2d975632
