All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Suzuki Poulose <suzuki@in.ibm.com>
Cc: kexec@lists.infradead.org
Subject: Re: Question regarding the kexec support for FSL Book E
Date: Thu, 07 Apr 2011 10:23:01 +0200	[thread overview]
Message-ID: <4D9D7465.8030102@linutronix.de> (raw)
In-Reply-To: <4D9D5F17.2040208@in.ibm.com>

Suzuki Poulose wrote:
> Hi Sebastian,
Hi,

> I am working on the Kexec support for PPC44x based boards. I was going 
> through
> the patchset that you have posted for FSL Book E. I was not able to 
> understand
> some parts of the setup code. If you have some time, could you please 
> help me by
> answering the questions below :
> 
> Here is what I understood from the code walk through :
> 
> In relocate_kernel :, we try to setup a 1:1 mapping for 0-2GB of memory 
> so that
> the code could run with the MMU switched on. We leave a temparory 
> mapping in
> place and create the mapping for 0-2GiB.
> 
> Q1: Does the temparory mapping cover the code which sets up the mapping 
> ? i.e,
> the code in fsl_booke_entry_mapping.S ?

Yes, it does. Please keep in mind that relocate_new_kernel is kmalloc()
into a separate page while running. This is not just the case for
FSL-BookE but for all arches.

> Q2: Does the relocate kernel also get loaded within the 0-2GB memory ? 

Yes. We don't have a mapping >2GiB.

> If so,
> won't we have multiple mappings for the code we are executing, unless we 
> were
> mapped 1:1 by the primary kernel ?

The primary kernel maps 0-2GiB 1:1. We jump to relocate_new_kernel() which
is somewhere within 0..2GiB and not part of the original kernel image.
This code has a page list of the new kernel. It copies the new kernel to
its final position and overwrites the old kernel. This is not a problem as
you remember relocate_new_kernel() is no longer part of the old image.

Once the image is copied, we jump to purgatory and then to the new kernel.

> Thanks
> Suzuki Poulose
> Linux Technology Center
> IBM India

Sebastian

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

       reply	other threads:[~2011-04-07  8:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4D9D5F17.2040208@in.ibm.com>
2011-04-07  8:23 ` Sebastian Andrzej Siewior [this message]
2011-04-07 11:08   ` Question regarding the kexec support for FSL Book E Suzuki Poulose
2011-04-07 15:19     ` McClintock Matthew-B29882
2011-04-07 16:22       ` Sebastian Andrzej Siewior
2011-04-08  4:47         ` Suzuki Poulose

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=4D9D7465.8030102@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=kexec@lists.infradead.org \
    --cc=suzuki@in.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.