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

[Alper Nebi Yasak]

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