On Wed, 2008-11-12 at 22:52 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2008-11-12 at 06:31 -0500, Josh Boyer wrote: > > On Wed, 12 Nov 2008 15:37:43 +1100 > > Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> 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 <hollisb@xxxxxxxxxx> > > > > > > While I prefer this approach, won't it break kexec ? > > > > Break it how? Particularly given that kexec doesn't work on 4xx (yet). > > Allright, wrong wording. It will make kexec more painful since it will > have to also create that reserved area in the target DT. > > > 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? > > Bah, do you know many RAM chip that will chop off the last 4K ? Forget pages. The errata is about the last 256 bytes of physical memory. > I still find it a bit tricky to have memory nodes not aligned on nice > fat big boundaries tho. I don't know what you're referring to. The patch I sent doesn't touch memory nodes, so they are indeed still aligned on nice fat big boundaries. I don't think this is overengineering at all. We can't touch the last 256 bytes, so we mark it reserved, and then we won't. Altering memory nodes is far more complicated and error-prone. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
