MMap function

[Joel Sherrill]

VALETTE Eric wrote:
> 
> Aaron J. Grier wrote:
> > On Thu, Mar 21, 2002 at 09:20:57AM +0100, VALETTE Eric wrote:
> >
> >
> >>Aaron J. Grier wrote:
> >>
> >>>RTEMS has no virtual memory subsystem, and the filesystems are usually
> >>>in-memory.  so no mmap() in RTEMS.
> >>
> >>This is not totally accurate. pc386 BSP has virtual memory turned on
> >>(with of course a 1-1)  mapping. The reason is that there is no way
> >>non-using the mmu to mark *only* portion of physical address space non
> >>cacheable (think about PCI configuration space registers access).
> >
> >
> > <slaps head> of course...  do other processors (thinking of powerPC and
> > MIPS) do similar things with their MMUs when running RTEMS?
> >
> 
> I do not know MIPS architecture at all so I cannot say. For PPC,
> situation is a little bit different depending on models :
>         1) On 6xx you have BATS registers that enable to control some big chunks
> of memory and they can be used if the memory map is not too complex (and
> in particlular if you do not need to map VME address space in addition
> to PCI, legacy IO, ...). I used them on motorola shared for performance
> reasons and also because I do not need to mess with Mmu. However, I
> think a more general implementation should use a conjunction of MMU and
> BAT for introducing flexibility in the address map,
>         2) On 8xx the MMU is on as there is no BAT, so MMU is activated and you
> can control caching attributes,

On other CPUs, the MMU/memory protection built-in has been used to
accomplish
various things.  One of the neatest tricks was on the HPPA where the BSP
provided the task stack memory via a user extension.  Each stack was
exactly 
one memory page and setup via the MMU so that a stack overflow or
udnerflow
was caught in HW.

The mips mongoosev has some way to guard memory regions and Greg Menke 
has mentioned multiple times that he wants to take advantage of that.

My gut feeling is that RTEMS people use the MMU on their CPU as a
defense mechanism. :)

> Hope this helps,
> 
> --
>     __
>    /  `                          Eric Valette - Canon CRF
>   /--   __  o _.                 Product Dev. Group Software Team Leader
> (___, / (_(_(__                 Rue de la touche lambert
>                                  35517 Cesson-Sevigne  Cedex
>                                  FRANCE
> Tel: +33 (0)2 99 87 68 91       Fax: +33 (0)2 99 84 11 30
> E-mail: valette at crf.canon.fr    http://www.crf.canon.fr

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985