Grant Likely wrote:
On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <m...@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 <m...@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.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
