Hi Vincent, On Tue, 11 Apr 2023 at 06:00, Vincent Stehlé <vincent.ste...@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
