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

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

[Matthew McClintock]

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@freescale.com>
---
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

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

[Tabi Timur-B04825]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Matthew McClintock wrote:

> +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,
> +};

I think Segher was suggesting that you use "linux,device-tree-xxx".

> +
> +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);

Does this work?

prop = of_find_property(node, flat_dt_start_prop.name, 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;

This is better, I think:

	flat_dt_end = flat_dt_start + initial_boot_params->totalsize;

-- 
Timur Tabi
Linux kernel developer

[-- Attachment #2: Type: text/html, Size: 2835 bytes --]

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

[Segher Boessenkool]

> V4: Fixed misspelling

Any particular reason you fixed only one of the two
mispelings I pointed out?  (device tree is two words,
not one).

> +	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);

You could use one property instead of two; use addr+len
like every other property does.

You also should use a better name for the property; is this
the previous kernel's device tree?  Just "device-tree" makes
no sense, it is not pointing to "the" device tree for sure!


Segher

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

[Matthew McClintock]

On Wed, 2010-07-14 at 17:35 +0200, Segher Boessenkool wrote:
> > V4: Fixed misspelling
> 
> Any particular reason you fixed only one of the two
> mispelings I pointed out?  (device tree is two words,
> not one).

Ahh, my fault.

> 
> > +	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);
> 
> You could use one property instead of two; use addr+len
> like every other property does.
> 
> You also should use a better name for the property; is this
> the previous kernel's device tree?  Just "device-tree" makes
> no sense, it is not pointing to "the" device tree for sure!
> 

What about just one node called "flat-device-tree"?

-Matthew

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

[Segher Boessenkool]

>> Any particular reason you fixed only one of the two
>> mispelings I pointed out?  (device tree is two words,
>> not one).
>
> Ahh, my fault.

Well I wasn't terribly clear ;-)

>> You could use one property instead of two; use addr+len
>> like every other property does.
>>
>> You also should use a better name for the property; is this
>> the previous kernel's device tree?  Just "device-tree" makes
>> no sense, it is not pointing to "the" device tree for sure!
>
> What about just one node called "flat-device-tree"?

But *what* flat device tree?  It cannot be "the" flat device tree,
or it would be useless information, since we are already reading it!


Segher

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

[Matthew McClintock]

On Wed, 2010-07-14 at 17:46 +0200, Segher Boessenkool wrote:
> > What about just one node called "flat-device-tree"?
> 
> But *what* flat device tree?  It cannot be "the" flat device tree,
> or it would be useless information, since we are already reading it! 

I thought about it all day and did not come up with anything terribly
insightful...

"boot-fdt-phys-addr" 
"fdt-phys-addr"
"boot-fdt-phys-reg"
"fdt-phys-addr-reg"

Thoughts?

-M

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

[Grant Likely]

On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock <msm@freescale.com> wro=
te:
> 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@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.

Cheers,
g.

> ---
> V4: Fixed misspelling
>
> V3: Remove unneeded cast, and fixed indentation screw up
>
> V2: messed up changes
>
> =A0arch/powerpc/kernel/prom.c | =A0 45 ++++++++++++++++++++++++++++++++++=
++++++++++
> =A01 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 @@
> =A0#include <linux/debugfs.h>
> =A0#include <linux/irq.h>
> =A0#include <linux/lmb.h>
> +#include <linux/bootmem.h>
>
> =A0#include <asm/prom.h>
> =A0#include <asm/rtas.h>
> @@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
> =A0}
> =A0__initcall(export_flat_device_tree);
> =A0#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 =3D {
> + =A0 =A0 =A0 .name =3D "linux,devicetree-start",
> + =A0 =A0 =A0 .length =3D sizeof(phys_addr_t),
> + =A0 =A0 =A0 .value =3D &flat_dt_start,
> +};
> +
> +static struct property flat_dt_end_prop =3D {
> + =A0 =A0 =A0 .name =3D "linux,devicetree-end",
> + =A0 =A0 =A0 .length =3D sizeof(phys_addr_t),
> + =A0 =A0 =A0 .value =3D &flat_dt_end,
> +};
> +
> +static int __init export_flat_device_tree_phys_addr(void)
> +{
> + =A0 =A0 =A0 struct property *prop;
> + =A0 =A0 =A0 struct device_node *node;
> +
> + =A0 =A0 =A0 node =3D of_find_node_by_path("/chosen");
> + =A0 =A0 =A0 if (!node)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOENT;
> +
> + =A0 =A0 =A0 prop =3D of_find_property(node, "linux,devicetree-start", N=
ULL);
> + =A0 =A0 =A0 if (prop)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 prom_remove_property(node, prop);
> +
> + =A0 =A0 =A0 prop =3D of_find_property(node, "linux,devicetree-end", NUL=
L);
> + =A0 =A0 =A0 if (prop)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 prom_remove_property(node, prop);
> +
> + =A0 =A0 =A0 flat_dt_start =3D virt_to_phys(initial_boot_params);
> + =A0 =A0 =A0 flat_dt_end =3D virt_to_phys(initial_boot_params)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 + initial_b=
oot_params->totalsize;
> + =A0 =A0 =A0 prom_add_property(node, &flat_dt_start_prop);
> + =A0 =A0 =A0 prom_add_property(node, &flat_dt_end_prop);
> +
> + =A0 =A0 =A0 return 0;
> +}
> +__initcall(export_flat_device_tree_phys_addr);
> +#endif
> --
> 1.6.6.1
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[Matthew McClintock]

