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

[Graeme Russ]

Hi Simon,

On 08/01/12 09:39, Simon Glass wrote:
> 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.

Using the proposal, there is no 'architecture init sequence' like there is
now. Instead, everything that needs to be initialised before the main loop
simply states that fact be adding an instance of the INIT_FUNC macro which
specifies:
 - The name of the function to be called
 - The type of init being performed (console, sdram, fpga etc)
 - What type(s) of inits need to be performed before the named function can
   be called
 - What type(s) of inits the named function needs to be called before

A board can freely insert additional init steps by adding INIT_CALLs

A board can override a 'standard' init step by adding SKIP_INIT and the
replacement INIT_CALL

>>
>>>
>>>> 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

Well, the arch code already can thanks to the init sequence being encoded
into arch/foo/lib/board.c

The problem is what if the CPU needs additional init, or the SoC, or a
single board that no other CPU/SoC/board under that arch needs? At the
moment, the solution is a combination of over-rideable weak functions and
#ifdefs


> Graeme's idea should achieve. The arch code will have several
> INITCALL() steps to achieve this. It actually lends itself quite well

Not only the arch code, but any code that needs to initialise something
prior to entering the main loop - This can include the arch, SoC, CPU,
board, chipset, drivers, etc...

So long term, we should see the mess that is the Ethernet and serial driver
init code cleaned up because each driver can simply add an INIT_FUNC

> 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.

Exactly :)

Regards,

Graeme