[U-Boot] [RFC] command/cache: Add flush_cache command
Tom Rini
trini at ti.com
Fri Mar 22 18:19:57 CET 2013
-----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 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.
>
> 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-----
More information about the U-Boot
mailing list