From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Wed, 24 Aug 2011 16:41:15 -0700 Subject: [U-Boot] [RFC] New init sequence processing without init_sequence array In-Reply-To: References: <1313587343-3693-1-git-send-email-graeme.russ@gmail.com> <20110822201023.0F8A111EF9D9@gemini.denx.de> <20110823114920.AD2ED201520@gemini.denx.de> <20110824053849.2317F11F9E75@gemini.denx.de> <20110824064819.0529D11F9E76@gemini.denx.de> <20110824124951.3FA2C11F9E75@gemini.denx.de> <4E54F501.6050706@gmail.com> <20110824132450.D253311F9E76@gemini.denx.de> <4E550369.8080207@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Graeme, On Wed, Aug 24, 2011 at 4:00 PM, Graeme Russ wrote: > Hi Wolfgang > > On Wed, Aug 24, 2011 at 11:58 PM, Graeme Russ wrote: >> Hi Wolfgang, >> >> On 24/08/11 23:24, Wolfgang Denk wrote: >>> Dear Graeme Russ, >>> >>> In message <4E54F501.6050706@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 No, and fair enough too. > > 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 Yes indeed. > > 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 Ick. The more I read of this thread the more I like your original implementation. It really doesn't seem that hard to see the order of initcalls either from System.map or objdump | grep or similar. Write a nice long Python script if you like! Your implementation allows tracing of initcalls as they are made which is a big win. Early init cannot necessarily printf() but I don't see why initcalls must solve a problem which exists currently anyway (I have been thinking about buffering pre-console pre-reloc output and printing it later - it's not that hard, just a bit ugly). Yes moving to a dependency-based init sounds lovely, but this is U-Boot not Upstart. We do need to keep things reasonably simple - at least with your scheme we can tell at link time what the order will be. The other thing is that init ordering is often not critical bar a few early routines, and most of these will be fixed by the order selected in the arch/xxx/lib/board.c code. Board maintainers would likely only have a few ranges within which to add their init, and strongly discouraged from inserting an init function into the middle of an existing stable sequence in that file. I do tend to agree that merging the board.c code is a bigger win, but this might be a nice vehicle for doing it, since one could imagine an incremental approach with a CONFIG_NEW_INIT option which can be turned on/off for each board. As problems with each architecture (then each board) are ironed out, the option will turned on in the board config file. Regards, Simon > > Regards, > > Graeme PS: Regarding the late night work, kids, wives, etc. I am reminded of that 'quote' from Dr Johnson about his work with his 'U-Boot': ...that has taken eighteen hours of every day for the last ten years. My mother died; I hardly noticed. My father cut off his head and fried it in garlic in the hope of attracting my attention; I scarcely looked up from my work. > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >