devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: devicetree@vger.kernel.org
Cc: Tom Rini <trini@konsulko.com>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Simon Glass <sjg@chromium.org>
Subject: [PATCH] dt-bindings: u-boot: Add a few more options bindings
Date: Fri, 19 Nov 2021 17:03:56 -0700	[thread overview]
Message-ID: <20211120000356.1850639-1-sjg@chromium.org> (raw)

This adds three new options with varying degree of interest / precedent.

This being sent to the mailing list since it might attract more review.
A PR will be sent when this has had some review. That is why the file
path is set up for https://github.com/devicetree-org/dt-schema rather
than the Linux kernel.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 schemas/options/u-boot.yaml | 51 +++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/schemas/options/u-boot.yaml b/schemas/options/u-boot.yaml
index 71dfda7..b8bdec1 100644
--- a/schemas/options/u-boot.yaml
+++ b/schemas/options/u-boot.yaml
@@ -71,6 +71,37 @@ properties:
       2: use simplified command line (e.g. avoid hush)
       3... reserved
 
+  load-environment:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    default: 1
+    maximum: 1
+    description: |
+      This allows control over whether U-Boot loads its environment after
+      relocation. This normally happens automatically, but can pose a security
+      risk, so disabling it in certain situations is useful.
+
+      Note: This could be a boolean. It is defined as an integer since that
+      allows changing the value without resizing the devicetree. I'm not sure
+      how ugly that is, but IMO the fact that 'false' boolean values are
+      represented by being missing is a bit of a pain. One must either add or
+      delete the property.
+
+      Values:
+
+      0: don't load the environment
+      1: do load the environment
+
+  no-apm-final:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description: |
+      For devices running on coreboot, this tells U-Boot not to lock down the
+      Intel Management Engine (ME) registers. This allows U-Boot to access the
+      hardware more fully for platforms that need it.
+
+      Absence of this property indicates that the ME registers should be locked
+      down as part of U-Boot's start-up sequence and before the command line is
+      available.
+
   silent-console:
     $ref: /schemas/types.yaml#/definitions/uint32
     default: 0
@@ -88,6 +119,23 @@ properties:
         enabled)
       2: console output is suppressed and not recorded
 
+  spl-payload-offset:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    default: 0
+    description: |
+      If present (and SPL is controlled by the devicetree), this allows the
+      offset of the SPL payload (typically U-Boot) to be specified. The offset
+      is in bytes from the start of the media (typically SPI flash).
+
+      Note: This is quite widely used in U-Boot, but since v2018.01 it is
+      possible to use Binman instead, to provide this offset (and various
+      others) to SPL, or even to U-Boot proper. So far I have not tried sending
+      the Binman bindings upstream, but perhaps that should be done instead.
+
+      See here for details:
+
+      https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-description-format
+
 required:
   - compatible
 
@@ -101,6 +149,9 @@ examples:
         bootcmd = "vboot go auto";
         bootdelay-sec = <(-1)>;
         bootsecure = <1>;
+        load-environment = <0>;
+        no-apm-final;
         silent-console = <1>;
+        spl-payload-offset = <0x40000>;   /* 256K */
       };
     };
-- 
2.34.0.rc2.393.gf8c9666880-goog


             reply	other threads:[~2021-11-20  0:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-20  0:03 Simon Glass [this message]
2021-11-20  0:13 ` [PATCH] dt-bindings: u-boot: Add a few more options bindings Simon Glass
2021-11-27  2:41   ` Simon Glass
2021-12-09 21:28 ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211120000356.1850639-1-sjg@chromium.org \
    --to=sjg@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).