On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock
> <msm@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@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.
> 
> Cheers,
> g. 

Grant,

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. 

There is already precedence for exporting the initrd physical addresses
in the same fashion, which is mostly why I took this route. So instead I
just choose to find and replace the device tree and initrd reserve
regions.

I'm open to other ideas, just let me know. 

Regards,
Matthew

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

[Grant Likely]

On Thu, Jul 15, 2010 at 9:19 AM, Matthew McClintock <msm@freescale.com> wro=
te:
> On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
>> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock
>> <msm@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@freescale.com>
>>
>> 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.
>>
>> Cheers,
>> g.
>
> Grant,
>
> 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.

g.

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

[Matthew McClintock]

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

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

-M

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

[Grant Likely]

On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock <msm@freescale.com> wr=
ote:
> 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? =A0Where does the device tree (and
>> memreserve list) come from
>> that you're passing to kexec? =A0My 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.

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

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

g.


>
> -M
>
>
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [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@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

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

[Grant Likely]

On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm@freescale.com> wr=
ote:
> On Thu, 2010-07-15 at 10:57 -0600, Grant Likely wrote:
>> On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock <msm@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 al=
l
>> >> 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? =A0Where does the device tree (and
>> >> memreserve list) come from
>> >> that you're passing to kexec? =A0My first impression is that if you h=
ave
>> >> 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? =A0(what mechanism?) =A0I 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?

It's unstable.  It is in the debugfs, so there are no guarantees that
the ABI will remain the same.  Plus it doesn't reflect any changes
that the kernel may make to the device tree.  That interface is *debug
only*.  Do not use it.

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

That is one option.  U-Boot really shouldn't be modifying the tree
very much anyway (I know on some platforms U-Boot is almost creating a
tree from scratch, but that is insane and an entirely different
discussion).  /proc/device-tree always gives the kernel's current view
of the tree.  You can use dtc to extract it and write it into a dtb.

> Ideally, we
> don't make the end user manually edit a device tree.

Of course not, any device tree manipulation is the job of the kexec
tools.  None of this should be manual.  However, the data source is a
significant and important question.

>> > 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 physic=
al
>> > addresses for the second reboot.
>>
>> This sounds like the model is backwards. =A0Rather 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.

What do you mean by "pull it every time"?

Out of curiosity, what is responsible for building up the memreserve
list?  The userspace portion, or the kernel portion of kexec?  Or is
it done by a totally separate program?

>> > The initrd addresses are already exposed, so we can update/remove/reus=
e
>> > that entry, we just need a way for kexec to determine the current devi=
ce
>> > 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 sur=
e
>> > 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?

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.

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

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

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

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

[Matthew McClintock]

On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm@freescale.com> wrote:
> > On Thu, 2010-07-15 at 10:57 -0600, Grant Likely wrote:
> >> On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock <msm@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?
> 
> It's unstable.  It is in the debugfs, so there are no guarantees that
> the ABI will remain the same.  Plus it doesn't reflect any changes
> that the kernel may make to the device tree.  That interface is *debug
> only*.  Do not use it.

Ok.

> 
> > 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?
> 
> That is one option.  U-Boot really shouldn't be modifying the tree
> very much anyway (I know on some platforms U-Boot is almost creating a
> tree from scratch, but that is insane and an entirely different
> discussion).  /proc/device-tree always gives the kernel's current view
> of the tree.  You can use dtc to extract it and write it into a dtb.

Ok wow, I've missed this completely. dtc to extract the device tree is a
very good option. I will pursue that line of thinking.

> 
> > Ideally, we
> > don't make the end user manually edit a device tree.
> 
> Of course not, any device tree manipulation is the job of the kexec
> tools.  None of this should be manual.  However, the data source is a
> significant and important question.

Ideally, we don't duplicate this in kexec and u-boot. Right now there is
nothing specific for say mpc85xx in kexec it's just ppc32. I would
prefer it stay this way.

> 
> >> > 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.
> 
> What do you mean by "pull it every time"?

Exactly what you are saying is bad to do ;-P. Pull it from debugfs. But
the above "dts -I fs" solution practically fixes that issue.

> 
> Out of curiosity, what is responsible for building up the memreserve
> list?  The userspace portion, or the kernel portion of kexec?  Or is
> it done by a totally separate program?

Currently, neither. I have submitted patches for the user space tool to
fixup the memreserve regions.

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

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

-M

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

[Grant Likely]

On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm@freescale.com> wr=
ote:
> On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
>> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm@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. =A0For
>> 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. =A0The 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. =A0It is
>> something that belongs in the tree-proper. =A0ie. 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. =A0The solution should focus not on "can I throw this one away?" but
>> rather "Is this one I should keep?" =A0:-) =A0A subtle difference, I kno=
w,
>> 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.

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

