Hi Tom, > From: Tom Rini <tr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot