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

[Simon Glass <sjg@chromium.org>]

Hi Graham,

On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Wolfgang,
>
> On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Graeme,
>>
>> In message <4F02DA64.60502@gmail.com> you wrote:
>>>
>
> [snip]
>
>>> INIT_FUNC(cpu_init_f, f, "fred", "blah", "foo");
>>>
>>> Generates the string:
>>> f:cpu_init_f:"fred":"blah":"foo"
>>>
>>> and we can parse each of the elf archives to obtain a list of string
>>> pointers from the .initfuncs, extract the strings and process them to
>>> generate the init arrays
>>>
>>> and add:
>>>
>>> ? ? ? /DISCARD/ : { *(.initfuncs*) }
>>>
>>> to the linker script to throw away the strings
>>>
>>> It's a tad ugly under the hood, but the output will be very clean
>>>
>>> Does this sound like a plan?
>>
>> Yes. ?Looks good to me.
>>
>> One thing comes to mind: it would be nice if we can find a way that
>> the INIT_FUNC definitions behave similar to "weak" functions - if an
>> init_func can be redefined / overwritten / modified by board specific
>> code we eventually have a very nice way to get rid of the related
>> #ifdef's.
>
> I have a thought on this. How about a SKIP_INIT macro. Here's the idea
> using SDRAM as an example:
>
> At the arch level you may have
>
> INIT_FUNC(sdram_init, f, "sdram", "console","")

Gosh this email took a few readings :-)

Can we get rid of the 'f' parameter? If we invent a prerequisite
called 'relocated' or something like that, to act as a barrier, then
maybe the order can be defined just like any other function which
depends on being before or after something?

>
> so sdram_init sets the "sdram" requisite and must be done after all
> "console" requisites have been completed.
>
> Now if a SoC or board has an init that must be done before SDRAM:
>
> INIT_FUNC(pre_sdram_init, f, "pre_sdram", "", "sdram")
>
> So this sets the pre_sdram requisite, requires no other initialisation
> before running and must happen before and "sdram" init functions are run
>
> Now lets say the Soc or board has a unique sdram init function that
> overrides the arch's sdram init. We could just use weak functions and
> allow the SoC or board to override sdram_init. But what if the SoC or
> board has additional pre-requisite (or post-requisite) init requirements?
>
> So in the SoC or board file:
>
> SKIP_INIT(sdram)
> INIT_FUNC(board_sdram_init, f, "board_sdram","pre_sdram,vreg,console", "")
>
> Using "board_sdram" versus "sdram_init" is cricital:
>
> The init sequence build tool will first create the entire init sequence
> including the functions marked as "sdram" and "board_sdram". But after
> building the arrays, it will strip out all the functions marked as "sdram"
> init functions. The reason the entire list has to be build first is so the
> functions that rely on "sdram" can be added without unmet prerequisite
> errors.
>
> Of course, if you use SKIP_INIT(foo), you need to make sure that any
> replacement INIT_FUNC will do everything foo did to make your board work.
>
> Interestingly, this allows the following:
>
> INIT_FUNC(calc_relocation, fr, "calc_reloc", "sdram", "")
> INIT_FUNC(copy_uboot_to_ram, fr, "copy_to_ram", "calc_relocation", "")
> INIT_FUNC(do_elf_reloc_adjusments, fr, "elf_reloc", "copy_to_ram", "")
> INIT_FUNC(clear_bss, fr, "clear_bss", "calc_reloc", "")
>
> #ifdef CONFIG_SYS_SKIP_RELOCATION
> SKIP_INIT(calc_reloc)
> SKIP_INIT(copy_to_ram)
> SKIP_INIT(elf_reloc)
> #endif
>
> So if CONFIG_SYS_SKIP_RELOCATION is defined, relocation is not performed,
> but clear_bss still is
>

I wonder what happens when you skip something - does it substitute for
any pre/post-requisites that the skipped item had? Or would that be
illegal?

I can see plenty of opportunity for confusion, but if the tool is
friendly enough, then this could solve a lot of the override problems.
In your particular example it feels like it would be easier to just
make the INIT_FUNC conditional on an config using #ifdef (horror!), or
perhaps yet another parameter(!).

Or we could just put those relocation functions in their own file and
have it omitted from the build by the Makefile in the case where
CONFIG_SYS_SKIP_RELOCATION is defined.

And if we want wanting to replace a generic function with a
board-specific one, why not just something like:

INIT_OVERRIDE(new_func, old_func)

Anyway, it sounds very promising.

Regards,
Simon

> Regards,
>
> Graeme