linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Matthew McClintock <msm@freescale.com>,
	Kumar Gala <kumar.gala@freescale.com>,
	linuxppc-dev@lists.ozlabs.org, Timur Tabi <timur@freescale.com>
Subject: Re: [PATCH V4] powerpc/prom: Export device tree physical address via  proc
Date: Mon, 19 Jul 2010 11:57:03 -0500	[thread overview]
Message-ID: <20100719115703.7faffa4f@schlenkerla.am.freescale.net> (raw)
In-Reply-To: <AANLkTimJwnmf1YTPIy7OqdjseiUspzlxwRcjPMQ6Vv6j@mail.gmail.com>

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

      reply	other threads:[~2010-07-19 17:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-14 15:18 [PATCH V4] powerpc/prom: Export device tree physical address via proc Matthew McClintock
2010-07-14 15:33 ` Tabi Timur-B04825
2010-07-14 15:35 ` Segher Boessenkool
2010-07-14 15:42   ` Matthew McClintock
2010-07-14 15:46     ` Segher Boessenkool
2010-07-15  6:17       ` Matthew McClintock
2010-07-15  6:21 ` Grant Likely
2010-07-15 15:19   ` Matthew McClintock
2010-07-15 16:22     ` Grant Likely
2010-07-15 16:39       ` Matthew McClintock
2010-07-15 16:57         ` Grant Likely
2010-07-15 18:03           ` Matthew McClintock
2010-07-15 18:37             ` Grant Likely
2010-07-15 18:58               ` Matthew McClintock
2010-07-15 19:18                 ` Grant Likely
2010-07-16  5:44                   ` Mitch Bradley
2010-07-17 16:41                   ` Segher Boessenkool
2010-07-19  4:24                     ` Matthew McClintock
2010-07-30  1:38                   ` David Gibson
2010-07-30  1:23         ` David Gibson
2010-07-19  0:09       ` Benjamin Herrenschmidt
2010-07-19  4:34         ` Matthew McClintock
2010-07-18 23:41   ` Benjamin Herrenschmidt
2010-07-19  4:28     ` Matthew McClintock
2010-07-19  4:32       ` Grant Likely
2010-07-19 16:57         ` Scott Wood [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100719115703.7faffa4f@schlenkerla.am.freescale.net \
    --to=scottwood@freescale.com \
    --cc=grant.likely@secretlab.ca \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=msm@freescale.com \
    --cc=timur@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).