[U-Boot] [PATCH v4 07/27] Introduce generic global_data

[Graeme Russ <graeme.russ@gmail.com>]

Hi Simon,

On 03/25/2012 10:10 AM, Simon Glass wrote:
> Hi Graeme,
> 
> On Sat, Mar 24, 2012 at 4:14 AM, Graeme Russ <graeme.russ@gmail.com> wrote:
>> Hi Simon,
>>

[snip]

>>
>> arch/asm/global_data.h:
>>
>> #define HAS_ARCH_GD
>>
>> struct arch_global_data {
>>        ...
>> };
>>
>> include/global_data.h:
>>
>>
>> #include <arch/asm/global_data.h>
>>
>> struct global_data {
>>        ...
>> #ifdef HAS_ARCH_GD
>>        struct arch_global_data agd;
>> #endif
>> };
>>
>> I like this better
>>
>> P.S. Can we ditch the typedef while we are at it?
> 
> Separate issue, but I can't see why not.

OK - See below

> But I now remember the main problem I had with this.
> CONFIG_SYS_GENERIC_BOARD is an option, not mandatory, so we must not
> change the C code (much, ideally not at all) to make this work. If we
> move things around as you suggest then we should probably do it first
> as part of the normal code, so that generic board can just use it.

Sounds like a solid plan

> So the first change might be to move arch-specific data into an agd
> structure, and get everything building again. Then finally pull out
> the common part of each file into a new asm-generic file. It's the
> opposite way to what I have done so far, but the result will be the
> same in the end. I suppose my only reservation is that it creates
> patches initially for little benefit. I will have to think about how
> to motivate it.

Clean-up work that, on the surface, appears to not do much does much more
than you think. It may highlight a few nasty quibbles that you hadn't
expected that you will need to plan around.

Big changes made against good, clean, consistent code are always easier
than against bad, dirty, inconsistent code :)

And I think this is the ideal opportunity to drop the typedef

>> Q: Are there any board specific global data members anywhere?
> 
> Probably, if we went into a deep enough. Certainly there are members
> which are only used for one sub-archs, and some of those sub-archs
> have a very small number of boards, perhaps 1 in some cases.

OK, it might be worth investigating HAS_BOARD_GD. Maybe bring that through
struct arch_global_data but it's not as clear an issue (there is a symlink
to include/arch/asm but none for include/board/. For the time being, we may
just have to leave the ifdefs in the include/arch/asm/global_data.h

>>> (I feel the last one has to come later, though, even if unfortunately
>>> it would simplify things now - how on earth are we going to work out
>>> what things are really needed in global data?)
>>
>> Look at the functions which are called prior to relocation - Anything
>> referenced in these functions needs to be in gd
> 
> Yes, but I'm just saying that is a long list, and involves a lot of
> code searching.

I didn't say it would be easy ;)

The board_init_f array is a starting point.

I was planning on moving pre-relocation functions into a .init section so
they were not copied during code relocation (much like Linux marks init
functions so the memory can be free'd post init). Once this is done,
identifying 'real' global data members will be trivial

Regards,

Graeme