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

Andreas Dannenberg dannenberg at ti.com
Wed May 22 22:08:40 UTC 2019


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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-spl-Allow-performing-BSS-init-early-before-board_ini.patch
Type: text/x-diff
Size: 4242 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190522/4074edb3/attachment.patch>


More information about the U-Boot mailing list