On 03/20/2013 02:59:19 PM, Tom Rini wrote:
On Wed, Mar 20, 2013 at 02:36:05PM -0500, Scott Wood wrote:
On 03/20/2013 02:15:19 PM, Tom Rini wrote:
On Wed, Mar 20, 2013 at 11:43:15AM -0500, Scott Wood wrote:
On 03/20/2013 09:58:36 AM, Wolfgang Denk wrote:
Dear Albert,
In message 20130320145927.2031b913@lilith you wrote:
I do understand what it does, but I still don't get why it
should be
done, since precisely payload control transfer happens through
bootm and
the like which already properly flush cache.
It doesn't always happen through bootm. Standalone apps use the "go" command.
So, to try and be a bit more verbose about this, for U-Boot applications which use 'go', we still need to ensure cache coherence, which is
why
bootm does a cache flush, we need some way to flush in this case.
It's also an issue with using the "cpu <n> release" command.
Hadn't seen that command before, where is it?
common/cmd_mp.c
And in this case you aren't better served by say bootelf ?
That wouldn't handle the "cpu release" case. In any case, "go" exists and is currently the recommended way to launch a standalone application in doc/README.standalone.
It's a user command! How can it be dead code? I don't know of a way to include a human user in a patchset...
Can you hightlight what exactly causes the world today to go off
and
fail? Is the hello_world example app sufficient in this case or
do we
need something much larger?
A user inside Freescale is running standalone performance test apps, using both "go" and "cpu <n> release" (since the test needs to run on all CPUs). They are seeing cache problems running on a T4240 if they don't have this flush. This flush is architecturally required between modifying/loading code and running it.
OK, so this does sound like a real need / use for it, and if we added the granularity of CONFIG_CMD_CACHE_FLUSH or similar, it would be reasonable to turn it on to a large number of boards for a small space savings (so lets not). My next concern is that this needs build testing (and some inspection) on say ARM where we have a weak flush_cache already. But perhaps the right answer is to say it doesn't make sense to add CONFIG_CMD_CACHE on an architecture which doesn't already provide flush_cache, so drop the weak one from this patch.
flush_cache() is already called from generic code, so we should be ok just dropping the weak function.
-Scott