From: Matt Porter <mporter@mvista.com>
To: Greg Griffes <ggg@ieee.org>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Memory map on custom MPC7400 board
Date: Mon, 25 Mar 2002 22:14:09 -0700 [thread overview]
Message-ID: <20020325221409.A871@home.com> (raw)
In-Reply-To: <004701c1d44e$3d643700$6401a8c0@attbi.com>; from ggg@ieee.org on Mon, Mar 25, 2002 at 05:41:43PM -0500
On Mon, Mar 25, 2002 at 05:41:43PM -0500, Greg Griffes wrote:
>
> Hello,
>
> I am porting the kernel.org 2.4.18 kernel to a custom PowerPC board
> based on the MPC7400 processor. I am using the gnu.org gcc-2.95.3
> and binutils-2.11.2 tools and cross-compiling on i686.
I really recommend using the linuxppc_2_4_devel tree as a starting
kernel source base...but it's your choice.
> My questions deal with memory mapping in the machine dependent layer
> in (my)_setup.c - platform_init(). To provide hardware support for the
> RTC and IRQ functions I need to use two DBATs to map a range of
> 384Mb. The rtc and irq hardware lies between phys 0xE000_0000
> and 0xF800_0000. I plan to use DBAT2 and DBAT3 to map this
> memory 1:1. DBAT0 and DBAT1 are used to map 16Mb of RAM
> from 0x0 (phys) to 0xC000_0000 (virt) for the kernel (this is the way
> it came from kernel.org). Does anyone foresee any problems with this
> approach?
You are misunderstanding the mapping of kernel RAM using BATs. The
16MB mapping is a temporary translation used before MMU_init().
If you look at arch/ppc/mm/ppc_mmu.c:bat_mapin_ram() you'll see
that the final mapping is done using BAT2 and BAT3 (the third
pair of bats is only used if total_lowmem > 256MB).
> On our board, there is 256Mb RAM at physical 0x0. Is there any reason why
> I should not change the kernel to map all 256Mb of RAM at phys 0x0 to virt
> 0xC000_0000 with a single IBAT and DBAT? This would allow me to use
> a DBAT to map additional PCI bus space.
That's fine. In a 256MB RAM system only BAT2 is used, so BAT1,3,4 are
free for I/O translations.
Do you really have to map a contiguous 384MB of physical address
space? If these are typical RTC and PIC parts...why?
Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-03-26 5:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-25 22:41 Memory map on custom MPC7400 board Greg Griffes
2002-03-26 5:14 ` Matt Porter [this message]
2002-03-26 11:35 ` Greg Griffes
2002-03-26 14:16 ` Matt Porter
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=20020325221409.A871@home.com \
--to=mporter@mvista.com \
--cc=ggg@ieee.org \
--cc=linuxppc-embedded@lists.linuxppc.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).