From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e6.ny.us.ibm.com", Issuer "Equifax" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 2844CDDDEE for ; Wed, 12 Nov 2008 22:31:59 +1100 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id mACBYYDt019832 for ; Wed, 12 Nov 2008 06:34:34 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mACBVZWb123468 for ; Wed, 12 Nov 2008 06:31:35 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mACBVZtB006004 for ; Wed, 12 Nov 2008 06:31:35 -0500 Date: Wed, 12 Nov 2008 06:31:29 -0500 From: Josh Boyer To: Benjamin Herrenschmidt Subject: Re: [PATCH] [v3] powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way Message-ID: <20081112063129.4d3ae18b@zod.rchland.ibm.com> In-Reply-To: <1226464663.13515.1.camel@pasglop> References: <700c59731cf97778d3a4.1226448406@localhost.localdomain> <1226464663.13515.1.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: linuxppc-dev@ozlabs.org, yanok@emcraft.com, kvm-ppc@vger.kernel.org, Hollis Blanchard , dwg@au1.ibm.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 12 Nov 2008 15:37:43 +1100 Benjamin Herrenschmidt wrote: > On Tue, 2008-11-11 at 18:06 -0600, Hollis Blanchard wrote: > > The current CHIP11 errata truncates the device tree memory node, and subtracts > > (hardcoded) 4096 bytes. This breaks kernels with larger PAGE_SIZE, since the > > bootmem allocator assumes that total memory is a multiple of PAGE_SIZE. > > > > Instead, use a device tree memory reservation to reserve only the 256 bytes > > actually affected by the errata, leaving the total memory size unaltered. > > > > Signed-off-by: Hollis Blanchard > > While I prefer this approach, won't it break kexec ? Break it how? Particularly given that kexec doesn't work on 4xx (yet). > I don't understand why we don't just have a bit of code in the kernel > itself that reserve that page on 44x at boot time and be done with it. > > It's like we are trying to be too smart and over-engineer the solution. I don't think that's it. I think it's more that we're opportunistic and the wrapper is the easiest place to do this, given that U-Boot itself will be doing the reserve for platforms that don't require the wrapper. So we could do the fixup in-kernel, but how do you do that deterministically given that U-Boot might have already done it? josh