initcall revisited - A new idea to discuss

Which got me to thinking, what if we had an initcall macro which included the dependency information. Imagine this rough example:

INITCALL(display_banner, "banner", "dram,board_early")

Which says that the display_banner() function, when completed fulfils the 'banner' dependency, and requires both the 'dram' and 'board_early' dependencies to be fulfilled in order to run

Dear Graeme Russ,

Quoted 3 lines · In message <[email protected]> you wrote:

Which got me to thinking, what if we had an initcall macro which included the dependency information. Imagine this rough example:

...

Quoted 5 lines

INITCALL(display_banner, "banner", "dram,board_early")

Which says that the display_banner() function, when completed fulfils the 'banner' dependency, and requires both the 'dram' and 'board_early' dependencies to be fulfilled in order to run

Sounds great!

Quoted 8 lines

Quoted 6 lines

INITCALL(display_banner, "banner", "dram,board_early")

Which says that the display_banner() function, when completed fulfils the 'banner' dependency, and requires both the 'dram' and 'board_early' dependencies to be fulfilled in order to run

Sounds great!

OK, I think I can do this...

#define INIT_FUNC(fn, stage, reqs, prereqs, postreqs) \
	static const char *__initfunc_ ## fn __used \
	__attribute__((__section__(".initfuncs"))) = \
	#stage ":" #fn ":" #reqs ":" #prereqs ":" #postreqs

'postreq' are requisite functions that the given function must be run before (USB init priot to console if using a USB serial dongle for example)

Then:

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?

Hi Wolfgang,

Quoted 6 lines · Wolfgang Denk

Dear Graeme Russ,

Quoted 3 lines · In message <[email protected]> you wrote:

Which got me to thinking, what if we had an initcall macro which included the dependency information. Imagine this rough example:

Quoted 8 lines

...

Quoted 5 lines

INITCALL(display_banner, "banner", "dram,board_early")

Which says that the display_banner() function, when completed fulfils the 'banner' dependency, and requires both the 'dram' and 'board_early' dependencies to be fulfilled in order to run

Sounds great!

OK, I think I can do this...

#define INIT_FUNC(fn, stage, reqs, prereqs, postreqs) \
? ? ? ?static const char *__initfunc_ ## fn __used \
? ? ? ?__attribute__((__section__(".initfuncs"))) = \
? ? ? ?#stage ":" #fn ":" #reqs ":" #prereqs ":" #postreqs

'postreq' are requisite functions that the given function must be run before (USB init priot to console if using a USB serial dongle for example)

Then:

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?

Regards,

Graeme

Dear Graeme,

Quoted 1 line · In message <[email protected]> you wrote:

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 been thinking if there is a way we can avoid the post-processing perhaps by specifying two function parameters to the macro (the init function to call and its prerequisite) and having the initcall code sort the list before starting. We could have dummy

Dear Simon Glass,

Quoted 1 line · In message <CAPnjgZ3aOyvYPA93ecbMyqhCaaZcBPhfcYhXYYa1ax+9_uEojw@mail.gmail.com>…

Quoted 4 lines

I have been thinking if there is a way we can avoid the post-processing perhaps by specifying two function parameters to the macro (the init function to call and its prerequisite) and having the initcall code sort the list before starting. We could have dummy

You mean sort at runtime?

NAK. ?all this must be done when building, i. e. at compile time.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "The combination of a number of things to make existence worthwhile." "Yes, the philosophy of 'none,' meaning 'all.'"
? ? ? ?-- Spock and Lincoln, "The Savage Curtain", stardate 5906.4

Dear Graeme,

Quoted 1 line · In message <[email protected]> you wrote:

Quoted 11 lines

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:

Quoted 7 lines

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

Hi Wolfgang,

Quoted 4 lines · Wolfgang Denk

Dear Graeme,

Quoted 1 line · In message <[email protected]> you wrote:

[snip]

Quoted 19 lines

Quoted 11 lines

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:

Quoted 7 lines

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

Quoted 7 lines

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","")

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

Regards,

Graeme

