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