* This is equivalent to building with --flags 1, which just
disables hashtree verification. This is enough for the bootloader
to pass "androidboot.vbmeta.device_state=unlocked androidboot.veritymode=disabled"
in the kernel command line, which is what we wanted this entire time.
* As explained in an earlier commit, any image with flags 3 will cause
the bootloader to totally break, which is why we must use flags 1
instead. Besides, flags 1 does exactly what we want it to now.
* PS: MediaTek fix your stupid bootloader
Change-Id: I7b9e5f7181f1b861bb416329ad90725fd6ec2c39
Signed-off-by: bengris32 <bengris32@protonmail.ch>
Signed-off-by: dodyirawan85 <40514988+dodyirawan85@users.noreply.github.com>
* We have a very, very broken bootloader. LK is extremely
fussy about our AVB setup, and if either --flags 3 is set
(hashtree verification disabled), or the wrong AVB algorithm
is used, it will cause the bootloader to crash shortly after
loading the boot image, which can be seen from the bootloader logs:
* [1111] [avb] img_auth_required = 0
[1116] invalid pubk size
[1116] avb_slot_verify.c[1116] :[1116] 851[1116] : ERROR: [1116] vbmeta_a[1116] : Public key used to sign data rejected.
[1370] [AVB20] malloc: heap size not enough
[1370] avb_util.c[1370] :[1370] 224[1370] : ERROR: [1370] Failed to allocate memory.
[1370] [avb] boot/recovery vfy time = 270 ms
[1370] mblock_create mblock start: 0xb0c00000 size: 0x8c00000 name: avb
[1371] [avb] avb_ret = 1
[1371] [avb] ret = 0
[6694] panic (caller 0x4822b7f1): ASSERT at (platform/common/boot/boot_info.c:616): g_boot_info.hdr_loaded
* Re-enable hashtree verification and match the AVB algorithm
with what MediaTek does on stock. Also create vbmeta images
for system, product and vendor partitions since that is done
as well. Use test keys for signing to make our lives easier.
* Also change BOARD_AVB_RECOVERY* to BOARD_AVB_BOOT*, AVB
recovery flags are no-ops on A/B devices since the recovery
ramdisk is in the boot image, so we should be enabling
chained vbmeta for boot instead.
Change-Id: I66c03f819178d00db956095e835e8e304ab1aab7
Signed-off-by: bengris32 <bengris32@protonmail.ch>
Signed-off-by: dodyirawan85 <40514988+dodyirawan85@users.noreply.github.com>
* vendor_dlkm contains kernel modules that were previously located to
/vendor/lib/modules and is updatable separately, making us able to
test kernel modifications faster
* Reference: https://source.android.com/docs/core/architecture/partitions/vendor-odm-dlkm-partition
Signed-off-by: Woomymy <woomy@woomy.be>
Change-Id: I38f5989d4e5a52bf295add8099f6bf6cb8ea3288
Signed-off-by: dodyirawan85 <40514988+dodyirawan85@users.noreply.github.com>
* BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD should contain the
list of modules loaded with the recovery, but the modules should be
installed using BOARD_VENDOR_RAMDISK_KERNEL_MODULES
Signed-off-by: Woomymy <woomy@woomy.be>
Change-Id: I72768f8325017e0f5b969a7eb03ccccbf4b7eae0
Signed-off-by: dodyirawan85 <40514988+dodyirawan85@users.noreply.github.com>
* Kernel is built separatly and placed in device/infinix/X6833B-kernel
Co-authored-by: Woomymy <woomy@woomy.be>
Signed-off-by: dodyirawan85 <40514988+dodyirawan85@users.noreply.github.com>
