-----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.
- -- Tom