RFC Create generic board init and move ARM and x86 to it

Hi Simon,

Sorry for the delay in reviewing this - I've been doing a lot of work on the x86 side of things. I now have a working solution to the board_init_f_r() / global data clobbering problem which involves having the gd 'variable' as a register like all other arch's. The solution is non-trivial and gd access is slightly more expensive than the vanilla variable approach, but it makes this a lot cleaner cross-arch wise...

Here's a hint ;)

static inline gd_t *get_fs_gd_ptr(void)

{
       gd_t *gd_ptr;

       asm volatile("fs movl 0, %0\n" : "=r" (gd_ptr));

       return gd_ptr;
}

#define gd get_fs_gd_ptr()

[snip]

I think that we can all agree that there is strong motivation for change.

However, I think this approach is not the right one - and I think the CFI driver backs me up. Your plan is to create generic code which you want ALL arches to cross over to, but you only look to migrate two initially and migrate the rest 'later'. This is similar to what happened with the CFI driver, and there are still boards with custom flash.c files which are completely redundant.

But, creating a single patch-set to migrate everyone in one go is going to be too massive a job to do in one go, and too prone to introducing breakage.

I think we should look at this sooner rather than later. I've shown with x86 that the init sequence has three distinct phases:

1) Execute in flash using temporary RAM
2) Copy U-Boot from flash to RAM
3) Execute in RAM

My latest work now has all init functions having the same signature (i.e. void parameter returning int). For x86, there is a little 'magic' that needs to be done as gd is copied from temporary RAM to SDRAM, but for other arches using a dedicated register, this is otherwise trivial.

So instead of trying to pluck out something (relocation in this case) from the molasses of ten different board.c files and having to perform open-heart surgery on them all to get the code grafted in, I think we should approach it from the generic init sequence angle.

If we work each individual arch to use a generic init sequence (like the proposed x86 code) then the init processing naturally falls out as common code and the patch to realise this is trivial. From there, we can start to pull out common init code like init_baudrate() and hang() and change the function signatures of the functions that require wrappers and move some #ifdef's into more appropriate locations - One example in board.c:

#ifdef CONFIG_BITBANGMII
int bb_miiphy_init_r(void)

{
	bb_miiphy_init();

	return 0;
}

#endif

Ouch!

The other big benefit is that you only touch one architecture at a time up until you 'pull the switch'. And when you do pull the switch, you should be factoring out identical code so the chances of breaking something should be vastly reduced. Take a look at the history of ARM relocation for example - that was constrained to one arch but still the amount of breakage was massive.

Note that not all arches need and/or use ELF relocation - Attacking this first does not move towards unity of board.c

This has been raised quite some time ago - The resulting code size increase is not worth it. x86 can now emulate the 'gd is a register' so gd is now available and writtable always on every arch. As I said before, gd access is slightly more expensive (one instruction) and initialising the gd pointer is _very_ expensive (rebuilding the Global Descriptor Table) but this only happens three times in total, so I am happy to accept the penalty for a unified architecture.

The big issue I have is that we now have two RFC's which have major impacts on x86 and one of us is going to have to give way to the other :)

My patch set is mostly re-factoring and has no impact on anybody else and is practically complete - I'll do one last RFC, but I think it's already close to 'PATCH' status

There are several x86 patches which simply do not belong in this series (and some of which already have non-RFC patches submitted)

I honestly think we should get the x86 init sequence patches finalised first for several reasons:

- Because x86 is so small, it provides a good test-bed - ELF relocation was first finalised on x86 (it came and went with varying levels of success previously)
- They bring x86 in line with other arches re: global data
- They are now fully run-tested

Regards,

Graeme