Android: fix dtbo loading, ramdisk loading, init_boot image and env loading
- Aug 20, 2024
-
-
Mattijs Korpershoek authoredWhen CONFIG_SYS_MMC_ENV_PART=2, the environment is loaded from the USER partition (hwpart=0) instead of from the BOOT1 partition (hwpart=2). IS_ENABLED() cannot be used for non-boolean KConfig options. Its documentation states: > * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y', > * 0 otherwise. So in our case, IS_ENABLED(CONFIG_SYS_MMC_ENV_PART) evaluates to 0. Because of this, the hwpart variable is never assigned and mmc_offset() ends up switching back to the USER hwpart (0) instead of BOOT1 (2). Fix it by using #define instead. Tested with: # have CONFIG_SYS_MMC_ENV_PART=2 in defconfig # 1. Erase mmc0boot1 => mmc dev 0 2 => mmc erase 0 400 => mmc read ${loadaddr} 0 400 => md ${loadaddr} 4 82000000: 00000000 00000000 00000000 00000000 ................ # 2. Restore default environment and save to MMC => env default -a -f => saveenv # 3. Read back mmc0boot1 and confirm the env is present => mmc read ${loadaddr} 0 400 => md ${loadaddr} 4 82000000: 13e0632e 72646461 7469665f 3978303d .c..addr_fit=0x9 Fixes: 5b4acb0f ("env: mmc: Apply GPT only on eMMC user HW partition") Signed-off-by:Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by:
Tom Rini <trini@konsulko.com> (am from https://patchwork.ozlabs.org/patch/1962545/) (also found at https://lore.kernel.org/r/20240719-fix-mmc-env-boot1-v1-1-e32b2037d4d8@baylibre.com)
-
Quote from [1]: "For devices launching with Android 13, the generic ramdisk is removed from the boot image and placed in a separate init_boot image. This change leaves the boot image with only the GKI kernel." While at it, update wrong error handling message when vendor_boot cannot be loaded. [1]: https://source.android.com/docs/core/architecture/partitions/generic-boot Signed-off-by:
Roman Stratiienko <r.stratiienko@gmail.com> Reviewed-by:
-
The boot_ramdisk and vendor_ramdisk must be both concatenated together. Without this change, Android root is missing some of the necessary tools to complete virtual AB OTA. Signed-off-by:
-
Mattijs Korpershoek authored
When booting Android, we observe the following crash: ** Booting bootflow 'mmc@fa10000.bootdev.whole' with android ## Booting Android Image at 0x82000000 ... Kernel load addr 0x92000000 size 20195 KiB Kernel extra command line: console=ttyS2,115200 cma=768M 8250.nr_uarts=10 printk.devkmsg=on init=/init quiet firmware_class.path=/vendor/firmware mem_sleep_default=deep bootconfig RAM disk load addr 0x88080000 size 16901 KiB "Synchronous Abort" handler, esr 0x96000005, far 0x155b104c8 elr: 0000000080808560 lr : 0000000080808558 (reloc) elr: 00000000ffebf560 lr : 00000000ffebf558 x0 : 00000000fff99000 x1 : 00000000fff9553c x2 : 000000000000000a x3 : 0000000002800000 x4 : 0000000002800000 x5 : 0000000000000020 This happens because the memory at fdtoverlay_addr_r is bogus. In fact: => printenv fdtoverlay_addr_r fdtoverlay_addr_r=0x89000000 And the ramdisk address range is: [0x88080000; 0x88080000 + 16901 KiB] Which is equal to: [0x88080000; 0x89101400] So, if we represent the addresses: fdtaddr 0x88000000 ramdisk 0x88080000 fdtoverlay_addr_r 0x89000000 ramisk (end) 0x89101400 We see that fdtoverlay_addr_r in fact has been overridden by the Android ramdisk. The maximum ramdisk size is 0x1080000 (15,5 MiB) and a compressed Android vendor ramdisk is 15MiB: $ file vendor_ramdisk.img vendor_ramdisk.img: LZ4 compressed data (v0.1-v0.9) $ du -sh vendor_ramdisk.img 15M vendor_ramdisk.img When it gets decompressed, it uses 16.5MiB, exceeding the maximum ramdisk size. Increase the maximum ramdisk size to 20.5MiB by moving fdtoverlay_addr_r higher up in the address space to fix the crash. Signed-off-by:
-
