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 9CC91C433F5 for ; Sat, 8 Jan 2022 14:53:48 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E655A8373B; Sat, 8 Jan 2022 15:53:39 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="CLevVS47"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3DB238326F; Sat, 8 Jan 2022 15:53:38 +0100 (CET) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 C37DA80EEE for ; Sat, 8 Jan 2022 15:53:34 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-vk1-xa2a.google.com with SMTP id 191so799019vkc.1 for ; Sat, 08 Jan 2022 06:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/R5wlwqJnvOViThaPmvalmnlIxVgxzBFyErUBGLRCu0=; b=CLevVS471EjQOBuqpjukQjnMVrZNS6WM26G2YdZTmMFs+jF5AdWdDMR4C/a+IrdGBX 2jrVI2u0oymriWpM3iVQ/lLToHdt5QJYpP7i0YfknKkHsTVvYLrOIkTfPOIluF4XFfT/ eVeYOeIzzaja9z3p5+AxBLBYBgJwZ559iqGKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/R5wlwqJnvOViThaPmvalmnlIxVgxzBFyErUBGLRCu0=; b=a8ypdBQs28S/DH8iOMnXa0ds6FpJDEnqbhjBhNow9Ef/3tQooLHfIv+go5qPxiqoUm ZalDUtXI8yfDuxPxZ27s+MlSsU93be5LKIYo/fzCNqv5s1o9X9Gm+I33xItVXZb7hoKY Rmvrrdq1lDgF2aPCQzvVbNBb5o2kZf8PypLJ845gd142pbz5O+Q3OOSaEW8EzofpAnO2 cRPAROGWxCDMQGmrQ7ZEjZ4UZ6rIAUIXfRKON0RmGgYrk+HAIfu0Ozk+zLk9Ax49C6IT zdChzEtnh0eZ6RN97CzA+YObzKSZV3B2hGIjStf5j3X6J8OmtT0h0x2xUPLsWQceBbK+ n4VQ== X-Gm-Message-State: AOAM530g3YQHZdjTMY++c8oms2S9G/AzbKcxURgza2W0QTYfHr8Eovx9 1DaoNXeFjZrDMLwZGfbNC4KZa25MFYBR955NGEWWDg== X-Google-Smtp-Source: ABdhPJwoQ2w+omVhExEM0VmwJ4NTcXPBGzlkK9AXPnQ8dazcd6sUlPgW3SbzmoqZLPbELtRGzz2HnxsHbNoRPL8vR10= X-Received: by 2002:a1f:9dca:: with SMTP id g193mr18374181vke.21.1641653613443; Sat, 08 Jan 2022 06:53:33 -0800 (PST) MIME-Version: 1.0 References: <20211221024709.GC40272@laputa> In-Reply-To: From: Simon Glass Date: Sat, 8 Jan 2022 07:53:21 -0700 Message-ID: Subject: Re: efi bootmenu To: Ilias Apalodimas Cc: Mark Kettenis , Heinrich Schuchardt , Masahisa Kojima , AKASHI Takahiro , U-Boot Mailing List , =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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.2 at phobos.denx.de X-Virus-Status: Clean Hi Ilias, On Fri, 7 Jan 2022 at 02:20, Ilias Apalodimas wrote: > > Hi Mark, > > [...] > > > > > > Also, keep in mind that BootOrder and Boot#### only really work if > > > > there is runtime EFI variable support. So the boot menu should > > > > include options to select a device to boot from and use the default > > > > (removable media) bootloader from the ESP on that device. And a way > > > > to make this selection stick! Pretty much all x86 EFI implementations > > > > provide functionality like that. I suppose this could be done by > > > > populating the EFI variable store with appropriate Boot#### variables > > > > and manipulating BootOrder. But that would make it hard to generalize > > > > the boot menu to non-EFI boot flows. > > > > > > We are talking here about an EFI boot menu. Why do you mention non-EFI? > > > > Because Simon did, and I agree with him that U-Boot would be better of > > with a way to select a boot device that is independent of the boot > > mechanism. Suppose that as a user I want to install a Linux distro on > > my machine. I copy the installer for that distro to a USB key and I > > want to boot it. But my system is set up to boot from eMMC. U-Boot > > should make it easy to do a one-off boot from USB without burdening > > the user with making a choice between EFI and non-EFI boot methods and > > just pick the boot method that makes the machine boot from the USB > > key. > > The concept here is fine, but I think we should agree on how we > implement that. IMHO Simon's boot series patches is a huge step > forward compared to the distro_bootcmd. However EFI has it's own boot > manager and logic. So I see two ways forward: > 1. Simon's bootmethod has an abstract entry called 'EFI' or something > similar. In that case we just invoke the efi bootmgr. > 2. We merge the efibootmgr code into Simon's patches. > > But isn't that orthogonal to the current discussion? We can just go > implement it for EFI now and then wire it up to whatever Simon does. Just one tweak here...I think the concept of a boot device (bootdev) could be useful as a way for EFI to find boot devices, so that U-Boot and EFI can share this logic / configuration. Regards, Simon