[BUG] issues with new bootflow, uefi and virtio

[Simon Glass]

Hi Vincent,

On Mon, 24 Apr 2023 at 13:44, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Vincent,
>
> On Tue, 11 Apr 2023 at 06:00, Vincent Stehlé <vincent.stehle at arm.com> wrote:
> >
> > On Fri, Apr 07, 2023 at 05:31:06PM +1200, Simon Glass wrote:
> > ..
> > > > When combined with the patch from Mathew[1], it does indeed repair the case of
> > > > efi boot with two virtio disks, specifically when the first virtio disk is the
> > > > one we want to boot from.
> > > > FWIW, the system will not boot when I invert the two virtio disks.
> > >
> > > Is this because it only uses the first virtio device? You could check
> > > your boot_targets variable. With standard boot you can use 'virtio'
> > > instead of 'vritio0' and it will find any virtio devices.
> >
> > Hi Simon,
> >
> > Thank you for the tips; I did not know that you could use a generic `virtio' or
> > a more specific `virtio0' specification in boot_targets.
> > By default the boot_targets variable does indeed contain the generic `virtio' in
> > my case.
> >
> > Quick tests matrix:
> >
> >                 disk image virtio
> >                 (#num) blk index
> >   boot_targets  (#30) 0  (#31) 1
> >   ------------  -------  -------
> >         virtio     ok      FAIL
> >        virtio0     ok     (fail)
> >        virtio1   (fail)     ok
> >
> > This is with both patches, on Qemu.
> > The fails between () are expected.
> >
> > I find it interesting that specifying `virtio1' does work when the bootable
> > image is on the second virtio disk, while auto-detection with `virtio' does not
> > seem to:
> >
> >   virtio1
> >   ~~~~~~~
> >
> >   => setenv boot_targets virtio1
> >   => boot
> >   Scanning for bootflows in all bootdevs
> >   Seq Method State Uclass Part Name Filename
> >   --- ------ ----- ------ ---- ---- --------
> >   Scanning global bootmeth 'efi_mgr':
> >   Scanning bootdev 'virtio-blk#31.bootdev':
> >     0 efi    ready virtio    1 virtio-blk#31.bootdev.par efi/boot/bootaa64.efi
> >   ** Booting bootflow 'virtio-blk#31.bootdev.part_1' with efi
> >   Using prior-stage device tree
> >   Missing TPMv2 device for EFI_TCG_PROTOCOL
> >   Booting /efi\boot\bootaa64.efi
> >
> >   virtio
> >   ~~~~~~
> >
> >   => setenv boot_targets virtio
> >   => boot
> >   Scanning for bootflows in all bootdevs
> >   Seq Method State Uclass Part Name Filename
> >   --- ------ ----- ------ ---- ---- --------
> >   Scanning global bootmeth 'efi_mgr':
> >   Scanning bootdev 'virtio-blk#30.bootdev':
> >   No more bootdevs
> >   --- ------ ----- ------ ---- ---- --------
> >   (0 bootflows, 0 valid)
> >
> > The messages seem to indicate that virtio #31 / 1 was not even considered when
> > specifying `virtio'.
> > (Note that I have edited the logs a bit to avoid wrapping lines.)
>
> Hmm I noticed the 'bootflow scan virtio' problem as well but haven't
> got back to it. Thanks for the detailed bug report.
>
> I will take a look soon.

I believe the problem is actually that it is running out of memory. I
sent a patch to allow this to be reported properly (with bootflow scan
-lae).

The .efi files are quite large so loading them when scanning is
probably not a good idea. I will have a rethink of this and see if I
can implement lazy loading. It doesn't matter for the simple case
where we boot the first thing we find, but it would make 'bootflow
scan' more reliable when memory is short and the files are large. It
would also fit better into U-Boot's 'lazy init' philosophy.

Regards,
Simon