From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76B21C7619A for ; Thu, 6 Apr 2023 00:25:54 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D5F2685FAE; Thu, 6 Apr 2023 02:25:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=traverse.com.au Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=traverse.com.au header.i=@traverse.com.au header.b="LPllpoVi"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="qVPbiMDp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 19BCD85FC9; Thu, 6 Apr 2023 02:25:49 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 99FEF85F8E for ; Thu, 6 Apr 2023 02:25:43 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=traverse.com.au Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=matt@traverse.com.au Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 317E83200941; Wed, 5 Apr 2023 20:25:40 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Wed, 05 Apr 2023 20:25:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=traverse.com.au; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1680740739; x=1680827139; bh=8TfzmClnV+QxNDMBT0sU+5kHM Z9wEpuaMfxfbbgSXwg=; b=LPllpoVieHmStCtGEZ8NVUWjCm+v+EYXckNL97i4M 3uczGX5dl6+a98gvbFXCHjO4kzTj97p2tiQ9X3XjK/gh3DSJHo8gyM9Eke7PexD/ OdVOOq1UKEXAF7Bg+DOZYCPr0sxKduX4pgfSHdDwrUg+pIQV69dlpsGjsKbDfvcH MIwC9j21AFGkRRaEV1Ck2WOt+bOXWHuabni3jq+0LsKM7W0NcYEhIZpTuad+INy9 tHLaI3b94iOWmEuXnUM4bcgrKjr6AMDgYiWgverX0kBU5RTyrnRA4/zD9yGUzcIx EwCYBtOoe5I0F7Jic7UGIxPbbWb2jzRnvCPzbu300nb5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1680740739; x=1680827139; bh=8TfzmClnV+QxNDMBT0sU+5kHMZ9wEpuaMfx fbbgSXwg=; b=qVPbiMDp0oUKcX0kxdf2+LWat05xqXbgReK29MI0t7rSJbQkGuj Uu1RdOqOo/lSH3GFuCuL6MsHHDf9Z08g34wLSHufrdzUFozFcp4Y0LWRb/Del/e3 0itkCyaseP4IkChld4R/RDvxJ0YUu3A+7ix4WWUCbuvA54oSaT0NBkZ9e+H8RJQW E+0lPH8ejcv/ugVZW3Z+ehAt7l+h1jJx0evrVDlOOeLT8Kl+o6tfU+40Mg4YkJ3R PtHpOHRYwshPurQzVzhGmsCy81840o3aEWj+e0symUy573lGY6jlAnUo9jgsBXRm gKAmojGSVRyKCknwg9LVCe6XYQ3oZEUle/Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejvddgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdfo rghthhgvficuofgtuehrihguvgdfuceomhgrthhtsehtrhgrvhgvrhhsvgdrtghomhdrrg huqeenucggtffrrghtthgvrhhnpedvtefftdeivdevleehledvgeeftefhfeefffeggeev gfdtteekvdeigeefkeeuheenucffohhmrghinhepghhithhlrggsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrthhtsehtrhgr vhgvrhhsvgdrtghomhdrrghu X-ME-Proxy: Feedback-ID: i426947f3:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 19E1A2340082; Wed, 5 Apr 2023 20:25:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6 Mime-Version: 1.0 Message-Id: In-Reply-To: <20230405150458.890460-1-vincent.stehle@arm.com> References: <20230405150458.890460-1-vincent.stehle@arm.com> Date: Thu, 06 Apr 2023 10:25:15 +1000 From: "Mathew McBride" To: =?UTF-8?Q?Vincent_Stehl=C3=A9?= , u-boot@lists.denx.de Cc: "Simon Glass" Subject: Re: [BUG] issues with new bootflow, uefi and virtio Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean Hi Vincent, On Thu, Apr 6, 2023, at 1:04 AM, Vincent Stehl=C3=A9 wrote: > Hi, >=20 > I am hitting an issue with the new bootflow when booting with UEFI fro= m a > virtio device on Qemu Arm. >=20 > 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 virt= io > 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 c= ase. >=20 > This is an extract of the output of `dm tree' on this platform, focuse= d on > the virtio device from which I would like to boot: >=20 > 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 >=20 > In this extract the actual virtio device number is 31, as will be pick= ed by > efiload_read_file(), but the desired block device index is zero, as wo= uld > be used with e.g. `ls virtio 0'. I came across the exact same issue a few days ago. Below is a patch whic= h 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 confu= sed 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: h= ttps://gitlab.com/traversetech/ls1088firmware/u-boot/-/commit/5ed3315b4a= 297f143fb84f44117b5b31e5617af5 - Matt ------------ >From 5ed3315b4a297f143fb84f44117b5b31e5617af5 Mon Sep 17 00:00:00 2001 From: Mathew McBride Date: Wed, 5 Apr 2023 02:44:48 +0000 Subject: [PATCH] bootstd: use blk uclass device numbers to set efi bootd= ev 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=3D) distro_efi_read_bootflow_file start (efi,fname=3D) setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170= 800 efi_dp_from_name calling blk_get_device_part_str dev=3Dvirtio devnr=3D35 path=3Defi/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/bo= ot/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=3D00000000beef9a40,addr=3D00= 00000000000000) Boot failed (err=3D-22) Signed-off-by: Mathew McBride --- 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 =3D 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); =20 strlcpy(dirname, bflow->fname, sizeof(dirname)); last_slash =3D strrchr(dirname, '/'); --=20 2.30.1