Memory map on custom MPC7400 board

Memory map on custom MPC7400 board

[Greg Griffes]

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.

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?

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.

Thanks in advance for your help.

Greg Griffes

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map on custom MPC7400 board

[Matt Porter]

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/

Re: Memory map on custom MPC7400 board

[Greg Griffes]

Matt,

Thanks very much for your advice.  You have saved me a big headache!

> I really recommend using the linuxppc_2_4_devel tree as a starting
> kernel source base...but it's your choice.

I will try using the linuxppc_2_4_devel tree.  Unforeseen problems I don't need.

> Do you really have to map a contiguous 384MB of physical address
> space? If these are typical RTC and PIC parts...why?

The RTC is typical but the PIC is split between a custom ASIC and
another device.  The RTC is at 0xE400_0000phys, one part of the PIC
is at 0xEC00_0000phys and the other part is at 0xF700_0000phys.
Their size is small, but they are spread out.  If I have to map them with
BATs, I would have to map 384Mb (because the BAT base address
must be a multiple of the mapped size.) Once the KVM is up,
I think that I can use ioremap(), or io_block_mapping() to map in
only what I need.  Is that right?

> 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).

Does this mean that before MMU_init() I can use BATs 2&3, then in
ppc_md.setup_io_mappings() (called after mapin_ram()) I would use
io_block_mapping() (as is done in chrp_setup.c?)

This helps a lot!  Thanks again for your advice.

Greg Griffes


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Memory map on custom MPC7400 board

[Matt Porter]

On Tue, Mar 26, 2002 at 06:35:54AM -0500, Greg Griffes wrote:
> Matt,
>
> Thanks very much for your advice.  You have saved me a big headache!
>
> > I really recommend using the linuxppc_2_4_devel tree as a starting
> > kernel source base...but it's your choice.
>
> I will try using the linuxppc_2_4_devel tree.  Unforeseen problems I don't need.
>
> > Do you really have to map a contiguous 384MB of physical address
> > space? If these are typical RTC and PIC parts...why?
>
> The RTC is typical but the PIC is split between a custom ASIC and
> another device.  The RTC is at 0xE400_0000phys, one part of the PIC
> is at 0xEC00_0000phys and the other part is at 0xF700_0000phys.
> Their size is small, but they are spread out.  If I have to map them with
> BATs, I would have to map 384Mb (because the BAT base address
> must be a multiple of the mapped size.) Once the KVM is up,
> I think that I can use ioremap(), or io_block_mapping() to map in
> only what I need.  Is that right?

You can ioremap() the devices in your board-specific *_setup_arch()
routine.  Early ioremap() calls start at ioremap_base and grow
down.  After the VM system is up, normal allocations in vmalloc
space kick in.  You can use io_block_mapping(), but ioremap()
allows the kernel to efficiently manage your VM.  Too often,
people waste VM space by dropping arbitrary io_block_mappings
everywhere so I would discourage it's use unless you want to
utilize a BAT for specific performance/optmizations reasons in
your application.

> > 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).
>
> Does this mean that before MMU_init() I can use BATs 2&3, then in
> ppc_md.setup_io_mappings() (called after mapin_ram()) I would use
> io_block_mapping() (as is done in chrp_setup.c?)

Do you need to use the parts very early?  95% of cases don't need
devices accessible within head.S.  I understand anything goes
with a custom board but if you are not utilizing the PIC and RTC
hardware until init_IRQ() and time_init(), respectively, then
you don't need to worry about early mappings via BATs.

If you must use a BAT then use io_block_mapping() to accomplish it
from your *_setup_arch().  If you need early access to the I/O,
utilize BATs, you can utilize DBATs 2&3.

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/