[PATCH] [v3] powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way

[Hollis Blanchard]

On Friday 14 November 2008 11:29:35 Milton Miller wrote:
> > I simply don't see a good place to do this in the kernel. It would have
> > to be before the first lmb_alloc() call, which for safety would put it
> > inside early_init_devtree() -- along with the other lmb_reserve()
> > calls.[1]
> >
> > [1] This is exactly where flat device tree reservations are done, and
> > that's why the patch I submitted works.
> 
> 
> > However, ppc_md.probe() hasn't even been called yet, so there's no way
> > of knowing if we're on an affected system, unless you want to add a
> > special of_scan_flat_dt() call here.
> 
> I think we decided a property is the right way to go, but am not sure 
> we decided if it should be a specific property in the /cpus/cpu@* nodes 
> or a general property that describes a base and length ... in which 
> case it is either a property in /memory (cpus nodes are not part of the 
> system address space, with an independent size 0 address space).   It 
> was also noted if we go the property route. that kexec tools would need 
> to know about it since it allocates destination pages based on reading 
> /memory reg ranges, although it also has a hardcoded 768M limit which 
> might hide this.
> 
> > I'm open to suggestions, but I don't see a better way than what I
> > already sent. I think the important part is to call lmb_add() for all
> > memory, but lmb_reserve() the last 256 bytes before lmb_alloc() 
> > happens.
> >
> > It sounds like kexec must have some knowledge of the platform and 
> > device
> > tree already, so is this really a big deal? At any rate, this
> > conversation is somewhat academic, since there is no kexec on 44x... so
> > maybe this can be re-addressed when that becomes a real issue.
> 
> As discussed, kexec userspace has some ideas of platforms, but its very 
> general and should not have lists of which cpus have an errata but 
> should base all its decisions off the device tree.
> 
> Alternatives to adding a property include just trimming the memory node 
> (and fixing the kernel to handle memory size not being page aligned),
> and adding an additional node that says this memory is in use.  We 
> should handle the memory size not some big power of 2 anyways, and if 
> we just create a new node it should not overlap the memory node 
> anyways.  Although we did note that due to current kexec implementation 
> we can name a node starting with /rtas and use linux,rtas-base and 
> rtas-size to reserve any 32 bit chunk of memory even to kexec, although 
> that is considered beyond acceptable for this errata fix (some else 
> might want to join me in using that to reserve memory for log buffers 
> across boot).
> 
> It has been described to me that the bug affects any access to the 256 
> bytes, so it would be accurate to describe the memory as not existing 
> or as this cpu has an errata tnd the dram is really here.  I just say 
> it needs to be described in the device tree.  Trimming the memory node 
> has the advantage that kexec userspace will not need a patch, adding 
> the cpu has errata property would only require a patch for platofrms 
> with <768MB (or manual override of the usable memory size via the 
> command line).

I don't think patching kexec userspace is too onerous, especially if it's done 
now long before kexec exists on 440. That would also allow you to drop your 
rtas hack...

Basically my revised proposal is to add explicit memory reservation properties 
to the device tree. Currently, "/memreserve" properties in .dts files are not 
present in the device tree itself, only in the FDT header. I think these 
reservations should be duplicated in the tree itself, so that they become 
visible to post-boot tools like kexec.

In summary, all memory reservations will then exist both in the device tree 
and in the FDT header. Comments?

Impact to uboot: revert memory node truncation; create reservation 
and /memreserve property.

Impact to cuboot wrapper: revert memory node truncation; create reservation 
and /memreserve property.

Impact to kernel: none. /memreserve will be ignored, since memory reservations 
are already handled properly.

Impact to kexec-tools: Must take /memreserve into account when placing data 
at "the end of memory".

If this is all too much, then I'm close to giving up and burning a 64KB page, 
which requires only ALIGN_DOWN() in the kernel.

-- 
Hollis Blanchard
IBM Linux Technology Center