[BUG] issues with new bootflow, uefi and virtio
Simon Glass
sjg at chromium.org
Sat Sep 23 21:53:26 CEST 2023
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.)
>
Apart from the out-of-memory problem that has been fixed, there is
another problem that it only looks at the first of the virtio devices
when boot_targets="virtio", as you have found.
I believe I have a fix for this so will send a patch.
Thank you for testing this.
Regards,
Simon
> Best regards,
> Vincent.
>
> >
> > >
> > > Best regards,
> > > Vincent.
> > >
> > > [1]: https://lists.denx.de/pipermail/u-boot/2023-April/514527.html
> >
> > Regards,
> > Simon
More information about the U-Boot
mailing list