How to avoid the need to run 'env default' command on modified env variable

How to avoid the need to run 'env default' command on modified env variable

[Mircea Carausu]

Hi All,
apologies in advance if my question is trivial:

I am changing some critical variables in the read-only / compiled-in
section of u-boot env variables via CFG_EXTRA_ENV_SETTINGS in
include/configs/<my_board.h>
All I want is to have them take effect automatically (i.e. without having
the need to stop in u-boot console and issue the env default command).
I see the new values if I use the env default command.
Since I am applying the new config via a RAUC bundle and some systems are
using automated testing it is not practical to issue env default on each
board.
Is there a way of telling u-boot to load / use the read-only / built-in
values instead of the ones stored in env storage?
Current behavior I am seeing in my setup is that old values stored in  env
take precedence.
I have dedicated storage in eMMC for env variables, which is configured via
<my_board>_a53_defconfig  like this:
CONFIG_ENV_OFFSET=0x3e0000
CONFIG_ENV_OFFSET_REDUND=0x3e0000
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y

My platform is a TI Am64x.

Thank you in advance for your attention.

Thank you,
Mircea

Re: How to avoid the need to run 'env default' command on modified env variable

[Quentin Schulz]

Hi Mirceam

On 8/11/25 6:30 AM, Mircea Carausu wrote:
> [You don't often get email from mcarausu@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi All,
> apologies in advance if my question is trivial:
> 
> I am changing some critical variables in the read-only / compiled-in
> section of u-boot env variables via CFG_EXTRA_ENV_SETTINGS in
> include/configs/<my_board.h>
> All I want is to have them take effect automatically (i.e. without having
> the need to stop in u-boot console and issue the env default command).
> I see the new values if I use the env default command.
> Since I am applying the new config via a RAUC bundle and some systems are
> using automated testing it is not practical to issue env default on each
> board.
> Is there a way of telling u-boot to load / use the read-only / built-in
> values instead of the ones stored in env storage?

Build U-Boot without external environment support?

E.g. with only ENV_IS_NOWHERE?

You can also entirely and permanently erase the stored environment with 
`env erase` if you have CONFIG_CMD_ERASEENV enabled.

If that's not fitting your use-case can you provide more information please?

Cheers,
Quentin

Re: How to avoid the need to run 'env default' command on modified env variable

[Mircea Carausu]

Hi Quentin,
Thank you for your reply.
I wish it would be that simple:
- as mentioned we are using RAUC for firmware upgrade (https://rauc.io/)
and A/B partitions. RAUC needs some u-boot env variables to point to the
active slot to load and it maintains a retry count.
(all of this is implemented with help from u-boot env variables, which have
to be writable).
I thought of erasing the entire u-boot env or corrupting the CRC signature
to force loading the defaults. I can do that from Linux also - prior to
reboot.
In this way I lose two things:
 - the active slot info that RAUC uses to point to the partition I just
programmed.
- the MAC address of the eth interfaces - perhaps for this there is a flag
to protect it (i.e. write once type of attribute).

I can think of working around these  obstacles - just fearing I am
reinventing the wheel when u-boot may already have a simpler way - hence
the question.
If there is no simple way in u-boot I will probably end up writing a RAUC
hook to do some of the automation  I need before rebooting.
Thank you,
Mircea


On Mon, Aug 11, 2025 at 9:00 AM Quentin Schulz <quentin.schulz@cherry.de>
wrote:

> Hi Mirceam
>
> On 8/11/25 6:30 AM, Mircea Carausu wrote:
> > [You don't often get email from mcarausu@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi All,
> > apologies in advance if my question is trivial:
> >
> > I am changing some critical variables in the read-only / compiled-in
> > section of u-boot env variables via CFG_EXTRA_ENV_SETTINGS in
> > include/configs/<my_board.h>
> > All I want is to have them take effect automatically (i.e. without having
> > the need to stop in u-boot console and issue the env default command).
> > I see the new values if I use the env default command.
> > Since I am applying the new config via a RAUC bundle and some systems are
> > using automated testing it is not practical to issue env default on each
> > board.
> > Is there a way of telling u-boot to load / use the read-only / built-in
> > values instead of the ones stored in env storage?
>
> Build U-Boot without external environment support?
>
> E.g. with only ENV_IS_NOWHERE?
>
> You can also entirely and permanently erase the stored environment with
> `env erase` if you have CONFIG_CMD_ERASEENV enabled.
>
> If that's not fitting your use-case can you provide more information
> please?
>
> Cheers,
> Quentin
>

Re: How to avoid the need to run 'env default' command on modified env variable

[Rasmus Villemoes]

On Mon, Aug 11 2025, Mircea Carausu <mcarausu@gmail.com> wrote:

> Hi Quentin,
> Thank you for your reply.
> I wish it would be that simple:
> - as mentioned we are using RAUC for firmware upgrade (https://rauc.io/)
> and A/B partitions. RAUC needs some u-boot env variables to point to the
> active slot to load and it maintains a retry count.
> (all of this is implemented with help from u-boot env variables, which have
> to be writable).
> I thought of erasing the entire u-boot env or corrupting the CRC signature
> to force loading the defaults. I can do that from Linux also - prior to
> reboot.

You could/should have a post-install hook that takes care of updating the
U-Boot env after you've installed the new bootloader.

But, why are these "critical variables" _variables_ in the first place?
Can you explain what they are used for and how, and why the consuming
code in U-Boot reads them from the environment?

We also use RAUC, but we've mostly abandoned the use of the U-Boot
environment for the RAUC bookkeeping variables, as a writable
environment is fundamentally incompatible with secure boot. I.e., we
still use that for POC projects, but eventually we do something
else. So this problem is mostly moot for us (as our U-Boot env is static
and built-in), but we did use to have logic for updating it: We use the
DEFAULT_ENV_FILE mechanism for defining the whole environment in a text
file, and as part of generating that, we also generate a version of it
that can be used in such a post-install hook. Quoting from our Yocto
meta-data:

    # uboot-env.txt will be used below, and by the u-boot recipe
    # itself to create the built-in environment. For both mkenvimage
    # and u-boot's build system, it has to be in "var=value"
    # format.

    # An unset variable is indistinguishable from one with an empty
    # value, at least in the U-boot shell, so comment out definitions
    # of such variables. [*]

    sed -e 's/^\([^=]*=\)$/# \1/' ${S}/uboot.txt > ${S}/uboot-env.txt

    # Create version suitable as a "script" to fw_setenv: Replace
    # first = by a space.

    # When updating the bootloader, we do not replace the environment
    # with the vanilla environment from this recipe, as that would
    # wipe RAUC status and other things that should not get
    # removed. Instead, we run fw_setenv with uboot-env.update as -s
    # argument. The effect is that variables set in this environment
    # take effect, while those that are not mentioned here are
    # preserved (RAUC status, maybe eth address, device serial number,
    # etc.).

    # This is not perfect, but just a reasonable heuristic. In any
    # case, updating the bootloader should be handled with great care.

    # If a "run-time" variable should explicitly be deleted by the
    # update, assign an empty value. This is also the reason for [*]
    # above: If we had an empty definition of foobar in the original
    # environment, and the update has the same environment, fw_setenv
    # would react to the empty value for foobar by deleting it, so the
    # update wouldn't really be a no-op.

    sed -e 's/=/ /' ${S}/uboot.txt > ${S}/uboot-env.update

Rasmus