[U-Boot] initcall revisited - A new idea to discuss

[Simon Glass]

Hi Gururaja,

On Thu, Jan 5, 2012 at 11:25 PM, Hebbar, Gururaja
<gururaja.hebbar at ti.com> wrote:
> On Fri, Jan 06, 2012 at 12:05:40, Wolfgang Denk wrote:
>> Dear "Hebbar, Gururaja",
>>
>
> [snip]
>
>> > > _after_ the list has been created - If this breaks dependencies that's
>> > > your problem ;). It is up to you as the 'skipper' to make sure that you
>> > > add init functions to allow things to still work
>> >
>> > Won't this lead to lots of code duplication across all boards, archs.
>> > So, tomorrow someone else will send a patch removing duplicate and merging
>> > it to a common place.
>>
>> I don't see why that would happen?  I see no intention nor any need
>> for duplicated code.
>>
>> > So, every board, even under same arch, needs to define its own *complete-set*
>> > of INIT_CALL api's. I am dreaming about a lot of MB getting added to u-boot
>> > src.
>>
>> What makes you think so?
>
> As mentioned before, the INIT_CALL code is to be added to each board file
> for each arch, soc.
> I was speaking of actual C Code. Every board needs serial, console, i2c and
> many other common code. Wont they increase u-boot source size (in actual c
> code size).
> Every Board Maintainer will have almost same "x-lines-added" in the U-Boot
> release statics/summary page.
>
> Kindly correct me if I am wrong.

I hope I understand you correctly. The idea is that the init list is
specified for the architecture (or hopefully soon for the whole of
U-Boot). Boards only need to mess with it if they want to add / remove
something. Hopefully most boards won't do much at all with the init
sequence.

>
>>
>> > Just a thought. Why don't split it to ARCH_INIT, BOARD_INIT,.
>>
>> Because it's not such an easy split. You can define such groups, like
>> arch, SoC, board family, board.  But you cannot initialize the system
>> in such grous - instead, initialization will jump around heavily
>> between these groups, in a sequence that needs to be well defined, and
>> that is often diofferent from board to board.
>
> Correct. Then Board maintainer will mention ARCH_INIT, SKIP_ARCH_INIT,
> BOARD_INIT ...
> By this way, Board maintainer can make use of common init calls between
> ARCHs, SOCs and BOARDs.

See above, which hopefully contains what you need.

At the moment we have things like arch_cpu_init() and the like to do
common init for an arch, soc. I think you are saying that the arch
code should be able to add things to the init list without every board
for that arch doing it explicitly. If so, then that's exactly what
Graeme's idea should achieve. The arch code will have several
INITCALL() steps to achieve this. It actually lends itself quite well
to this requirement. Any file can put an INITCALL() in the sequence
and the collection tool / linker tidy things up at the end. The boards
should only have to worry about what they want to add/change for their
own narrow purposes.

Regards,
Simon

>
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>
>
> Regards,
> Gururaja