From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Fri, 06 Jan 2012 07:35:40 +0100 Subject: [U-Boot] initcall revisited - A new idea to discuss In-Reply-To: <1BAFE6F6C881BF42822005164F1491C305CE73@DBDE01.ent.ti.com> References: <4F019ABB.9010201@gmail.com> <20120102144904.A3F1082272@gemini.denx.de> <4F02DA64.60502@gmail.com> <20120103144413.981E0183AA32@gemini.denx.de> <1BAFE6F6C881BF42822005164F1491C305CE73@DBDE01.ent.ti.com> Message-ID: <20120106063540.3C5791FD3DA@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear "Hebbar, Gururaja", In message <1BAFE6F6C881BF42822005164F1491C305CE73@DBDE01.ent.ti.com> you wrote: > > > 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. This point of vew is too restricted. Think of boards that use SPL, or where a rom boot loader loads U-Boot directory to RAM, or ... > > 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. I don't see why that would happen? I see no intention nor any need for duplicated code. > 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. What makes you think so? > Just a thought. Why don't split it to ARCH_INIT, BOARD_INIT,. Because it's not such an easy split. You can define such groups, like arch, SoC, board family, board. But you cannot initialize the system in such grous - instead, initialization will jump around heavily between these groups, in a sequence that needs to be well defined, and that is often diofferent from board to board. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de When properly administered, vacations do not diminish productivity: for every week you're away and get nothing done, there's another when your boss is away and you get twice as much done. -- Daniel B. Luten