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