[U-Boot] [RFC] New init sequence processing without init_sequence array

[Graeme Russ]

Hi Wolfgang

On Wed, Aug 24, 2011 at 11:58 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Wolfgang,
>
> On 24/08/11 23:24, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message <4E54F501.6050706 at gmail.com> you wrote:

[snip]

>
> Hmmm, now we're talking ;) Let me ramble aimlessly for a second...
>
> I can see this heading towards an auto-generated init-sequence.c file with
> an init array specifically crafted for the build target. That would have
> less linker functionality dependencies than initcall...
>
> So if we define a file, say 'init.txt' which lists the init dependencies
> and we drill-down and pre-process this to generate /common/init-sequence.c
> which has the array of function pointers (and optionally the function name
> strings for debug output...)
>
> Hmmm, it _sounds_ messy on the surface, but it is a pre-compile step so
> what you get code-wise for the final build is exactly what you want - A
> clean array that is 'right there'
>
> So we might have in init.txt for a board:
>
> INIT_STEP_TIMER(board_foo_timer_init)
> DEPENDS_ON(INIT_STEP_ARM_TIMER)
>
> and in arch/arm/Soc/init.txt
>
> INIT_STEP_ARM_TIMER(arm_timer_init)
> DEPENDS(INIT_STEP_SDRAM)
> DEPENDS(INIT_STEP_GPIO)
>
> Can't say I like it much...could be xml, but still very clunky
>
> Maybe there is something to be gleaned...
>
> Dunno - thoughts?

Midnight is not the best time to come up with ideas ;) - Way to much
convaluted pre-processing, non of it in native C code (or even pre-
processor) - Yetch! All to complicated for a very simple goal:

 - Allow any arch/Soc/board to seamlessly inject an init function without
   needing to modify any other files other than its own.

In essance, I see three 'big' problems with the initcall implementation:

 1. Do all linkers used to compile latest mailline U-Boot support
    SORT_BY_NAME()? If not, game over
 2. There is no definative init sequence list in the code (a la the
    current init function array)
 3. Managing the init call sequence

There is nothing I can do about #1 as mentioned before

For #2, if we had a post-build step which generated the init sequence into
a text file for reference would that help? If I name the initcall sections
something like .initfunc.1000.init_cpu_f then it will be pretty trivial to
post-process u-boot.map

As for #3 - What about INIT_AFTER (and maybe INIT_BEFORE) macros so you may
have in init.h

#define INIT_START	1000

and in /arch/.../cpu.c:

INIT_AFTER(INIT_START, init_cpu_f)
int init_cpu_f(void)
{
...
}

The only problem I have with that is that you cannot define a new macro in
a macro. I would love to do:

INIT_AFTER(INIT_START, init_cpu_f, INIT_CPU_F)

which would then define INIT_CPU_F so you could then:

INIT_AFTER(INIT_CPU_F, init_timers_f, INIT_TIMERS_F)

but I cannot figure out how that would work

Regards,

Graeme