[PATCH] env: Add option to only ever append environment

From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [PATCH] env: Add option to only ever append environment
Date: Tue, 2 Jun 2020 21:06:42 +0200	[thread overview]
Message-ID: <56bcc881-c414-c129-aaa2-f9479488e72e@denx.de> (raw)
In-Reply-To: <20200602173627.GN21630@bill-the-cat>

On 6/2/20 7:36 PM, Tom Rini wrote:
[...]
>>>>>> One will append the environment, the other will override it (if you have
>>>>>> multiple envs enabled).
>>>>>
>>>>> So it sounds like it wouldn't be valid to have this option differ
>>>>> between SPL and main U-Boot?
>>>>
>>>> Consider the case where you have default env in SPL, and multiple envs
>>>> in U-Boot proper.
>>>
>>> Yes, today you can end up with cases where you build something that doesn't
>>> work as intended (likely something around falcon boot and/or boot count
>>> limit in env).  Which is what I'm getting at here.  Is there some
>>> cases where it would make any sense to enable this option in full U-Boot
>>> but disable it in SPL?
>>
>> Yes, like my current use case, where I want to configure the SPL
>> differently than U-Boot itself. SPL doesn't even have environment
>> support enabled, but it might be needed later.
> 
> Sorry I wasn't clear enough.  Does it make sense (when? how?) to have
> environment in SPL but mismatch this feature?

If you have only one env source in SPL and multiple in U-Boot for
example. But this is besides the point, I want to be able to configure
my env handling whichever I need it to without working around problems
like the ones below.

>> And also, I don't want to end up in the same problem we currently have
>> e.g. with USB gadget, where I have to manually #ifdef CONFIG_SPL_BUILD
>> #undef CONFIG_ options in the board config file.
> 
> Yes, don't do that, I've had to fix a few of those of late in catching
> converted but still in config header options.

This is the result of not having a dedicated SPL/TPL config options though.