From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Tue, 07 Feb 2012 12:55:24 +0530 Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation In-Reply-To: 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> <4F2F9294.4030805@gmail.com> Message-ID: <4F30D1E4.5000902@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Monday 06 February 2012 08:19 PM, Tom Rini wrote: > On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote: >> 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... > > To pick up Wolfgang's argument, but why do we want to skip relocation? > You can debug through it, it's documented (official wiki has GDB, > over in TI-land, the wiki page for CCS has the bits for doing it in > that Eclipse-based env, other debuggers I'm sure have a similar "now > add symbols at this offset from link" option) and the end result makes > it very easy for end-users to break their world (default kernel load > addrs being where U-Boot would be). Why do all that circus if it's not adding any value for a given platform. Also, in the previous thread on this I had pointed out a specific case where this was hurting us. On a slow FPGA platform the delay due to the relocation was getting magnified and un-necessarily wasting our time. best regards, Aneesh