From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Thu, 09 Feb 2012 11:31:49 +0530 Subject: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? In-Reply-To: <20120208162335.EDD21185B4D4@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> Message-ID: <4F33614D.8020904@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 Wednesday 08 February 2012 09:53 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4F328B41.2050008@ti.com> you wrote: >> >> But since then I changed my mind due to some other factors: >> 1. Difficulty in debugging. I use JTAG debuggers. The workarounds >> available are still painful and not many people know about it. > > We use JTAG debuggers all day, and have been doing so for well over 10 > years. All development of PPCBoot nad U-Boot has been done withJTAG > debuggers. Relocation has never been a real problem here. > > Reasinf the manual may help - this is documented in detail there. > > This is not a good reason to reconsider. > >> 2. On FPGA platform, it was adding a considerable delay (I don't have >> the exact number, but that will be in minutes). The u-boot was already >> scaled down and was doing minimal stuff, but this one could not be >> removed easily. That's when I created that patch. > > 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. > >> 3. Un-necessary complexity without any benefit for our platform. I > > Maintaining different configurations of the code that behave > differently, that can cause different types of addressing, compile > and link and debug issues is also adding complexity. Using a single, > well tested approach is one of the benefits even for your platform. Fair enough. But will the new INITCALL framework help? I haven't really followed the discussions on it. But if, as Graeme claims, all relocation stuff is collected in one place and is easily pluggable then maintainability is not a problem, right? Maybe, I should stop the arguments now and wait till that framework is a reality. best regards, Aneesh