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

[Aneesh V]

Dear Wolfgang,

On Wednesday 08 February 2012 07:28 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4F3219A8.7090607 at ti.com>  you wrote:
>>
>> As for ignoring comments, I think you are culpable of that more than me
>> in this specific instance:) (of course I know you are busy person, but
>> still..). For instance, my arguments in the previous round [1] never
>> got an answer from you.
>>
>> [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/96371
>
> I don't see any question from you that has not been answered?
>
> You suggest to do things in a way that introduces a number of
> often discussed disadvantages.  And you claim that for you this would
> be good enough.  What should I comment on this?
>
> For the record:
>
> - You continiue to talk about relocation, but you mean something
>    different (a memory copy).  I am not sure if you really understand
>    the difference.

I do understand what the ELF relocation does.

>
> - You claim omitting this copy operation would be important to
>    optimize boot times, but you cannot provide any real numbers that
>    support such a claim:
>
>    * You do not know how much time exactly is needed for this copy
>      operation, so you don't know how much you can potentially safe,
>      and if this would result in any perceptible imprvement of the boot
>      time.

I had provided data for OMAP4 and agreed with you that from the boot
time point of view it doesn't make sense to disable relocation [1].

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.

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.

3. Un-necessary complexity without any benefit for our platform. I
nearly get exhausted explaining to new u-boot users how it all works
and nearly always gets confronted with the question "why do we
need it?" In our platforms U-Boot starts from SDRAM and we do not need
any of the flexibilities relocation may provide.

>
>    * You did not investigate how long other parts of the boot process
>      are talking, so you don't really know where the hot spot where you
>      should focus your optimization efforts.
>
>    * You did not investigate how the timing behaviour changes if you
>      enable both instruction and data cache in the SPL. In my
>      experience this would be a way more rewarding target for
>      optimization efforts than omitting a little memcpy().

We have caches enabled. But anyway, these two points are irrelevant
because my argument is not from the point of view of time.

At the end of the day I think we are making U-Boot way too complex for
a bootloader and I think relocation is one of the factors.

[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88288