On 03/21/2013 08:37:32 AM, Wolfgang Denk wrote:
Dear Tom,
In message <20130321122923.GB26945@bill-the-cat> you wrote:
>
> > Not really. Only a tiny fraction of users will ever run any
standalone
> > applications, so please let's save the memory footprint for the
> > overwhelming majority of users who do not need that.
>
> Well, can we run into this problem on ARM (v7 or v8) systems as
well?
Probably.
But I wonder what the exact usage szenario is that will trigger the
problem. If I understand correctly, this can only happen when you
perform a (manual) memory copy (either between different locations in
RAM, or from parallel NOR flash to RAM) of the code you are going to
run.
Yes, the person who is seeing this problem is copying code from flash
to RAM.
As far as I understand all other ways to load any such code (over the
network or from storage devices) already make sure to run
flush_cache()
after any such load operation.
A lot of places seem to have it, but it seems not everywhere. I'm not
aware of such a flush for NAND reads.
We could instead try to make sure everything, including commands like
"cp" and "mm", flush cache when they're done. This approach is more
user friendly, though it has a higher risk of missing some code path.
Scott: is my understanding correct that you only need this because
you are performing such memory copy ops manually? From where / to
where are you copying, and why?
As above it's from flash (I assume NOR) to RAM. The "why" is to be
able to run the code from RAM. :-P
Thinking about alternatives:
- eventually we should discourage the use of "go"; it may be
conveniend when you know what you are doing, but if it's casuing
such problems we might be better off recommending to use
proper IH_TYPE_STANDALONE legacy images in combination with the
bootm command instead.
That or bootelf, sure. I think there still should be some way to do it
manually, though. bootm/bootelf probably wouldn't work for this use
case because it involves releasing other cores after the image is
copied/flushed, but before u-boot gives up control on the boot core.
- Also, instead of adding a new command, this could probably be
scripted; I guess this should be roughly equivalent?
setenv flush_cache 'dc off;ic off;dc on;ic on'
This assumes that we support those cache operations, that they affect
all relevant caches (on 85xx it only flushes L1, but at least on newer
chips L2 is relevant as well), and that there are no errata or
architectural limitations to running with caches off.
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
