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

[Matthew McClintock]

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

-Matthew


> Cheers,
> Ben.
> 
>> Cheers,
>> g.
>> 
>>> ---
>>> V4: Fixed misspelling
>>> 
>>> V3: Remove unneeded cast, and fixed indentation screw up
>>> 
>>> V2: messed up changes
>>> 
>>> arch/powerpc/kernel/prom.c |   45 ++++++++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 45 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>>> index fd9359a..ff3e240 100644
>>> --- a/arch/powerpc/kernel/prom.c
>>> +++ b/arch/powerpc/kernel/prom.c
>>> @@ -32,6 +32,7 @@
>>> #include <linux/debugfs.h>
>>> #include <linux/irq.h>
>>> #include <linux/lmb.h>
>>> +#include <linux/bootmem.h>
>>> 
>>> #include <asm/prom.h>
>>> #include <asm/rtas.h>
>>> @@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
>>> }
>>> __initcall(export_flat_device_tree);
>>> #endif
>>> +
>>> +#ifdef CONFIG_KEXEC
>>> +static phys_addr_t flat_dt_start;
>>> +static phys_addr_t flat_dt_end;
>>> +
>>> +static struct property flat_dt_start_prop = {
>>> +       .name = "linux,devicetree-start",
>>> +       .length = sizeof(phys_addr_t),
>>> +       .value = &flat_dt_start,
>>> +};
>>> +
>>> +static struct property flat_dt_end_prop = {
>>> +       .name = "linux,devicetree-end",
>>> +       .length = sizeof(phys_addr_t),
>>> +       .value = &flat_dt_end,
>>> +};
>>> +
>>> +static int __init export_flat_device_tree_phys_addr(void)
>>> +{
>>> +       struct property *prop;
>>> +       struct device_node *node;
>>> +
>>> +       node = of_find_node_by_path("/chosen");
>>> +       if (!node)
>>> +               return -ENOENT;
>>> +
>>> +       prop = of_find_property(node, "linux,devicetree-start", NULL);
>>> +       if (prop)
>>> +               prom_remove_property(node, prop);
>>> +
>>> +       prop = of_find_property(node, "linux,devicetree-end", NULL);
>>> +       if (prop)
>>> +               prom_remove_property(node, prop);
>>> +
>>> +       flat_dt_start = virt_to_phys(initial_boot_params);
>>> +       flat_dt_end = virt_to_phys(initial_boot_params)
>>> +                               + initial_boot_params->totalsize;
>>> +       prom_add_property(node, &flat_dt_start_prop);
>>> +       prom_add_property(node, &flat_dt_end_prop);
>>> +
>>> +       return 0;
>>> +}
>>> +__initcall(export_flat_device_tree_phys_addr);
>>> +#endif
>>> --
>>> 1.6.6.1
>>> 
>>> 
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev at lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>> 
>> 
>> 
>> 
> 
> 
>