[PATCH V4] powerpc/prom: Export device tree physical address via proc

[Matthew McClintock]

On Thu, 2010-07-15 at 10:57 -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock <msm at freescale.com> wrote:
> > On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
> >> > Thanks for taking a look. My first thought was to just blow away all
> >> the
> >> > memreserve regions and start over. But, there are reserve regions
> >> for
> >> > other things that I might not want to blow away. For example, on
> >> mpc85xx
> >> > SMP systems we have an additional reserve region for our boot page.
> >>
> >> What is your starting point?  Where does the device tree (and
> >> memreserve list) come from
> >> that you're passing to kexec?  My first impression is that if you have
> >> to scrub the memreserve list, then the source being used to
> >> obtain the memreserves is either faulty or unsuitable to the task.
> >
> > I'm pulling the device tree passed in via u-boot and passing it to
> > kexec.
> 
> How?  (what mechanism?)  I hope you're not using the debugfs
> flat-device-tree file.

That is one way to get a good working copy. What is wrong with this
mechanism?

Should we duplicate everything u-boot does in kexec to build up a flat
device tree? Or is there another way to get a good tree? Ideally, we
don't make the end user manually edit a device tree.

> 
> > It is the most complete device tree and requires the least amount
> > of fixup.
> >
> > I have to scrub two items, the ramdisk/initrd and the device tree
> > because upon kexec'ing the kernel we have the ability to pass in new
> > ramdisk/initrd and device tree. They can also live at different physical
> > addresses for the second reboot.
> 
> This sounds like the model is backwards.  Rather than scrubbing items,
> the memreserve list should be built up from a known good source.

You can build one up yourself and it will still work out fine. Or you
can pull one from debugfs to get yourself started. Or you can pull it
every time. 

> 
> > The initrd addresses are already exposed, so we can update/remove/reuse
> > that entry, we just need a way for kexec to determine the current device
> > tree address so it can replace the correct memreserve region for the
> > kexec'ing kernels' device tree.
> >
> > The whole problem comes from repeatedly kexec'ing, we need to make sure
> > we don't keep losing blobs of memory to reserve regions (so we can't
> > just blindly add). We also need to make sure we don't lose other
> > memreserve regions that might be important for other things (so we can't
> > just blow them all away).
> 
> Right, so you need to have a known-good list of reserve sections.
> Trying to go the other way sounds very fragile.
> 

Yes. Where would we get a list of memreserve sections? Should we export
the reserve sections instead of the device tree location? We just need a
way to preserve what was there at boot to pass to the new kernel.

-M