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 mmc2to 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 spiDoes 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-sj... 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.