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-aurel...@aurel32.net/
I think there's room for improvement on top of https://patchwork.ozlabs.org/project/uboot/patch/20230108025047.522240-71-...@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
signature.asc
Description: PGP signature