Hi Graham,

Quoted 8 lines · Graeme Russ

Hi Wolfgang,

Quoted 4 lines · Wolfgang Denk

Dear Graeme,

Quoted 1 line · In message <[email protected]> you wrote:

Quoted 12 lines

Quoted 6 lines

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

Quoted 1 line

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?

Quoted 45 lines

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

Quoted 3 lines

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.

Hi Simon,

Quoted 11 lines · Simon Glass

Hi Graham,

Quoted 8 lines · Graeme Russ

Hi Wolfgang,

Quoted 4 lines · Wolfgang Denk

Dear Graeme,

Quoted 1 line · In message <[email protected]> you wrote:

[snip]

Quoted 12 lines

Quoted 12 lines

Quoted 6 lines

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

Quoted 8 lines

Quoted 1 line

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?

Well I kind of like see that a particular init function is explicitly a pre- or post- relocation function. But yes, having barrier pre-requisites would achieve the same effect.

Quoted 49 lines

Quoted 48 lines

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

Quoted 3 lines

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?

SKIP_INIT(foo) simply removes all 'foo' init functions from the list _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

Quoted 6 lines

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(!)

The idea behind this all is that we do not know today what we will need tomorrow. Our biggest issue right now is that if a board needs to tweak the init sequence, it needs to touch arch/foo/board.c and hence introduces the potential to break working boards.

With this proposal, if a board wants to entirely re-write the init sequence, it can add a whole bunch of SKIP_INIT(blah) and then add it's own INIT_FUNC(init_func, "myboard_bar"...) and nobody else will be the wiser as to what is going on. The problem the is if the arch adds a new init step, it may not be covered by the skip list by that board - tough, lesson learn't for being so esoteric ;)

Quoted 3 lines

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.

Exactly. My example was a poor practical example, but it demonstrated a point. Obviously, clear_bss() does not belong with the relocation code

Quoted 4 lines

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)

In such circumstances, we still have weak functions. I see no reason to not keep on using weak functions for init functions that have well defined override scenarios (cache initialisation is a prime example, so is timer initialisation)

Quoted 1 line

Anyway, it sounds very promising.

Yes, it's a lot better than my original proposal :)

Regards,

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

Quoted 5 lines

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?

Well I kind of like see that a particular init function is explicitly a pre- or post- relocation function. But yes, having barrier pre-requisites would achieve the same effect.

Quoted 3 lines

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?

SKIP_INIT(foo) simply removes all 'foo' init functions from the list _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

With this proposal, if a board wants to entirely re-write the init sequence, it can add a whole bunch of SKIP_INIT(blah) and then add it's own INIT_FUNC(init_func, "myboard_bar"...) and nobody else will be the wiser as to what is going on. The problem the is if the arch adds a new init step, it may not be covered by the skip list by that board - tough, lesson learn't for being so esoteric ;)

Quoted 1 line

Anyway, it sounds very promising.

Yes, it's a lot better than my original proposal :)

Quoted 4 lines

Well I kind of like see that a particular init function is explicitly a pre- or post- relocation function. But yes, having barrier pre-requisites would achieve the same effect.

Quoted 4 lines

SKIP_INIT(foo) simply removes all 'foo' init functions from the list _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.

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.

Just a thought. Why don't split it to ARCH_INIT, BOARD_INIT,.

Quoted 2 lines · Wolfgang Denk

Dear "Hebbar, Gururaja",

[snip]

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

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

Quoted 8 lines

I don't see why that would happen? ?I see no intention nor any need for duplicated code.

Quoted 3 lines

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.

Quoted 9 lines

Quoted 3 lines

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.

Quoted 6 lines

Best regards,

Wolfgang Denk

Regards,
Gururaja

Hi Gururaja,

Quoted 31 lines · Gururaja

Quoted 2 lines · Wolfgang Denk

Dear "Hebbar, Gururaja",

[snip]

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

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

Quoted 8 lines

I don't see why that would happen? I see no intention nor any need for duplicated code.

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

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.

Quoted 4 lines

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

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

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.