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 D1C20C433F5 for ; Wed, 27 Oct 2021 14:11:22 +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 5321760EFE for ; Wed, 27 Oct 2021 14:11:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5321760EFE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 ACD67835D7; Wed, 27 Oct 2021 16:11:20 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="N3/y1mnj"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 47508835EA; Wed, 27 Oct 2021 16:11:19 +0200 (CEST) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 BAEB0835D3 for ; Wed, 27 Oct 2021 16:11:15 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-vk1-xa2a.google.com with SMTP id u130so1424215vku.2 for ; Wed, 27 Oct 2021 07:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2ygIz9qSkNf/j0/bhiBcmyjZWFcYwATyUu31xw+TWTk=; b=N3/y1mnjD8iAcMtOE0+AFzyytveqe6+spVTjL2qYdmiBV1DArxb2kegwKAtzP9iZaO 4LVlF+2XBILKajB55+SlfYbMNfG9ASbsG3sqX+DlW/eULoFoeUvNkd/y+18RJJZdG2U4 e2r+OZuyk3hJUkqbRp6spEj0d6i7GApT7TZB8= 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=2ygIz9qSkNf/j0/bhiBcmyjZWFcYwATyUu31xw+TWTk=; b=SB08W76hk6PMnyjuIduxXpSSVVakJ8cMbmbga6O5l3lZIeoYx6a5ZdxXvWK+oQWFKV j7h7Ev2/SP5AuSUkHZRnIvSJNjSpMWYEmnFyudLVAvW3fBRe+LXPF7We+PVWoVv7KKAP k5j439RfPYW+qACRLq2KNTHTz5j+T1Nj0xIpEf7bxZkpXngR9T/itornZbZgpcyYIkyM qyuiS8aHgnWrDr4TYwXss1VLoqvdjlLlRs7LmB027f3iExMy2aL2hfAOsLc8OAyGsf0C ctO27QW8PP67Zh+wkC/TjfQw8dwJsISnqgAd5bNyW23X+A/PUsbo/fjQqSC9t1EH7yyV 76Dg== X-Gm-Message-State: AOAM530yweO0kntEp/pvHaVwiRWQFXU81o7yOGuMcetLnAEv+l8Fp7Vm 8T0TQxzmNP91m9BF4HGMNfom0GvQHgirCM9CzzQf3g== X-Google-Smtp-Source: ABdhPJzem5Jq/M4NSJL66q+ZFcpeBm1xT3UWyfGcaUuvj3qPhdkvzStQbQJCCanZ4mkBsTl7Nx+zDlVqKgnQDr93sKQ= X-Received: by 2002:a05:6122:1212:: with SMTP id v18mr18984318vkc.9.1635343874205; Wed, 27 Oct 2021 07:11:14 -0700 (PDT) MIME-Version: 1.0 References: <20211023232635.9195-1-sjg@chromium.org> <3fde4b98-e7c0-71c3-d7c4-22c6f43eae31@canonical.com> In-Reply-To: <3fde4b98-e7c0-71c3-d7c4-22c6f43eae31@canonical.com> From: Simon Glass Date: Wed, 27 Oct 2021 08:11:03 -0600 Message-ID: Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot To: Heinrich Schuchardt Cc: 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 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) - 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