From: Matthew McClintock <msm@freescale.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: 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: Thu, 15 Jul 2010 11:39:21 -0500 [thread overview]
Message-ID: <1279211961.31679.11.camel@localhost> (raw)
In-Reply-To: <AANLkTikIGXBNU7NQEL7riZYB-BJU3jhxauzGo6XhUF3t@mail.gmail.com>
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
next prev parent reply other threads:[~2010-07-15 16:54 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 [this message]
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
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=1279211961.31679.11.camel@localhost \
--to=msm@freescale.com \
--cc=grant.likely@secretlab.ca \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--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).