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

[Simon Glass]

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.

Regards,
Simon