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

[Graeme Russ]

Hi Wolfgang,

On 24/08/11 23:24, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4E54F501.6050706 at gmail.com> you wrote:
>>
>>> Sorry, but when reading the source code or when revioewing patches I
>>> cannot paick up any next funtion pointers, I'm stuck with reading the
>>> source code only.
>>
>> Well, I guess I had a good shot at creating a 'better' init sequence - one
>> where any board, SoC, or arch can seamlessly inject a custom init step
>> without treading on any toes.
>>
>> I must say, it was rather fun learning how to build the macros and get the
>> linker to do the right thing and have it all work so quickly. I'll stick it
>> in my bag of tricks for another day :)
> 
> Hey, you give up early.  Are you suffering from hot weather, too?  :-)

No, just young kids, new job and pregnant wife :)

> Seriously,  I do not think we should stop this discussion yet. I agree
> that a better approach to the init code would be a good thing, but at
> the same time I want to make sure the result will be really better,
> and we not by means of Beelzebub expel the demons...
> 
> 
> I already tried to lend a helping hand by suggesting to create a list
> of init functions as part of the build process - OK, we still have to
> build the code to get this, but at last we can then see the complete
> and precise order for this specific configuration.

Something like how we auto generate asm-offsets.h?

> Also, Detlev made some interesting remarks - he noted that basicly
> what we are trying to solve is a dependency issue: each init function
> has a list of dependencies (other init steps) that need to be run
> before.  Instead of manually assigning initcall numbers, we could try
> and write down these dependencies, for example in a format that can
> be digested by a tool like tsort.  We could then use this to
> auto-generate the list of init calls.  This is a completely new
> approach, but it has the charme of making the dependencies clear.

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?

Regards,

Graeme