From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Mon, 06 Feb 2012 19:43:00 +1100 Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation In-Reply-To: <20120206075151.5A1C1193BB41@gemini.denx.de> References: <1328424259-12914-1-git-send-email-sjg@chromium.org> <201202050239.46251.vapier@gentoo.org> <201202051305.13462.marek.vasut@gmail.com> <201202051538.07054.vapier@gentoo.org> <20120205224446.17E8E193BB47@gemini.denx.de> <20120206075151.5A1C1193BB41@gemini.denx.de> Message-ID: <4F2F9294.4030805@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 02/06/2012 06:51 PM, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message you wrote: >> >> I think the immediate focus should be on centralising the init sequence >> processing into /common/init.c and then bringing the new'initcall' >> architecture online > > Agreed. > >> Once these have been done, any board can just specific: >> >> SKIP_INIT(RELOC) > > I will probably object to his, too - for the same reasons. Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object... It would be like a board not populated with USB hardware on a arch that globally defines it saying SKIP_INIT(USB) to avoid linking in the USB initialisation (maybe not the best example, but you get the point) Or if a pre-loader initialises SDRAM the board can specify SKIP_INIT(SDRAM) The point is we can specify a 'standard' set of init 'components' and boards can trivially disable any of these components as they see fit with zero impact on any other part of the U-Boot code base And they can add their own init components, again with zero impact on the U-Boot code base Regards, Graeme