[U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure

[Graeme Russ]

Hi Wolfgang,

On Wed, Dec 5, 2012 at 6:25 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ2KVHV6JCvOjiQBrXFCfHMeWfEfj9bLHFw_Qyf5_7dj8Q at mail.gmail.com> you wrote:
>>
>> > To be honest, I think gd should only be a temporary structure used to
>> > carry specific data through the initialisation process up to the point
>> > BSS becomes available. With the 'early malloc' patches in the
>> > pipeline, it might even be possible to malloc the gd structure early
>> > and then when BSS is available, copy the data into the final global
>> > data structure in BSS. I think that would be complicated by functions
>> > that need to use gd both before and after BSS becomes available.
>>
>> I mostly agree, but that sounds like an exercise in removing fields
>> from the gd one by one in the source code. The bit I am not sure of is
>> whether it is useful for gd to hang around post relocation to provide
>> access to the data that was decided on early in boot (after all, the
>> position in memory of gd changes post relocation, so why maintain two
>> structures for the same info?).
>
> Sure.  If you look back how this developed, then initially there was
> only struct bd_info.  Then it turned out that it costs too much of
> code size (and performance, actually) to pass around the same struct
> as parameter to about each and every functiuon, so I invented GD - wit
> the intention to drop it as soon as writable global data becomes
> available, i. e. after relocation.  I even think the first versions
> worked that way.  Only later that code code optimized because it
> seemed easier to keep this struct and be able to use the same code
> before and after relocation.  And open Pandora's box was...

Yes, the old 'cost versus complexity' problem. Seriously, take a look at
arch/x86/lib/board.c, it's nice and clean and give a good view of how we
can move forward.

For starters, the functions listed in init_sequence_f and init_sequence_f_r
never need to be copied into RAM (there are functions they call that may
need to be though). Like the Linux kernel, these can be moved into a
dedicated linker section and not copied (and their relocation entries can
be skipped as well). For x86, there are not a lot of functions in these
two lists. Maybe these can have 'gd' passed to them

init_sequence_r is the big list so passing 'gd' to each of these will
result in massive code bloat. But by this stage, we have BSS, so global
data is writable and there is no need to pass gd.

BSS is actually available during the processing of init_sequence_f_r,
so in theory it would be possible to copy data from gd (used during
init_sequence_f) into BSS during the processing of init_sequence_f_r

All that would be left is dealing with the (handful?) of functions that
are called from both init_sequence_f and init_sequence_r (I doubt any
common functions will be called during init_sequence_f_r). One option
may be to pass a point to gd to these functions. If it is NULL, use
the variable in BSS, otherwise use gd.

Regards,

Graeme