[PATCH v2 00/71] bootstd: Allow migration from distro_bootcmd scripts

[Peter Robinson]

On Fri, Jan 13, 2023 at 9:05 PM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Mark, Heinrich,
>
> On Fri, 13 Jan 2023 at 13:32, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> >
> > > Date: Fri, 13 Jan 2023 20:54:06 +0100
> > > From: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > >
> > > On 1/8/23 03:49, Simon Glass wrote:
> > > > So far, standard boot does not replicate all the of the functionality
> > > > of the distro_bootcmd scripts. In particular it lacks some bootdevs and
> > > > some of the bootmeths are incomplete.
> > > >
> > > > Also there is currently no internal mechanism to enumerate buses in order
> > > > to discover bootdevs, e.g. with USB.
> > > >
> > > > This series addresses these shortcomings:
> > > >
> > > > - Adds the concept of a 'bootdev hunter' to enumerate buses, etc. in an
> > > >    effort to find bootdevs of a certain priority
> > > > - Adds bootdevs for SCSI, IDE, NVMe, virtio, SPI flash
> > > > - Handles PXE and DHCP properly
> > > > - Supports reading the device tree with EFI and reading scripts from the
> > > >    network
> > > >
> > > > It also tidies up label processing, so it is possible to use:
> > > >
> > > >     bootflow scan mmc2
> > > >
> > > > to scan just one MMC device (with BOOTSTD_FULL).
> > > >
> > > > As before this implementation still relies on CONFIG_CMDLINE being
> > > > enabled, mostly for the network stack. Further work would be required to
> > > > disentangle that.
> > > >
> > > > Quite a few tests are added but there are some gaps:
> > > >
> > > > - SPI flash bootdev
> > > > - EFI FDT loading
> > > >
> > > > Note that SATA works via SCSI (CONFIG_SCSI_AHCI) and does not use
> > > > driver model. Only pogo_v4 seems to be affected. Probably all thats is
> > > > needed is to call bootdev_setup_sibling_blk() in the Marvell SATA driver.
> > > >
> > > > Also, while it would be possible to init MMC in a bootdev hunter, there is
> > > > no point since U-Boot always inits MMC on startup, if present.
> > > >
> > > > With this series it should be possible to migrate boards to standard boot
> > > > by removing the inclusion of config_distro_bootcmd.h and instead adding
> > > > a suitable value for boot_targets to the environment, e.g.:
> > > >
> > > >     boot_targets=mmc1 mmc0 nvme scsi usb pxe dhcp spi
> > >
> > > Does nvme mean all nvme drives? Would mmc mean all mmc block devices?
> > >
>
> Yes it means to scan all. It is controlled by flags:
>
>  * @BOOTFLOWF_SINGLE_UCLASS: (internal) Keep scanning through all devices in
>  * this uclass (used with things like "mmc")
>  * @BOOTFLOWF_SINGLE_MEDIA: (internal) Scan one media device in the uclass (used
>  * with things like "mmc1")
>
> > > doc/develop/bootstd.rst should describe the syntax.
> > >
> > > On generic boards it does not make much sense to restrict scanning to
> > > one instance of a block device type.
> > >
> > > Cf.
> > > [PATCH] board: sifive: unmatched: enable booting on a second NVME device
> > > https://lore.kernel.org/all/20230107223239.2387940-1-aurelien@aurel32.net/
> >
> > But it would still make sense to be able to specify the order in which
> > those instances are scanned.
>
> I hope that the internal/external stuff will help with this, at least
> to provide a sensible default, e.g. we normally scan internal mmc
> before external SD card. But that is not yet fully implemented.

I would have thought you'd scan external first as you might have a
situation where you want to boot off external as a priority if say the
internal boot was broken.