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

[Patrick DELAUNAY]

Hi Tom,

> From: Tom Rini <trini at konsulko.com>
> Sent: vendredi 20 septembre 2019 21:03
> 
> On Fri, Sep 20, 2019 at 11:09:14AM +0200, Stefan Roese wrote:
> > Hi Patrick,
> >
> > On 18.09.19 11:29, Patrick Delaunay wrote:
> > >This patchset is a the 3rd version of
> > >   http://patchwork.ozlabs.org/project/uboot/list/?series=129339
> > >   "env: Add CONFIG_ENV_SUPPORT"
> > >
> > >The first patch of the serie only solves the regression introduced by
> > >commit 7d4776545b0f ("env: solve compilation error in SPL");
> > >change_ok was always NULL in U-Boot.
> > >See "U-Boot: Environment flags broken for U-Boot" mail
> > >http://u-boot.10912.n7.nabble.com/U-Boot-Environment-flags-broken-for
> > >-U-Boot-tt382673.html
> > >
> > >This first patch can be integrated in master branch for v2019.10 as
> > >requested Tom Rimi.
> > >
> > >The next patches of the serie is a proposal after Wolfgang Denk
> > >review on the first proposal: I make the env support coherent between
> > >U-Boot, SPL and TPL.
> > >
> > >I need to change many defconfig (to add
> > >CONFIG_(SPL/TPL)_ENV_IS_NOWHERE) because I modify the dependency
> between the CONFIG used by SPL.
> > >
> > >Moreover the size of SPL increase after this last patch.
> > >
> > >For example on stm32mp15_basic, the SPL sizes:
> > >
> > >   62024	   4616	    892	  67532	  107cc	spl/u-boot-spl 00003e6c
> > >
> > >increase by 250 byte to
> > >
> > >   62274	   4640	    896	  67810	  108e2	spl/u-boot-spl 00003f56
> > >
> > >And the patch also breaks the compilation of few boards, when SPL
> > >size is near to its limit (.sram overflowed in SPL or SPL image too big):
> > >  imx6q_logic (by 1572 bytes)
> > >  omap3_logic_somlv (by 220 bytes)
> > >  omap3_logic (by 276 bytes)
> > >  omap35_logic_somlv (by 156 bytes)
> > >  omap35_logic (by 3064 bytes)
> > >  smartweb (by 408 bytes)
> > >  duovero (by 952 bytes)
> > >  x600 (by 1624 bytes)
> > >
> > >So the last patch can't be integrated today with these errors but any
> > >review and advice are welcome.
> >
> > I'm looking into this because of the x600 breakage. So this patchset
> > increases the SPL image size because all the environment "features"
> > are now also available in SPL (please correct me if I'm wrong). In the
> > case of x600 (IIRC), env is not used at all in the SPL stage.
> > Perhaps it would be possible to (optionally) remove the environment
> > support completely from SPL/TPL in such cases?
> 
> As part of correcting things here, we need to be able to have boards
> either:
> - Work as-is today, whatever options that need to be on/off now, are
>   on/off.
> - In the potential cases of undesirable configurations we need to be
>   able to opt for "OK, drop stuff" as well as there's going to be many
>   cases where the board doesn't have the binary space for more features
>   and removal of really unused stuff is fine.  ie TPL/SPL environment
>   use cases boil down to:
>   - Need read-only support, for network stack.
>   - Need some read/write support, for bootcount
>   - Maybe a few things along those lines I can't think of off-hand but
>     are $X needs read-only or $Y needs limited write.

I think that it was already managed by Kconfig :

+ not supported => only read of default env =>  CONFIG_SPL_ENV_IS_NOWHERE
+ Read-only on XXX => default behavior and activated when CONFIG_SPL_ENV_IS_IN_XXX is activated
+ Write support => CONFIG_SPL_SAVEENV (deactivated by default)

(Same for CONFIG_TPL)

I just be sure that it is the correct and expected behavior before to go futher / cheakc why the SPL size increase on the broken board.

Regards
Patrick

> --
> Tom