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 75EC9C76196 for ; Fri, 7 Apr 2023 19:39:00 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 37FF78611D; Fri, 7 Apr 2023 21:38:57 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="IGkBd7E1"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 47C328619A; Fri, 7 Apr 2023 21:38:55 +0200 (CEST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5AA95860A4 for ; Fri, 7 Apr 2023 21:38:52 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf33.google.com with SMTP id o7so913783qvs.0 for ; Fri, 07 Apr 2023 12:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; t=1680896331; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=UJ/4zuQdtEDgnwYrqxWoONHXEirrhi1lPuhIc5pXbBc=; b=IGkBd7E1iqf4nWrynoGL+VMf5vE0YnynhsJIQl5YlWGO2jIg9W7QRiEfwU6CyHupux kncDicucTWk+SIwZFhcrkWJSWwuslkflRHWZ/GBx79MMDVkNVfuMZkhYYHtjCGsh7axq dUgUYHsCBlczURduUYLhU+f4Tn3qALidgzo9g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680896331; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UJ/4zuQdtEDgnwYrqxWoONHXEirrhi1lPuhIc5pXbBc=; b=wYrIue9w/+cZ3vJ5S+ehdQeizz840HDD9mHTa4Tqwro6X7zYZHmfUyL2p/XXB9/2XC 2665HGaoa7zN2pUWCQZWKxo8eoxz8C560xtW2nwWNmHx3O/q+aO3Jbj1BIrvTGD4EC0r twNWLLf00LyGs0IlmSohmPLMNa04QifMNzNrpK0RDXJuELtRmjGJ33LbnMQ2/78GFTKg U77/41arwhiaU0YsogJZHDkzQbRgzSH5A+HDgFrbPGFFFAVqKp4kFpc+0LZKiHuftMGr dxNRAyaVv4+ygRr73lrc4HZwXCbvnedorwwKFid8Aisc90lLK1QWIrwMuTp5YLdiSZpl I/sA== X-Gm-Message-State: AAQBX9cemWd0f5BjwxoEPTLGbf0jTuoIDiTq4bNDfuLvXtzlx7lWBhvq tYVp446iW0BNFscuTgsGVTDhtg== X-Google-Smtp-Source: AKy350Z8h9Xa7wguJ4Flfz/3uawTz3bxk0FGeHocn+R0uTH8GHaqM7ibLcLvqiQWZTgDNsKM8bZAhQ== X-Received: by 2002:a05:6214:19c3:b0:57e:866e:ba1b with SMTP id j3-20020a05621419c300b0057e866eba1bmr7468299qvc.24.1680896330889; Fri, 07 Apr 2023 12:38:50 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-6400-4d7a-a40c-ed12-3a35.res6.spectrum.com. [2603:6081:7b00:6400:4d7a:a40c:ed12:3a35]) by smtp.gmail.com with ESMTPSA id h2-20020ad45442000000b005dd8b9345e0sm1540013qvt.120.2023.04.07.12.38.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Apr 2023 12:38:50 -0700 (PDT) Date: Fri, 7 Apr 2023 15:38:48 -0400 From: Tom Rini To: Mark Kettenis Cc: sjg@chromium.org, vagrant@debian.org, pbrobinson@gmail.com, ilias.apalodimas@linaro.org, xypron.glpk@gmx.de, u-boot@lists.denx.de, hl@rock-chips.com, jeffy.chen@rock-chips.com, kever.yang@rock-chips.com, philipp.tomsich@theobroma-systems.com Subject: Re: [PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist Message-ID: <20230407193848.GF1134230@bill-the-cat> References: <20230331102559.v5.1.Id5a4b4ee7b653591dfb25e75204c17215521164b@changeid> <20230331102559.v5.3.Ifa423a8f295b3c11e50821222b0db1e869d0c051@changeid> <20230331180222.GB13222@bill-the-cat> <20230403141742.GF19998@bill-the-cat> <20230405144759.GW1134230@bill-the-cat> <87355eat78.fsf@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KiQRc+gFAyYRcnMj" Content-Disposition: inline In-Reply-To: <87355eat78.fsf@bloch.sibelius.xs4all.nl> X-Clacks-Overhead: GNU Terry Pratchett 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 --KiQRc+gFAyYRcnMj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 05, 2023 at 11:56:59PM +0200, Mark Kettenis wrote: > > Date: Wed, 5 Apr 2023 10:47:59 -0400 > > From: Tom Rini > >=20 > > On Wed, Apr 05, 2023 at 05:28:07PM +1200, Simon Glass wrote: > > > Hi Tom, > > >=20 > > > On Tue, 4 Apr 2023, 02:17 Tom Rini, wrote: > > >=20 > > > > On Mon, Apr 03, 2023 at 12:56:49PM +0300, Ilias Apalodimas wrote: > > > > > On Sat, Apr 01, 2023 at 07:31:49PM +1300, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Sat, 1 Apr 2023 at 07:02, Tom Rini wrot= e: > > > > > > > > > > > > > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote: > > > > > > > > > > > > > > > The current EFI implementation has a strange quirk where it= watches > > > > > > > > loaded files and uses the last-loaded file to determine the= device > > > > that > > > > > > > > is being booted from. > > > > > > > > > > > > > > > > This is confusing with bootstd, where multiple options may = exist. > > > > Even > > > > > > > > loading a device tree will cause it to go wrong. There is n= o API > > > > for > > > > > > > > passing this information, since the only entry into booting= an EFI > > > > image > > > > > > > > is the 'bootefi' command. > > > > > > > > > > > > > > > > To work around this, call efi_set_bootdev() for EFI images,= if > > > > possible, > > > > > > > > just before booting. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > > Shouldn't this all be a simple wrapper around the EFI Standard > > > > > > > BootDeviceOrder or whatever that's called? > > > > > > > > > > > > I think you are referring to boot manager, which isn't used her= e. This > > > > > > is replicating the existing distroboot functionality in standar= d boot. > > > > > > > > > > The distroboot functionality *was* trying to behave like the EFI = spec > > > > > expects the bootmanager to behave. Unfortunately I haven't had t= ime to > > > > > review the distroboot patches closely, but back when this started= , my > > > > point > > > > > was that EFI doesn't need anything. Whenever the EFI flow is add= ed > > > > bootstd > > > > > should 'just' call the bootmanager. > > > > > > > > Yes, this. We're trying make things cleaner overall, so the EFI por= tion > > > > of bootstd distro boot should just be "call EFI bootmanager" as tha= t has > > > > a well defined standard way to specify what devices to try in what > > > > order. > > > > > > >=20 > > > We already call bootmgr in standard boot, if it is enabled. > > >=20 > > > But I am not sure how widely that is used... > > >=20 > > > This patch is about corner cases in the distro scripts. If we are to = turn > > > these down we do need to try to do the same thing. > >=20 > > We probably need some distro people to chime in about what they're doing > > / expecting at this point in time? I would have sworn that the long term > > part of EFI "distro boot" would be using bootmgr since that's the > > standards based way to set boot order. And if you don't have a device > > tree in U-Boot, and want the distribution one, aren't you then using > > something like grub which has a "dtb" keyword to handle that on its own? > > That's not saying that "distro boot" doesn't need to load the device > > tree, for when it's then calling booti/bootz/bootm, but not for the EFI > > case these days? Or no? >=20 > The short anserwer is no. >=20 > The long answer: >=20 > OpenBSD requires EFI (booti/bootz/bootm only support booting Linux > kernels in various forms) but also relies on a proper device tree > being provided to its EFI bootloader. While we have made significant > progress in having U-Boot provide a fully synched up device tree for > most of the SoCs that OpenBSD supports, we're not quite there yet, so > some people rely on U-Boot loading (and tweaking) an updated > device-tree from the EFI System Partition. >=20 > Our bootloader does have a "mach dtb" command to load a device tree > from the OpenBSD root partition, but this is considered to be a > debugging command and can't load a device tree from the EFI System > Partition. Loading a device tree this way means the device tree does > not get tweaked by U-Boot, which is problematic on some SoCs/boards. >=20 > We now have the EFI_DT_FIXUP_PROTOCOL, but our bootloader doesn't use > this yet. If the consensus is that distroboot-with-efiboot needs to > deprecated I can work on supporting that protocol in our bootloader. > But a release of OpenBSD with support for that will not be available > until november 2023. >=20 > Alternatively bootmgr could implement the device tree loading and > fixup. Or the bootstd stuff could do this before starting bootmgr. I > understand the concerns about loading device trees from disk when > secure boot is enabled. So maybe this should only be done when secure > boot is disabled. >=20 > Also note that setting the BootOrder EFI variable from inside the OS > isn't supported by most (all?) boards currently supported by U-Boot. > So a convenient way to set the BootOrder EFI variable from within > U-Boot is needed. >=20 > Cheers, >=20 > Mark >=20 > P.S. Does grub support the EFI_DT_FIXUP_PROTOCOL these days? If not > (or if your Linux distro still ships with an older version of > grub) you'll face the same issue as OpenBSD regarding the lack of > fixups for loaded devictrees. I just want to chime in and say thanks for explaining your use case, so we can make sure what we're doing will actually work for everyone. --=20 Tom --KiQRc+gFAyYRcnMj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmQwcUUACgkQFHw5/5Y0 tyx5Vwv9ELUnFBFBfbcXRz68pxH3YqavnyuyCY+0W+rXPfOZC6HpWz/ec1BCcesb w64mIcNPMCrmX17nsYZbE9rZaCP04vDMsBSJ8BpIOHjp+KQV9/4cm2OfSSn1fi8O foyT6X/0nBqELSFJ6B/Cc/JCDoZsUutqYcFiEkB6dSr8qVUTRWuvjZGdCIUGxR9b AkZi+PHblZM2OXsfTh0wRWmPcaqKq24qwbA55cLadCa9uD4aIw1ZQJhJLr/JB9qW +dYmTTSOTdfCCNCFEIQCZkIZIElmZhBcqfxZhjghMPw+aUGFyJfCZHA+8g/52kwj Lsj0Wo2so/wDzFUsp/4Cp6s7zIMU98lk0jsm38ZnOHDOtnlG7zot754or1d47lq7 Bd+Gfmxsv2Wwf6m21VPgRIROu5af/FULJSsPNr0L4mRZJ3kohr6ItyMr7pZRz5sD z7/Futs8aIdBDCJcQpVZZ/HUqysL2GYe3gwl0cpGvLU+6Z3oFn2kIHB4+4XAR6bW N7mROdJ6 =nMia -----END PGP SIGNATURE----- --KiQRc+gFAyYRcnMj--