Hi Scott,
On Wed, 20 Mar 2013 17:35:51 -0500, Scott Wood scottwood@freescale.com wrote:
On 03/20/2013 05:11:57 PM, Albert ARIBAUD wrote:
Hi Scott,
On Wed, 20 Mar 2013 14:36:05 -0500, Scott Wood scottwood@freescale.com 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.
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.
Still, why make it a shell command? Since this user needs a flush with "go" and "cpu release", then we should add a programmatic global cache flush in the "go" and "cpu release" commands.
Why add any new commands? They could all be subcommands of bootm! :-)
I did not say "subcommand", I said "programmatic" -- precisely, I don't like the idea that a specific command or command form is needed to avoid a situation that can be avoided automatically.
Really, instead of adding one command, you want to modify *two* commands to do the same thing separately, which involves changing the syntax of both commands to accept memory range information?
There is no need to change any syntax.
-Scott
Amicalement,