Hi Tom and Wolfgang,
From: Patrick DELAUNAY Sent: jeudi 26 septembre 2019 11:58
Hi Tom,
From: Tom Rini trini@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