On 03/22/2013 09:29:04 AM, Tom Rini wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/22/2013 10:03 AM, Wolfgang Denk wrote:
> Dear Tom,
>
> In message <514c4be8.10...@ti.com> you wrote:
>>
>> It seems like we're going around and around with one point not
>> being addressed. When using 'go', how do you know the size to
>> flush? And since Scott is talking about performance testing
>> apps, the cache should not be disabled (unless we expect all
>> standalone apps to enable the cache, in which case we need to
>> provide something in the jump table to make that easy and
>> document this change).
>
> 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.
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?
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.
Scott, part of the problem here is that we have multiple cores, yes?
Say core0 is the one that read things in from NOR to DDR, core1 is the
one that will be running things. How about we make flush_cache depend
on CONFIG_MP || CONFIG_CMD_CACHE_FLUSH ? It's a likely required often
thing for CONFIG_MP systems and anyone else that needs it can opt-in.
Multiple CPUs may make it more likely to see problems on some hardware,
but architecturally on PPC the flush is required even with a single
CPU. Icache fetches won't snoop the dcache.
Can we have it depend on a new config symbol, so it's not bloating
anyone's U-Boot who doesn't want it, and deal with improvements to
recommended standalone app workflow as a separate issue? We're not
talking about a huge amount of code here, just exposing functionality
that U-Boot already has internally.
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
