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 B87BAC433EF for ; Thu, 28 Oct 2021 17:50:24 +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 1A4DD610A0 for ; Thu, 28 Oct 2021 17:50:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1A4DD610A0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 CDE7B834A3; Thu, 28 Oct 2021 19:50:21 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com 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=gmail.com header.i=@gmail.com header.b="lxEhEd8r"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EFC9083480; Thu, 28 Oct 2021 19:50:19 +0200 (CEST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 CA08182F33 for ; Thu, 28 Oct 2021 19:50:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pbrobinson@gmail.com Received: by mail-ed1-x536.google.com with SMTP id g10so27770302edj.1 for ; Thu, 28 Oct 2021 10:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jFkTCyaN3jlBeklMOZ8A0qTPn1tli4oMYZop49TO2/w=; b=lxEhEd8rZ84aw5QAvs4FNPAElcxz59wbEBsotqQ5rR+BAzYKAkdpva5ooJPBTkBDSR eMSURqO9HAf+4v3zZH8umIPJYkesWwx1c6cuHEHrrlC/Bq/vLO5+v2gCkGuVv35Utm1K pCZTpmGf+epLBArgQn1ny31G4hp5GSzdyhrlHtDCr7sdSfZinczPU0JBs2bpkOL9S6PD Fka3ACdBtpZcA7q1b4ANTkbeL83EJ22zj1g6f+ihPLZ2VN6A6sHKcz70fo9IJwtL3ld4 FN71yRyb3ySl61nCzs7r+WZhTyg/Gor2GolqEMMQFjVDV8H58VwJeAPHBRQ71OAFUGPq C2iA== 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=jFkTCyaN3jlBeklMOZ8A0qTPn1tli4oMYZop49TO2/w=; b=be2GrJUehTTW7repuS2oQyDxVp2evrDJntxCBcZ1iq/XynvOANghyP/qzCn7tx8lwD Xe8UfC5cEE+c4WzFJJmmjNTTuMZSI0RS++3LWcO1/bJBWvTEQYRhUZPZy/qkQQTb3Ls3 xfhseY2VVLt9rGKjpzYMzZp4lGlctgH/gnOeWayLFFM9FvZLGDJR0pkIGoKD8RmkXYX1 PxpjmGH/gGeU/NGdrZ5e6Gw8Hgm7m803hYyp579OVfFerLM29I7JR0yqhZcJvNhHs4QZ JhJ42L0Ak5Ar1nnav2a65CNUaJCRWtlPIZyeYr58J+qXFgtG0wCYLbdEPFUFiMzP1CpO 07Bg== X-Gm-Message-State: AOAM533ATehp6hmEAW6iELG/of23sj+6bM6rLJa1MEwjLVJccPF7yILJ +m+aLYtwNxJwVz0JaOa/YVXhJuDGTybOSHzBOEg= X-Google-Smtp-Source: ABdhPJzFSe23+dBPLNmG/A5FMKef14Hjm6AL4ydOfoDeCViBh+Wd1JEhxhlTxPftZaS/iFd1TYSwNeCHIT009/+nADE= X-Received: by 2002:a50:e1c4:: with SMTP id m4mr7910244edl.307.1635443414375; Thu, 28 Oct 2021 10:50:14 -0700 (PDT) MIME-Version: 1.0 References: <20211023232635.9195-1-sjg@chromium.org> <3fde4b98-e7c0-71c3-d7c4-22c6f43eae31@canonical.com> <20211028174721.GE8284@bill-the-cat> In-Reply-To: <20211028174721.GE8284@bill-the-cat> From: Peter Robinson Date: Thu, 28 Oct 2021 18:50:02 +0100 Message-ID: Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot To: Tom Rini Cc: Simon Glass , Heinrich Schuchardt , Michal Simek , Ilias Apalodimas , Daniel Schwierzeck , Steffen Jaeckel , =?UTF-8?B?TWFyZWsgQmVow7pu?= , Lukas Auer , Dennis Gilmore , Jaehoon Chung , Marek Vasut , Masahiro Yamada , Pavel Herrmann , Peng Fan , Stephen Warren , Stephen Warren , =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , Heinrich Schuchardt , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" 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 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 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? 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.