[U-Boot] [PATCH v3 0/3] env: Add CONFIG_ENV_FULL_SUPPORT
Patrick DELAUNAY
patrick.delaunay at st.com
Tue Oct 1 08:11:10 UTC 2019
Hi Tom and Wolfgang,
> From: Patrick DELAUNAY
> Sent: jeudi 26 septembre 2019 11:58
>
> 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-f
> > > >or
> > > >-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.
I come back to mys proposition and I check the reason for the SPL size increasing...
It is directly linked to default_environment[]
=> before my patch this symbol wan't used so the associated code was removed by the linker.
After my path it is used in env_nowhere_init().
I propose to create 3 new flags to configure the default environment size:
CONFIG_ENV_DEFAULT => default = y
CONFIG_SPL_ENV_DEFAULT => default = n
CONFIG_TPL_ENV_DEFAULT => default = n
So the default environment will be empty for SPL/TPL, with the code:
const uchar default_environment[] = {
#if CONFIG_IS_ENABLED(ENV_DEFAULT)
...
#endif /* ENV_DEFAULT */
}
I assume the environment in SPL need to be loaded (from the last u-boot saveenv) or is empty.
Do you think this assumption is OK ?
With this patch all the board compilation are ok except smartweb (`.sram' overflowed by 56 bytes)
But I don't know how solve the issue for this bard
Partial compilation result :
arm: + smartweb
+/local/home/frq07632/.buildman-toolchains/gcc-7.3.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram'
+/local/home/frq07632/.buildman-toolchains/gcc-7.3.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: SPL image too big
+/local/home/frq07632/.buildman-toolchains/gcc-7.3.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 56 bytes
+make[2]: *** [spl/u-boot-spl] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
x86: (for 26/26 boards) all -23.5 bss -7.4 spl/u-boot-spl:all -226.7 spl/u-boot-spl:data +0.9 spl/u-boot-spl:rodata -228.6 spl/u-boot-spl:text +1.0 text -16.1
aarch64: (for 225/225 boards) all +0.1 rodata +0.1 spl/u-boot-spl:all -33.3 spl/u-boot-spl:bss -0.1 spl/u-boot-spl:data +18.0 spl/u-boot-spl:rodata -64.3 spl/u-boot-spl:text +13.2
powerpc: (for 309/309 boards) spl/u-boot-spl:all -338.8 spl/u-boot-spl:data -338.8
sandbox: (for 6/6 boards) all -46.7 rodata +16.0 spl/u-boot-spl:all -496.0 spl/u-boot-spl:rodata -496.0 text -62.7
microblaze: (for 1/1 boards) all +4.0 bss +100.0 data -4.0 rodata -8.0 spl/u-boot-spl:all +1136.0 spl/u-boot-spl:bss -8.0 spl/u-boot-spl:data +24.0 spl/u-boot-spl:rodata +1092.0 spl/u-boot-spl:text +28.0 text -84.0
arm: (for 689/689 boards) all -0.1 bss +0.1 rodata +0.1 spl/u-boot-spl:all -131.3 spl/u-boot-spl:data +12.9 spl/u-boot-spl:rodata -154.7 spl/u-boot-spl:text +10.5 text -0.3
Do you think I am still on the good trend with this proposal ?
Regards
Patrick
More information about the U-Boot
mailing list