Hi Wolfgang On Wed, Aug 24, 2011 at 11:58 PM, Graeme Russ <graeme.r...@gmail.com> wrote: > Hi Wolfgang, > > On 24/08/11 23:24, Wolfgang Denk wrote: >> Dear Graeme Russ, >> >> In message <4e54f501.6050...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot