On 2023-08-28 20:54 +03:00, Simon Glass wrote: > Hi Alper, > > On Sun, 27 Aug 2023 at 09:49, Alper Nebi Yasak <alpernebiya...@gmail.com> > wrote: >> >> On 2023-08-15 01:43 +03:00, Simon Glass wrote: >>> Hi Alper, >>> >>> On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiya...@gmail.com> >>> 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? > > We sort-of have that, in that bootdevs have a priority. We could add > something to struct bootflow which takes that but adds more > fine-grained information, e.g. based on some sort of filter function > that can decide? > > Bear in mind that we normally want to boot the first thing we find, > and we also want to use lazy init (so no USB unless we need it). But > yes for the case where we display a menu I think we could make more of > the priority feature. What are you thinking of?
For the priorities, I'm thinking of ChromiumOS boot flow where there is an in-method order that's different from the order we encounter things in. And I'm also thinking of customizing boot order for same-uclass device (I guess boot_targets="usb1 usb0" works?). And a bit worried about if we would want to mix and match orders. If we say methA > methB and dev0 > dev1, do we say methA-on-dev1 > methB-on-dev0 or the other way? Not sure if I make sense here at all, need to think more on it. In general, what I want is a graphical boot menu like rEFInd [1], but more specifically with a better theme more like [2]. Or, at least to support rEFInd better. (More bugs here, upstream builds don't start at all with U-Boot, Debian builds boot on arm64 but not x86). Regarding lazy init. If we don't init USB, rEFInd can't search USB drives to boot things from it. Not sure if that's a fundamental problem or there's some way for EFI apps to tell firmware to init USB etc. [1] https://www.rodsbooks.com/refind/ [2] https://github.com/bobafetthotmail/refind-theme-regular > BTW, even for the menu, my original vision was that the menu would > display immediately, with new bootflows appearing as they are > discovered. Shifting list elements around while people are choosing from the list is definitely not good, only way that could be OK is if the list was append-only and not centered-in-append-direction. We should be displaying a priority-sorted list, I'm not sure we can guarantee we will add things in priority order, and I would like things centered as personal preference...
