Hi Simon,
On 23/10/11 08:41, Graeme Russ wrote:
Hi Simon,
On 23/10/11 03:36, Simon Glass wrote:
Hi Graeme,
[snip]
I vote to pick an arch, convert it to a unified style and move it to lib/board.c and then merge each arch over. This should be done in a single series rather than the ol' 'migrate over time' which never happens.
I thing you mean merge each arch over in its own series?
I mean merge all arches in one series
x86 is a good arch to start with because the number of boards is so small (1)
Also, I'd personally like the init sequence patches I posted earlier to be re-examined
I already examined and thought it was good. Let's be careful to keep it simple in the sense that we only need a very small number of init functions. Most of the board_init_r() code should not be there as I understand it (e.g. on ARM MMC, USB, NAND should be inited if/when used and not before). Need to be careful not to confuse this bit with driver init or any refactor of the driver model. So we have things like
My biggest gripe with the init code is the lack of consistency. There are two prime examples of this:
1) The pre-relocation sequence and post-relocation sequences can be implemented using identical code (a sequence loop) - x86 almost gets there, other arches only loop for one, and have sequential logic for the other 2) Even with the init loop, there is a lot of sequential code after the loop that could be merged into the loop
- init memory and make it so we can relocate code, etc. (this is
called from start.S at present)
- init the CPU core
- arch init like turn off caches, MMU, flush TLBs, etc.
- early board init (hopefully just requires an initcall in board code if needed)
- the current init sequence like banner, serial, etc.
- relocate
- console init
- board_init (initcall in board code if needed)
- (hopefully all other post-relocation init can be punted)
So board.c becomes a few functions and about a dozen initcalls. Albert will want to use weak symbols instead of #ifdef, and we will be done.
The INIT_CALL approach eliminated this need - If the .c file does not get compiled in, the INIT_CALL does not get included. And adding a new INIT_CALL was as simple as including the macro in the .c file without needing to mess with board.c at all - simple :)
INIT_CALL is a completely separate issue to what you are looking at and would be easier to implement after board.c was merged into lib
Regard,
Graeme