[PATCH V4] powerpc/prom: Export device tree physical address via proc
msm at freescale.com
Mon Jul 19 14:24:53 EST 2010
On Jul 17, 2010, at 11:41 AM, Segher Boessenkool 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.
> Let's take a step back: what exactly _are_ "memreserve sections", what
> are they used for, who (kernel, firmware, bootloader, etc.) holds what
> responsibility wrt them?
On the platform I'm working on (mpc85xx) they can be the following:
1) Boot page (aka cpu-release-addr) - always present on MP
2) Flat Device Tree - always present
3) Initrd - optional
When kexec'ing a kernel, we will provide new memory regions for the flat device tree and the initrd (if present). However, all others will not be replaced by kexec and should either be tossed or preserved. The question is how to decide what to do... save them all by default? Save none of them? If we save them all at a minimum we need to remove/replace the device tree and initrd regions as well. So we need a way to identify which regions correspond to these.
Grant and I talked and though a property that lives in the device tree describing a persistant-memreseve might work. And Mitch talked about an available memory property to go along with the current one which could be used to determine which ranges were invalid and need a memreserve for...
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
More information about the Linuxppc-dev