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 > - 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
