From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Wed, 8 Feb 2012 08:16:15 +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> <4F321B8C.3090907@de.bosch.com> Message-ID: <4F32213F.5050203@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 08:12, Simon Glass wrote: > Hi Dirk, > > On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme wrote: >> On 08.02.2012 00:36, 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? >>> >>> 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. >>> - They don't base their accessment on any real, measured timings, or >>> otherwise they would start optimizing completely different areas of >>> the code. >> >> Maybe they are looking at all areas (including the different ones) of >> possible optimizations. And this thread is only one topic (note 1). >> >> Best regards >> >> Dirk >> >> note 1: I agree that the different topics will give more improvement. E.g. >> [1]. Looking at that thread, unfortunately there is less discussion than >> here while it will give more improvement :( >> >> [1] http://lists.denx.de/pipermail/u-boot/2012-February/117270.html > > But turning on the cache should be trivial - it is already supported > so you just need to implement the enable_dcache() function(?) As I understand it, the issue seems to be the non-cache-aware drivers. Best regards Dirk Btw.: If possible, let's discuss the cache topic in the cache thread ;)