[PATCH v2] boot: add support for button commands

[Dragan Simic]

On 2024-01-18 16:11, 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.
> 
> Not sure locking down the whole environment is a good idea.

Not the entire environment, just the default button-command associations
supplied through CONFIG_EXTRA_ENV_SETTINGS.  I'm sorry if I didn't write
it clearly before.

>>>>> 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.
> 
> IIRC there is already a mechanism for that. Environment hooks
> or something like that. But I'm not sure that has other implications
> and qualify as simple and lightweight for this use-case.
> 
> Anyway, we digress. I just wanted to make you aware of another
> use-case, which btw. is already done today in the lsxl board for
> example.