[BUG] issues with new bootflow, uefi and virtio

[Simon Glass]

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.

Regards,
Simon