Re: [PATCH v5 00/17] enable menu-driven boot device selection

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Masahisa Kojima <masahisa.kojima@linaro.org>
> Date: Thu, 28 Apr 2022 17:09:33 +0900
> 
> This patch series adds the menu-driven boot device selection,
> by extending the existing "bootmenu" to include UEFI and distro_boot
> related entries, and supports menu-driven UEFI boot variable
> maintenance.
> 
> This patch series also includes the removable media support
> that UEFI specification requires to support.
> 
> The menu example is as follows.
> 
>   *** U-Boot Boot Menu ***
> 
>      bootmenu_00   : Boot 1. kernel
>      bootmenu_01   : Boot 2. kernel
>      bootmenu_02   : Reset board
>      UEFI BOOT0000 : debian
>      UEFI BOOT0001 : ubuntu
>      UEFI BOOT0002 : mmc0:1
>      UEFI BOOT0003 : mmc0:2
>      UEFI BOOT0004 : nvme0:1
>      UEFI BOOT0005 : nvme0:2
>      UEFI BOOT0006 : usb0:2
>      UEFI BOOT0007 : usb1:1
>      UEFI BOOT0008 : usb1:2
>      distro_boot   : usb0
>      distro_boot   : scsi0
>      distro_boot   : virtio0
>      distro_boot   : dhcp
> 
>   Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit
> 
> [How to run on QEMU(arm64)]
> 1) clone source code
>  $ git clone https://git.linaro.org/people/masahisa.kojima/u-boot.git \
> -b kojima/bootmenu_v5_upstream_0428 --depth 1
> 
> 2) prepare U-Boot .config
>  $ make qemu_arm64_menuconfig
>   then, enable CONFIG_CMD_BOOTMENU and CONFIG_AUTOBOOT_MENU_SHOW

So when I do this on a Apple M1 system it ends up doing something
weird.  With CONFIG_AUTOBOOT_MENU_SHOW=y, it shows the boot menu and
then automaticaly selects the "UEFI Boot Manager Maintenance" option
after the boot delay expires.  That is a bit weird.  Initially I
expected it to fall through into the normal distro_bootcmd script by
executing bootcmd.

Now this happens because NVMe isn't probed automatically.  So no
viable boot options are found.  But distro_boot explicitly probes NVMe
if CONFIG_NVME is enabled (see include/config_distro_bootcmd.h).  So
falling through into the distro boot would actually have worked.

Another surprise is that the default boot order seems to depend on the
order in which devices are probed.  With:

  CONFIG_PREBOOT="nvme scan; usb start"

it boots from NVMe by default, and with:

  CONFIG_PREBOOT="usb start; nvme scan"

it boots from USB by default, despite the fact that in
include/configs/apple.h I have:

  #define BOOT_TARGET_DEVICES(func) \
          BOOT_TARGET_NVME(func) \
	  BOOT_TARGET_USB(func)

If I change the boot order through the "UEFI Boot Manager Maintenance"
option, it seems that the new boot order only persists if I actually
boot into the OS.  When I reset the board before doing that it keeps
the old boot order.

Last but not least, it seems that
CONFIG_CMD_BOOTMENU_ENTER_UBOOT_CONSOLE is disabled by default despite
the fact that doc/usage/cmd/bootmenu.rst suggests the opposite.  I
think the default for that option should be "y" otherwise I fear a lot
of boards will end up with shipping with a U-Boot with no way for
users to get at the u-boot prompt.

All in all, I don't think any of this is a show-stopper.  It just
needs some further polishing, which probably is best done after this
lands (except for the CMD_BOOTMENU_ENTER_UBOOT_CONSOLE thing).  It
does make it possible for me to use the EFI bootmgr on Apple M1
systems and it definitely improves the user interface for naive users.