In message 200804211658.44036.vapier@gentoo.org you wrote:
I tried understanding what you are trying to do, and even though I feel it's not exactly an important or frequently used feature for most of the users I tried to come up with a compromize that allows you to do what you want to do without hurting others and without polluting the command name space.
i consider the cache one aspect of it. the users shouldnt have to know "oh i gotta turn off cache", they just have to know "i'm loading up my code and
I agree that cache is just one aspect; I disagree that users shouldn't know what they are doing. On contrary, I want to give them all necessary control to do what they may want to do. It is a matter of higher software levels to provide more convenient abstractions.
it's going to take over the system". that is why a "-noret" flags makes
Who says that *my* application which doesn;t return does the same as your application? Maybe I *want* to have the caches on for perfor- mance?
I accept that the default settings may be not optimal for your use case, so please accept that your settings may not be always optimal, either. As a solution I imagine options to the "go" command. If you consider this too complicated for your users, please feel free to provide an alias in an envrionment variable which your users can "run".
sense instead of trying to break down specific aspects. also adding a myriad of cache options to one function achieves the same thing as doing: dcache off; icache off; go <address>
Ah! You see - there is no need at all for any changes - you can put *that* sequence in a variable and run it.
So what exactly was the reason we need a new command?
it's really quite simple. the need is to jump to an address to execute a blob and never return to u-boot. what features are available to standalone u-boot
"go" does that. If your application does not attempt to return, that's fine.
applications (while useful) dont really matter. such applications rely on u-boot remaining resident which is the opposite of what i'm talking about.
But then it doesn't hurt, does it? Your application can do anything it wants as long as it does not attempt to return to U-Boot.
I see zero justification for a new command (and very little for changes to the implementation of "go", but I am still willing to allow for such extensions if you think it's necessary or more convenient).
I thik this is my last word on this.
Best regards,
Wolfgang Denk