From mboxrd@z Thu Jan 1 00:00:00 1970 From: Larry Johnson Date: Thu, 27 Mar 2008 13:36:36 -0500 Subject: [U-Boot-Users] [PATCH] ppc4xx: Don't use last 256 bytes of SDRAM, workaround for 440EPx CHIP 11 errata In-Reply-To: <200803270721.20326.sr@denx.de> References: <20080320100330.B00C624A87@gemini.denx.de> <200803202212.26067.sr@denx.de> <47EB0B8A.3030206@acm.org> <200803270721.20326.sr@denx.de> Message-ID: <47EBE934.5010706@acm.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Stefan Roese wrote: > On Thursday 27 March 2008, Larry Johnson wrote: >> Yes, we normally use ECC modules in our testing. I've been looking at a >> patch for "initdram()" Denali SPD, but I've been waiting to see how your >> "CFG_MEM_TOP_HIDE" patch would turn out. >> >> As things stand now, can I assume that boards using the Denali SPD will >> also define "CFG_MEM_TOP_HIDE", and therefore initdram() should continue >> to return the full size of the memory? > > Correct. > >> The only place that the last 256 bytes of memory are touched is when >> "dflush()" is called to zero the SDRAM. > > To be more specific, in the dcbz_area() call. > >> This does not cause a Machine >> Check interrupt. I am guessing that all the writes from "dflush()" are >> aligned, and therefore there are no burst that access beyond the end of >> of the SDRAM memory space. If so, then my inclination is not to change >> this part of the code. Does this make sense? > > I recommend to change it this way: > > /* Zero the memory */ > debug("Zeroing SDRAM..."); > - dcbz_area(CFG_SDRAM_BASE, dram_size); > + dcbz_area(CFG_SDRAM_BASE, dram_size - CFG_MEM_TOP_HIDE); > dflush(); > > And perhaps put something like: > > #ifndef CFG_MEM_TOP_HIDE > #error "Please define CFG_MEM_TOP_HIDE (see README) in your board config > file!" > #endif > > at the top of the file. What do you think? > > Best regards, > Stefan That sound fine, I'll try to get a patch out soon. Best regards, Larry