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 42F47C433EF for ; Thu, 28 Oct 2021 17:38:03 +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 66BA16103B for ; Thu, 28 Oct 2021 17:38:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 66BA16103B 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 4CF4E832C6; Thu, 28 Oct 2021 19:38:00 +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="XSFfgEza"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3EC8D82F33; Thu, 28 Oct 2021 19:37:58 +0200 (CEST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 3DA8B832C6 for ; Thu, 28 Oct 2021 19:37:54 +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-x52a.google.com with SMTP id w15so28062005edc.9 for ; Thu, 28 Oct 2021 10:37:54 -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=BzFjsBLsx+WFmuXaNmWPuPPV9uYDyUu+EB1JPDYf65k=; b=XSFfgEzaGLlF9SdioFWQcHxL7G/r8CPrIPuu9uj3hN+1xWUUY8q7lwC5VQh3rXD6sv NVHgMZ0JHgKHZsJ5WNwfXBPyewYXM68vQy/STPGg0Dsj2rrbX1dQPT9SBVrg5M/lWozF ARfXJ6Lq6lTnPD6Jk0bAmgEp5l7dx8x64wv2kn7HfsGRMaaZW6cddLAXMg0oSF5gUNON b0UFZqf+j00WMvEAMqvSxmJHSz8NdbNciNOZ9apSFwRd+WcZOibZ7ANc8XYq/HZOUqlT 6HNifEiE3e5cFHpe0rkcJy+lsW7lbTNsOaxlbakhXtj1zjA4LpVncU7VgRPWb+sxbbl5 gmrg== 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=BzFjsBLsx+WFmuXaNmWPuPPV9uYDyUu+EB1JPDYf65k=; b=Tpmx3tnFyL8WZnLu16WO3qwZzdnWtO7JNBs0+cHT9f6y9ELUgoIxcfjxdtpgnUl3qg DouOaOTQYzXsf2R9NiUTDQLP8AUTDNcpGy4DOxzqqc/vX892nWEGfWY6owpNvM1SzphK wAcA3/gi6kmlMCAie/Nc7LOD2kYmEKJvWSUNEa/ttlY41xv+6cj5MiHKpPLVxKo8g/yd K26cDz/6PX7FjYyzgyaQmnBB+DuK0WUp3hfvdqoWSgty6cYhiNNbpapYDn5yUB5gvYIi Uw1pLxpwIfuXnplUiJV27tRvpejW8BIw+qdArhzFXz70ux2+iHQda1kqa0SBSwE+xirk z7LA== X-Gm-Message-State: AOAM530geB1CH4oIOFLLh/oqY2J1YfIeml4hbyqM8e1b24aeKYr4xLau bVEBZ2lhIQjQXuqO7qY0Cl1qQcCJJda90y4EYT8= X-Google-Smtp-Source: ABdhPJznQjhzuMrAa4kopkHKBCOglrBKqUvjFZ2wfSQuFPdngQpdH+k/w4G8qpOH3jZy+/fsWEiIsvc6heOCDCUGgvI= X-Received: by 2002:a05:6402:1778:: with SMTP id da24mr7769051edb.318.1635442673854; Thu, 28 Oct 2021 10:37:53 -0700 (PDT) MIME-Version: 1.0 References: <20211023232635.9195-1-sjg@chromium.org> <3fde4b98-e7c0-71c3-d7c4-22c6f43eae31@canonical.com> In-Reply-To: From: Peter Robinson Date: Thu, 28 Oct 2021 18:37:42 +0100 Message-ID: Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot To: Simon Glass Cc: Heinrich Schuchardt , Michal Simek , Tom Rini , 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 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. I do actually like a bunch of the ideas in here, random scripts in distro_boot were a big step forward for straight forward booting a decade or so when everything prior was random board specific boot.scr and uImage but things have evolved into booting via UEFI which is very standard across the general purpose compute devices style industries and clearing up the random behind the scenes hush scripting is definitely long overdue but I don't feel there needs to be another layer of unnecessary indirection here. > - Move all this stuff out of the environment so we can move to a > text-based environment that doesn't rely on ad-hoc CONFIG options > (this unblocks the 7-year-old CONFIG migration) > - Add proper tests to cover this important functionality (the scripts > have no tests) > (this makes development much easier and faster) > - Provide a path to booting more 'directly' without needing the CLI > (which adds size / security risk) > > This initial series is not the end of the matter. I expect various > other people will contribute to cover their use cases and additional > features, but at least now we have good basis for this development and > innovation. > > [..] > > Regards, > Simon