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

[Graeme Russ <graeme.russ@gmail.com>]

Hi Simon,


On 23/10/11 03:36, Simon Glass wrote:
> Hi Graeme,
> 
> Did you mean to send to list?

Oops, yes I did - Done now

> On Fri, Oct 21, 2011 at 10:49 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
>> Hi Simon
>>
>> On Oct 22, 2011 4:11 PM, "Simon Glass" <sjg@chromium.org> wrote:
>>>
>>> Hi,
>>>
>>> Each architecture has its own board.c but they are mostly quite similar.
>>>
>>> New features such as fdt, boot timing, trace, profiling, etc. must be
>>> done separately for each arch, even if there are no
>>> architecture-specific bits.
>>
>> Yes, it is a mess - something my unit sequence patches tried to clean up
>>
>>> What would you say to adding something like lib/board.c which is a
>>> simplified cleaned-up copy of one of the existing board.c files, and a
>>
>> 100% agree
>>
>>> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the
>>> architecture-specific one. Then perhaps people could try it out and we
>>> could slowly move to it over time...
>>
>> 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?
> 
>>
>> 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
> 
> - 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.
> 
> Regards,
> Simon
> 
>>
>> Regards,
>>
>> Graeme
>>
>