[U-Boot] [RFC] command/cache: Add flush_cache command

[Wolfgang Denk <wd@denx.de>]

Dear Tom,

In message <514C6AB0.7090808@ti.com> you wrote:
> > 
> > I also wonder about this. To me it appears much easier to use a 
> > IH_TYPE_STANDALONE image, which 1) provides the needed size 
> > information and 2) can be used with bootm, so the required 
> > additional steps (flush caches, release CPU) can be handled in 
> > bootm subcommands.
> 
> But that then circles us back to Scott's other point of "go" is broken
> then and it is the recommended way to start standalone applications.

I'm not sosure about this  It once was, yes, when IH_TYPE_STANDALONE
did not exist yet.  Later this changed.

Of course "go" has it's right to exist.  For example, I use it
regularly when I want to crash a system by jumping to a non-existent
or unaligned address ;-)

But today, "bootm" for a IH_TYPE_STANDALONE image ppears to be a
better way to start a standalone app.

> Now, if we want to change things and say that no, you can't just run
> totally raw binaries reliably with "go" but instead need to throw some
> form of header on top of them, how portable, really, is mkimage?

I think it would be wrong here tobe so absolute - this or that, and
nothing inbetween.  The thing is, for well over a decase "go" has been
working fine, and problems like this here hever never been much of an
issue.  And being able just to jump anywhere _is_ a necessary
function, IMO.

How portable is mkimage?  Well, pretty much, it seems - probably more
than your options are to build a bare metal standalone image to run on
the target hardware.  Why exactly are you asking this?

> We've just made that a required part of the work-flow for anyone doing
> development that's not producing ELF or something else already
> boot*'able.  That might be a rather large pool I suspect.

How many of the total number of U-Boot users are actively using
standalone apps?

And how many of these are actually experiencing the problems we're
discussing here?

I'd be willing to bet a few beer that it's only a _tiny_ fraction.

Of course we should provide working solutions for each and every use
case, but here I fear we're designing for a lot of overkill.


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
IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe,  Inclu-
ding  This Product, May One Day Collapse Back into an Infinitesimally
Small Space. Should  Another  Universe  Subsequently  Re-emerge,  the
Existence of This Product in That Universe Cannot Be Guaranteed.