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

[Simon Glass]

Hi Graeme,

On Wed, Aug 24, 2011 at 4:00 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> 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

No, and fair enough too.

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

Yes indeed.

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

Ick. The more I read of this thread the more I like your original
implementation. It really doesn't seem that hard to see the order of
initcalls either from System.map or objdump | grep or similar. Write a
nice long Python script if you like! Your implementation allows
tracing of initcalls as they are made which is a big win.

Early init cannot necessarily printf() but I don't see why initcalls
must solve a problem which exists currently anyway (I have been
thinking about buffering pre-console pre-reloc output and printing it
later - it's not that hard, just a bit ugly).

Yes moving to a dependency-based init sounds lovely, but this is
U-Boot not Upstart. We do need to keep things reasonably simple - at
least with your scheme we can tell at link time what the order will
be. The other thing is that init ordering is often not critical bar a
few early routines, and most of these will be fixed by the order
selected in the arch/xxx/lib/board.c code. Board maintainers would
likely only have a few ranges within which to add their init, and
strongly discouraged from inserting an init function into the middle
of an existing stable sequence in that file.

I do tend to agree that merging the board.c code is a bigger win, but
this might be a nice vehicle for doing it, since one could imagine an
incremental approach with a CONFIG_NEW_INIT option which can be turned
on/off for each board. As problems with each architecture (then each
board) are ironed out, the option will turned on in the board config
file.

Regards,
Simon

>
> Regards,
>
> Graeme

PS: Regarding the late night work, kids, wives, etc. I am reminded of
that 'quote' from Dr Johnson about his work with his 'U-Boot':

...that has taken eighteen hours of every day for the last ten years.
My mother died; I hardly noticed. My father cut off his head and fried it
in garlic in the hope of attracting my attention; I scarcely looked up from
my work.

> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>