Dear Patrick,
In message 9c7801afb8c94c638933cf33746ae300@SFHDAG6NODE3.st.com you wrote:
And I agree the name seens not perfect.
- CONFIG_SPL_ENV_SUPPORT for SPL
- CONFIG_TPL_ENV_SUPPORT for TPL
These pre-existing name are defined in common/spl/Kconfig
With the same issue (env/common.o env/env.o are always compiled for SPL/TPL so it is alo bad names)
Correct.
So please reconsider this whole implementation, and make sure that only a single macro ise used everywhere to enable these features.
But, if I use the same CONFIG for the 3 binary SPL,TPL and U-Boot, l increase the size of TPL/SPL for all the platforms when these additional features are not needed.
Either the U-Boot environment makes use of these features, then they have to be enabled, and exactly the same way in SPL, TPL and U-Boot proper. Or you don't need them, then they can be disabled, but again in a consistent way in SPL, TPL, and U-Boot proper.
It is not acceptable to have for example .flags support in U-Boot, but not is SPL. If you cannot affort the size in SPL (and need environment there at all), then you cannot have it in U-Boot either. Yes, this is sad, but anything else would break the implementation of these features, and given that they are often used to implement some level of protection or security, introduce massive security issues.
So if SPL size is critical, you can try do not access the environment at all and omit _all_ of the environment code there; or you can try to arrange for a read-only implementation (omitting at least the code needed for "env save" including write routines to storage). But you CANNOT omit the extensions if these are present in U-Boot proper.
Best regards,
Wolfgang Denk