From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Thu, 09 Feb 2012 19:13:31 +0530 Subject: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? In-Reply-To: <20120209114417.2CEC0193BB47@gemini.denx.de> References: <4F2B8BD1.2030009@de.bosch.com> <4F2CF73F.2090407@ti.com> <4F2D0FE7.8020107@aribaud.net> <4F304463.1050901@aribaud.net> <20120206222721.30001193BB55@gemini.denx.de> <4F30D06E.8060200@ti.com> <20120207232605.3009682373@gemini.denx.de> <4F3219A8.7090607@ti.com> <20120208135837.A1E6C185B4D3@gemini.denx.de> <4F328B41.2050008@ti.com> <20120208162335.EDD21185B4D4@gemini.denx.de> <4F33614D.8020904@ti.com> <20120209114417.2CEC0193BB47@gemini.denx.de> Message-ID: <4F33CD83.6080302@ti.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 Thursday 09 February 2012 05:14 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4F33614D.8020904@ti.com> you wrote: >> >>> What exactly are you talking about here that "was adding a >>> considerable delay" - the memory copy ? Are you really sure about >>> that? >> >> I didn't measure it part by part, but removing relocation gave a >> noticeable speed-up, this platform is several orders of magnitude >> slower than the real silicon. So, that should not be surprising. > > Could you please start using exact terminology, so we understand what > you actually refer to? Did you really remove the _relocation_, i. e. > link for a static address, or did you just skip the memory copy? Note > that the latter should be a no-op anyway if you just load the image to > the resulting target address. I defeated relocation by passing to the relocate_code() function the same address as it is linked to. I patched up arch/arm/lib/board.c for this and fixed up the relocate_code() to correctly handle this special case. So, relocate_code() does only .bss init now. > >> Maybe, I should stop the arguments now and wait till that framework is >> a reality. > > I am very much convinced that you are tracking down a red herring. It > does not really matter if you run the code on real silicon or in an > emulation - the relative times will always be the same. Without any > detailed timing analysis I simply do not believe you that you really > have found a hot spot. You focus on it because you found out that it > exists and you think it was "not needed" in your configuration - > without spending time on real optimization. Please note that our bootloaders and kernel are customized and scaled down for this environment. For instance, u-boot doesn't load the kernel from network or a memory device. The kernel is preloaded in the modeled memory for it. So, u-boot was just used to jump to the kernel. As such, the u-boot run-time is now more dominated by pure software stuff such as relocation. The relative timing doesn't quite apply. > > This is a fundamentally broken approach, and it will remain to be > broken even if new concepts get implemented that may make it easier to > skip certain steps of the initialization. > > If you are concerned about boot time optimization, you _must_ start > with timing measurements. You know where premature optimization leads > to, don't you? As I mentioned earlier boot-time is not my key care-about. Even on an emulation platform I will probably try SPL Linux boot next time. My key concerns are about the other aspects I mentioned, namely avoidable complexity and problems with debugger. br, Aneesh