On 08.02.2012 08:12, Simon Glass wrote:
Hi Dirk,
On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
On 08.02.2012 00:36, Wolfgang Denk 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?
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.
- They don't base their accessment on any real, measured timings, or
otherwise they would start optimizing completely different areas of
the code.
Maybe they are looking at all areas (including the different ones) of
possible optimizations. And this thread is only one topic (note 1).
Best regards
Dirk
note 1: I agree that the different topics will give more improvement. E.g.
[1]. Looking at that thread, unfortunately there is less discussion than
here while it will give more improvement :(
[1] http://lists.denx.de/pipermail/u-boot/2012-February/117270.html
But turning on the cache should be trivial - it is already supported
so you just need to implement the enable_dcache() function(?)
As I understand it, the issue seems to be the non-cache-aware drivers.
Best regards
Dirk
Btw.: If possible, let's discuss the cache topic in the cache thread ;)
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
