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 CA70AC433EF for ; Wed, 27 Oct 2021 18:33:38 +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 5140361039 for ; Wed, 27 Oct 2021 18:33:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5140361039 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 B5DB883498; Wed, 27 Oct 2021 20:33:36 +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="BdjPJUGi"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 65A8B83152; Wed, 27 Oct 2021 20:33:35 +0200 (CEST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 D888B83498 for ; Wed, 27 Oct 2021 20:33:31 +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-xa31.google.com with SMTP id bc10so1795631vkb.1 for ; Wed, 27 Oct 2021 11:33:31 -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=796RZg6dpe7/G+F1dve3kOw19GtJXuHGkKnymmUF2kw=; b=BdjPJUGiFo426k0BL2iX5UbYITF7thoMoPitH72PpnH0L4NLstCN56xxluJDwbxB9Y jjec6SR2OjJTmJ023AD0GKgTq5MlFl3FlOByTQtspVWA7/JUiOKaJdEJN4XWeRnzEeAM sXDKds8J9guPODB57sVlw+s+6ze7eHhVW83Dg= 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=796RZg6dpe7/G+F1dve3kOw19GtJXuHGkKnymmUF2kw=; b=gjioQg2LxZNtHt8u5OHI7A4UvvCk+ZZ888tJtVhv7G1inwpu/k9fNb+MLUNhPibkIG Orx80j/vqI5QbAiIJLDtsW2f24hexxKY3zE3MBKgUwH+c11Dq65lAUbMq7EzQxh16jkk XLxCKDdvHKdoj8i03IfUCCHR5VjLlXfQyuhronoih51yfSZEvFTcepl2YlFWkcpdFHmU ag/8tatgrgQPZ3RY3tdkmCduduEmQfHda2zH/aDQBOk9YI6swT6/bgE2AMZlXtCsHl2i V2Vs4tOP5IwN9L88RhvmkyI8h4bQwYxwo5VkCcTabedkzMukZe3X/k8muWaL8z0vHgGA 1Blg== X-Gm-Message-State: AOAM532xXKJ7x3LIwn/7x0tb52PfmFP1oaM9ZmbaGsMRk7EBTZVnyE0j mkTpT7oXZgQriiLPXRa5y+Zti7dZMmNaDIeg1PawbA== X-Google-Smtp-Source: ABdhPJx36WceFeu0BgbN/ULYfCyoyY48b8sWWpIOIA68RPRUWLN13gWg3lG9J41L3ElkFo+JUMrkpzMCcVaer3Cn0O8= X-Received: by 2002:a05:6122:1212:: with SMTP id v18mr20753609vkc.9.1635359610422; Wed, 27 Oct 2021 11:33:30 -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 12:33:19 -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? See previous email in thread. Continuing here on a few of your other points... > > 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? We already have this with distro boot, so nothing really changes there. Think of this as a generalised 'standard boot' implementation, which can support distro boot and anything else we need in the future. There is nothing required in the devicetree for normal operation. > > You still have an open discussion with Linaro about the source of > devicetrees. This discussion needs to be finalized before considering > this series. Why is that? They don't seem to be at all related to me. > > 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. See previous post, they are not defined in the devicetree. Can you suggest how I can change the language to make that clear? Regards, Simon > > > > > This series provides an implementation of these, enabled to scan for > > bootflows from MMC, USB and Ethernet. It supports the existing distro > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > similiarly to the existing script-based approach, but is native to > > U-Boot. > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > bootflow scan -lb > > > > which means to scan, listing (-l) each bootflow and trying to boot each > > one (-b). The final patch shows this. > > > > With a standard way to identify boot devices, booting become easier. It > > also should be possible to support U-Boot scripts, for backwards > > compatibility only. > > > > [..]