On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock [off-list ref] wr=
ote:

On Jul 18, 2010, at 6:41 PM, Benjamin Herrenschmidt wrote:

quoted

On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:

quoted

On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock [off-list ref]=

 wrote:

quoted

quoted

quoted

To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel

Signed-off-by: Matthew McClintock <redacted>

Hi Matthew.

I don't understand. =A0Why does userspace need to know about the old
memreserve sections? =A0Doesn't kexec tear down all of the old
allocations anyway? =A0How are they relevant for constructing the dtb
for the kexec kernel? =A0I'll need a lot more details before I consider
merging this.

Also, please cc: me and Ben Herrenschmidt on powerpc related device
tree changes.

I admit to be the victim of a similar misunderstanding...

Care to explain in more details ? (with examples)

Upon first examining the details of getting kexec working on our platform=

 I noticed our device tree passed from u-boot contained an additional memre=
serve section for the boot page. Subsequently, I've been trying to preserve=
 the ones passed in for the kexec'ed kernel thinking anyone could add anyth=
ing they wanted for their own particular needs and would quite possibly nee=
d those regions preserved across reboots.

Recently, I've discovered the boot page address is given in the device tr=

ee as a property. So, for our platform (mpc85xx) in particular, I'm back to=
 not needing the read the old memreserve sections... I can completely recon=
struct the appropriate memreserve regions for kexec'ing from the informatio=
n passed in the device tree.

That isn't to say there might not be more memreserve regions that are not=

 there for some valid reason. I'm not sure if we need to attempt to address=
 another scenario where there are other memreserve regions. So this would b=
e a good time to address this issue if anyone believes it is a worthwhile p=
ursuit to have a mechanism to have memreserve regions persistent across kex=
ec'ing - or any other reboot.

No, we haven't needed anything to date, so no sense trying to design a
solution for a theoretical need.  Leave it be for now.

g.