From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 20 Mar 2013 18:48:38 -0500 Subject: [U-Boot] [RFC] command/cache: Add flush_cache command In-Reply-To: <4BABA974-A22D-4FD7-9678-035DD5AE5107@prograde.net> (from mboards@prograde.net on Wed Mar 20 18:33:41 2013) References: <20130320191519.GO25919@bill-the-cat> <1363808165.25034.14@snotra> <20130320231157.4f312493@lilith> <1363818951.25034.28@snotra> <4BABA974-A22D-4FD7-9678-035DD5AE5107@prograde.net> Message-ID: <1363823318.25034.33@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 06:33:41 PM, Michael Cashwell wrote: > On Mar 20, 2013, at 6:35 PM, Scott Wood > wrote: > > > Really, instead of adding one command, you want to modify *two* > commands to do the same thing separately, which involves changing the > syntax of both commands to accept memory range information? > > What is the purpose of limiting the memory range to be flushed? Is > there a reason one might want to NOT flush certain data sitting in a > dirty cache line out to memory before doing a go or boot command? Because it would take a while to flush all of RAM? > If you drive the operation as a "walk the cache" process rather than > a "iterate over all SDRAM physical address space to cherry pick > within a range" it wouldn't seem that slow. I mean, there's only so > much cache memory. There's no way to "walk the cache" on many chips, including ours. There are generally ways to flush the entire thing, but they are (more) hardware-specific than using the architected method of flushing a memory range, and sometimes these methods have errata associated with them. -Scott