On 03/21/2013 12:58:37 PM, Albert ARIBAUD wrote:
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.
bootm subcommands are programmatic in normal use cases.
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.
Then how would we know what range to flush?
-Scott