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.
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.
<nitpick> Also, it was added unconditionally which is a strict no-no as it just adds code-bloat to everyone, without benefit. </nitpick>
Maybe this is some code that might come in handy for some future target not in U-Boot yes which will have the first core start a payload on another core? Then the previous argument applies (the fix should not be a shell command, it should be in source code), plus, the patch is dead code until and unless said target is also added in a single series.
Agreed! Thanks.
Best regards,
Wolfgang Denk