From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 06 Feb 2012 22:17:42 +0100 Subject: [U-Boot] [PATCH] arm: Add option to disable code relocation In-Reply-To: <201202061427.02208.vapier@gentoo.org> References: <1328424259-12914-1-git-send-email-sjg@chromium.org> <4F2F9294.4030805@gmail.com> <201202061427.02208.vapier@gentoo.org> Message-ID: <4F304376.3020400@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. > although, with SPL picking up direct-to-Linux booting, this argument might not > matter that much anymore. Agreed, although one could make a point that SPL direct-to-Linux is not the most common case currently and may not be applicable to all cases anyway. > -mike Amicalement, -- Albert.