VxWorks - MMU, sysPhysMemDesc question -Reply
Charlie Grames
Unless you use Wind River's optional VxVMI product, there is no virtual memory with VxWorks. The
only reason the MMU is used is to handle memory attributes (writeable, cacheable, etc.).
Otherwise, in most BSPs, the memory translation from physical to "virtual" is one-to-one.
sysPhysMemDesc is used to describe the memory attributes for different regions of memory.
Some architectures, like PowerPC, also provide the opportunity to describe a memory space that is
used for I/O.
That's pretty "nut-shell" and hopefully useful.
Charlie Grames
The Boeing Company
(314) 233-1956
Charles....@boeing.com
>>> the vxWorks Users Group Exploder <vxwe...@lbl.gov> 01/12/99 12:43pm >>>
Submitted-by owner-vxwexplo-process Tue Jan 12 10:43:06 1999
Submitted-by: Alexander_R...@res.raytheon.com
I am confused about the usage of MMU in VxWorks and
what is the role of sysPhysMemDesc.
I would appreciate, if someone could give me "in nut-shell"
kind of answer.
My background stems from Solaris (UNIX) world, where
clearly Virtual Memory is used and where MMU serves for the mapping of
the task's physical addresses into virtual (logical!) address space.
VxWorks (in its default setting, at least - I think) doesn't use the
Virtual Memory per se, since all tasks are running in the same
address space. Yet seems to be (looking into WRS's manuals),
MMU is used anyway. Is there another "meaning" for Virtual Memory
and MMU in VxWorks "land" (like mapping physical addresses of
the BSP Memory Board into physical addresses on VME bus) ?
What is the role of sysPhysMemDesc in this business ?
Thomas Keith Buchanan
memory
> with VxWorks. The
> only reason the MMU is used is to handle memory attributes (writeable,
> cacheable, etc.).
Not quite so... In architectures where a MMU exists, it is used by VxWorks.
In some architectures (like SPARC), you cannot even run the boot code w/o
initializing the MMU. The difference is mainly in the levels of MMU support.
By default, VxWorks only sets up and uses a single context. Most BSP authors
choose to select a one-to-one mapping to keep it simple. You can change it if
you want to. For example, you could set up the virtual memory map to make two
non-contiguous areas of physical memory look contiguous. In architectures that
are not 32-bits (again like the SPARC), the mappings are not one-to-one. It
has little to do with VME access except that the local physical addresses that
result in VME bus transactions must have a virtual-physical mapping. You still
have to setup the VME interface hardware to respond.
If you get VxVMI, you can use additional contexts and alter the page table
entries on the fly. Even with VxVMI, VxWorks does not implement task-based
memory protection using the MMU. Using taskCreate and taskSwitch hooks, you
can partially implement such a scheme if you wish. In addition, VxWorks offers
no support for swapping virtual memory regions to disk as you would expect from
a real-time OS.
HTH