From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Thu, 25 Aug 2011 09:00:50 +1000 Subject: [U-Boot] [RFC] New init sequence processing without init_sequence array In-Reply-To: <4E550369.8080207@gmail.com> 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 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 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