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 4A410C433EF for ; Thu, 6 Jan 2022 03:02:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4ACEA82F87; Thu, 6 Jan 2022 04:02:17 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="ZWTILsfu"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1610282F91; Thu, 6 Jan 2022 04:02:16 +0100 (CET) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 86F1B80FCC for ; Thu, 6 Jan 2022 04:02:09 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pl1-x62a.google.com with SMTP id z3so1528153plg.8 for ; Wed, 05 Jan 2022 19:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=v6fonsc5Ys/G55WNK4x7iarczR/U6sSWe47/7j+kwjQ=; b=ZWTILsfuHV9bYi1G/kwZJyNduRWqrvjdIS28rR9h/Gn/RwkKIlYFCcNiqyE2YFmTrR HPFwriHDqW7r9fodcTuzl8Aj06OeY4DfUPMPlE9fwKrta6Qir32oHr3U0vLax2LS52NX Bt7rjHgC+bCR2gpdt3SSbG2Y6bH4WjhekBboS49GPO0MXOfLIwRx8MSN16EcPJWEn5yN WBvgFGgqpiJ2d7luZXVFhXU9MoblhIPUWbnO23HFGRXaKNUMvslVhF2unJYvP7lzR3Ko xIiivhVyqlxGQ5LBttiRMOp6yrywU1fBWVd62aH1o9wYW+hcN4ysRdpibKD5/+V3r5ri G8iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=v6fonsc5Ys/G55WNK4x7iarczR/U6sSWe47/7j+kwjQ=; b=M+Vdj/nb1C6Yoq1c0Kjsnk5aYp4fc7i7dZqHseD8p9aDgq+2NAhRgDfpRLwSu0HPAk aOLHu0wKLGYhH/rxAZQCle5h6BQiW7cV5gaL169wA4/2BblcR1oehBtgLWql+Evhhh1s Zd/pTD5yqTEy3OX5ZIbzSb/uGXYSvFfUGfJ2ovI0v128lx00phmzkpOrOsFEkCe+F/pm gyG8xMJrr+nhc/ups8GXEmBeWhReH+CrFhxoaLnRPBXpmDRAHm6mTmj6cHcW4vtQ0EHv y5UeKuNCSXVqb2a1eut5BcH1GIYNx7qnIGOexDbM6I/UuSoK08LSlljQZaiDSEQD1UfD zTRA== X-Gm-Message-State: AOAM533vtSN30DzQCtn8Z5cZ91Xj0qSm7gmudmmyCQuVgnNJbjf896+n 8bS9cK09jMOxrvuQjDWkyysZuQ== X-Google-Smtp-Source: ABdhPJwoocaoeP8UOg+t6abNaUV8+cZxaSIG7mHdl7SWtei7nWF2Skj54O9j7UX8J2eMQT4qiRz2Qw== X-Received: by 2002:a17:90b:50e:: with SMTP id r14mr7592836pjz.175.1641438127615; Wed, 05 Jan 2022 19:02:07 -0800 (PST) Received: from laputa ([2400:4050:c3e1:100:9127:7a05:487c:d781]) by smtp.gmail.com with ESMTPSA id lx8sm4171869pjb.18.2022.01.05.19.02.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 19:02:07 -0800 (PST) Date: Thu, 6 Jan 2022 12:02:03 +0900 From: AKASHI Takahiro To: Mark Kettenis Cc: Fran??ois Ozog , sjg@chromium.org, xypron.glpk@gmx.de, ilias.apalodimas@linaro.org, masahisa.kojima@linaro.org, u-boot@lists.denx.de Subject: Re: efi bootmenu Message-ID: <20220106030203.GA45004@laputa> Mail-Followup-To: AKASHI Takahiro , Mark Kettenis , Fran??ois Ozog , sjg@chromium.org, xypron.glpk@gmx.de, ilias.apalodimas@linaro.org, masahisa.kojima@linaro.org, u-boot@lists.denx.de References: <20211221024709.GC40272@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 On Wed, Dec 29, 2021 at 05:04:17PM +0100, Mark Kettenis wrote: > > From: François Ozog > > Date: Wed, 29 Dec 2021 14:39:36 +0100 > > > > HI Simon > > > > On Wed, 29 Dec 2021 at 14:36, Simon Glass wrote: > > > > > Hi François, > > > > > > On Tue, 28 Dec 2021 at 03:15, François Ozog > > > wrote: > > > > > > > > > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass a écrit : > > > >> > > > >> Hi Masahisa, > > > >> > > > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > > > >> wrote: > > > >> > > > > >> > Hi Takahiro, > > > >> > > > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > > >> > wrote: > > > >> > > > > > >> > > On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote: > > > >> > > > Hi Heinrich, Ilias, Akashi-san, > > > >> > > > > > > >> > > > Ilias and I are now discussing to create efi bootmenu, almost > > > similar > > > >> > > > to UiApp in EDK2. > > > >> > > > > > >> > > Why not discuss this topic openly in ML? > > > >> > > > > >> > Yes, I included U-Boot ML.(Sorry, I should include from the the > > > beginning.) > > > >> > > > > >> > > > > > >> > > How is this feature related to Simon's bootmethod proposal? > > > >> > > > > >> > If I correctly understand Simon's bootmethod proposal, > > > >> > the difference is that efi bootmenu only targets to implement > > > >> > the menu based UI to select/edit/add/delete "Boot####" and > > > "BootOrder". > > > >> > > > >> Yes, EFI would be one of the bootmethods. Others would be U-Boot > > > >> scripts, Chrome OS, Android, etc. plus people might add custom ones. > > > >> > > > >> Also I am thinking that (perhaps) the bootdev part of the standard > > > >> boot thing could be used to provide boot devices for EFI. > > > >> > > > >> If we do have a bootmenu, I wonder if it could be generic, instead of > > > >> tied to EFI? > > > > > > > > EFI BootXXXX specify an array of device paths and boot options. A device > > > path is quite a unique construct despite its name. > > > > A device path is itself an array of elements, some elements can be a > > > file path , configuration information, or diverse metadata. An example of > > > configuration information element is UART baud,stop bits, parity along with > > > terminal (vt100, ansi…). Another device path element can cover IP address, > > > transport information (tcp, UDP and port number). > > > > The traditional EFI boot menu is quite crude and does not expose the > > > full capabilities of BootXXXX (lacks edit of boot options for instance!). > > > > > > > > In the long run we will need to leverage all the BootXXXX capabilities > > > and those are EFI specific while being OS agnostic. > > > > The other U-Boot boot methods (Android , ChromeOS…) are OS specific. > > > > The goals are thus very different and making a generic approach seems > > > quite compromised. If there is a fully generic framework available in the > > > future, it may be possible to integrate the EFI boot menu. But at least > > > there is a need to solve, code first, the EFI complexities to fuel the > > > generic architecture discussion. > > > > > > Despite this, the goal of standard boot is to encompass all of this > > > within U-Boot. I believe that it will be successful, even if the path > > > at present is a bit unclear. > > > > > So I would suggest we work bottom up. Starting by making EFI menu work, > > then extend it more generic or integrated it in a framework. Starting top > > down would require a long architecture process based on not enough known > > problems to solve for each environment. > > > > Well, whatever you do, please build something that works well with a > serial console. EDK2 makes assumptions the terminal emulation on the > other side, insists on changing the colors to white on black and > relies on function keys that need escape sequences. And escape > sequences over serial are always iffy since they depend on timing for > their interpretation. You can do better for U-Boot. > > 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. I think that this issue can/should be addressed in a separate patch although I have had no progress on my patch[1]. -Takahiro Akashi [1] https://lists.denx.de/pipermail/u-boot/2021-November/466583.html > 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.