WHDLoad and the MMU

WHDLoad and the Memory Managment Unit (MMU)

An MMU is contained in the following processors of the 68000 family: MC68030, MC68040, MC68060. There are also so called EC versions of these processors which have a broken, out of action MMU. For example, all standard A4000/030 have only an MC68EC030 CPU. On third party accelerator boards this is different, look in the appropriate documentation to learn about it. As far as I know, all 68040/68060's ever built into 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). Another 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

On startup, WHDLoad scans 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, the memory used by the Freezer will also be marked as valid. All other memory is marked as invalid, and therefore every access to such an area (Read or Write) will create an Access Fault Exception which will end in an appropriate error requester created by WHDLoad.

Cache managment using the MMU in WHDLoad

The Caches are usually controled via the CacheControlRegister (CACR). With the MMU this may be finely adjusted 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 WriteThrough, 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, by 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 use the Caches to improve performance. The Slave can enable (or disable if previous enabled) the Caches via the function resload_SetCACR. This function may also modify the MMU tables for the BaseMem area depending on the Cache set.

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 to 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 while 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 exception occuring will be handled by WHDLoad, which will quit the installed program if any unwanted 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 (temporarily)
- in general each program which changes basic functions 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 management 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 does disable the MMU usage.

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