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

[Tom Rini]

On Fri, Jan 13, 2023 at 08:54:06PM +0100, Heinrich Schuchardt wrote:
> 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?
> 
> 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/

I think there's room for improvement on top of
https://patchwork.ozlabs.org/project/uboot/patch/20230108025047.522240-71-sjg@chromium.org/
with more examples / documentation on how to handle a storage type which
can have more than one location. But since this leverages DM, it's not
restricted to a single NVMe, since our uclass isn't restricted to a
single NVMe.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230113/de79a0f9/attachment.sig>