[U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation

[Aneesh V]

Dear Wolfgang,

On Friday 25 March 2011 07:42 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1301058732-30898-1-git-send-email-aneesh at ti.com>  you wrote:
>> Relocation may not be needed and desirable in many cases:
>>   * For many boards the amount of SDRAM is fixed.
>>     So relocation is not needed.
>
> This is plain wrong.  This has been explained a couple of times
> before.  Please read the archives.
>

I read this one:
http://tree.celinuxforum.org/pipermail/celinux-dev/2009-December/001916.html

I also read again this discussion I had started sometime back:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262

I don't think any of these features will suffer due to my change.
Please note that the memory for pRAM, frame buffer etc would still
be allocated at the end of available memory. I am preventing only code
relocation.

My strategy is to leave enough space before and after the U-boot in the
non-relocation case. Before the U-Boot for Linux, after U-boot for
stack, heap and all other dynamic needs. Wouldn't that work? Am I
missing something?

>>   * Relocation adds un-necessary additional overhead when
>>     it's not needed. This delay is singificant on slower
>>     platforms such as FPGA
>
> Do you have numbers?  How much delay do you see caused by the
> relocation of U-Boot?

No, I don't have any numbers. In fact, if I enable relocation I get
into some issues on the FPGA platform I am working on currently. But
that seems to be a problem with the platform (For some reason, it
doesn't work well when some code is copied to a new area and
executed from there - maybe some issue with the memory model).

But the platform is so slow that booting U-boot itself takes couple of
minutes. The overhead due to relocation will surely get magnified in
such cases.

Another problem I have with relocation is that it makes debugging with
JTAG debugers more difficult. The addresses of symbols in the ELF
target are no longer valid. Of course, you can load the symbols at an
offset from the original location. But one has to first enable debug
prints, find the relocation offset, use it while loading the symbols
before you can do source level debugging.

>
>>   * Many boards have ample memory. So reserving enough memory
>>     for Linux in the first half is not a challenge even without
>>     relocation
>
> You appear not to understand what relocation is needed for.
>
>
> I tend to reject your patch, unless you can come up with really
> convincing arguments. Also, your patch should then work for all
> boards - not only ARM, but also PowerPC (one of the arguments for
> relocation was that we want to unify the code).

I am afraid I will not be able to do that for all the archs primarily
because I will not be able to test anything other than armv7 and also I do
not understand their assembly languages. Sometimes, fixes in
relocate_code() will be needed to make sure the special case of
relocation offset = 0 works well. I had to do that for armv7(It's part
of the SPL series). However, the same principles as in this patch
should apply everywhere it shouldn't be very difficult to make it work
for any architecture when there is a need.

best regards,
Aneesh