[Mitch Bradley]

Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm@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 <msm@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.
>   

In the /memory node, the "reg" property specifies all of memory and the 
"available" property specifies those portions that the OS is permitted 
to use.  Subtracting "available" from "reg" gives you the regions that 
are used for other purposes, such as frame buffers or firmware needs.

Often the OS can just look at "available", as it typically wants to know 
what it can use, not what it can't.

The full size as given by "reg" is useful for system configuration 
reporting purposes - the user thinks he bought 2G of memory, so it's 
good to report that 2G is indeed installed in the system.  (As an aside, 
when I first invented Open Boot, 16M was a typical memory size.  I'm 
rather gratified that the overall device tree design has held up 
reasonably well over the scale factors that have happened since then.)

It would be possible to mark the "used" regions with a finer-grained 
distinction than "they are unavailable to the OS", but that quickly gets 
into the diminishing returns realm - a lot of trouble for fairly small 
incremental value. The PC BIOS "E820" memory description scheme has a 
few extra categories of memory.  The one category that seems like it 
might (just barely) be worth the effort is "temporarily used by firmware 
but reclaimable after a certain point" - but then you have to define 
rather carefully the reclamation time and conditions.

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

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

[Segher Boessenkool]

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

Let's take a step back: what exactly _are_ "memreserve sections", what
are they used for, who (kernel, firmware, bootloader, etc.) holds what
responsibility wrt them?


Segher

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

[Matthew McClintock]

On Jul 17, 2010, at 11:41 AM, Segher Boessenkool wrote:

>>>>> Yes. Where would we get a list of memreserve sections?
>>>>=20
>>>> 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.
>>>=20
>>> 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?
>>=20
>> 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.
>=20
> Let's take a step back: what exactly _are_ "memreserve sections", what
> are they used for, who (kernel, firmware, bootloader, etc.) holds what
> responsibility wrt them?
>=20

On the platform I'm working on (mpc85xx) they can be the following:

1) Boot page (aka cpu-release-addr) - always present on MP
2) Flat Device Tree - always present
3) Initrd - optional

When kexec'ing a kernel, we will provide new memory regions for the flat =
device tree and the initrd (if present). However, all others will not be =
replaced by kexec and should either be tossed or preserved. The question =
is how to decide what to do... save them all by default? Save none of =
them? If we save them all at a minimum we need to remove/replace the =
device tree and initrd regions as well. So we need a way to identify =
which regions correspond to these.

Grant and I talked and though a property that lives in the device tree =
describing a persistant-memreseve might work. And Mitch talked about an =
available memory property to go along with the current one which could =
be used to determine which ranges were invalid and need a memreserve =
for...

-Matthew

>=20
> Segher
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20

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

[David Gibson]

On Thu, Jul 15, 2010 at 01:18:21PM -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm@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 <msm@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?

Well.. I don't think it should be this way as a matter of spec.  But
you could use a property as an interim stash for memreserve
information.

I agree that the precise defined semantics of the memreserve regions
is kind of fuzzy and non-obvious.  Here's how I believe they need to
work:

	memory in a reserved region must *never* be touched by the OS
(or subsequent kexec-invoked OSes) unless something else in the device
tree explicitly instructs it how

There already exist several mechanisms for instructing the OS to use
particular reserved regions for particular purposes: e.g. the initrd
properties, and the spin-table properties.  More such mechanisms might
be added in future ePAPR (or whatever) revisions.  But if the OS
version doesn't understand such a future mechanism, it must fall back
to assuming that the memory is reserved in perpetuity.

