From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 6 May 2021 11:03:00 -0400 Subject: [PATCH v2 1/2] env: allow environment to be amended from control dtb In-Reply-To: <20210421090655.1458746-2-rasmus.villemoes@prevas.dk> References: <20210413224345.2692591-1-rasmus.villemoes@prevas.dk> <20210421090655.1458746-1-rasmus.villemoes@prevas.dk> <20210421090655.1458746-2-rasmus.villemoes@prevas.dk> Message-ID: <20210506150300.GM17669@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Apr 21, 2021 at 11:06:54AM +0200, Rasmus Villemoes wrote: > It can be useful to use the same U-Boot binary for multiple purposes, > say the normal one, one for developers that allow breaking into the > U-Boot shell, and one for use during bootstrapping which runs a > special-purpose bootcmd. Or one can have several board variants that > can share almost all boot logic, but just needs a few tweaks in the > variables used by the boot script. > > To that end, allow the control dtb to contain a /config/enviroment > node (or whatever one puts in fdt_env_path variable), whose > property/value pairs are used to update the run-time environment after > it has been loaded from its persistent location. > > The indirection via fdt_env_path is for maximum flexibility - for > example, should the user wish (or board logic dictate) that the values > in the DTB should no longer be applied, one simply needs to delete the > fdt_env_path variable; that can even be done automatically by > including a > > fdt_env_path = ""; > > property in the DTB node. > > Reviewed-by: Simon Glass > Signed-off-by: Rasmus Villemoes > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: