From: Dan Malek <dan@netx4.com>
To: Ralph Blach <rcblach@raleigh.ibm.com>
Cc: Daris A Nevil <dnevil@snmc.com>,
Graham Stoney <greyham@research.canon.com.au>,
Daniel Wu <Daniel.Wu@alcatel.com.au>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: Porting LinuxPPC
Date: Fri, 19 May 2000 11:50:38 -0400 [thread overview]
Message-ID: <392562CE.A71A4F49@embeddededge.com> (raw)
In-Reply-To: 39253D0B.F9AF86EE@raleigh.ibm.com
Ralph Blach wrote:
> I disagree. I beleive that the Kernel load simply must be above
> 0x80000000.
OK, time for another memory map lesson........
Virtual addresses from 0 to 0x7fffffff are for user context. Above
this are the kernel virtual addresses. The PowerPC processors have
more than 32-bits of addressing, but I won't go into that since it
is not important for this discussion.
During the early kernel initialization, the kernel virtual memory
allocator is not operational. Prior to this KVM initialization, we
choose to map virtual to physical addresses 1:1. That is, the kernel
virtual address exactly matches the physical address on the bus. These
mappings are typically done in arch/ppc/kernel/head.S, or
arch/ppc/mm/init.c. Only absolutely necessary mappings should be
done at this time, for example board control registers or a serial
uart. Normal device driver initialization should map resources
later when necessary.
Although platform dependent, and certainly the case for embedded 8xx,
traditionally memory is mapped at physical address zero, and I/O
devices above phsical address 0x80000000. The lowest and highest
(above 0xf0000000) I/O addresses are traditionally used for devices
or registers we need to map during kernel initialization and prior
to KVM operation. For this reason, and since it followed prior PowerPC
platform examples, I chose to map the embedded 8xx kernel to the
0xc0000000 virtual address. This way, we can enable the MMU to map the
kernel for proper operation, and still map a few windows before the
KVM is operational.
On some systems, you could possibly run the kernel at the 0x80000000
or any other virtual address. It just depends upon mapping that must
be done prior to KVM operational. You can never map devices or
kernel spaces that overlap with the user virtual space. This is why
default IMMR mapping used by most BDM tools won't work. They put
the IMMR at something like 0x10000000 or 0x02000000 for example. You
simply can't map these addresses early in the kernel, and continue
proper system operation.
The embedded 8xx/82xx kernel is mature enough that all you should need
to do is map the IMMR someplace at or above 0xf0000000 and it should
boot far enough to get serial console messages and KGDB connected on
any platform. There are lots of other subtle memory management design
features that you simply don't need to worry about. If you are changing
functions related to MMU initialization, you are likely breaking things
that are known to work and are heading down a path of disaster and
frustration. Your changes should be to make the flexibility of the
processor fit Linux, not force arbitrary and non-workable memory
mappings into Linux.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-05-19 15:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-19 4:31 Porting LinuxPPC Daniel Wu
2000-05-19 5:10 ` Graham Stoney
2000-05-19 8:09 ` Daniel Wu
2000-05-19 8:19 ` Graham Stoney
2000-05-19 11:07 ` Dan A. Dickey
2000-05-19 12:57 ` Daris A Nevil
2000-05-19 13:09 ` Ralph Blach
2000-05-19 15:50 ` Dan Malek [this message]
2000-05-23 7:18 ` Daniel Wu
2000-05-23 21:01 ` Richard Hendricks
2000-05-23 22:00 ` Richard Hendricks
[not found] ` <392A3147.3A9AC5C2@alcatel.com.au>
2000-05-30 7:49 ` Daniel Wu
2000-05-30 18:54 ` Tom Roberts
2000-05-19 11:39 ` Ralph Blach
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=392562CE.A71A4F49@embeddededge.com \
--to=dan@netx4.com \
--cc=Daniel.Wu@alcatel.com.au \
--cc=dnevil@snmc.com \
--cc=greyham@research.canon.com.au \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=rcblach@raleigh.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 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).