From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 22 Mar 2013 11:48:49 -0500 Subject: [U-Boot] [RFC] command/cache: Add flush_cache command In-Reply-To: <514C6AB0.7090808@ti.com> (from trini@ti.com on Fri Mar 22 09:29:04 2013) Message-ID: <1363970929.24790.3@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.10508@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