[U-Boot] [RFC] command/cache: Add flush_cache command
Scott Wood
scottwood at freescale.com
Thu Mar 21 21:34:42 CET 2013
On 03/21/2013 02:25:10 PM, Wolfgang Denk wrote:
> Dear Scott,
>
> In message <1363890157.31522.14 at snotra> you wrote:
> >
> > As above it's from flash (I assume NOR) to RAM. The "why" is to be
> =20
> > able to run the code from RAM. :-P
>
> * Why don't you run it form flash?
Presumably because it's slow. As indicated elsewhere in the thread,
these are performance tests.
> * Why do you insist on using the "go" command (instead of "bootm" with
> a IH_TYPE_STANDALONE image?
Presumably because of the need to release other cores first.
> > > - 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.
>
> The "releasing other cores" would then be a sub-command in the bootm
> sequence?
Perhaps it could be, or the application could be altered to release
secondary cores through the spin table. I don't think that excuses a
situation where some ways of putting a blob of bytes into RAM flush the
cache (to the extent the architecture requires it for the blob of bytes
to be executable) and others don't, and there's no way to do it
manually. Would you remove the "go" command entirely? I think that
would be a mistake.
-Scott
More information about the U-Boot
mailing list