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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D00CDC433F5 for ; Thu, 28 Oct 2021 21:40:50 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id AE34E60F9C for ; Thu, 28 Oct 2021 21:40:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AE34E60F9C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DCA2F82B45; Thu, 28 Oct 2021 23:40:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl 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 4F9FB83513; Thu, 28 Oct 2021 23:40:45 +0200 (CEST) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 01CE6827C5 for ; Thu, 28 Oct 2021 23:40:41 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 07f988ce; Thu, 28 Oct 2021 23:40:34 +0200 (CEST) Date: Thu, 28 Oct 2021 23:40:34 +0200 (CEST) From: Mark Kettenis To: Tom Rini Cc: pbrobinson@gmail.com, sjg@chromium.org, heinrich.schuchardt@canonical.com, michal.simek@xilinx.com, ilias.apalodimas@linaro.org, daniel.schwierzeck@gmail.com, jaeckel-floss@eyet-services.de, marek.behun@nic.cz, lukas.auer@aisec.fraunhofer.de, dennis@ausil.us, jh80.chung@samsung.com, marex@denx.de, yamada.masahiro@socionext.com, morpheus.ibis@gmail.com, peng.fan@nxp.com, swarren@nvidia.com, swarren@wwwdotorg.org, francois.ozog@linaro.org, xypron.glpk@gmx.de, u-boot@lists.denx.de In-Reply-To: <20211028174721.GE8284@bill-the-cat> (message from Tom Rini on Thu, 28 Oct 2021 13:47:21 -0400) Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot References: <20211023232635.9195-1-sjg@chromium.org> <3fde4b98-e7c0-71c3-d7c4-22c6f43eae31@canonical.com> <20211028174721.GE8284@bill-the-cat> Message-ID: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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 > Date: Thu, 28 Oct 2021 13:47:21 -0400 > From: Tom Rini > > On Thu, Oct 28, 2021 at 06:37:42PM +0100, Peter Robinson wrote: > > On Wed, Oct 27, 2021 at 3:11 PM Simon Glass wrote: > > > > > > Hi Heinrich, > > > > > > On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt > > > wrote: > > > > > > > > > > > > > > > > On 10/24/21 01:25, Simon Glass wrote: > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to automatically > > > > > boot an Operating System without custom scripting and other customisation. > > > > > This is called 'standard boot' since it provides a standard way for > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > - bootdev - a device which can hold a distro > > > > > - bootmeth - a method to scan a bootdev to find bootflows (owned by > > > > > U-Boot) > > > > > - bootflow - a description of how to boot (owned by the distro) > > > > > > > > Please, describe why you are suggesting this change. > > > > > > > > Replacing a script by a devicetree chunk is just decreasing flexibility > > > > and increasing complexity. Where is the benefit? > > > > > > > > I am missing a description here of where and how a boot flow shall be > > > > defined. Describing some device-tree binding in patch 40/41 does not > > > > replace describing the development and usage workflow. Who will provide > > > > which bootflow information when? > > > > > > > > You still have an open discussion with Linaro about the source of > > > > devicetrees. This discussion needs to be finalized before considering > > > > this series. > > > > > > > > In my view bootflows cannot be defined in the devicetree because prior > > > > firmware providing a devicetree is completely independent of any distro > > > > and therefore cannot provide a distro specific bootflow. > > > > > > There is actually no need to use devicetree here. I think you might > > > have the wrong end of the stick. It is certainly possible to add nodes > > > to configure things, if needed, but it works find without any changes > > > to the devicetree, as you can see from the rpi_3 patch. > > > > > > There are several aims with this effort: > > > > > > - Provide a standard way to boot anything on U-Boot, that everyone can > > > plug into (distros, board vendors, people using a custom flow) > > > > I as a distro maintainer don't want this, we already get the "standard > > way to boot" from UEFI, this just feels like another unnecessary > > abstraction to that. > > Right. But part of the problem is "How do I find UEFI". Something > somewhere needs to be configurable to say where to look, yes? Before we had "bootefi bootmgr", this was done using "setenv boot_targets ...", where you would specify a list of devices to try and boot from. This is effectively a command line version of the menu that most x86 BIOS (and UEFI) implementations offer to specify the order of devices to boot from. We document this in the OpenBSD/arm64 installtion instructions and it wouldn't surprise me of some of the Linux distro's do this as well. This still works fine, unless you set the UEFI variables that "bootefi bootmgr" looks at. But I fear Simon's patch series breaks this. I didn't try the patch series yet though, so I might be mistaken. When "bootefi bootmgr" is used, the device/OS to boot is specified by the Boot#### and BootOrder UEFI variables. I believe these can be set from the U-Boot command line, but doing so in the right way isn't trivial. The way this is supposed to work I think is that the OS installer defines an appropriate Boot#### variable and adds it to tje BootOrder variable. But that pretty much relies on on the ability to set those variables at OS runtime using EFI runtime services. And as was pointed out that doesn't really work for most U-Boot targets. To be honest, I don't really understand how "bootefi bootmgr" is used in the real world right now. There is a lot of good work done in this area in U-Boot. But I get the feeling that too much of it is driven by meeting requirements of specs and that there is too little thought put into the practicalities of actually booting a general purpose OS (e.g. a mainstrain Linux distro) on a board with U-Boot support.