From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Wed, 3 Jun 2020 01:42:40 +0200 Subject: [PATCH] env: Add option to only ever append environment In-Reply-To: <20200602233227.GX21630@bill-the-cat> 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> <20200602233227.GX21630@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 6/3/20 1:32 AM, Tom Rini wrote: > 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? I have the env completely disabled in SPL, so it does not. >>>> 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. OK, then I can re-do this patch without the CONFIG_IS_ENABLED() and then add another #undef into the board config.