From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Vorontsov Date: Tue, 17 Mar 2009 20:43:19 +0300 Subject: [U-Boot] [PATCH] 8313erdb: Set guarded bit on BAT that covers the end of the address space. In-Reply-To: <20090317170931.GA14779@ld0162-tx32.am.freescale.net> References: <20090317170931.GA14779@ld0162-tx32.am.freescale.net> Message-ID: <20090317174319.GA11078@oksana.dev.rtsoft.ru> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Mar 17, 2009 at 12:09:31PM -0500, Scott Wood wrote: > This board currently sets DBAT6 to cover all of the final 256MiB of > address space; however, not all of this space is covered by a device. In > particular, flash sits at 0xfe000000-0xfe7fffff, and nothing is mapped > at the far end of the address space. > > In zlib, there is a loop that references p[-1] if p is non-NULL. Under > some circumstances, this leads to the CPU speculatively loading from > 0xfffffff8 if p is NULL. This leads to a machine check. > > Signed-off-by: Scott Wood > --- > Note that there are likely other board with the same issue. Wow, I was actually chasing this (I think) bug for some time. The effect of this bug was quite weird: some kernels didn't boot, and the only difference in the kernel image was.. the build date (i.e. data in linux_banner and init_uts_ns symbols). I suspected the decompression code (what else could it be?), but I didn't manage to track it down to a failing instruction, as the failing kernel was booting *OK* with BDI-2000 attached. Heh. I wonder how you tracked it down to zlib code and a particular loop, please share the technique. ;-) Thanks! -- Anton Vorontsov email: cbouatmailru at gmail.com irc://irc.freenode.net/bd2