From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 20 Mar 2013 16:31:01 -0500 Subject: [U-Boot] [RFC] command/cache: Add flush_cache command In-Reply-To: <20130320195919.GR25919@bill-the-cat> (from trini@ti.com on Wed Mar 20 14:59:19 2013) Message-ID: <1363815061.25034.18@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/20/2013 02:59:19 PM, Tom Rini wrote: > On Wed, Mar 20, 2013 at 02:36:05PM -0500, Scott Wood wrote: > > On 03/20/2013 02:15:19 PM, Tom Rini wrote: > > >On Wed, Mar 20, 2013 at 11:43:15AM -0500, Scott Wood wrote: > > >> On 03/20/2013 09:58:36 AM, Wolfgang Denk wrote: > > >> >Dear Albert, > > >> > > > >> >In message <20130320145927.2031b913@lilith> you wrote: > > >> >> > > >> >> I do understand what it does, but I still don't get why it > > >should be > > >> >> done, since precisely payload control transfer happens through > > >> >bootm and > > >> >> the like which already properly flush cache. > > >> > > >> It doesn't always happen through bootm. Standalone apps use the > > >> "go" command. > > > > > >So, to try and be a bit more verbose about this, for U-Boot > > >applications > > >which use 'go', we still need to ensure cache coherence, which is > why > > >bootm does a cache flush, we need some way to flush in this case. > > > > It's also an issue with using the "cpu release" command. > > Hadn't seen that command before, where is it? common/cmd_mp.c > > >And in this case you aren't better served by say bootelf ? > > > > That wouldn't handle the "cpu release" case. In any case, "go" > > exists and is currently the recommended way to launch a standalone > > application in doc/README.standalone. > > > > >> It's a user command! How can it be dead code? I don't know of a > > >> way to include a human user in a patchset... > > > > > >Can you hightlight what exactly causes the world today to go off > and > > >fail? Is the hello_world example app sufficient in this case or > do we > > >need something much larger? > > > > A user inside Freescale is running standalone performance test apps, > > using both "go" and "cpu release" (since the test needs to run > > on all CPUs). They are seeing cache problems running on a T4240 if > > they don't have this flush. This flush is architecturally required > > between modifying/loading code and running it. > > OK, so this does sound like a real need / use for it, and if we added > the granularity of CONFIG_CMD_CACHE_FLUSH or similar, it would be > reasonable to turn it on to a large number of boards for a small space > savings (so lets not). My next concern is that this needs build > testing > (and some inspection) on say ARM where we have a weak flush_cache > already. But perhaps the right answer is to say it doesn't make sense > to add CONFIG_CMD_CACHE on an architecture which doesn't already > provide > flush_cache, so drop the weak one from this patch. flush_cache() is already called from generic code, so we should be ok just dropping the weak function. -Scott