[PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant binding

[Joel Peshkin]

On Thu, Apr 7, 2022 at 11:17 AM Rob Herring <robh at kernel.org> wrote:
>
> On Thu, Apr 07, 2022 at 04:55:14AM -0700, Joel Peshkin wrote:
> > Hi Rafal,
> >
> >    The first 32b value is a magic number (endian swapped mnemonic of
"uEnv"
> > short for "u-boot environment").   Finding that magic number of a 4K
> > boundary followed by a length and then a u-boot environment with a valid
> > CRC permits a scan of the flash partition to locate the environment
without
> > knowing a-priori where it is.
>
> So it doesn't need to be described in DT? But how does one identify
> whether to scan the flash or not. You wouldn't want to do that one every
> platform. IOW, it's a sufficient discovery mechanism for a custom build,
> but not generic OS.
>
> Rob

Hi Rob,

  I'm not sure how much of this you would want to try to upstream (this is
actually the reason why we didn't attempt to upstream it ourselves).
There is quite
a chicken-and-egg problem with using the DT.  I'll explain here in case the
explanation is useful but I don't think there is a good path to upstreaming all
of it.

  Our early boot loader (SPL) doesn't even know where the FIT image lives
until it has the uboot environment.   Once the environment is found (using
the magic number
and the CRC check I described earlier), there are variables within the
environment that are used to find the device in which the FIT image is
located, DTB included.
There is also a variable, env_boot_magic that identifies the physical
offset (after any skipbb has been done) of all of the copies of the
environment.  For example,

env_boot_magic=16384 at 0x40000,0xaa000

  This value is written after the image is first recorded with skipbb and
is used to ensure that, even if one copy were to be corrupted by something
like a powerfail during
write, all copies are restored when there is a write or a refresh.

   I would be happy to upstream this if we could find a decent way to make
it fit.

Regards,

Joel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4209 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220408/f82a341e/attachment.bin>