/* mmu40Lib.c - mmu library for MC68040 and MC68060 *//* Copyright 1984-1996 Wind River Systems, Inc. */#include "copyright_wrs.h"/*modification history--------------------01o,10feb99,wsl  add comment documenting ERRNO code01n,29oct96,dat  fixed in-line assembly for 2.7 compiler. (SPR 7403) 01m,07mar95,ism  fixed problem with restoration of d) from stack (SPR#4065).01l,22nov94,dzb  added cacheClear() in mmuEnable() as per Heurikon request.01k,31oct94,tmk  added MC68LC040 support01j,16jun94,tpr  added MC68060 cpu support.		 clean up following code review.01j,05jul94,rdc  mods to decrease fragmentation and provide alternate memory 		 source.  Fixed bug that caused pages containing page 		 descriptors to be write enabled.01i,12feb93,rdc  changed scheme for sharing data structures with vmLib.01h,09feb93,rdc  fixed bug preventing mapping of large vm spaces.01g,09oct92,rdc  moved reset of TT regs to mmuEnable.01f,01oct92,jcf  warnings.01e,22sep92,rdc  doc.01d,28jul92,jmm  added forward declarations for all functions01c,21jul92,rdc  fixed bug in mmuMemPagesWriteEnable/Disable, 		 added init code to mmuCurrentSet to write protect pte memory		 for global trans tbl.01b,13jul92,rdc  changed reference to vmLib.h to vmLibP.h.01a,08jul92,rdc  written.*//*DESCRIPTION:mmuLib.c provides the architecture dependent routines that directly controlthe memory management unit.  It provides 10 routines that are called by thehigher level architecture independent routines in vmLib.c: mmuLibInit - initialize modulemmuTransTblCreate - create a new translation tablemmuTransTblDelete - delete a translation table.mmuEnable - turn mmu on or offmmuStateSet - set state of virtual memory pagemmuStateGet - get state of virtual memory pagemmuPageMap - map physical memory page to virtual memory pagemmuGlobalPageMap - map physical memory page to global virtual memory pagemmuTranslate - translate a virtual address to a physical addressmmuCurrentSet - change active translation tableApplications using the mmu will never call these routines directly; the visable interface is supported in vmLib.c.mmuLib supports the creation and maintenance of multiple translation tables,one of which is the active translation table when the mmu is enabled.  Note that VxWorks does not include a translation table as part of the taskcontext;  individual tasks do not reside in private virtual memory.  However,we include the facilities to create multiple translation tables so thatthe user may create "private" virtual memory contexts and switch them in anapplication specific manner.  Newtranslation tables are created with a call to mmuTransTblCreate, and installedas the active translation table with mmuCurrentSet.  Translation tablesare modified and potentially augmented with calls to mmuPageMap and mmuStateSet.The state of portions of the translation table can be read with calls to mmuStateGet and mmuTranslate.The traditional VxWorks architecture and design philosophy requires that allobjects and operating systems resources be visable and accessable to all agents(tasks, isrs, watchdog timers, etc) in the system.  This has traditionally beeninsured by the fact that all objects and data structures reside in physical memory; thus, a data structure created by one agent may be accessed by anyother agent using the same pointer (object identifiers in VxWorks are oftenpointers to data structures.) This creates a potential problem if you have multiple virtual memory contexts.  For example, if asemaphore is created in one virtual memory context, you must gurantee thatthat semaphore will be visable in all virtual memory contexts if the semaphoreis to be accessed at interrupt level, when a virtual memory context other thanthe one in which it was created may be active. Another example is thatcode loaded using the incremental loader from the shell must be accessablein all virtual memory contexts, since code is shared by all agents in thesystem.This problem is resolved by maintaining a global "transparent" mappingof virtual to physical memory for all the contiguous segments of physical memory (on board memory, i/o space, sections of vme space, etc) that is sharedby all translation tables;   all available  physical memory appears at the same address in virtual memory in all virtual memory contexts. This technique provides an environment that allowsresources that rely on a globally accessable physical address to run withoutmodification in a system with multiple virtual memory contexts.An additional requirement is that modifications made to the state of global virtual memory in one translation table appear in all translation tables.  Forexample, memory containing the text segment is made read only (to avoidaccidental corruption) by setting the appropriate writeable bits in the translation table entries corresponding to the virtual memory containing the text segment.  This state information must be shared by all virtual memory contexts, so that no matter what translation table is active, the text segmentis protected from corruption.  The mechanism that implements this feature isarchitecture dependent, but usually entails building a section of a translation table that corresponds to the global memory, that is shared byall other translation tables.  Thus, when changes to the state of the globalmemory are made in one translation table, the changes are reflected in allother translation tables.mmuLib provides a seperate call for constructing global virtual memory -mmuGlobalPageMap - which creates translation table entries that are sharedby all translation tables.  Initialization code in usrConfig makes callsto vmGlobalMap (which in turn calls mmuGlobalPageMap) to set up global transparent virtual memory for allavailable physical memory.  All calls made to mmuGlobalPageMap must occur beforeany virtual memory contexts are created;  changes made to global virtualmemory after virtual memory contexts are created are not guaranteed to be reflected in all virtual memory contexts.Most mmu architectures will dedicate some fixed amount of virtual memory to a minimal section of the translation table (a "segment", or "block").  This creates a problem in that the user may map a small section of virtual memoryinto the global translation tables, and then attempt to use the virtual memoryafter this section as private virtual memory.  The problem is that the translation table entries for this virtual memory are contained in the global translation tables, and are thus shared by all translation tables.  This condition is detected by vmMap, and an error is returned, thus, the lowerlevel routines in mmuLib.c (mmuPageMap, mmuGlobalPageMap) need not performany error checking.A global variable called mmuPageBlockSize should be defined which is equal to the minimum virtual segment size.  mmuLib must provide a routine mmuGlobalInfoGet, which returns a pointer to the globalPageBlock array.This provides the user with enough information to be able to allocate virtual memory space that does not conflict with the global memory space.This module supports the 68040 and 68060 mmu with a three level translationtable:                                            root                                             |                                             |    LEVEL 1                 -------------------------------------    TABLE DESCRIPTORS (128) | td  | td  | td  | td  | td  | td  | ...                                 -------------------------------------                               |     |     |     |     |     |                                 |     |     |     |     |     |                        ----------     |     v     v     v     v                        |              |    NULL  NULL  NULL  NULL                      |              |                        |              -------------------------                      |                                      |                      v                                      vLEVEL2   -------------------------------      -------------------------------TABLE    | td  | td  | td  | td  | td  | ...  | td  | td  | td  | td  | td  | ..DESCRIP. -------------------------------      -------------------------------  (128/table) |     |                              |     |            |     ----  ...                      |     ----  ...             |        |                           |        |            v        v                           v        v          ----     ----                         ----     ----          | pd |   | pd |                       | pd |   | pd |PAGE      ----     ----                         ----     ---- DESCRIP. | pd |   | pd |   ...                 | pd |   | pd |   ...(32-64    ----     ----                         ----     ----  per     | pd |   | pd |                       | pd |   | pd | table)   ----     ----                         ----     ----         | pd |   | pd |                       | pd |   | pd |          ----     ----                         ----     ----           .         .           .         .           .         .The top level consists of an array of 128 level 1 table descriptors (LEVEL_1_TABLE_DESC).  These point to arrays of 128 level 2 table descriptors (LEVEL_2_TABLE_DESC), which in turn point to arrays of page descriptors(PAGE_DESC).  The page descriptor arrays contain either 32 entries when usedwith an 8k page size, or 64 entries when used with a 4k page size. Memory forthese data structures is managed internal to the module by the routinesmmuTableDescBlockAlloc and mmuPageDescBlockAlloc, which are fixed block memory allocators.  They obtain memory from the system memory partition alignedto page boundries, and break this memory up into fixed length buffers.  Thememory for all descriptors is free'd automatically when a translation table is deleted.To implement global virtual memory, a seperate translation table called mmuGlobalTransTbl is created when the module is initialized.  Calls to mmuGlobalPageMap will augment and modify this translation table.  When newtranslation tables are created, memory for the top level array of level 1 tabledescriptors is allocated and initialized by duplicating the pointers in mmuGlobalTransTbl's top level level 1 table descriptor array.  Thus, the new translation table will use the globaltranslation table's state information for portions of virtual memory that aredefined as global.  Here's a picture to illustrate:	   GLOBAL TRANS TBL		        NEW TRANS TBL		root				     root                 |                                    |                 |                                    |                 v                                    vLEVEL 1  -------------------                  -------------------TABLE    | td  | td  | td  |...               | td  | td  | td  |... DESC.    -------------------                  -------------------             |     |                              |     |            o-------------------------------------     |            |     |                                    |            |     ------------                         |            |                |                         |            |                o--------------------------            |                |            v                vLEVEL2   -------------      ------------TABLE    | td  | td  |...  | td  | td  |...DESCRIP. -------------      ------------ (128/table) |     |           |     |            |     ----  ...   |     ----  ...             |        |        |        |            v        v        v        v          ----     ----       ----     ----          | pd |   | pd |     | pd |   | pd |PAGE      ----     ----       ----     ---- DESCRIP. | pd |   | pd | ..  | pd |   | pd | ...(32-64    ----     ----       ----     ----  per     | pd |   | pd |     | pd |   | pd | table)   ----     ----       ----     ----         | pd |   | pd |     | pd |   | pd |          ----     ----       ----     ----           .         .           .         .           .         .Note that with this scheme, the global memory granularity is 32MB.  Each timeyou map a section of global virtual memory, you dedicate at least 32MB of the virtual space to global virtual memory that will be shared by all virtualmemory contexts.The physcial memory that holds these data structures is obtained from thesystem memory manager via memalign to insure that the memory is pagealigned.  We want to protect this memory from being corrupted,so we write protect the descriptors that we set up in the global translationthat correspond to the memory containing the translation table data structures.This creates a "chicken and the egg" paradox, in that the only way we canmodify these data structures is through virtual memory that is now write protected, and we can't write enable it because the page descriptors for that memory are in write protected memory (confused yet?)So, you will notice that anywhere that page descriptors are modified, we do so by locking out interrupts, momentarily disabling the mmu, accessing the memory with its physical address, enabling the mmu, andthen re-enabling interrupts (see mmuStateSet, for example.)USER MODIFIABLE OPTIONS:1) Memory fragmentation - mmuLib obtains memory from the system memory   manager via memalign to contain the mmu's translation tables.  This memory   was allocated a page at a time on page boundries.  Unfortunately, in the   current memory management scheme, the memory manager is not able to allocate   these pages contiguously.  Building large translation tables (ie, when   mapping large portions of virtual memory) causes excessive fragmentation   of the system memory pool.  An attempt to alleviate this has been installed   by providing a local buffer of page aligned memory;  the user may control   the buffer size by manipulating the global variable mmuNumPagesInFreeList.   By default, mmuPagesInFreeList is set to 4.2) Alternate memory source - A customer has special purpose hardware that   includes seperate static RAM for the mmu's translation tables.  Thus, they   require the ability to specify an alternate source of memory other than   memalign.  A global variable has been created that points to the memory   partition to be used as the source for translation table memory; by default,   it points to the system memory partition.  The user may modify this to    point to another memory partition before mmu40LibInit is called.*/#include "vxWorks.h"#include "string.h"#include "intLib.h"#include "stdlib.h"#include "memLib.h"#include "private/memPartLibP.h"#include "private/vmLibP.h"#include "arch/mc68k/mmu40Lib.h"#include "mmuLib.h"#include "errno.h"#include "cacheLib.h"/* forward declarations */LOCAL void mmuMemPagesWriteEnable (MMU_TRANS_TBL_ID transTbl);LOCAL void mmuMemPagesWriteDisable (MMU_TRANS_TBL *transTbl);LOCAL STATUS mmuPageDescGet (MMU_TRANS_TBL *pTransTbl, void *virtAddr,                             PAGE_DESC **result);LOCAL MMU_TRANS_TBL *mmuTransTblCreate ();LOCAL STATUS mmuTransTblInit (MMU_TRANS_TBL *newTransTbl);LOCAL STATUS mmuTransTblDelete (MMU_TRANS_TBL *transTbl);LOCAL STATUS mmuVirtualPageCreate (MMU_TRANS_TBL *pTransTbl, void *virtAddr);LOCAL PAGE_DESC *mmuPageDescBlockAlloc (MMU_TRANS_TBL *transTbl);LOCAL LEVEL_2_TABLE_DESC *mmuTableDescBlockAlloc (MMU_TRANS_TBL *transTbl);LOCAL void *mmuBufBlockAlloc(LIST *pList,UINT bufSize,MMU_TRANS_TBL *pTransTbl);LOCAL STATUS mmuEnable (BOOL enable);LOCAL STATUS mmuStateSet (MMU_TRANS_TBL *transTbl, void *pageAddr,                          UINT stateMask, UINT state);LOCAL STATUS mmuStateGet (MMU_TRANS_TBL *transTbl, void *pageAddr, UINT *state);LOCAL STATUS mmuPageMap (MMU_TRANS_TBL *transTbl, void *virtualAddress,                         void *physPage);LOCAL STATUS mmuGlobalPageMap (void *virtualAddress, void *physPage);LOCAL STATUS mmuTranslate (MMU_TRANS_TBL *transTbl, void *virtAddress,                           void **physAddress);LOCAL void mmuCurrentSet (MMU_TRANS_TBL *transTbl);LOCAL void mmuATCFlush (void *addr);int mmuPageSize;/* a translation table to hold the descriptors for the global transparent * translation of physical to virtual memory  */LOCAL MMU_TRANS_TBL mmuGlobalTransTbl;/* initially, the current trans table is a dummy table with mmu disabled */LOCAL MMU_TRANS_TBL *mmuCurrentTransTbl = &mmuGlobalTransTbl;LOCAL BOOL mmuEnabled = FALSE;LOCAL STATE_TRANS_TUPLE mmuStateTransArrayLocal [] =    {    {VM_STATE_MASK_VALID, MMU_STATE_MASK_VALID,     VM_STATE_VALID, MMU_STATE_VALID},    {VM_STATE_MASK_VALID, MMU_STATE_MASK_VALID,     VM_STATE_VALID_NOT, MMU_STATE_VALID_NOT},    {VM_STATE_MASK_WRITABLE, MMU_STATE_MASK_WRITABLE,     VM_STATE_WRITABLE, MMU_STATE_WRITABLE},    {VM_STATE_MASK_WRITABLE, MMU_STATE_MASK_WRITABLE,     VM_STATE_WRITABLE_NOT, MMU_STATE_WRITABLE_NOT},    {VM_STATE_MASK_CACHEABLE, MMU_STATE_MASK_CACHEABLE,     VM_STATE_CACHEABLE, MMU_STATE_CACHEABLE},    {VM_STATE_MASK_CACHEABLE, MMU_STATE_MASK_CACHEABLE,     VM_STATE_CACHEABLE_NOT, MMU_STATE_CACHEABLE_NOT},    {VM_STATE_MASK_CACHEABLE, MMU_STATE_MASK_CACHEABLE,     VM_STATE_CACHEABLE_WRITETHROUGH, MMU_STATE_CACHEABLE_WRITETHROUGH},#if (CPU == MC68040 || CPU == MC68LC040)    {VM_STATE_MASK_CACHEABLE, MMU_STATE_MASK_CACHEABLE,     VM_STATE_CACHEABLE_NOT_NON_SERIAL, MMU_STATE_CACHEABLE_NOT_NON_SERIAL}#elif (CPU == MC68060)    {VM_STATE_MASK_CACHEABLE, MMU_STATE_MASK_CACHEABLE,     VM_STATE_CACHEABLE_NOT_IMPRECISE, MMU_STATE_CACHEABLE_NOT_IMPRECISE}#endif /* (CPU == MC68060) */    };LOCAL MMU_LIB_FUNCS mmuLibFuncsLocal =    {