On Wed, Mar 20, 2013 at 11:43:15AM -0500, Scott Wood wrote:
On 03/20/2013 09:58:36 AM, Wolfgang Denk wrote:
Dear Albert,
In message 20130320145927.2031b913@lilith you wrote:
I do understand what it does, but I still don't get why it should be done, since precisely payload control transfer happens through
bootm and
the like which already properly flush cache.
It doesn't always happen through bootm. Standalone apps use the "go" command.
So, to try and be a bit more verbose about this, for U-Boot applications which use 'go', we still need to ensure cache coherence, which is why bootm does a cache flush, we need some way to flush in this case.
And in this case you aren't better served by say bootelf ?
Assuming that no, it's not, we have a real example where we need this. So please make sure to update the README with the new command CONFIG_CMD_CACHE sets.
Full agrement.
Is there an ARM multi-core target in U-Boot where U-Boot runs on one core but its payload shall be started on another, "un-booted", core, and which experiences issues due to the first core not
flushing
cache? If no existing target needs this, then this patch is
useless. If
there exists such a target and issue, then the right fix is not
a shell
command, it is a programmatic flush before the other core is
enabled,
so that it always sees correct RAM.
Agreed again. As is, the patch was only adding dead code, as there are no users of the feature.
It's a user command! How can it be dead code? I don't know of a way to include a human user in a patchset...
Can you hightlight what exactly causes the world today to go off and fail? Is the hello_world example app sufficient in this case or do we need something much larger?