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.
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...
<nitpick>
Also, it was added unconditionally which is a strict no-no as it just
adds code-bloat to everyone, without benefit.
</nitpick>
Only for boards which select CONFIG_CMD_CACHE... not sure how
fine-grained it makes sense to make it.
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
