All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vincent Stehlé" <vincent.stehle@arm.com>
To: Simon Glass <sjg@chromium.org>
Cc: u-boot@lists.denx.de
Subject: Re: [BUG] issues with new bootflow, uefi and virtio
Date: Tue, 11 Apr 2023 14:00:24 +0200	[thread overview]
Message-ID: <ZDVL2Ac7uz19ARzl@debian> (raw)
In-Reply-To: <CAPnjgZ2FkU_wKLd1djMdArvqPaX3-jvA=p-ZHbhnKgSpx+KULw@mail.gmail.com>

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.)

Best regards,
Vincent.

> 
> >
> > Best regards,
> > Vincent.
> >
> > [1]: https://lists.denx.de/pipermail/u-boot/2023-April/514527.html
> 
> Regards,
> Simon

  reply	other threads:[~2023-04-11 12:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 15:04 [BUG] issues with new bootflow, uefi and virtio Vincent Stehlé
2023-04-05 18:38 ` Simon Glass
2023-04-06 10:05   ` Vincent Stehlé
2023-04-07  5:31     ` Simon Glass
2023-04-11 12:00       ` Vincent Stehlé [this message]
2023-04-24 19:44         ` Simon Glass
2023-05-10 14:35           ` Simon Glass
2023-09-23 19:53         ` Simon Glass
2023-04-06  0:25 ` Mathew McBride
2023-04-06  9:53   ` Vincent Stehlé
2023-04-07  5:30   ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZDVL2Ac7uz19ARzl@debian \
    --to=vincent.stehle@arm.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.