On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock <m...@freescale.com> wrote: > On Jul 18, 2010, at 6:41 PM, Benjamin Herrenschmidt wrote: >> On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote: >>> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock <m...@freescale.com> >>> wrote: >>>> 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 <m...@freescale.com> >>> >>> Hi Matthew. >>> >>> I don't understand. Why does userspace need to know about the old >>> memreserve sections? Doesn't kexec tear down all of the old >>> allocations anyway? How are they relevant for constructing the dtb >>> for the kexec kernel? I'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 memreserve > 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 anything > they wanted for their own particular needs and would quite possibly need > those regions preserved across reboots. > > Recently, I've discovered the boot page address is given in the device tree > 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 reconstruct > the appropriate memreserve regions for kexec'ing from the information 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 be a > good time to address this issue if anyone believes it is a worthwhile pursuit > to have a mechanism to have memreserve regions persistent across kexec'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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
