From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 20 Mar 2013 15:15:19 -0400 Subject: [U-Boot] [RFC] command/cache: Add flush_cache command In-Reply-To: <1363797795.25034.0@snotra> References: <1363724992-9803-1-git-send-email-yorksun@freescale.com> <20130319230141.72357073@lilith> <5148E1A5.4030502@freescale.com> <1363735959.16671.38@snotra> <20130320145927.2031b913@lilith> <20130320145836.C129020063B@gemini.denx.de> <1363797795.25034.0@snotra> Message-ID: <20130320191519.GO25919@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. And in this case you aren't better served by say bootelf ? Assuming that no, it's not, we have a real example where we need this. So please make sure to update the README with the new command CONFIG_CMD_CACHE sets. > > >Full agrement. > > > >> Is there an ARM multi-core target in U-Boot where U-Boot runs on > >> one core but its payload shall be started on another, "un-booted", > >> core, and which experiences issues due to the first core not > >flushing > >> cache? If no existing target needs this, then this patch is > >useless. If > >> there exists such a target and issue, then the right fix is not > >a shell > >> command, it is a programmatic flush before the other core is > >enabled, > >> so that it always sees correct RAM. > > > >Agreed again. As is, the patch was only adding dead code, as there > >are no users of the feature. > > 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? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: