From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hawkins Date: Mon, 03 Mar 2008 09:55:21 -0800 Subject: [U-Boot-Users] MPC8349EMDS.h Why do the BAT entries use Memory coherency? In-Reply-To: <47C9F4E7.3000709@ovro.caltech.edu> References: <20080229235544.4546A2476B@gemini.denx.de> <47C9CFEC.4050704@ovro.caltech.edu> <47C9F4E7.3000709@ovro.caltech.edu> Message-ID: <47CC3B89.7040806@ovro.caltech.edu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi all, Once I'd written the email on this subject to the U-Boot list, I figured it was starting to sound like a Freescale support request, so I submitted one too. Here's their response: "Actually, snooping occurs inside MPC8349 device. Besides e300 core, other possible masters are: PCI1, PCI2, DMA, TSEC1, TSEC2, USB, Ecnryption engine." So, it does sound like there are devices internal to the MPC8349EA that are monitoring the e300 core gbl# signal, and hence the M-bit would need to be set in the BAT entries. > FYI: > - The M-bit is set for the BAT entries for: > DDR, PCI memory, SDRAM, stack-in-dcache, and Flash) > - The M-bit is not set for: > PCI I/O, IMMRs, and BCSRs > these are cache inhibited and guarded. And this list pretty much makes sense. The exception would be the stack-in-dcache, since there is no external memory associated with the stack-in-dcache trick. Trying to understand the stack-in-dcache trick was what what started all this ... but, I guess in that case, having the M-Bit set in the BAT entry doesn't really matter, since nothing is (or should be) snooping that address anyway. Sorry for the 'noise' :) Cheers, Dave