From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Tue, 7 Feb 2012 07:41:24 +0100 Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation In-Reply-To: References: <1328424259-12914-1-git-send-email-sjg@chromium.org> <4F2F9294.4030805@gmail.com> <201202061427.02208.vapier@gentoo.org> Message-ID: <4F30C794.50206@de.bosch.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 06.02.2012 21:25, Graeme Russ wrote: > Hi Mike, > > On Tue, Feb 7, 2012 at 6:27 AM, Mike Frysinger wrote: >> On Monday 06 February 2012 09:49:27 Tom Rini wrote: >>> On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote: >>>> On 02/06/2012 06:51 PM, Wolfgang Denk wrote: >>>>> Graeme Russ 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). >> if you have a static platform which never changes, isn't the relocation a >> waste of time ? i can understand wanting relocation by default for platforms >> where memory sizes are unknown, but it's not uncommon for people to have fixed >> hardware when they deploy. > > Also, if SPL can determine total SDRAM, copy U-Boot to the final location > and perform the relocations, there is no need for relocation to be done by > U-Boot. As I understand it, SPL loads U-Boot into a fixed address and then > U-Boot copies itself to top-of-RAM. We can save one copy Yes, exactly, saving this one copy was the the reason for me to start this thread. Thanks Dirk