From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Mon, 21 Apr 2008 11:45:27 +0200 Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440 In-Reply-To: <20080421091255.1E5A224764@gemini.denx.de> References: <20080421091255.1E5A224764@gemini.denx.de> Message-ID: <200804211145.28004.sr@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Monday 21 April 2008, Wolfgang Denk wrote: > > This has nothing to do with 440. It's more a general question. But OK, > > from my > > Well, it affects only processors which need MMU support. Most doen't. I'm not so sure here anymore with all the newer PPC's and other platforms. But I have to admit that I'm no expert for those other platforms. > > understanding, it makes most sense that the i/dcache U-Boot commands > > touch the cache attributes of all SDRAM related TLB's. > > In general, the chackes should be enabled whenever and whereever > possible. > > I think it should be pretty safe to enable the I cache for all SDRAM, > SRAM and flash areas; or, put differently, for all memory areas > except maybe any mapped PCI memory windows. > > If possible, also D cahce should be enabled, but I cannot judge if > this works or not with the given driver code. > > Also, it depends on where the initial stack and data is located (you > probably cannot disable caches if you put initial data in cache). Another problemtic issue could be the POST area for caches etc. I know that self modifying code is used here in some places. This could be more problematic with caches enabled. > > And what does this mean that you "insist that this must be fixed for the > > next release"? I'm sorry, but I personally can't promise to "fix" this > > issue until the next merge window opens. > > Next release means the one that comes after the next merge window. I did understand this part of the sentence. I'm just not sure what should happen with the current code if it doesn't get changed. Again, I personally can't promise to "fix" this issue until the next merge window opens. Best regards, Stefan ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================