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

[Ilias Apalodimas]

Hi Alper,

On Sun, 27 Aug 2023 at 18: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.

eficonfig, apart from displaying the boot options on a menu scans all
media that have a simple filesystem protocol installed and configures
the efi boot options.  That's why bootefi bootmgr boots properly
afterwards.  You can probably boot even without eficonfig, but only
bootXXX.efi files will be accounted for and no boot options will be
added.

The EFI spec describes the bootmgr functionality in detail.  Back when
the bootmeth patches were added, I suggested we shouldn't deal with
EFI at all simply because it all already works and is backed by a
spec.  Instead, we should just have a boot option in the methods that
spells "EFI" and let the bootmanager deal with the details. But
honestly, I've lost track of those patches.

Thanks
/Ilias
> >
> > 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?