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

[Andreas Dannenberg]

Simon & Simon,

On Wed, May 22, 2019 at 05:08:40PM -0500, Andreas Dannenberg wrote:
> Hi Simon (Glass)
> 
> On Tue, May 21, 2019 at 06:53:31PM -0600, Simon Glass wrote:
> <snip>
> > > > > Not having BSS available to carry over certain state to the
> > > > > board_init_r() world would lead to a bunch of hacky changes across
> > > > > the board I'm afraid, more below.
> > > >
> > > > This is really unfortunate.
> > > >
> > > > It seems to me that we have two choises:
> > > >
> > > > 1. Hack around with board_init_f() such as to remove the distinction
> > > > between this and board_init_r().
> > > >
> > > > 2. Enter board_init_r() without DRAM ready, and deal with setting it up there.
> > > >
> > > > I feel that the second solution is worth exploring. We could have some
> > > > board-specific init in board_init_r(). We already have
> > > > spl_board_init() so perhaps we could have spl_early_board_init()
> > > > called right near the top?
> > > >
> > > > We can refactor a few of the functions in spl/spl.c so they can be
> > > > called from board-specific code if necessary. We could also add new
> > > > flags to global_data to control the behaviour of the SPL code, and the
> > > > board code could set these.
> 
> I have an alternative solution working, that essentially makes
> board_init_f() more useful. I understand that this is not what you
> wanted to see but I wanted to throw it out here anyways so we can have
> another look at it.
> 
> Please see attached RFC for the general concept of allowing to move BSS
> setup prior to board_init_f for SPL via Kconfig option. This should also
> allow a few folks to get rid of the "hacky" memset() calls to manually
> clear BSS in board_initf() and with this bring some cleanup across the
> board (no pun intended). Of course such solution would need to go along
> with comment/documentation updates that are not yet comprehended in this
> RFC.

Ok I just realized yesterday after I sent that RFC that it was
essentially the same approach that was already part of Simon's patch
series here... give or take that my approach was using a macro to avoid
the duplication of BSS clearing code in crt0.S. So it's not really
adding to the discussion here of coming up with something entirely
different. Should have looked at the original patch more closely, my
bad.

--
Andreas Dannenberg
Texas Instruments Inc

> Background, I played with the adding a hook early into SPL's
> board_init_r() but as expected it was not very straightforward. One
> challenge for example is that gd/stack are "relocated" to DDR prior to
> board_init_r(), but since I don't have DDR until I can use BSS to bring
> up DDR, adding a hook into board_init_r() to bringup DDR I couldn't see
> a good way to both avoid doing and then to re-do some of that stuff
> usually done in crt0.S after my early board_init_r() hook has ran
> without making changes to crt0.S itself...
> 
> I'm still thinking about it...
> 
> --
> Andreas Dannenberg
> Texas Instruments Inc
> 


> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot