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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot