From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Tue, 7 Feb 2012 07:51:22 +0100 Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation In-Reply-To: <4F304376.3020400@aribaud.net> References: <1328424259-12914-1-git-send-email-sjg@chromium.org> <4F2F9294.4030805@gmail.com> <201202061427.02208.vapier@gentoo.org> <4F304376.3020400@aribaud.net> Message-ID: <4F30C9EA.30401@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 22:17, Albert ARIBAUD wrote: > Le 06/02/2012 20:27, Mike Frysinger a ?crit : >> 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. > > Relocation may not be a waste of time if the static platform boots > U-Boot from NOR, as relocation will be needed to move U-Boot to RAM in > working order. > > Now if the platform is static and has a preloader of sorts, then one can > predict (or just observe) where U-Boot would want to relocate, and set > the preloader once and for all (for a given release of U-Boot, that is) > to load U-Boot directly at that address. U-Boot will skip copy and > relocation if it already resides at the right address. For the i.MX6 preloader, i.e. the i.MX6 boot ROM, the issue I observed is that the copy *and* relocation will be skipped [1]. The skipped copy is fine, skipping the relocation breaks things, though: Getting the address where U-Boot will relocate to, and setting this as CONFIG_SYS_TEXT_BASE will result in skipping the copy. Fine. But the whole 'fix .rel.dyn relocations' in e.g. arch/arm/cpu/armv7/start.S is skipped, too. And this breaks things. Best regards Dirk [1] http://lists.denx.de/pipermail/u-boot/2012-February/117134.html