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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190920/10c79fd3/attachment.sig>