[U-Boot] [RFC PATCH 01/19] Introduce generic global_data

[Simon Glass <sjg@chromium.org>]

Hi Andreas,

On Wed, Dec 28, 2011 at 11:47 PM, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> Dear Simon,
>
> On 28.12.11 07:35, Simon Glass wrote:
>> We want to unify the global_data structure. Most fields are common across
>> architectures, but there are a fair number of SOC-specific additions. It
>> isn't clear how best to deal with these, but for now we just use #ifdef.
>

Sorry your email got a little buried this week.

> I would like to see some more 'clustering' here. Especially the timer
> stuff is implementation specific and should therefore not coded directly
> but with some pointer to the specific stuff i.e. introduce some timer_t
> which is specific for arm in general and maybe has some more
> specialization for atmel devices or what else and just save a pointer to
> that struct in gd_t like it is done with bd_t.

Actually I wonder if we should an architecture-specific structure,
something like

struct global_data {
   /* generic things first */
   ulong baud_rate;
   ulong ram_size;
   /* hopefully lots of other things that are mostly common */

   /* architecture-specific things */
   struct arch_global_data arch;
};

struct arch_global_data  can be defined in include/asm/global_data.h
before it includes include/asm-generic/global_data.h, or the other way
around might be better.

One thing I notice is that some architectures share some fields, and
others omit them.I feel we should include them at the global level if
at least 2 architectures need them. This means that the 'minimal'
architectures with hardly any fields will have quite a few unused
fields in global_data. I don't think that matters, and the use will
increase as that arch gets more functionality.

> Well maybe having a pointer here is stated critical so we could just
> insert the struct directly and let the compiler decide about the size
> (BTW this could be done with bd_t now too cause we have a pre-calculated
> size of gd_t since some time, saves some little steps when instantiating
> gd_t when running).

Yes I agree that just including the structure seems better. A pointer
is slower and we just point to a place very close anyway.

It would be nice to subsume bd_t into global_data.

> Beside that we could also introduce some more structs holding specific
> stuff i.e. console_t, reloc_t, ...
> (but yes, it should be done in a second step ...)
>
> What do you think about that?

Certainly agree for reloc and perhaps there are other cases too. It is
far too long at present. Something to think about.

For now I would prefer to do nothing on either point, since bringing
everything into one place shows up the conflicts and similarities.
Part of the purpose of the generic board effort is to minimise these,
and they are hard to spot if they are all in separate files.

But when we get through this, and find that there are things which
genuinely are specific to a single arch, then I think breaking them
out is reasonable, hopefully combined with joining global_data and
bd_t.

Regards,
Simon

>
> best regards
>
> Andreas Bie?mann