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

[Tom Rini <trini@ti.com>]

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

On 03/22/2013 12:48 PM, Scott Wood wrote:
> On 03/22/2013 09:29:04 AM, Tom Rini wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 03/22/2013 10:03 AM, Wolfgang Denk wrote:
>>> Dear Tom,
>>> 
>>> In message <514C4BE8.10508@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.
> 
> Multiple CPUs may make it more likely to see problems on some 
> hardware, but architecturally on PPC the flush is required even 
> with a single CPU.  Icache fetches won't snoop the dcache.
> 
> Can we have it depend on a new config symbol, so it's not bloating 
> anyone's U-Boot who doesn't want it, and deal with improvements to 
> recommended standalone app workflow as a separate issue?  We're not
> talking about a huge amount of code here, just exposing 
> functionality that U-Boot already has internally.

Works for me.

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

iQIcBAEBAgAGBQJRTJK8AAoJENk4IS6UOR1W27sP/0pS2QGy0qzfgKrRyuIDbgRG
harO37ddiKNy5NTKFP8kXEFz1mIFgYk8Lu6SE30hu5kDje4t4bWK9S2F1NPcU8tr
r5zM+ekR8y3q29P4Upk98YPMEkgV6L0FmnyQOkcQi3Kdg6Lx+S5GHikUQ6uvPJlh
EBir2XQEZWxVWrL5KTdJV3TZ34NfLPh/gkXSpQTlvfFgGhsbskypt4DOgxz5Vl9d
khOGMk9nX8o3iMaO/gf9F1d5wIoCAt4rzrBaPc/lu/KCMfC6JVmsJP21BCEOVols
NgykmYxm+E8M5/vItCBzWrbGgkmeUfHbnhxGZXYHFPgPkPlz4s8CJZgKblwk4RkN
BVEgfAnJblgPut5vV4Mz+x1D9Z0EQ12ZC3yTJlO2BssfbBK+oVr3r6e2S4HLp08o
VV0wEF5E6fdc2M0gUUJFIMsX/vxjz7fB2y7dYKZmYk08IZvmL5Ddr31E0t/o6IvG
Kp4lymSEEe20IdNuUxp0km4evild4NrcefCNsB/41F5poIdoJ9XudIK9aSFVHAah
IB0nNiszLSgO4fUz3i7XUo8cW/jUzlS2vZe4RBXo8BqYR9GLo9wAhICFibIFVP4i
JK7WA01Vjaqax6zn66L2ngdd/moA/jKalIMchxJehy2v4/Manvh1tno4OQJQ5BKJ
cfCkfeurwOY6BgCef7mz
=OaP1
-----END PGP SIGNATURE-----