[U-Boot] [RFC] command/cache: Add flush_cache command

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/22/2013 10:03 AM, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <514C4BE8.10508 at ti.com> you wrote:
>> 
>> It seems like we're going around and around with one point not 
>> being addressed.  When using 'go', how do you know the size to 
>> flush?  And since Scott is talking about performance testing 
>> apps, the cache should not be disabled (unless we expect all 
>> standalone apps to enable the cache, in which case we need to 
>> provide something in the jump table to make that easy and 
>> document this change).
> 
> I also wonder about this. To me it appears much easier to use a 
> IH_TYPE_STANDALONE image, which 1) provides the needed size 
> information and 2) can be used with bootm, so the required 
> additional steps (flush caches, release CPU) can be handled in 
> bootm subcommands.

But that then circles us back to Scott's other point of "go" is broken
then and it is the recommended way to start standalone applications.

Now, if we want to change things and say that no, you can't just run
totally raw binaries reliably with "go" but instead need to throw some
form of header on top of them, how portable, really, is mkimage?
We've just made that a required part of the work-flow for anyone doing
development that's not producing ELF or something else already
boot*'able.  That might be a rather large pool I suspect.

Scott, part of the problem here is that we have multiple cores, yes?
Say core0 is the one that read things in from NOR to DDR, core1 is the
one that will be running things.  How about we make flush_cache depend
on CONFIG_MP || CONFIG_CMD_CACHE_FLUSH ?  It's a likely required often
thing for CONFIG_MP systems and anyone else that needs it can opt-in.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRTGqwAAoJENk4IS6UOR1WaLsP/0exKAgPt0pOskKewNCNP2C5
RlaZ55mG+ueWtYCXDhosNTD8H5AgPmOzA+zblUPOzUpX4+EASoaAoq4LNNnaKGJf
a9lPS+rsnSoefrM4qCzcDx6Iq8AIY6Vaj9I9VaaDtCDgT9wMILNpkHobalujC7hl
PoCW0niIJZl05mRI6YaMP32zrtHxnZAJHRGPIX1/f7PMAg7WwoJXZc14snMaaFGT
Bi2JXFswT07Vjttmk14qnaYt1zApHY2vmTn+kAnncokl9vu7Go5pcwOmrnNCONcY
qeHkYSed+y+q/5fczxFYMncxbeBNC1l3RpkOX5j05Sa9DEylyNxPlQAfFZ7klt2s
Fy+5C4s08q/vNFsL/b/Ic7xl80bfTWIu0BAY3OFKBJl7OnKyIdEtri7LCYEYrkZI
0UvDu6TZVc37WG5CcrqM0DcRr7YCZ6Ak6N3qMYwcWKKarW9T9dhC/pyQ9m591Abr
NTjsRyRdDYhFNs3a/25SNazvqDlI1cF/BwUGUsLdZJ9tdG9mS5mLNU7okP+KtP7K
cfJGb0Ln+AB1TPZRXFuEM4gEJIYhoDbOmJenjEKWDxWbV2cLAqX/Lk3dBTO+RnMS
XHYBS2cSG46gkgXf3rqvhd4md93HoYRD6h2MBzxLyKhyjOicHk5zfeFMYmYrZCEO
/uyGAvA+hkIyJXmVzNbb
=Hn61
-----END PGP SIGNATURE-----