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

[Simon Glass]

Hi Albert,

On Sat, Oct 22, 2011 at 12:17 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Le 22/10/2011 07:11, Simon Glass a écrit :
>>
>> 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.
>>
>> 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
>> 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'd say anything that factorizes ARM code is a good thing. :)
>
> However I'm not in favor of a CONFIG option that would force the board code
> to provide some functions just in odrer to override one, not if weak

My suggestion was:

CONFIG_ARCH_GENERIC_BOARD - you get lib/board.c
not CONFIG_ARCH_GENERIC_BOARD - you get arch/xxx/lib/board.c

> definitions can do a finer job. I am looking into that already for cache
> management function specialization, and it seems like there is the same kind
> of possibility here, with lib functions defined weak and the board code
> overriding the ones it deems necessary to.

ok. Just one little point. Weak symbols are the punishment our C++
overlords gave us for not having to understand what code is executed
when we instantiate a C++ subclass. It is nice to know what code is
being linked in and avoid having to disassemble to find out. I think
using weak symbols to avoid a OBJS-$(CONFIG_ARCH_GENERIC_BOARD) in a
couple of Makefiles risks going too far.

Regards,
Simon

Regards,
Simon


Regards,
Simon

>
> I will look into it a bit more this morning.
>
> Amicalement,
> --
> Albert.
>