[PATCH v2] boot: add support for button commands

[Dragan Simic]

On 2024-01-18 08:59, Michael Walle wrote:
>> Using CONFIG_EXTRA_ENV_SETTINGS should be good enough to provide
>> the fallback defaults.  However, the users can still mess the things 
>> up,
>> but again, they can do that already in many places.
> 
> I disagree. In my case that is a last resort recovery. And it should
> work in any case. Even if the user has messed up anything (except
> from erasing the bootloader in the SPI flash ;)).

Maybe the solution could be another compile-time option to "lock down" 
the built-in defaults provided through CONFIG_EXTRA_ENV_SETTINGS?  If 
that new option is selected, changes to the environment would make no 
changes to the built-in defaults, i.e. those parts of the environment 
would actually be ignored.

>>> In summary, the registered (compiled-in) command should always take
>>> precedence. If one wants to supply a default command which can be
>>> changed later, that can go via the (compiled-in) default environment.
>> 
>> Sorry, this is a bit confusing to me.  Didn't you write above that
>> the users should be able to change the associated commands through
>> the environment variables?
> 
> I had two kinds of button commands in mind: immutable ones and mutable
> ones. The first can be achieved with compiled-in commands, the second
> with a default environment and environment variables.
> 
> Also, whether a command is a mutable one or not is the decision of
> the developer (or the one who's compiling/configuring u-boot),
> not the user.

I believe that the additional compile-time option, which I proposed 
above, could be extended to specify which of the built-in default 
button-command associations are immutable, and which are allowed to be 
modified through the environment variables.