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 824C8C76196 for ; Tue, 11 Apr 2023 12:00:41 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id ECEED85E1B; Tue, 11 Apr 2023 14:00:36 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 4B59B85ECA; Tue, 11 Apr 2023 14:00:33 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id CAE7C8563C for ; Tue, 11 Apr 2023 14:00:28 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=vincent.stehle@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 673D5D75; Tue, 11 Apr 2023 05:01:12 -0700 (PDT) Received: from debian (X72Y076X74.nice.arm.com [10.34.129.29]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 967C63F6C4; Tue, 11 Apr 2023 05:00:27 -0700 (PDT) Date: Tue, 11 Apr 2023 14:00:24 +0200 From: Vincent =?utf-8?Q?Stehl=C3=A9?= To: Simon Glass Cc: u-boot@lists.denx.de Subject: Re: [BUG] issues with new bootflow, uefi and virtio Message-ID: References: <20230405150458.890460-1-vincent.stehle@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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