From: "Mathew McBride" <matt@traverse.com.au>
To: "Vincent Stehlé" <vincent.stehle@arm.com>, u-boot@lists.denx.de
Cc: "Simon Glass" <sjg@chromium.org>
Subject: Re: [BUG] issues with new bootflow, uefi and virtio
Date: Thu, 06 Apr 2023 10:25:15 +1000 [thread overview]
Message-ID: <fa967aab-83bb-4116-b405-bbfe74690add@app.fastmail.com> (raw)
In-Reply-To: <20230405150458.890460-1-vincent.stehle@arm.com>
Hi Vincent,
On Thu, Apr 6, 2023, at 1:04 AM, Vincent Stehlé wrote:
> Hi,
>
> I am hitting an issue with the new bootflow when booting with UEFI from a
> virtio device on Qemu Arm.
>
> It seems the device number computation in efiload_read_file() does not work
> in the general virtio case, where it will pick the virtio device number
> instead of the block device index. On Qemu arm virt machine, many virtio
> mmio devices are provisioned in the memory map and no assumption can be
> made on the number of the actual virtio device in use in the general case.
>
> This is an extract of the output of `dm tree' on this platform, focused on
> the virtio device from which I would like to boot:
>
> virtio 31 [ + ] virtio-mmio |-- virtio_mmio@a003e00
> blk 0 [ + ] virtio-blk | |-- virtio-blk#31
> partition 0 [ + ] blk_partition | | |-- virtio-blk#31:1
> partition 1 [ + ] blk_partition | | `-- virtio-blk#31:2
> bootdev 2 [ + ] virtio_bootdev | `-- virtio-blk#31.bootdev
>
> In this extract the actual virtio device number is 31, as will be picked by
> efiload_read_file(), but the desired block device index is zero, as would
> be used with e.g. `ls virtio 0'.
I came across the exact same issue a few days ago. Below is a patch which I believe fixes the problem, by using the devnum of blk uclass (virtio 0) instead of the sequence number of the parent udevice (e.g virtio-blk#35).
Separately, the devnum was previously being parsed as a hex which meant "virtio_blk#35" was actually being parsed as "virtio_blk#23". That confused me for a while.
If the patch looks good I can re-post it directly to the ML. I'm not 100% sure that I got it right.
In case the email mangles the patch, you can grab a diff here as well: https://gitlab.com/traversetech/ls1088firmware/u-boot/-/commit/5ed3315b4a297f143fb84f44117b5b31e5617af5
- Matt
------------
From 5ed3315b4a297f143fb84f44117b5b31e5617af5 Mon Sep 17 00:00:00 2001
From: Mathew McBride <matt@traverse.com.au>
Date: Wed, 5 Apr 2023 02:44:48 +0000
Subject: [PATCH] bootstd: use blk uclass device numbers to set efi bootdev
When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")
This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:
Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)
Signed-off-by: Mathew McBride <matt@traverse.com.au>
---
boot/bootmeth_efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 6a97ac02ff..bc106aa736 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -117,7 +117,7 @@ static int efiload_read_file(struct blk_desc *desc, struct bootflow *bflow)
* this can go away.
*/
media_dev = dev_get_parent(bflow->dev);
- snprintf(devnum_str, sizeof(devnum_str), "%x", dev_seq(media_dev));
+ snprintf(devnum_str, sizeof(devnum_str), "%d", desc->devnum);
strlcpy(dirname, bflow->fname, sizeof(dirname));
last_slash = strrchr(dirname, '/');
--
2.30.1
next prev parent reply other threads:[~2023-04-06 0:25 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é
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 [this message]
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=fa967aab-83bb-4116-b405-bbfe74690add@app.fastmail.com \
--to=matt@traverse.com.au \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=vincent.stehle@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox