Hi Wolfgang and Tom, > From: Wolfgang Denk <w...@denx.de> > Sent: lundi 7 octobre 2019 19:57 > > Dear Patrick, > > In message <20191003072428.19197-1-patrick.delau...@st.com> you wrote: > > > > This patchset follow > > > > http://patchwork.ozlabs.org/project/uboot/list/?series=131268&state=* > > > > It follow the first proposal > > http://patchwork.ozlabs.org/project/uboot/list/?series=129339 > > "env: Add CONFIG_ENV_SUPPORT" > > Do I understand correctly that all of this is obsolete and no longer needed > after > Tom's commit d90fc9c3de ``Revert "env: solve compilation error in SPL"'' ?
The revert is a solution of the intial regression. A other solution only to correct he regression was the first patch of the serie [U-Boot,v4,1/3] env: correct the check of env_flags_validate presence http://patchwork.ozlabs.org/patch/1171096/ But I am OK with Tom decision to just revert my initial patch. The two other patch of the serie is a proposal after your remarks in: http://patchwork.ozlabs.org/patch/1157174/ = This scares me. Why are there different settings for SPL, TPL and = U-Boot proper? This looks conceptually broken to me - if a system = is configured to use a specific set of environment features and = extensions, then the exact same settings must be use in all of SPL, = TPL and U-Boot proper. .... = So please reconsider this whole implementation, and make sure that = only a single macro ise used everywhere to enable these features. Today in v2010.10 with have ENV attribute / callback / flags 1/ always used in U-Boot proper 2/ optional in SPL/TPL (CONFIG_SPL_ENV_SUPPORT & CONFIG_TPL_ENV_SUPPORT) In env:Makefile : obj-y += common.o env.o ifndef CONFIG_SPL_BUILD obj-y += attr.o obj-y += callback.o obj-y += flags.o else obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o endif Perhaps I not correctly understood the initial issue, but I do my best to have the same level of ENV features (CONFIG_ENV_FULL_SUPPORT activate the features and extensions= attribute / callback / flags) between U--Boot proper, SPL and TPL. With the serie => when read from device (ENV_IS_IN....) is not supported ENV is still supported in SPL/TPL with (SPL_TPL_)ENV_IS_NOWHERE with same feature level than U-Boot (only the default env is supported) => the only remaining issue today after my serie is the size of this default environment (default_environment[]) in SPL and TPL. The content of this variable need to have the same content in SPL/TPL than in U-Boot proper ? However if I not correctly understood the initial issue around ENV and security, and if the current ENV code behavior is enough for you,Wolfgang and Tom, or any other maintainers interested by ENV, I will abandon the serie. PS: I can change also the serie as RFC.... to have more feedback > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The > scientists of today think deeply instead of clearly. One must be sane to > think > clearly, but one can think deeply and be quite insane. > - Nikola Tesla Regards Patrick _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
