From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 20 Mar 2013 11:43:15 -0500 Subject: [U-Boot] [RFC] command/cache: Add flush_cache command In-Reply-To: <20130320145836.C129020063B@gemini.denx.de> (from wd@denx.de on Wed Mar 20 09:58:36 2013) 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> Message-ID: <1363797795.25034.0@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 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. > 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... > > Also, it was added unconditionally which is a strict no-no as it just > adds code-bloat to everyone, without benefit. > Only for boards which select CONFIG_CMD_CACHE... not sure how fine-grained it makes sense to make it. -Scott