From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 2 Jun 2020 19:32:27 -0400 Subject: [PATCH] env: Add option to only ever append environment In-Reply-To: <56bcc881-c414-c129-aaa2-f9479488e72e@denx.de> References: <02e0326f-c93c-da9e-e0ec-dd3bc2dc9e4a@prevas.dk> <20200602124450.GA21630@bill-the-cat> <20200602143848.GH21630@bill-the-cat> <098da29c-9457-9a8e-7ca2-67b71d3df8f9@denx.de> <20200602160000.GM21630@bill-the-cat> <20200602173627.GN21630@bill-the-cat> <56bcc881-c414-c129-aaa2-f9479488e72e@denx.de> Message-ID: <20200602233227.GX21630@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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: