[U-Boot] A bit about board.c, board.c

[Graeme Russ]

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