Now, some of these mechanisms (implicitly) permit the OS to re-use the
reserved memory after it's done using them as instructed (initrd is
the most obvious one).  In that case the OS can re-add the reserved
space to it's general pools, and excise it from the reserved space for
subsequent kexec()-style boots.  However that's (potentially) a more
complex process than just removing an entry - the initial firmware is
free to combine adjacent reserved regions into one reserve entry, or
even to cover a single reserved region with multiple entries.  So in
order to do this manipulation you will need an allocator of sorts that
does the region reservation/dereservation correctly handling the
semantics on a byte-by-byte basis.

You should also be careful that the regions you're handling do
actually lie in memory space.  Linux doesn't support this right now,
but I do have an experimental patch that allows the initrd properties
to point to (e.g.) flash instead of RAM.  In that case the initrd
wouldn't have to lie in an explicitly reserved region, and obviously
could not be returned to the general pool after use.

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

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

[David Gibson]

On Thu, Jul 15, 2010 at 11:39:21AM -0500, Matthew McClintock 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. 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.

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

Ok, be careful with this.  You do have the information you need, but
you might have to split an existing entry.  Having a single reserve
entry to cover the initrd would be typical, but it doesn't have to
happen that way - e.g. if a firmware reserves a big region for its own
purposes, and places the initrd within that region.

Also, the latest specs do *not* require the device tree itself to be
mem reserved.

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

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

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

[Benjamin Herrenschmidt]

On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
> 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.

The kernel should ultimately pass the thing to userspace I reckon, with
an appropriate hook for platform code to insert/recover reserved
regions.

Ben.

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

[Matthew McClintock]

On Jul 18, 2010, at 7:09 PM, Benjamin Herrenschmidt wrote:

> On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
>> 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.
>=20
> The kernel should ultimately pass the thing to userspace I reckon, =
with
> an appropriate hook for platform code to insert/recover reserved
> regions.
>=20

Or possibly in the device tree itself? As I mentioned in my previous =
email - my particular case can already be handled by the information =
passed in the device tree (as I recently discovered), is this something =
we would want to make generic for the device tree or add platform code =
to expose these memreserve regions?

-Matthew

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

[Benjamin Herrenschmidt]

On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock <msm@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@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)

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@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> 
> 
> 

Re: [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@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
>>>=20
>>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>>=20
>> Hi Matthew.
>>=20
>> 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.
>>=20
>> Also, please cc: me and Ben Herrenschmidt on powerpc related device
>> tree changes.
>=20
> I admit to be the victim of a similar misunderstanding...
>=20
> Care to explain in more details ? (with examples)
>=20

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.
>=20
>> Cheers,
>> g.
>>=20
>>> ---
>>> V4: Fixed misspelling
>>>=20
>>> V3: Remove unneeded cast, and fixed indentation screw up
>>>=20
>>> V2: messed up changes
>>>=20
>>> arch/powerpc/kernel/prom.c |   45 =
++++++++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 45 insertions(+), 0 deletions(-)
>>>=20
>>> 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>
>>>=20
>>> #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 =3D {
>>> +       .name =3D "linux,devicetree-start",
>>> +       .length =3D sizeof(phys_addr_t),
>>> +       .value =3D &flat_dt_start,
>>> +};
>>> +
>>> +static struct property flat_dt_end_prop =3D {
>>> +       .name =3D "linux,devicetree-end",
>>> +       .length =3D sizeof(phys_addr_t),
>>> +       .value =3D &flat_dt_end,
>>> +};
>>> +
>>> +static int __init export_flat_device_tree_phys_addr(void)
>>> +{
>>> +       struct property *prop;
>>> +       struct device_node *node;
>>> +
>>> +       node =3D of_find_node_by_path("/chosen");
>>> +       if (!node)
>>> +               return -ENOENT;
>>> +
>>> +       prop =3D of_find_property(node, "linux,devicetree-start", =
NULL);
>>> +       if (prop)
>>> +               prom_remove_property(node, prop);
>>> +
>>> +       prop =3D of_find_property(node, "linux,devicetree-end", =
NULL);
>>> +       if (prop)
>>> +               prom_remove_property(node, prop);
>>> +
>>> +       flat_dt_start =3D virt_to_phys(initial_boot_params);
>>> +       flat_dt_end =3D 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
>>>=20
>>>=20
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>>=20
>>=20
>>=20
>>=20
>=20
>=20
>=20

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

[Grant Likely]

On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock <msm@freescale.com> wr=
ote:
> 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@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@freescale.com>
>>>
>>> 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.

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

[Scott Wood]

On Sun, 18 Jul 2010 22:32:38 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:

> On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock <msm@freescale.com> wrote:
> > 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.

So why do we have memreserve at all?

If we honor it on the first boot, seems like we should keep that
information around on subsequent boots.  I wouldn't want to be the one
to have to debug when that theoretical need becomes actual. :-(

Or am I misunderstanding what this is trying to do?

-Scott