[U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Aneesh V <aneesh@ti.com>]

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