On Thu, Jul 15, 2010 at 01:18:21PM -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock
> wrote:
> > On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
> >> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock
> >> wrote:
> >> > Yes. Where would we get a list of
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
On Sun, 18 Jul 2010 22:32:38 -0600
Grant Likely wrote:
> On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock
> 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
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
On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock 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
>>> wrote:
To build a proper flat device tree for kexec
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
>> wrote:
>>> To build a proper flat device tree for kexec we need to know which
>>> memreserve region was used for the device
On Jul 17, 2010, at 11:41 AM, Segher Boessenkool 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
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 mem
On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock
> 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
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
Grant Likely wrote:
On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock wrote:
On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock wrote:
Yes. Where would we get a list of memreserve sections?
I would say the l
On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock wrote:
> On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
>> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock
>> wrote:
>> > Yes. Where would we get a list of memreserve sections?
>>
>> I would say the list of reserves that are not u
On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock
> wrote:
> > On Thu, 2010-07-15 at 10:57 -0600, Grant Likely wrote:
> >> On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock
> >> wrote:
> >> > On Thu, 2010-07-15 at 10:22 -0600, Grant
On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock wrote:
> On Thu, 2010-07-15 at 10:57 -0600, Grant Likely wrote:
>> On Thu, Jul 15, 2010 at 10:39 AM, Matthew McClintock
>> wrote:
>> > On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
>> >> > Thanks for taking a look. My first thought wa
On Thu, 2010-07-15 at 10:57 -0600, Grant Likely wrote:
> On Thu, Jul 15, 2010 at 10:39 AM, 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 star
On Thu, Jul 15, 2010 at 10:39 AM, 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
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 sy
On Thu, Jul 15, 2010 at 9:19 AM, Matthew McClintock wrote:
> On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
>> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock
>> wrote:
>> > To build a proper flat device tree for kexec we need to know which
>> > memreserve region was used for the devi
On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
> On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock
> 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
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 no
On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock 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
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",
> + .leng
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 t
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", NUL
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 =
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
---
V4: Fixed misspelling
V3: R
26 matches
Mail list logo