Hi, On Fri, Jan 06, 2012 at 10:29:48, Graeme Russ wrote: > Hi Simon, > > On Fri, Jan 6, 2012 at 3:30 PM, Simon Glass <s...@chromium.org> wrote: > > Hi Graham, > > > > On Thu, Jan 5, 2012 at 2:18 PM, Graeme Russ <graeme.r...@gmail.com> wrote: > >> Hi Wolfgang, > >> > >> On Wed, Jan 4, 2012 at 1:44 AM, Wolfgang Denk <w...@denx.de> wrote: > >>> Dear Graeme, > >>> > >>> In message <4f02da64.60...@gmail.com> you wrote: > >>>> > >> > > [snip] > > >>> > >>> One thing comes to mind: it would be nice if we can find a way that > >>> the INIT_FUNC definitions behave similar to "weak" functions - if an > >>> init_func can be redefined / overwritten / modified by board specific > >>> code we eventually have a very nice way to get rid of the related > >>> #ifdef's. > >> > >> I have a thought on this. How about a SKIP_INIT macro. Here's the idea > >> using SDRAM as an example: > >> > >> At the arch level you may have > >> > >> INIT_FUNC(sdram_init, f, "sdram", "console","") > > > > Gosh this email took a few readings :-) > > > > Can we get rid of the 'f' parameter? If we invent a prerequisite > > called 'relocated' or something like that, to act as a barrier, then > > maybe the order can be defined just like any other function which > > depends on being before or after something? > > Well I kind of like see that a particular init function is explicitly a > pre- or post- relocation function. But yes, having barrier pre-requisites > would achieve the same effect. > > >> so sdram_init sets the "sdram" requisite and must be done after all > >> "console" requisites have been completed. > >> > >> Now if a SoC or board has an init that must be done before SDRAM: > >> > >> INIT_FUNC(pre_sdram_init, f, "pre_sdram", "", "sdram") > >> > >> So this sets the pre_sdram requisite, requires no other initialisation > >> before running and must happen before and "sdram" init functions are run > >> > >> Now lets say the Soc or board has a unique sdram init function that > >> overrides the arch's sdram init. We could just use weak functions and > >> allow the SoC or board to override sdram_init. But what if the SoC or > >> board has additional pre-requisite (or post-requisite) init requirements? > >> > >> So in the SoC or board file: > >> > >> SKIP_INIT(sdram) > >> INIT_FUNC(board_sdram_init, f, "board_sdram","pre_sdram,vreg,console", "") > >> > >> Using "board_sdram" versus "sdram_init" is cricital: > >> > >> The init sequence build tool will first create the entire init sequence > >> including the functions marked as "sdram" and "board_sdram". But after > >> building the arrays, it will strip out all the functions marked as "sdram" > >> init functions. The reason the entire list has to be build first is so the > >> functions that rely on "sdram" can be added without unmet prerequisite > >> errors. > >> > >> Of course, if you use SKIP_INIT(foo), you need to make sure that any > >> replacement INIT_FUNC will do everything foo did to make your board work. > >> > >> Interestingly, this allows the following: > >> > >> INIT_FUNC(calc_relocation, fr, "calc_reloc", "sdram", "") > >> INIT_FUNC(copy_uboot_to_ram, fr, "copy_to_ram", "calc_relocation", "") > >> INIT_FUNC(do_elf_reloc_adjusments, fr, "elf_reloc", "copy_to_ram", "") > >> INIT_FUNC(clear_bss, fr, "clear_bss", "calc_reloc", "") > >> > >> #ifdef CONFIG_SYS_SKIP_RELOCATION > >> SKIP_INIT(calc_reloc) > >> SKIP_INIT(copy_to_ram) > >> SKIP_INIT(elf_reloc) > >> #endif > >> > >> So if CONFIG_SYS_SKIP_RELOCATION is defined, relocation is not performed, > >> but clear_bss still is > >> > > > > I wonder what happens when you skip something - does it substitute for > > any pre/post-requisites that the skipped item had? Or would that be > > illegal? > > SKIP_INIT(foo) simply removes all 'foo' init functions from the list > _after_ the list has been created - If this breaks dependencies that's > your problem ;). It is up to you as the 'skipper' to make sure that you > add init functions to allow things to still work
Won't this lead to lots of code duplication across all boards, archs. So, tomorrow someone else will send a patch removing duplicate and merging it to a common place. Why don't start it in 1st place. > > > I can see plenty of opportunity for confusion, but if the tool is > > friendly enough, then this could solve a lot of the override problems. > > In your particular example it feels like it would be easier to just > > make the INIT_FUNC conditional on an config using #ifdef (horror!), or > > perhaps yet another parameter(!) > > The idea behind this all is that we do not know today what we will need > tomorrow. Our biggest issue right now is that if a board needs to tweak > the init sequence, it needs to touch arch/foo/board.c and hence introduces > the potential to break working boards. > > With this proposal, if a board wants to entirely re-write the init > sequence, it can add a whole bunch of SKIP_INIT(blah) and then add it's > own INIT_FUNC(init_func, "myboard_bar"...) and nobody else will be the > wiser as to what is going on. The problem the is if the arch adds a new > init step, it may not be covered by the skip list by that board - tough, > lesson learn't for being so esoteric ;) > So, every board, even under same arch, needs to define its own *complete-set* of INIT_CALL api's. I am dreaming about a lot of MB getting added to u-boot src. Just a thought. Why don't split it to ARCH_INIT, BOARD_INIT,. > > Or we could just put those relocation functions in their own file and > > have it omitted from the build by the Makefile in the case where > > CONFIG_SYS_SKIP_RELOCATION is defined. > > Exactly. My example was a poor practical example, but it demonstrated a > point. Obviously, clear_bss() does not belong with the relocation code > > > And if we want wanting to replace a generic function with a > > board-specific one, why not just something like: > > > > INIT_OVERRIDE(new_func, old_func) > > In such circumstances, we still have weak functions. I see no reason to > not keep on using weak functions for init functions that have well defined > override scenarios (cache initialisation is a prime example, so is timer > initialisation) > > > Anyway, it sounds very promising. > > Yes, it's a lot better than my original proposal :) > > Regards, > > Graeme > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > Regards, Gururaja _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot