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

From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] env: Add option to only ever append environment
Date: Tue, 2 Jun 2020 19:32:27 -0400	[thread overview]
Message-ID: <20200602233227.GX21630@bill-the-cat> (raw)
In-Reply-To: <56bcc881-c414-c129-aaa2-f9479488e72e@denx.de>

On Tue, Jun 02, 2020 at 09:06:42PM +0200, Marek Vasut wrote:
> 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,

Yes, so lets set that aside.

> I want to be able to configure
> my env handling whichever I need it to without working around problems
> like the ones below.

You're instead adding two others kinds of problems.  You're adding code
that would make use of a symbol that doesn't exist.  You're also adding
what seems like a non-functional runtime (we set the variable in full
U-Boot and can't read it in SPL).  So can you confirm that having this
enabled in full U-Boot but disabled in SPL does not result in the case
of a mismatch in the environment, in the case of having access to more
than just the default compiled environment?

> >> 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.

Then we should fix that.  But not every option is/should be listed in
triplicate.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200602/26c08ff2/attachment.sig>