On Fri, Jan 13, 2023 at 9:05 PM Simon Glass <s...@chromium.org> wrote: > > Hi Mark, Heinrich, > > On Fri, 13 Jan 2023 at 13:32, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > > Date: Fri, 13 Jan 2023 20:54:06 +0100 > > > From: Heinrich Schuchardt <xypron.g...@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-aurel...@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.