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.