WHDLoad and the MMU

WHDLoad and the Memory Managment Unit (MMU)

A MMU is contained in the following processors of the 68000er family: MC68030, MC68040, MC68060. There are also so called EC versions of these processors which have a broken, out of function MMU. For example all standard A4000/030 have only a MC68EC030 CPU. On third party accelerator boards this is different, look in the appropriate documentation to learn about. As far as known all 68040/68060 ever build in an Amiga are full CPU's containing a working MMU (because burstmode and Zorro III requires MMU mapping of IO space). The distinction between a full CPU and a EC version cannot be done by software (at least in acceptible time). Therefore the user must do this by setting the right options for WHDLoad.
For the MC68020 there is an external MMU called MC68851, but this is currently not supported by WHDload.

Features of a MMU and using in WHDLoad

The main purpose of the MMU is to translate logical addresses to physical ones. This is required for virtual memory and separated address spaces (for example in a protected multi process system). A other feature is to specify special properties like Supervisor Only, Write Protected and Caching mode for every physical address space (on a page base, where a page used in WHDLoad has a size of 4096 bytes). WHDLoad does not use logical to physical address translation. But it uses the MMU for memory protection, cache managment and some special features (Snooping, resload_Protect#?).

Memory protection in WHDLoad

WHDLoad scans on startup the memory list and will build a translation tree which includes all accessible memory. It marks the following address spaces as valid and accessible : $0...BaseMem (using the information from the slave), $dff000...$dff200 (Custom registers), $bfd000...$bff000 (Cia registers) and the memory used by the Slave and WHDLoad. If a Freezer is found in memory also the memory uses by the Freezer will be marked as valid. All other memory is marked as invalid, and therefore every access to such a area Read or Write will create an Access Fault Exception which will normaly end in a appropriate error requester created by WHDLoad.

Cache managment using the MMU in WHDLoad

The Caches are normally controled via the CacheControlRegister (CACR). With the MMU this may be adjusted finer because the cacheability can be set for each memory page separately. On the 68030 a memory page can be Cacheable or NotCacheable. On a 68040/68060 it can be cachable WriteTrough, cachable CopyBack, NonCachable or NonCachable Serialized. The area of WHDLoad and the Slave are always marked as cacheable (WHDLoad=CopyBack, Slave=WriteTrough). If the MMU is used by WHDLoad on default the BaseMem area is marked as NonCachable, and the Data and Instruction Cache are enabled in the CACR. So the program located in the BaseMem area runs without Caches but WHDLoad and the Slave uses the Caches to improve performance. The Slave can enable (or disable if previous enabled) the Caches via the function resload_SetCACR. This function will depending on the Cache set also modify the MMU tables for the BaseMem area.

User control of the MMU handling in WHDLoad

There are 3 different modes how WHDLoad does affect an existing MMU.

"ignore MMU":
In this mode WHDLoad does not change any MMU related register. This may be useful if you have running programs which are banging the MMU and you want that the functionalities of these programs remain intact (for example a software freezer like TK).
Warning: Because WHDLoad does not control the MMU itself a lot of problems are possible. These problems may cause crashes, malfunctions or other unforseeable misbehaviors. Here a list of existing risks:
- running Enforcer/CyberGuard or a similar tool will lock/crash the machine, because WHDLoad will create a lot of Hits each time it switches the OS off and on. These Hits are not bugs of WHDLoad but part of normal operation.
- newer versions of the 68060.library (starting v41.1) will remap the memory $0-$1000 (the first page) to a Fast memory location using the MMU, in "ignore MMU" mode this address translation will remain intact, if the installed program tries to use this area for any DMA actions (e.g. a copperlist in this area) the results will be unforeseeable, because the CPU will read/write the Fast memory location and the DMA's the real Chip memory which contains random data.
- if the running MMU stuff depends on his exception handler ("Access Fault" exception) the option NoTrapHandler/S must be activated, otherwise any occuring exception will be handled by WHDLoad, which will quit the installed program if any unwantend things happen
- if the running MMU stuff uses any memory (exception handler, translation tree, ...) inside the BaseMem of the installed program, it may crash, because the BaseMem will be overwritten during executing the installed program (temporarly)
- in general each program which changes basic function of the system (using the MMU) may conflict with WHDLoad ...
"disable MMU":
In this mode, which is possible only on 68030, the MMU will be switched off by WHDLoad, no MMU related features are available.
"use MMU":
In this mode WHDLoad takes full control over the MMU and realizes memory protection and cache managment as explained above.

On the 68030 the default mode is "disable MMU". On the 68040/68060 default is "use MMU". There are two options to control this behavior. MMU/S enables the MMU feature and must be used on 68030 systems to enable the MMU functionality. NoMMU/S disables the MMU usage.

"An Enforcer hit is an Enforcer hit, period" (Michael Sinz)