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

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4C9399A7.5020006 at free.fr> you wrote:
>
> Depends on the processor I guess; but still, my point is that "start at 
> any location" does not require that you detect whether you are fresh out 
> of reset or not.

OK. I've repeated that often enough now, I will not iterate over this
any longer.

> 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 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.

> > 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.

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...


> 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Calm down, it's *__only* ones and zeroes.