On 2023-08-15 01:43 +03:00, Simon Glass wrote: > Hi Alper, > > On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <[email protected]> > wrote: >> I actually want to put the root.img device first so that the VM can boot >> into the installed system when it reboots, but U-Boot can't find the >> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow >> scan -lab`, but it seems to only ever search the first virtio-blk. >> However, `eficonfig; bootefi bootmgr` makes it boot somehow. > > Yes, this is annoying. > > The problem is that the scanning is getting so complicated. The > boot_targets var lists things which can either be a uclass, or a > uclass with a device number. The currently implementation sees > "virtio" and moves on to the next thing in boot_targets once it has > processed one virtio device. That is obviously not correct, but... > > Would it be possible to just drop the 'boot_targets' var? That is what > is stuffing it up, but we don't actually need it now. The defaults end > up doing the same thing, apart (perhaps) from the strangeness of > virtio which can be both a network and a blk device. > > I believe it is possible to do the right thing, but I'll need to > create a better test mechanism to handle all the cases.
I think some kind of a "priority score" could help -- iterate over boot_targets first just to generate bootdev priorities, then carry them over as bootflows are discovered (adjusted for bootmeth order), then use those scores as the order to boot / to show a sorted menu / to test?
