On 08.02.2012 00:48, Graeme Russ wrote:
Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk <w...@denx.de> wrote:
Dear Graeme Russ,
In message <CALButCKfG+guStJP+M5E=nsr34vphzgbrebxquxd6028sw6...@mail.gmail.com>
you wrote:
If SPL was to determing the relocation address, it would also have to
read the environment, because there are a number of environment
variables which can cause (dynamically) the relocation address to
change.
But this is not neccessarily the case for every board (or even every arch)
Not neccessarily, but possible.
For those boards/arches which CAN calculate the relocation address (either
because it is fixed do to npn-variable RAM size, or fixed in relation to
the maximum RAM address) why should we prohibit a method of skipping the
redundant copy operation in a way which is 100% transparent to everyone
else?
Can we please focus on unifying the boot process first, before we try
to come up with micro-optimizations?
Agreed - And as I have stated before, this capability will come about as
a natural side-effect of the boot process unification (see current x86
repo ready for pull for illustrative example plus the INIT_CALL code I
am currently working on). So there is no need to look at hackish ways
to sidestep 'relocation' until then (at which point they won't be
needed anyway)
Most of the people who complain here that they need to skip
relocation are probably wrong in at least two accounts:
- They are not actually talking about relocation at all.
Correct - The 'issue' is the additional in-RAM copy
Yes.
Best regards
Dirk
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
