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

[Alper Nebi Yasak]

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?