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 2A2B4C433EF for ; Thu, 28 Oct 2021 18:27:15 +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 5EFBB610C8 for ; Thu, 28 Oct 2021 18:27:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5EFBB610C8 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 DDBA1834A3; Thu, 28 Oct 2021 20:27:11 +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="n0hEYbjs"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id ABAFF832C6; Thu, 28 Oct 2021 20:27:09 +0200 (CEST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 827C3832C6 for ; Thu, 28 Oct 2021 20:27:05 +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-x733.google.com with SMTP id bk22so70958qkb.6 for ; Thu, 28 Oct 2021 11:27:05 -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=NVvcJubIlciqTd/ptEZZwpmyBbQMQI/bBl7VWzIc81M=; b=n0hEYbjs5RccGuYyjchQGNSolbNE16mfOWw2Ki0TWlrg/mcdzqhRU0JaJ2PqEsh4zF rJ+Myb0dIGp9qIo8oGNpxCpG+MmNiPVhT09/Wq6n91EQ2HWHy+k6140ZieNBIf69AtR9 CDF2w+aSAYB7zAd1bM+/n2Eb7YuygvAFikc2Y= 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=NVvcJubIlciqTd/ptEZZwpmyBbQMQI/bBl7VWzIc81M=; b=jl+P95ZzOuUoCL4KXj4lkL9F1Vcv4uU3ULBNFZmGj0SP34YZ3/yfT7zx9KdhSlqDEB Mh1eOMJOch5nMB0YG/txhpH6wsF1YZCT1SIQl6+pyZEJUYbwWyyFyHLix/P3alaHeHK5 2LgjhLzY+r2JSvSirfx/kZNTXT4Nv7HeWXYVhBd4S0DXIPdfBrYBzYZOwq53gsLVW/Lw 0TUr7jIMW8U4xg7e/M+9WYDMaWKM5hjU4TokeBdM3vz0nkLAggt1x7CFbBl+YidQqOXK 86HaK7oPicEMN4P86U/N9LrQsDfqGNIvmlRpd5sq86/oQLisg94B7nC8Rmj5XEAkKxcc ucJQ== X-Gm-Message-State: AOAM533KKZ5D8XJ4L+hXMqseIN73+GgaDH1iD1RpTqn4DNmU3/gj0GP0 E295fAbIDjfuPCFTe490YEqN1A== X-Google-Smtp-Source: ABdhPJz1VTJTKvVkenNfwwJCaRyjl24Il30SZDMNFHvRJy1TpngT/nwvqR4PvU/HZOuu4uoto9g6Xg== X-Received: by 2002:a05:620a:1709:: with SMTP id az9mr5241097qkb.191.1635445624312; Thu, 28 Oct 2021 11:27:04 -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 bs33sm2500804qkb.130.2021.10.28.11.27.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Oct 2021 11:27:03 -0700 (PDT) Date: Thu, 28 Oct 2021 14:27:00 -0400 From: Tom Rini To: =?iso-8859-1?Q?Fran=E7ois?= Ozog Cc: Daniel Schwierzeck , Dennis Gilmore , Heinrich Schuchardt , Heinrich Schuchardt , Ilias Apalodimas , Jaehoon Chung , Lukas Auer , Marek =?iso-8859-1?Q?Beh=FAn?= , Marek Vasut , Masahiro Yamada , Michal Simek , Pavel Herrmann , Peng Fan , Peter Robinson , Simon Glass , Steffen Jaeckel , Stephen Warren , Stephen Warren , U-Boot Mailing List Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot Message-ID: <20211028182700.GI8284@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="PRtJxKEaMxV1eKQN" 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 --PRtJxKEaMxV1eKQN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2021 at 08:17:50PM +0200, Fran=C3=A7ois Ozog wrote: > Hi Tom, >=20 > Le jeu. 28 oct. 2021 =C3=A0 19:59, Tom Rini a =C3=A9= crit : >=20 > > 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: > > > > > > > > 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 bootflo= ws > > (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 d= oes > > not > > > > > > > replace describing the development and usage workflow. Who wi= ll > > provide > > > > > > > which bootflow information when? > > > > > > > > > > > > > > You still have an open discussion with Linaro about the sourc= e of > > > > > > > devicetrees. This discussion needs to be finalized before > > considering > > > > > > > this series. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > 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 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 every= one > > 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? > > > > > > Is this question from the board PoV, the developer of U-Boot or the > > > distro trying to boot? > > > > > > 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. > > > > 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) > > > > 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. > > > > Because we need to have _something_ that says where to look for what, > > yes? >=20 > Shouldn=E2=80=99t we describe the user point of view ? No, because to extend the x86 metaphor we're talking about the defaults here, not what the user has configured later on. The user has and continues to be able to configure the system afterwards, if desired. --=20 Tom --PRtJxKEaMxV1eKQN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmF6624ACgkQFHw5/5Y0 tyzCNwv9FkBySUxJ/Vh+zBAGcCmNxD7y1syydNqtcrGiu9k2Pwq8+a/pW2wgSRQr ipo4iJYyficovk82cQ5An7ltIpQhCL+hc94QMi/g/zatRX/4PQBfmqvI3ZP3czY5 roOHSoMMUkQesfl2ls47tPicufOeTGYKtxIQ+344FQ02zFiLTEL5Ru6P/LJuls+c GjX7JooqqACGESQx4DaHj1TJSTdN7o31hcrWkmYHoiAfyM6JyakyBt06XB1QPJQi wMJSOPCFqTP2LaqauHxwM6TP4JoCaJ3yTAdkoHLvjsZcgKHNBibZWt9XEvZqYyO/ eA3WtSLpFwddkOrlhD65ADuE8cajiEfv1KqIO93PjSlOlTiNCFL1WCUfjV8eJrTz d7x4XrZRGjK2Z0Pq83AhQ695CG7zegjgO9rbonLpK2dCHpg0NWmZkY8KGau/8hZp 46YGDR8+ge4399pp91bXk2g54UXzC7cDavSHhQ8eOa2Qgo2JqKaGER00aBnkTqO6 UH9lHmDN =mv9C -----END PGP SIGNATURE----- --PRtJxKEaMxV1eKQN--