[U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early

[Simon Goldschmidt]

Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com> schrieb am Sa., 30.
März 2019, 21:18:

>
>
> Simon Glass <sjg at chromium.org> schrieb am Sa., 30. März 2019, 21:06:
>
>> Hi Simon,
>>
>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
>> <simon.k.r.goldschmidt at gmail.com> wrote:
>> >
>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it
>> clears
>> > the bss before calling board_init_f() instead of clearing it before
>> calling
>> > board_init_r().
>> >
>> > This also ensures that variables placed in BSS can be shared between
>> > board_init_f() and board_init_r() in SPL.
>> >
>> > Such global variables are used, for example, when loading things from
>> FAT
>> > before SDRAM is available: the full heap required for FAT uses global
>> > variables and clearing BSS after board_init_f() would reset the heap
>> state.
>> > An example for such a usage is socfpa_arria10 where an FPGA
>> configuration
>> > is required before SDRAM can be used.
>> >
>> > Make the new option depend on ARM for now until more implementations
>> follow.
>> >
>>
>> I still have objections to this series and I think we should discuss
>> other ways of solving this problem.
>>
>> Does socfgpa have SRAM that could be used before SDRAM is available?
>> If so, can we not use that for the configuration? What various are
>> actually in BSS that are needed before board_init_r() is called? Can
>> they not be in a struct created from malloc()?
>>
>
> The problem is the board needs to load an FPGA configuration from FAT
> before SDRAM is available. Yes, this is loaded into SRAM of course, but the
> whole code until that is done uses so many malloc/free iterations that The
> simple mall of implementation would require too much memory.
>
> And it's the full malloc state variables only that use BSS, not the FAT
> code.
>
> One way out could be to move the full mall of state variables into 'gd'...
>

Maybe I should point out again that the whole purpose of this series is to
have an SPL that uses full malloc right from the start. This is currently
not possible as full malloc needs BSS.

Regards,
Simon


> Another way would be to continue into board_init_f without SDRAM enabled
> and in it it later...
>
> Regards,
> Simon
>
>
>> If this is a limitation of FAT, then I think we should fix that, instead.
>>
>> Regards,
>> Simon
>>
>> > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
>> > ---
>> >
>> > Changes in v3:
>> > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed
>> >
>> > Changes in v2:
>> > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now
>> >
>> >  common/spl/Kconfig | 12 ++++++++++++
>> >  1 file changed, 12 insertions(+)
>> >
>> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> > index 206c24076d..6a4270516a 100644
>> > --- a/common/spl/Kconfig
>> > +++ b/common/spl/Kconfig
>> > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN
>> >           to give board_init_r() a larger heap then the initial heap in
>> >           SRAM which is limited to SYS_MALLOC_F_LEN bytes.
>> >
>> > +config SPL_CLEAR_BSS_F
>> > +       bool "Clear BSS section before calling board_init_f"
>> > +       depends on ARM
>> > +       help
>> > +         The BSS section is initialized to zero. In SPL, this is
>> normally done
>> > +         before calling board_init_r().
>> > +         For platforms using BSS in board_init_f() already, enable
>> this to
>> > +         clear the BSS section before calling board_init_f() instead of
>> > +         clearing it before calling board_init_r(). This also ensures
>> that
>> > +         variables placed in BSS can be shared between board_init_f()
>> and
>> > +         board_init_r().
>> > +
>> >  config SPL_SEPARATE_BSS
>> >         bool "BSS section is in a different memory region from text"
>> >         help
>> > --
>> > 2.17.1
>> >
>>
>