Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!sdcc6!jclark
From: jclark@sdcc6.ucsd.edu (John Clark)
Newsgroups: comp.sys.m68k
Subject: Re: 68040 MMU Prog Question
Message-ID: <19417@sdcc6.ucsd.edu>
Date: 15 May 91 21:58:35 GMT
References: <62390@mcdchg.chg.mcd.mot.com>
Organization: University of California, San Diego
Lines: 54

In article <62390@mcdchg.chg.mcd.mot.com> heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) writes:
+I have a customer who is trying to convert their application from an
+MVME133XT to an MVME165.  They have a 68040 MMU related question that
+has arisen from their configuration and the requirements of using the
+on-chip cache for performance.  They have four regions of memory.

This is coming from Mot???

The TT registers have an ignore mask to be used in conjuction with
the base 16 meg TT zone. However it seem that this may not work.

For the MMU set up on need not have 'all' of memory mapped. The A
level could map as 'invalid' everything but the low memory and those
regions of VME and high control addresses. Each A level entry 'points'
to a 32 meg region. B level 128 128K regions. C level 32 or 64 8 or
4K regions. It would seem that with sufficient 'holes' not all the B
and C level tables need be filled out either.

A 'critique', the 'mask' value of the TT register would have been
better as a 'length'. I.e. start at Meg 16 and map the next
umpty-ump Megs.


>
>1.  On-board memory - 4Meg at 0x0, to be cached I&D, copyback
>2.  A24 VMEbus space - 12Meg just after the end of 1, non-cached
>3.  A32 VMEbus space - various areas, many megabytes, non-cached
>4.  On-board resources - high memory, non-cached
>
>We believe that 3 and 4 can be treated the same, as they are both A32
>and non-cached.  If so, then they collapse to a single region.
>
>We had hoped to be able to do something simple, like with transparent
>translation registers, but 16Meg seems to be the minimum size for a TT
>reg.  Perhaps one could be used for everything beyond the first 16Meg?
>As there are only two TT registers, and we have three kinds of memory
>space, it looks as though we have to construct MMU page tables.  The
>customer is concerned that it seems like a lot of work and a lot of
>memory used up in page tables.  As I look at it, I don't see how to
>create a TT register that maps everything except the first 16Meg.  If
>it is possible, then page tables are needed for only that first 16Meg,
>which looks like it would be doable in about 8KBytes (with 8K pages).
>
>I'm not an MMU expert.  I'm hoping to find one that can help guide us
>in configuring the 040 MMU for this application.  Thanks much.
>-- 
>Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
>"Wrong is wrong, even when it helps you." Popeye


-- 

John Clark
jclark@ucsd.edu