From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Wed, 24 Aug 2011 23:58:01 +1000 Subject: [U-Boot] [RFC] New init sequence processing without init_sequence array In-Reply-To: <20110824132450.D253311F9E76@gemini.denx.de> 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> Message-ID: <4E550369.8080207@gmail.com> 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 24/08/11 23:24, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <4E54F501.6050706@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