[U-Boot] [PATCH 12/26] ARM: add relocation support

[Albert ARIBAUD]

Le 17/09/2010 21:04, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,

>> Reminder: here we're talking about fitting a>64 KB u-boot in flash,
>> with _start at the reset vector (0xffff0000 on orion5x), without wasting
>> the space above the reset vector (64 KB on orion5x) and with minimal
>> waste in the rest of the mapping.
>
> We do similar things on several boards to align the environment with
> special, small flash sectors that happen to lie in the middle of the
> image.
>
> Your case is the same  - you would align the _start such that it is
> located right in the middle of the image: not on a specific flash
> sector, but at the reset vector.
>
>> You suggested tweaking the linker file to manually place the _start
>> symbol at the reset location, and then bin-pack the rest of the code --
>> some of which will have to go above _start, some below. This can only be
>> achieved by defining 'MEMORY' regions in the linker file, and then you
>
> This is not needed.

This is the only way to *ensure* a symbol ends up linked at a given 
address. Methods based on  -- at least the only one that isn't utterly 
sensitive to any change in the configuration.

>> This is why I say that the proposed solution of manually tweaking the
>> linker file is sensitive to configuration changes.
>
> Yes, it is. I do not deny that. But this is not a real problem. If
> the configuration grows such that you need an additional flash
> sector, you will have to adjust TEXT_BASE.  This does not happen
> frequently.
>
>>>> Only for a given u-boot configuration. Change it, and that changes the
>>>> image content, thus the mapping, and you've got to fix _start again.
>>>
>>> Why should I?
>>
>> Your change may overfill one of the 'MEMORY' regions that would have to
>> be defined to get _start mapped to the reset vector location.
>> Personally, I hate it when I enable some configuration option and it
>> results in a link-time mapping error.
>
> The "upper part", for reset vector to end of address space, would
> never change.

This is a bold assumption to make, and hard to prove, I think.

>>> location? Then we can use constant data (comon to all board
>>> configurations) to fill the gap between there and end of physical
>>> memory space.
>>
>> That will not fill it properly and consistently unless that constant
>> data is 1) really constant across all configuration option choices for
>> all boards and 2) nicely filling the gap up to 64 KB.
>
> See for example the TQM860L board configuration - it uses an embedded
> flash sector, with manual tweaking in the linker script.

You mean the one in which the comment about hand-optimizing ends with 
"XXX FIXME XXX" ? :)

I fail to see that it is an example of setting _start at a specific 
location within the image: it sets it at the first location of .text 
always. My problem is being able flash an image bigger than 64 KB while 
getting _start to end up flashed at 0xffff0000, which means putting 
_start somewhere in the middle of the .text section (which this ld trick 
does not help do)... or use the solution I posted (see below).

> u-boot.map for this board shows:
>
> ...
>   arch/powerpc/lib/cache.o(.text)
>   .text          0x40007c20       0x64 arch/powerpc/lib/cache.o
>                  0x40007c20                flush_cache
>                  0x00008000                . = DEFINED (env_offset)?env_offset:.
>   *fill*         0x40007c84      0x37c 00
>   common/env_embedded.o(.ppcenv)
>   .ppcenv        0x40008000     0x8000 common/env_embedded.o
>                  0x40008000                environment
>                  0x4000c000                redundand_environment
>   *(.text)
>   .text          0x40010000        0x4 common/env_embedded.o
>                  0x40010000                env_size
>   .text          0x40010004        0x0 lib/libgeneric.a(ctype.o)
> ...
>
> So we are "wasting" 0x37c = 892 bytes of memory for an unused gap.
> The last changes where the object placing had to be changed due to
> code size etc. were commit 32482be6 (Feb 19, 2009), and before that
> fe57bb19 (Sep 18, 2002). Having to tweak this file every 7 years or
> so is something I'm considering to be acceptable.  YMMV...

This is a simple alignment. I do not need to align code, I need to map 
*one* symbol, namely _start, at a given location, here 0xffff0000, so 
that the 64 KB sector which contains start is not wasted and the image 
resides in as few sectors as possible.

>> As I said, I have a solution for my problem which puts _start at the
>> reset vector location without changing the linker file at all, and with
>> little, contained and controlled changes to the start.S file. I will
>> post this as a [PATCH][NEXT] ([RFC] also if you will), clearly exposing
>> the issue it addresses and the solution it uses, and we can discuss its
>> merit then.
>
> I'm looking forward to seeing your patches.

I am finishing it for next, but you can already see the version for 
master I'd posted, and then withdrawn only because I wanted to rewrite 
it above Heiko's patches. It is at 
http://www.mail-archive.com/u-boot@lists.denx.de/msg37952.html, and 
there is a large comment to explain how it works. As indicated, it has 
been tested for all functional cases.

Note that the new version will slightly differ in the order of the 
copies, so as to minimize register usage.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.