Trim the boot menu to a useful set, and add Android dual-boot #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The menu has grown to ~17 entries from bring-up experiments. Cut it back to what is actually used, and add Android as a real target.
Target menu
Trimming also fixes a real usability bug: the menu has no wrap-around and
bootmenu_defaultis 16, so with vol-up flaky it was impossible to reach the low-numbered entries by hand. A short list makes that moot.Keep the existing invariant in mind:
bootmenu_16must mirrorbootcmd(the env file's own comment warns about this, and forgetting it cost a debugging cycle when the one-shotbootonceprotocol silently didn't run).Android dual-boot
Better supported than expected — two pieces are already compiled in:
CONFIG_ANDROID_BOOT_IMAGE=y— U-Boot can boot an Android boot image directly. Combined with ext4 support, the image can simply live at/boot/android-boot.imginside the Linux rootfs, which answers "where do we store it" without repartitioning or touching sboot's view of the GPT.CONFIG_SAVE_PREV_BL_FDT_ADDR=y— U-Boot saves the FDT that ABL handed it into the env varprevbl_fdt_addr(set inarch/arm/lib/save_prev_bl_data.c). ABL's/chosen/bootargscarries theandroidboot.*parameters Android needs (serialno, bootdevice, verifiedbootstate, …).So cmdline forwarding is:
then boot the Android image. Worth dumping
${prevbl_fdt_addr}'s/chosenon the real device first to confirm what ABL actually passes us.Notes
CONFIG_CMD_ABOOTIMGis not enabled;ANDROID_BOOT_IMAGEmay be sufficient viabootm, otherwise enable it.ramdisk=0, so it needs a validsystempartition — dual-boot only makes sense once stock is flashed.sda20and a bad env has already bricked booting twice (recovery was deletinguboot.env, then repairing vars from TWRP).