[U-Boot] [PATCH v4 0/3] env: Add CONFIG_ENV_FULL_SUPPORT

Patrick DELAUNAY patrick.delaunay at st.com
Mon Oct 14 14:46:25 UTC 2019

Hi Wolfgang and Tom,

> From: Wolfgang Denk <wd at denx.de>
> Sent: lundi 7 octobre 2019 19:57
> Dear Patrick,
> In message <20191003072428.19197-1-patrick.delaunay at 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

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:

= 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

In env:Makefile :

obj-y += common.o env.o

obj-y += attr.o
obj-y += callback.o
obj-y += flags.o
obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o

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: wd at 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



More information about the U-Boot mailing list