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