From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: kexec: selective MMU identity mapping
Date: Wed, 2 Feb 2011 22:47:45 +0000 [thread overview]
Message-ID: <20110202224745.GK31043@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <alpine.LFD.2.00.1102021723330.8212@xanadu.home>
On Wed, Feb 02, 2011 at 05:27:40PM -0500, Nicolas Pitre wrote:
> On Wed, 2 Feb 2011, Russell King - ARM Linux wrote:
>
> > It's known to work on Assabet. It works on SA1100 because the kernel
> > mapping is already a 1:1 mapping.
> D'oh.
>
> > What setup_mm_for_reboot() is doing on Assabet though is making the
> > flash available for cpu_reset(0) to be able to call, not making the
> > kernel code for cpu_reset() available for calling.
>
> Right. So if RAM is located at 0xd0000000 instead then this won't work
> as intended.
It'll work as intended for cpu resetting, except for v6 and v7 as they
don't have the necessary code in their cpu_reset() function to work,
and secondly perversely, v6 and v7 CPUs stall the pipeline when turning
the MMU off, while previous CPUs didn't. Meanwhile, many other
instructions which did stall the pipeline no longer do.
> And overwriting the entire user space is not the best thing to do for
> kexec anyway.
Probably not. As I see it, having RAM located above PAGE_OFFSET in phys
address space, but not being a 1:1 mapping, will always be a problem.
What if it ends up overwriting the L2 cache controller mapping?
next prev parent reply other threads:[~2011-02-02 22:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-02 14:43 [PATCH v2] ARM: kexec: selective MMU identity mapping Per Fransson
2011-02-02 20:48 ` Nicolas Pitre
2011-02-02 21:09 ` Russell King - ARM Linux
2011-02-02 22:10 ` Nicolas Pitre
2011-02-02 22:19 ` Russell King - ARM Linux
2011-02-02 22:27 ` Nicolas Pitre
2011-02-02 22:47 ` Russell King - ARM Linux [this message]
2011-02-03 7:32 ` Mika Westerberg
2011-02-03 10:14 ` Per Fransson
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=20110202224745.GK31043@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).