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 10AFBC433EF for ; Mon, 4 Oct 2021 19:30:44 +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 083FB61354 for ; Mon, 4 Oct 2021 19:30:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 083FB61354 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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 09FCD83178; Mon, 4 Oct 2021 21:30:40 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 9F5A583176; Mon, 4 Oct 2021 21:30:37 +0200 (CEST) Received: from mail-oo1-f46.google.com (mail-oo1-f46.google.com [209.85.161.46]) (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 37A8F82C90 for ; Mon, 4 Oct 2021 21:30:33 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=robherring2@gmail.com Received: by mail-oo1-f46.google.com with SMTP id j11-20020a4a92cb000000b002902ae8cb10so5707094ooh.7 for ; Mon, 04 Oct 2021 12:30:33 -0700 (PDT) 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=02S49qZan5P9pcQBODqwhVWORBdgxGhsFL7lo9suVgE=; b=HZoP8SexKyZN0scxPE0atLaae7e9ipFDeBZ864YAXMziB9nvhIC0KK+0XV/Pz5qihb APqtMOeebhhLJlL/zecmiRPsGnqRFGLWy6lvnxPg9xhRqeP5ZsR/oLsj3hY8DdDNWw5b RhoFHROrZrYgXmCCQZKxu1TPhtXL9ZRHyYzPkgDuhRcu6Sd/I1i6hp3flnTs/MPz+/tR RpWQKSv1d5691bIpYlKw+prC03/aO4Sp8ExdbBwqsTRGZSI7BUXz0b1lUQuaCi5Su9Om OAvy6s3LfHzxMXwIGrg0nOxT/9gWUzJ/A6CTFoRn4mjWaaqcKq5leul6hLT2Mcq/8PQx TiBw== X-Gm-Message-State: AOAM530/MrJBXv0PjMbtiz3/WAx49fiVZevaZe4u8lG56pGvZtrK5gTo uWwYOtRzuF2HklL9bvKgyw== X-Google-Smtp-Source: ABdhPJx45WNtT8iFmQcSMc4Lfdp3BUIOVf53ojw34cpccbwB8CIbVWSsF/XIAejEr0cZmr3ii3FKtQ== X-Received: by 2002:a4a:a9ce:: with SMTP id h14mr10267521oon.89.1633375831424; Mon, 04 Oct 2021 12:30:31 -0700 (PDT) Received: from robh.at.kernel.org (66-90-148-213.dyn.grandenetworks.net. [66.90.148.213]) by smtp.gmail.com with ESMTPSA id l19sm3073199ota.17.2021.10.04.12.30.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 12:30:30 -0700 (PDT) Received: (nullmailer pid 1708016 invoked by uid 1000); Mon, 04 Oct 2021 19:30:29 -0000 Date: Mon, 4 Oct 2021 14:30:29 -0500 From: Rob Herring To: Simon Glass Cc: devicetree@vger.kernel.org, Tom Rini , U-Boot Mailing List , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config Message-ID: References: <20211003125134.2.I7733f5a849476e908cc51f0c71b8a594337fbbdf@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211003125134.2.I7733f5a849476e908cc51f0c71b8a594337fbbdf@changeid> 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 Sun, Oct 03, 2021 at 12:51:53PM -0600, Simon Glass wrote: > U-Boot makes use of the devicetree for its driver model. Devices are bound > based on the hardware description in the devicetree. > > Since U-Boot is not an operating system, it has no command line or user > space to provide configuration and policy information. This must be made > available in some other way. > > Therefore U-Boot uses devicetree for configuration and run-time control > and has done for approximately 9 years. This works extremely well in the > project and is very flexible. However the bindings have never been > incorporated in the devicetree bindings in the Linux tree. This could be > a good time to start this work as we try to create standard bindings for > communicating between firmware components. > > Add an initial binding for this node, covering just the config node, which > is the main requirement. It is similar in concept to the chosen node, but > used for passing information between firmware components, instead of from > firmware to operating system. > > Signed-off-by: Simon Glass > --- > Please be kind in your review. Some words about why this is needed are > included in the description in config.yaml file. > > The last attempt to add just one property needed by U-Boot went into the > weeds 6 years ago, with what I see as confusion about the role of the > chosen node in devicetree[1]. > > I am trying again in the hope of reaching resolution rather than just > going around in circles with the 'devicetree is a hardware description' > argument :-) > > Quoting from the introduction to latest devicetree spec[2]: > > >>> > To initialize and boot a computer system, various software components > interact. Firmware might perform low-level initialization of the system > hardware before passing control to software such as an operating system, > bootloader, or hypervisor. Bootloaders and hypervisors can, in turn, > load and transfer control to operating systems. Standard, consistent > interfaces and conventions facilitate the interactions between these > software components. In this document the term boot program is used to > generically refer to a software component that initializes the system > state and executes another software component referred to as a client > program. > <<< > > This clearly envisages multiple software components in the firmware > domain and in fact that is the case today. They need some way to > communicate configuration data such as memory setup, runtime-feature > selection and developer conveniences. Devicetree seems ideal, at least for > components where the performance / memory requirements of devicetree are > affordable. > > I hope that the Linux community (which owns the devicetree bindings) finds > this initiative valuable and acceptable. Owns? I'm having a sale and can make you a good offer. Buy 1 binding, get 2000 free. :) > > [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html > [2] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 > > .../devicetree/bindings/u-boot/config.yaml | 137 ++++++++++++++++++ > 1 file changed, 137 insertions(+) > create mode 100644 Documentation/devicetree/bindings/u-boot/config.yaml Might as well put this into dt-schema rather than the kernel. But might get more review here first. > diff --git a/Documentation/devicetree/bindings/u-boot/config.yaml b/Documentation/devicetree/bindings/u-boot/config.yaml > new file mode 100644 > index 00000000000000..336577a17fdf5a > --- /dev/null > +++ b/Documentation/devicetree/bindings/u-boot/config.yaml > @@ -0,0 +1,137 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/u-boot/config.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: U-Boot configuration node > + > +maintainers: > + - Simon Glass > + > +description: | > + The config node does not represent a real device, but serves as a place > + for passing data between firmware elements, like memory maps. Data in the > + config node does not represent the hardware. It is ignored by operating > + systems. > + > + Purpose of config node > + ---------------------- > + > + A common problem with firmware is that many builds are needed to deal with the > + slight variations between different, related models. For example, one model > + may have a TPM and another may not. Devicetree provides an excellent solution > + to this problem, in that the devicetree to actually use on a platform can be > + injected in the factory based on which model is being manufactured at the time. > + > + A related problem causing build proliferation is dealing with the differences > + between development firmware, developer-friendly firmware (e.g. with all > + security features present but with the ability to access the command line), > + test firmware (which runs tests used in the factory), final production > + firmware (before signing), signed firmware (where the signatures have been > + inserted) and the like. Ideally all or most of these should use the same > + U-Boot build, with just some options to determine the features available. For > + example, being able to control whether the UART console or JTAG are available, > + on any image, is a great debugging aid. > + > + When the firmware consists of multiple parts (various U-Boot phases, TF-A, > + OP-TEE), it is helpful that all operate the same way at runtime, regardless of > + how they were built. This can be achieved by passing the runtime configuration > + (e.g. 'enable UART console', 'here are your public keys') along the chain > + through each firmware stage. It is frustrating to have to replicate a bug on > + production firmware which does happen on developer firmware, because they are > + completely different builds. > + > + The config node provides useful functionality for this. It allows the different > + controls to be 'factored out' of the U-Boot binary, so they can be controlled > + separately from the initial source-code build. The node can be easily updated > + by a build or factory tool and can control various features in U-Boot. It is > + similar in concept to a Kconfig option, except that it can be changed after > + U-Boot is built. > + > + The config node is similar in concept to /chosen (see chosen.txt) except that chosen.yaml now (in dt-schema). > + it is for passing information *into* and *between) firmware components, > + instead of from firmware to the Operating System. Also, while operating > + systems typically have a (sometimes extremely long) command line, U-Boot does > + not support this, except with sandbox. The devicetree provides a more > + structured approach in any case. What about having a /chosen/u-boot/ node instead? > + > +properties: > + > + compatible: > + enum: > + - "u-boot,config" nit: don't need quotes. > + > + bootcmd: > + $ref: /schemas/types.yaml#/definitions/string > + description: | > + Allows overwriting of the boot command used by U-Boot on startup. If > + present, U-Boot uses this command instead. Note that this feature can > + work even if loading the environment is disabled, e.g. for security > + reasons. See also bootsecure. > + > + bootdelay: bootdelay-sec > + $ref: /schemas/types.yaml#/definitions/int32 And then you don't need a type. (Though we've defined '-sec' as unsigned, I think that's safe to change. In any case, signedness is kind of broken in the dts->dtc->yaml flow ATM.) > + description: | > + Allows selecting of the U-Boot bootdelay, to control whether U-Boot > + waits on boot or for how long. This allows this option to be configured > + by the build system or by a previous-stage binary. For example, if the > + images is being packed for testing or a user holds down a button, it may > + allow a delay, but disable it for production. > + > + If this property is not present, a default value is used instead. > + > + Values: > + > + -1: no bootdelay and the user cannot interrupt boot > + 0: no bootdelay but use user can still interrupt boot by holding down a > + key, if enabled > + >= 1: delay for this many seconds > + > + > + bootsecure: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: | > + Controls the execution of the boot command in U-Boot, e.g. selecting > + between using a special function to run commands, or the normal CLI. This > + can be used in production images, to restrict the amount of parsing done > + or the options available, to cut back on the available surface for > + security attacks. > + > + Values: > + > + 0: normal boot using CLI (default if not present) > + 1: use secure boot mechanism instead to parse and run commands > + other values are reserved for future use > + 2: use simplified command line (e.g. avoid hush) > + 3... reserved Add constraints: default: 0 maximum: 2 > + > + silent-console: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: | > + This allows the console to be silenced by default on boot. This can allow > + easy disabling of console output on a production build, for example. When > + suppressed, the console is still active. This feature only suppresses the > + console output itself, on all output devices. > + > + Values: > + > + 0: console output appears as normal (default) > + 1: console output is suppressed but console recording still operates (if > + enabled) > + 2: console output is suppressed and not recorded default: 0 maximum: 2 > + > +required: > + - compatible > + > +additionalProperties: false > + > +examples: > + - | > + u-boot,config { > + compatible = "u-boot,config"; > + bootcmd = "vboot go auto"; > + bootdelay = <(-1)>; > + bootsecure = <1>; > + silent-console = <1>; > + }; > -- > 2.33.0.800.g4c38ced690-goog > >