+Rob Herring oops
On Fri, 19 Nov 2021 at 17:04, Simon Glass <s...@chromium.org> wrote: > > 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 <s...@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 >
