Trim the boot menu to a useful set, and add Android dual-boot #3

Open
opened 2026-08-22 14:55:03 +00:00 by kit · 0 comments
Owner

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

  1. Boot Linux
  2. Boot from SD card
  3. Fastboot
  4. USB serial console
  5. Shell
  6. Reboot to recovery (TWRP)
  7. Reboot normally

Trimming also fixes a real usability bug: the menu has no wrap-around and bootmenu_default is 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_16 must mirror bootcmd (the env file's own comment warns about this, and forgetting it cost a debugging cycle when the one-shot bootonce protocol 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.img inside 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 var prevbl_fdt_addr (set in arch/arm/lib/save_prev_bl_data.c). ABL's /chosen/bootargs carries the androidboot.* parameters Android needs (serialno, bootdevice, verifiedbootstate, …).

So cmdline forwarding is:

fdt addr ${prevbl_fdt_addr}
fdt get value abl_args /chosen bootargs
setenv bootargs ${abl_args}

then boot the Android image. Worth dumping ${prevbl_fdt_addr}'s /chosen on the real device first to confirm what ABL actually passes us.

Notes

  • CONFIG_CMD_ABOOTIMG is not enabled; ANDROID_BOOT_IMAGE may be sufficient via bootm, otherwise enable it.
  • Android on this device is system-as-root with ramdisk=0, so it needs a valid system partition — dual-boot only makes sense once stock is flashed.
  • Do this work with the serial console reachable, since it reflashes sda20 and a bad env has already bricked booting twice (recovery was deleting uboot.env, then repairing vars from TWRP).
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 1. Boot Linux 2. Boot from SD card 3. Fastboot 4. USB serial console 5. Shell 6. Reboot to recovery (TWRP) 7. Reboot normally Trimming also fixes a real usability bug: the menu has **no wrap-around** and `bootmenu_default` is 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_16` must mirror `bootcmd`** (the env file's own comment warns about this, and forgetting it cost a debugging cycle when the one-shot `bootonce` protocol 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.img` **inside 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 var **`prevbl_fdt_addr`** (set in `arch/arm/lib/save_prev_bl_data.c`). ABL's `/chosen/bootargs` carries the `androidboot.*` parameters Android needs (serialno, bootdevice, verifiedbootstate, …). So cmdline forwarding is: ``` fdt addr ${prevbl_fdt_addr} fdt get value abl_args /chosen bootargs setenv bootargs ${abl_args} ``` then boot the Android image. Worth dumping `${prevbl_fdt_addr}`'s `/chosen` on the real device first to confirm what ABL actually passes us. ## Notes - `CONFIG_CMD_ABOOTIMG` is **not** enabled; `ANDROID_BOOT_IMAGE` may be sufficient via `bootm`, otherwise enable it. - Android on this device is system-as-root with `ramdisk=0`, so it needs a valid `system` partition — dual-boot only makes sense once stock is flashed. - Do this work with the **serial console reachable**, since it reflashes `sda20` and a bad env has already bricked booting twice (recovery was deleting `uboot.env`, then repairing vars from TWRP).
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kit/u-boot-gts6l#3
No description provided.