On 03/21/2013 02:25:10 PM, Wolfgang Denk wrote:
Dear Scott,
In message 1363890157.31522.14@snotra you wrote:
As above it's from flash (I assume NOR) to RAM. The "why" is to be
=20
able to run the code from RAM. :-P
- Why don't you run it form flash?
Presumably because it's slow. As indicated elsewhere in the thread, these are performance tests.
- Why do you insist on using the "go" command (instead of "bootm" with a IH_TYPE_STANDALONE image?
Presumably because of the need to release other cores first.
- eventually we should discourage the use of "go"; it may be conveniend when you know what you are doing, but if it's casuing such problems we might be better off recommending to use proper IH_TYPE_STANDALONE legacy images in combination with the bootm command instead.
That or bootelf, sure. I think there still should be some way to
do it
manually, though. bootm/bootelf probably wouldn't work for this use case because it involves releasing other cores after the image is copied/flushed, but before u-boot gives up control on the boot core.
The "releasing other cores" would then be a sub-command in the bootm sequence?
Perhaps it could be, or the application could be altered to release secondary cores through the spin table. I don't think that excuses a situation where some ways of putting a blob of bytes into RAM flush the cache (to the extent the architecture requires it for the blob of bytes to be executable) and others don't, and there's no way to do it manually. Would you remove the "go" command entirely? I think that would be a mistake.
-Scott