[PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros

[Simon Glass]

Hi Alper,

On Sun, 27 Aug 2023 at 09:49, Alper Nebi Yasak <alpernebiyasak at 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 <alpernebiyasak at 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?

BTW, even for the menu, my original vision was that the menu would
display immediately, with new bootflows appearing as they are
discovered.

Regards,
Simon