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. 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
