From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Wed, 8 Feb 2012 07:42:12 +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> <4F30C794.50206@de.bosch.com> <20120207232317.D164482373@gemini.denx.de> <20120207233628.0F9A282373@gemini.denx.de> Message-ID: <4F321944.2070803@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 08.02.2012 00:48, Graeme Russ wrote: > Hi Wolfgang, > > On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk wrote: >> Dear Graeme Russ, >> >> In message you wrote: >>>> If SPL was to determing the relocation address, it would also have to >>>> read the environment, because there are a number of environment >>>> variables which can cause (dynamically) the relocation address to >>>> change. >>> But this is not neccessarily the case for every board (or even every arch) >> Not neccessarily, but possible. >> >>> For those boards/arches which CAN calculate the relocation address (either >>> because it is fixed do to npn-variable RAM size, or fixed in relation to >>> the maximum RAM address) why should we prohibit a method of skipping the >>> redundant copy operation in a way which is 100% transparent to everyone >>> else? >> Can we please focus on unifying the boot process first, before we try >> to come up with micro-optimizations? > > Agreed - And as I have stated before, this capability will come about as > a natural side-effect of the boot process unification (see current x86 > repo ready for pull for illustrative example plus the INIT_CALL code I > am currently working on). So there is no need to look at hackish ways > to sidestep 'relocation' until then (at which point they won't be > needed anyway) > >> Most of the people who complain here that they need to skip >> relocation are probably wrong in at least two accounts: >> >> - They are not actually talking about relocation at all. > > Correct - The 'issue' is the additional in-RAM copy Yes. Best regards Dirk