[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk <wd@denx.de>]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie