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()
On 28/12/11 17:35, Simon Glass wrote:
This series creates a generic board.c implementation which contains the essential functions of the various arch/xxx/lib/board.c files.
What is the motivation for this change?
[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.
All the functions of board_init_f() and board_init_r() are broken into separate function calls so that they can easily be included or excluded for a particular architecture. It also makes it easier to adopt Graeme's initcall proposal later if desired.
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.
Generic relocation is used (see previous series) but now rather than calling relocate_code() to do everything, we call the individual relocation steps one by one. Again this makes it easier to leave things out, particularly for SPL.
Note that not all arches need and/or use ELF relocation - Attacking this first does not move towards unity of board.c
ARM is a relatively large board.c file and one which I can test, therefore I think it is a good target for this series. On the other hand, x86 is relatively small and simple, but different enough that it introduces a few issues to be solved. So I have chosen both ARM and x86 for this series.
The next target should probably be PowerPC, since it is large and has some additional features. I suspect we may want to leave some of these very architecture-specific functions in arch/powerpc/lib/board.c, taking out only the generic code. I haven't felt a strong need to do this for ARM/x86, but we could even go as far as putting the initcall list into the architecture-specific board file if the architecture adds a lot of unusual calls.
A generic global_data structure is also required. This might upset a few people. Here is my basic reasoning: most fields are the same, all architectures include and need it, most global_data.h files already have #ifdefs to select fields for a particular SOC, so it is hard to see why architecures are different in this area. We can perhaps add a way to put architecture-specific fields into a separate header file, but for now I have judged that to be counter-productive.
There was dicussion on the list about passing gd_t around as a parameter to pre-relocation init functions. I think this makes sense, but it can be done as a separate change, and this series does not require it.
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.
While this series needs to stand on its own (as with the link script cleanup series and the generic relocation series) the goal is the unification of the board init code. So I hope we can address issues with this in mind, rather than focusing too narrowly on particular ARM or x86 issues.
Comments welcome. Note that the x86 side of this still needs a fair bit of work, sorry.
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
Simon Glass (19): Introduce generic global_data Make relocation functions global Add basic initcall implementation define CONFIG_SYS_LEGACY_BOARD everywhere Add generic post-relocation board_r.c Add generic pre-relocation board_f.c Add spl load feature switch ARM over to generic board arm: Remove unused code in board.c, global_data.h Add CONFIG_SYS_SYM_OFFSETS to support offset symbols x86: Remove compiler warning in sc520_timer.c x86: Remove dead code in eNET x86: Add processor library and relocation functions Tidy up asm/generic sections.h to include x86 symbols Add fields required by x86 to global_data x86: Change stub example to use asm-generic/sections.h x86: Add initial memory barrier macros Bring in x86 to unified board architecture x86: Remove unused board/global_data code
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