[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yk8qnxqXK7WZvXrS@robh.at.kernel.org>
Date: Thu, 7 Apr 2022 13:17:03 -0500
From: Rob Herring <robh@...nel.org>
To: Joel Peshkin <joel.peshkin@...adcom.com>
Cc: Rafał Miłecki <zajec5@...il.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Tom Rini <trini@...sulko.com>,
Florian Fainelli <f.fainelli@...il.com>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
"u-boot@...ts.denx.de" <u-boot@...ts.denx.de>,
Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>,
linux-kernel@...r.kernel.org,
Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant
binding
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
Powered by blists - more mailing lists