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