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

[Simon Glass]

Hi Alper,

On Thu, 31 Aug 2023 at 03:57, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>
> On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> > 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?
>
> 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

Yes

> 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.

I hope not, but at least we have the data structures now and can do
these sorts of things.

>
> 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).

Could you implement that as a theme on the existing 'bootflow menu'?
It looks like you might be able to.

>
> 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.

EFI sort-of has a fundamental problem here, I believe.

>
> [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...

Yes that is annoying, but all UIs do it these days. It is better to
display something, even if you have to move an existing thing. Two
other points:

1. The good news is that you are almost always adding at the end
2. This is often using the keyboard, so you can move the highlight
when you insert an earlier item

Regards,
Simon