Dear Albert ARIBAUD,
In message <4c9399a7.5020...@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: w...@denx.de
Calm down, it's *__only* ones and zeroes.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
