Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@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
- They don't base their accessment on any real, measured timings, or
otherwise they would start optimizing completely different areas of the code.
Yes - x86 achieved a not insignificant performance boost after I added the ability to enable the SDRAM cache before copying U-Boot to RAM :)
Regards,
Graeme