From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 20 Mar 2013 18:38:13 +0100 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: <20130320183813.2cb9153a@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Scott, On Wed, 20 Mar 2013 11:43:15 -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. Hence my "and the like". > > 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... But as I stated, you can, and should, include at least one board that will need this command. So far, apparently, no board needs it. > > > > 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. As a command, and useful at most to a few boards, it should have its own option so that only the board(s) that will need it will have the command list entry and associated code. > -Scott Amicalement, -- Albert.