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 4FFC9C433FE for ; Thu, 28 Oct 2021 18:13:32 +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 9016F60240 for ; Thu, 28 Oct 2021 18:13:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9016F60240 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com 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 BE0F4834B5; Thu, 28 Oct 2021 20:13:29 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (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="GNrh7kD8"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 33FBF83556; Thu, 28 Oct 2021 20:13:27 +0200 (CEST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 D80AE834A4 for ; Thu, 28 Oct 2021 20:13:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x732.google.com with SMTP id ay10so1603014qkb.12 for ; Thu, 28 Oct 2021 11:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VCnzg9GTKXF5ZeXVq8R4OCRLbfaFY7zsMSHPjVtu3Hs=; b=GNrh7kD8qvdJQglvQLXYKQzJ5ipVB2Er4h4UeptsZHhQI9gFI/8dK9+uA8YHWacm0Y RCReGOKGZxwgY9nLgS6v+xPGciZ39ZdT7S+ctot2Uz05lvIORMp9PwuFSwevLERMSadS IoxHCVhkr5ldnRCtZVG7XsyjrjyuiYrbvQhrE= 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:references :mime-version:content-disposition:in-reply-to; bh=VCnzg9GTKXF5ZeXVq8R4OCRLbfaFY7zsMSHPjVtu3Hs=; b=NC+1kbJzFr9tM9JfkL+rtiW8BXcbWHSIbSkEsIfuiscjeiVA8TCDLwm8K7XzUFHSfO DA6jWVHoF3lqsHYPzlzrU+kBmA3mz4JQ1vT1HxNdQQLK+8u7Dw0T6Pym3UMCB5Nd0aFR crmjVrdmjyN/nsD+XR0yzj61jre/Odjx9gh86zu6EtvgItCEA77yW7LF9nhL6cdsUdtF Qd9/O6OphJl+avHC2gpeXtTYs8ScSeUXAwrRDq8Cp6M1/GAbKtrLuUVkv+R38e7XgyHm 0pjKxUU5biFVc6y/9A71CqmHg3KXPv+asqSQhBthYE/RnxX4gs82YXnh5GqGdLynfoMa jKpg== X-Gm-Message-State: AOAM532K4kRJ5UyyVnzuaXc6nxwmmVyFmbb0BHk27PNZERt2AcrtCfr1 tRdmVaKBBX7XS3fnHAd6qwaPGA== X-Google-Smtp-Source: ABdhPJwJT6l4WvIKWzO8HWZ583OySZDiqpVkg9qX99kSRjdDSioev2kvCgEAGEpJMZFEugt2KWr+UQ== X-Received: by 2002:a05:620a:bc1:: with SMTP id s1mr5091015qki.49.1635444800834; Thu, 28 Oct 2021 11:13:20 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-015b-1704-43dd-8832.res6.spectrum.com. [2603:6081:7b01:cbda:15b:1704:43dd:8832]) by smtp.gmail.com with ESMTPSA id s7sm1222748qta.3.2021.10.28.11.13.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Oct 2021 11:13:20 -0700 (PDT) Date: Thu, 28 Oct 2021 14:13:17 -0400 From: Tom Rini To: Heinrich Schuchardt Cc: Simon Glass , Heinrich Schuchardt , Michal Simek , Ilias Apalodimas , Daniel Schwierzeck , Steffen Jaeckel , Marek =?iso-8859-1?Q?Beh=FAn?= , Lukas Auer , Dennis Gilmore , Jaehoon Chung , Marek Vasut , Masahiro Yamada , Pavel Herrmann , Peng Fan , Stephen Warren , Stephen Warren , =?iso-8859-1?Q?Fran=E7ois?= Ozog , U-Boot Mailing List , Peter Robinson Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot Message-ID: <20211028181317.GH8284@bill-the-cat> References: <20211023232635.9195-1-sjg@chromium.org> <3fde4b98-e7c0-71c3-d7c4-22c6f43eae31@canonical.com> <20211028174721.GE8284@bill-the-cat> <20211028175902.GG8284@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Z7LlPTH9npGOZ5Qw" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett 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 --Z7LlPTH9npGOZ5Qw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2021 at 08:09:35PM +0200, Heinrich Schuchardt wrote: > On 10/28/21 7:59 PM, Tom Rini wrote: > > On Thu, Oct 28, 2021 at 06:50:02PM +0100, Peter Robinson wrote: > > > On Thu, Oct 28, 2021 at 6:47 PM Tom Rini wrote: > > > >=20 > > > > On Thu, Oct 28, 2021 at 06:37:42PM +0100, Peter Robinson wrote: > > > > > On Wed, Oct 27, 2021 at 3:11 PM Simon Glass wr= ote: > > > > > >=20 > > > > > > Hi Heinrich, > > > > > >=20 > > > > > > On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt > > > > > > wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > On 10/24/21 01:25, Simon Glass wrote: > > > > > > > >=20 > > > > > > > > The bootflow feature provide a built-in way for U-Boot to a= utomatically > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > It introduces the following concepts: > > > > > > > >=20 > > > > > > > > - bootdev - a device which can hold a distro > > > > > > > > - bootmeth - a method to scan a bootdev to find bootfl= ows (owned by > > > > > > > > U-Boot) > > > > > > > > - bootflow - a description of how to boot (owned by th= e distro) > > > > > > >=20 > > > > > > > Please, describe why you are suggesting this change. > > > > > > >=20 > > > > > > > Replacing a script by a devicetree chunk is just decreasing f= lexibility > > > > > > > and increasing complexity. Where is the benefit? > > > > > > >=20 > > > > > > > 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 d= oes not > > > > > > > replace describing the development and usage workflow. Who wi= ll provide > > > > > > > which bootflow information when? > > > > > > >=20 > > > > > > > You still have an open discussion with Linaro about the sourc= e of > > > > > > > devicetrees. This discussion needs to be finalized before con= sidering > > > > > > > this series. > > > > > > >=20 > > > > > > > In my view bootflows cannot be defined in the devicetree beca= use prior > > > > > > > firmware providing a devicetree is completely independent of = any distro > > > > > > > and therefore cannot provide a distro specific bootflow. > > > > > >=20 > > > > > > There is actually no need to use devicetree here. I think you m= ight > > > > > > have the wrong end of the stick. It is certainly possible to ad= d nodes > > > > > > to configure things, if needed, but it works find without any c= hanges > > > > > > to the devicetree, as you can see from the rpi_3 patch. > > > > > >=20 > > > > > > There are several aims with this effort: > > > > > >=20 > > > > > > - Provide a standard way to boot anything on U-Boot, that every= one can > > > > > > plug into (distros, board vendors, people using a custom flow) > > > > >=20 > > > > > I as a distro maintainer don't want this, we already get the "sta= ndard > > > > > way to boot" from UEFI, this just feels like another unnecessary > > > > > abstraction to that. > > > >=20 > > > > Right. But part of the problem is "How do I find UEFI". Something > > > > somewhere needs to be configurable to say where to look, yes? > > >=20 > > > Is this question from the board PoV, the developer of U-Boot or the > > > distro trying to boot? > > >=20 > > > If you mean from a boot flow PoV for UEFI to find the HW that contains > > > the OS to boot I thought that was handled elsewhere in the series. > >=20 > > What I mean is that today looking at Pi we have: > > #define BOOT_TARGET_DEVICES(func) \ > > BOOT_TARGET_MMC(func) \ > > BOOT_TARGET_USB(func) \ > > BOOT_TARGET_PXE(func) \ > > BOOT_TARGET_DHCP(func) > >=20 > > As the board maintainer set that as the list of places to start looking > > for the next payload (say the GRUB EFI binary). Simon's series replaces > > that with I think he said "bootflow scan -b". And then the above env > > portion is replaced with, well, what's documented in patch #40 if you > > don't just want to rely on device probe order. > >=20 > > Because we need to have _something_ that says where to look for what, > > yes? Or should that be replaced entirely with efi vars and > > BootOrder/BootXXX and "bootefi bootmgr $fdt_addr_r" ? > >=20 >=20 > UEFI variables must be supported for booting via UEFI. But if no valid > image can be found via the UEFI variables you have to scan the EFI > system partition for the file EFI/BOOT/BOOT.EFI and run it. This > requires to scan all block devices for the ESP. >=20 > Furthermore not all distributions use UEFI by default on all systems. Assume a UEFI distribution for the moment. What should the default boot command look like, these days? Can U-Boot have persistent UEFI variables directly (rather than say indirectly with a preboot=3D... to set them) or no? Or should it continue to be the EFI-related logic in include/config_distro_bootcmd.h ? --=20 Tom --Z7LlPTH9npGOZ5Qw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmF66DMACgkQFHw5/5Y0 tyxi5gv+P2FRBWO4ApeCq+R7zO4u1jD9no1PTRrQMUYB8JQfecH7Anl121bZzEOh UxTjIN10ZfAYYMaexsAKrjm17wHbI+n2goiwAHm06POzfXcHT866opRHw4uWlpvU pIE7Lu7YJGllSxXSDTYfrPfSRDXPwknJ6NSkq0j9axLaoy9mChEC+mrCR2w1WBFL hnP9T1BEfVmng4CuNJ2yjtfKy5NAXIn00Jt5UZdf69AaVbXU6mXOyS1GLmealfnO nMZ5cqdVN6EaulESyOyN1Wb6FjL95RKjGgIqTE0VQLqBz34KCHrm2pCgVsutfXGw oKqwl/A30zOFjNIc3tVRglBaaoWiZ13IbBvB6+dubsMiwySw2AuByniIMY2MS8N7 LCJOJ9/QEf9JUZ+sbT78dCNRGCpmKrWsfI/HK8g43IeGrsOUGvUEnTWYdJoyQRL/ ElQ/cJaartoNeQKB++Uvcx97PZbZHBUPe/0/gNTivfcsetNc9uNkLHEpaOn9dncE YZQm2Rj2 =egL0 -----END PGP SIGNATURE----- --Z7LlPTH9npGOZ5Qw--