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 72B3DC3ABAA for ; Mon, 5 May 2025 19:55:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D75C982161; Mon, 5 May 2025 21:55:00 +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="WU2fGaQs"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6B5FD82163; Mon, 5 May 2025 21:55:00 +0200 (CEST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 0DFF88215B for ; Mon, 5 May 2025 21:54:58 +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-ot1-x32f.google.com with SMTP id 46e09a7af769-72ec926e828so1343168a34.0 for ; Mon, 05 May 2025 12:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; t=1746474897; x=1747079697; darn=lists.denx.de; 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=6nBclmiOcBQ6rB+M28AU7+b/+CJG4PChRTkl0cAwvD4=; b=WU2fGaQsqAZkbudSWRweN5t7TfZqbpNrqkkYRlKm6L1JIVpeiUnsuydl44AL8HYC7Q p+Z7S05M/3OJbsPVfI2cN4MUX6VCtn4/Mo3g77C21XkrO4AxFx4l1B8fVBEYzet6D/Ul wBys39kE5F2LtYTfnnoaaen2NK7U5vkdnHqzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746474897; x=1747079697; 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=6nBclmiOcBQ6rB+M28AU7+b/+CJG4PChRTkl0cAwvD4=; b=YA45E733HRsb0zQbWJXmt/9gQk0NuqZL0+9MTXqP+2eaJqsTmAuIx/jO/7uDWHG7kL fUOupW0s01lXve8cMQxH1FaRnjNibO8uBdTgTP5ommah4sW2osJCAMFeWfXS0/QlInOd 2DkwfgFFamwjnwLNhDg1O6E1GOnsGngCvqfRLbURQMpOE2VWimQFyJg+eBpaXWgI2wNV vlK8ES/HlMjf2RMhsVZK9peU/e74uoBErFkVJfmNWlMPVrV33HT1U+U0UoVCPH0VKs3p gYOANp9BvCRlUO4nlx+vBxc05uYcWf6I7CKabjURibJn/EWWlKyl8rnK1ZcmZb8aMUKA qwAQ== X-Forwarded-Encrypted: i=1; AJvYcCWXQtah7kAAuCunOMWriRk5Y3pfc1+xj4ZREJf47HJYNU42vaSU72FsPgKFqg3mJBmNQ5kHDpo=@lists.denx.de X-Gm-Message-State: AOJu0Yx+0NuCpBw37cIvJLdPUs2qFVhGkSloUHr050byyzcoR7lm7dWZ eiT80HRIDz3PPaTTyqko/9bmT7ThrRVPtCpWXB1bIUz7sIHs9y7AXdUa/y2f488= X-Gm-Gg: ASbGncvyvjIX74iPrTGdyAUUj6k840JXtdEjzwS/zxVOppgWnjADQ+dODgP2Eu4PggH 8gH8E9DCt3s1GNfsB2fme94nnNM5mbOVgw2x9XpWVLfKmxycJzwUw+pMp/IfV4DVh9MbzjZqJ6w udg6F9Xm3yrZECNhMx1gPHo+iCbQi3J2nAAo4l3BBl/c4DMQHAZvnPeQLHB/17XEbh6l9aexI0/ 7gEkf+qg3JoALEEo+fVZzJe4S8uMmomP+s8YvqEtbMb6tPz/b2AvLJTFIizEkJufPP5C+ZSbnpn g91btMGKRVmQpdfB4LZxa5CIpqRzB+hXs19ojrn6DWY1ytAS6K2G5zd/8vkPxoL58Ti1c3TNPBu NcKweaWmcR0Uq X-Google-Smtp-Source: AGHT+IHU+Z/VAK4wt3bxMkj3hf7TV1YI0UrakhTAO9drNbuXlfRmsZGVwFUWLnWO9AAc77CvWhfefA== X-Received: by 2002:a05:6870:d6a5:b0:2c2:2e8e:2030 with SMTP id 586e51a60fabf-2dae83838fbmr5332512fac.23.1746474896700; Mon, 05 May 2025 12:54:56 -0700 (PDT) Received: from bill-the-cat (fixed-187-190-205-42.totalplay.net. [187.190.205.42]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-2daa0edb233sm2153400fac.16.2025.05.05.12.54.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 May 2025 12:54:55 -0700 (PDT) Date: Mon, 5 May 2025 13:54:52 -0600 From: Tom Rini To: Heinrich Schuchardt Cc: Mark Kettenis , Simon Glass , Ilias Apalodimas , Tuomas Tynkkynen , Patrick Rudolph , Mattijs Korpershoek , U-Boot Mailing List Subject: Re: [RFC 1/8] boot: EFI boot manager does not depend on BootOrder Message-ID: <20250505195452.GK5430@bill-the-cat> References: <20250421162555.1200687-1-heinrich.schuchardt@canonical.com> <20250421162555.1200687-2-heinrich.schuchardt@canonical.com> <279d1706-d140-409e-a74a-4f1d9eaef311@canonical.com> <875xieanhm.fsf@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NNwqhJrfDPa0+PJd" Content-Disposition: inline In-Reply-To: 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 --NNwqhJrfDPa0+PJd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 05, 2025 at 09:51:52PM +0200, Heinrich Schuchardt wrote: > Mark Kettenis schrieb am Mo., 5. Mai 2025, 21:0= 3: >=20 > > > Date: Fri, 2 May 2025 18:08:56 +0200 > > > From: Heinrich Schuchardt > > > > > > On 5/2/25 16:49, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Mon, 21 Apr 2025 at 10:26, Heinrich Schuchardt > > > > wrote: > > > >> > > > >> The EFI boot manager bootmeth does not require variable BootOrder = to > > be > > > >> preexisting. It creates this variable. > > > >> > > > >> Signed-off-by: Heinrich Schuchardt > > > > > >> --- > > > >> boot/bootmeth_efi_mgr.c | 21 +++------------------ > > > >> 1 file changed, 3 insertions(+), 18 deletions(-) > > > >> > > > >> diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c > > > >> index 42b8863815e..1669cbed5bd 100644 > > > >> --- a/boot/bootmeth_efi_mgr.c > > > >> +++ b/boot/bootmeth_efi_mgr.c > > > >> @@ -47,30 +47,15 @@ static int efi_mgr_check(struct udevice *dev, > > struct bootflow_iter *iter) > > > >> > > > >> static int efi_mgr_read_bootflow(struct udevice *dev, struct > > bootflow *bflow) > > > >> { > > > >> - struct efi_mgr_priv *priv =3D dev_get_priv(dev); > > > >> - efi_status_t ret; > > > >> - efi_uintn_t size; > > > >> - u16 *bootorder; > > > >> - > > > >> - if (priv->fake_dev) { > > > >> - bflow->state =3D BOOTFLOWST_READY; > > > >> - return 0; > > > >> - } > > > >> + int ret > > > >> > > > >> ret =3D efi_init_obj_list(); > > > >> if (ret) > > > >> return log_msg_ret("init", ret); > > > >> > > > >> - /* Enable this method if the "BootOrder" UEFI exists. */ > > > >> - bootorder =3D efi_get_var(u"BootOrder", > > &efi_global_variable_guid, > > > >> - &size); > > > >> - if (bootorder) { > > > >> - free(bootorder); > > > >> - bflow->state =3D BOOTFLOWST_READY; > > > >> - return 0; > > > >> - } > > > >> + bflow->state =3D BOOTFLOWST_READY; > > > >> > > > >> - return -EINVAL; > > > >> + return 0; > > > >> } > > > >> > > > >> static int efi_mgr_read_file(struct udevice *dev, struct bootflow > > *bflow, > > > >> -- > > > >> 2.48.1 > > > >> > > > > > > > > How do we know if the board is using EFI bootmgr? My understanding = was > > > > that this was a way to find out? > > > > > > The boot manager must always run. > > > > > > The check for the BootOrder variable introduced in commit f2bfa0cb1794 > > > is a bug. > > > > Well, at the time the boot manager did not attempt to boot the default > > path. So there was no point in running the boot manager code unless > > BootOrder (or BootNext) was set. And of course before that commit the > > boot manager didn't run at all on non-sandbox builds that had the > > standard boot stuff enebaled. > > > > Anyway, I believe the thinking behind that commit is still sound. As > > I explained earlier, I think that... > > > > > The boot manager handles in sequence: > > > > > > * Try to boot as indicated by BootNext. > > > * Try to boot as indicated by BootOrder. > > > * Try to boot default path for available media. > > > This will add Boot#### entries and update BootOrder. > > > > ...doing this all in a monolithic sequence isn't the best way to > > handle EFI boot in the u-boot ecosystem. > > > > Your series moves the boot manager further down the list because the > > third step in the sequence has to happen late. But as a result > > BootNext and BootOrder processing will also happen late. So what > > happens if you have a board with two OS installations: > > > > 1. A generic Linux distro that boots via EFI. > > > > 2. Something like Armbian that provides an extlinux.conf file. > > > > Currently such a system will probably boot OS #1. But after your > > >=20 > This did not happen with distoboot. So migration from distroboot to > standard boot results in a change that you want to avoid. >=20 > changes it will probably boot OS #2. And if OS #1 sets BootOrder or > > BootNext that will not change anything. > > > > So I think we need a solution where BootNext and BootOrder processing > > happens early, like we do now. > > >=20 > As of today BootNext does not invoke the boot manager. >=20 > If BootOrder is set the boot manager may fail because not all devices are > detected as "hunters" have not been running. E.g. nvme scan and usb start > are only invoked after the EFI boot manager. >=20 > I originally suggested to probe all boot devices before the boot manager > runs, but users complained that this slows down their non-EFI boot flows. > This is why I now move it after all boot methods but PXE. Can we not see what BootOrder is and then ensure it's been "hunted" ? --=20 Tom --NNwqhJrfDPa0+PJd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmgZF4cACgkQFHw5/5Y0 tyxdvAv9ENajoHQkETiqgH4YEbP8gTFQYxG6tnDX1GNHMUoSIrHkJiZHJpXETnve T4FEQ+AuQuqHnd3V9PtoSMpfpBEIA8stkRQhXh3XZl+94DdZtGxiXTpwSKiT+4Mp h0rBLZbFRPj6FWYN+E4dNo9SQ9RUtjdgKMbcbVx5JC98qmWXfoiAYzxJoEG+qF7v sECmuKVEjMxYES/T7D7aXmOO+bE1E/M4wLw9p3O4cwBR550Mx3C71PpDjaY1EcsS SwSmiDxnlR//i/pmsQ44d6FMfiduOS9CEpbcjByC4DYuMP4vyIV3cCr73w/3b4rb yjE4RzM37nkaFK0egYW4HSIxWODeOtOnRjFtXjilGAPOM7SeeQz32//kkr8KU2Ei SeZxI+ivipVhJqj0gOOXBXnhy9mdnKi5EX6/r0cT97DqKgRPHSY0FRlVikIbVZOr QubRfzIXpIVu9QghltT1uVGO+LEZIZVlHrgfZntV9HP1V1YGQE1nciZlu14bOm5W D3cXPk2v =VtCd -----END PGP SIGNATURE----- --NNwqhJrfDPa0+PJd--