diff options
| author | Rasmus Villemoes <rasmus.villemoes@prevas.dk> | 2021-04-21 11:06:54 +0200 |
|---|---|---|
| committer | Tom Rini <trini@konsulko.com> | 2021-05-04 11:50:50 -0400 |
| commit | 95fd9772011f29fad2c40fbc3060b5dac042152c (patch) | |
| tree | e06d8d10b7e5cd0b011372786ae918067b982d3e /common/board_r.c | |
| parent | 1cbfed8d3e9254d7e2a9466498ef867f7cb3f4cd (diff) | |
env: allow environment to be amended from control dtb
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 <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Diffstat (limited to 'common/board_r.c')
| -rw-r--r-- | common/board_r.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/common/board_r.c b/common/board_r.c index c835ff8e26..3f82404772 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -459,6 +459,8 @@ static int initr_env(void) else env_set_default(NULL, 0); + env_import_fdt(); + if (IS_ENABLED(CONFIG_OF_CONTROL)) env_set_hex("fdtcontroladdr", (unsigned long)map_to_sysmem(gd->fdt_blob)); |