Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

[Mitch Bradley <wmb@firmworks.com>]

Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm@freescale.com> wrote:
>   
>> On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
>>     
>>> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm@freescale.com> wrote:
>>>       
>>>> Yes. Where would we get a list of memreserve sections?
>>>>         
>>> I would say the list of reserves that are not under the control of
>>> Linux should be explicitly described in the device tree proper.  For
>>> instance, if you have a region that firmware depends on, then have a
>>> node for describing the firmware and a property stating the memory
>>> regions that it depends on.  The memreserve regions can be generated
>>> from that.
>>>       
>> Ok, so we could traverse the tree node-by-bode for a
>> persistent-memreserve property and add them to the /memreserve/ list in
>> the kexec user space tools?
>>     
>
> I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch,
> David Gibson, and other device tree experts on whether or not that
> exact property naming is a good one.
>   

In the /memory node, the "reg" property specifies all of memory and the 
"available" property specifies those portions that the OS is permitted 
to use.  Subtracting "available" from "reg" gives you the regions that 
are used for other purposes, such as frame buffers or firmware needs.

Often the OS can just look at "available", as it typically wants to know 
what it can use, not what it can't.

The full size as given by "reg" is useful for system configuration 
reporting purposes - the user thinks he bought 2G of memory, so it's 
good to report that 2G is indeed installed in the system.  (As an aside, 
when I first invented Open Boot, 16M was a typical memory size.  I'm 
rather gratified that the overall device tree design has held up 
reasonably well over the scale factors that have happened since then.)

It would be possible to mark the "used" regions with a finer-grained 
distinction than "they are unavailable to the OS", but that quickly gets 
into the diminishing returns realm - a lot of trouble for fairly small 
incremental value. The PC BIOS "E820" memory description scheme has a 
few extra categories of memory.  The one category that seems like it 
might (just barely) be worth the effort is "temporarily used by firmware 
but reclaimable after a certain point" - but then you have to define 
rather carefully the reclamation time and conditions.

> Write up a proposed binding (you can use devicetree.org).  Post it for
> review (make sure you cc: both devicetree-discuss and linuxppc-dev, as
> well as cc'ing the people listed above.)
>
>   
>>>> Should we export
>>>> the reserve sections instead of the device tree location?
>>>>         
>>> It shouldn't really be something that the kernel is explicitly
>>> exporting because it is a characteristic of the board design.  It is
>>> something that belongs in the tree-proper.  ie. when you extract the
>>> tree you have data telling what the region is, and why it is reserved.
>>>       
>> Agreed.
>>
>>     
>>>> We just need a
>>>> way to preserve what was there at boot to pass to the new kernel.
>>>>         
>>> Yet there is no differentiation between the board-dictated memory
>>> reserves and the things that U-Boot/Linux made an arbitrary decision
>>> on.  The solution should focus not on "can I throw this one away?" but
>>> rather "Is this one I should keep?"  :-)  A subtle difference, I know,
>>> but it changes the way you approach the solution.
>>>       
>> Fair enough. I think the above solution will work nicely, and I can
>> start implementing something if you agree - if I interpreted your idea
>> correctly. Although it should not require any changes to the kernel
>> proper.
>>     
>
> Correct.
>
> g.
>
>
>