Multitasking on the operating system running upon NedHAL is outside the scope of this document – however, what NedHAL provides for the operating system’s multitasker is within the scope of this document.

NedHAL provides facilities for even the most ambitious of multitaskers, whilst remaining scalable for extremely simple multitasking. Facilities include:

• Process memory map remapping support
• Process exception vector remapping support
• Remote processor block memory writes

Process memory map remapping support

Some operating systems may wish to implement a consistent process memory map or memory protection or indeed both. A consistent memory map for a process is sometimes necessary when a compiler cannot produce relocatable executables and hence they must be built to run at a certain address. Win32 executables are like this – so are most Macintosh and Unix executables. As it happens, the ARM SDT can produce relocatable executables (the ARM instruction set is inherently relocatable), but Unix-like operating systems will still require fixed location executables.

The mapping of virtual address space to physical address space is performed by the Memory Management Unit of the processor or MMU as it is more commonly known. All ARM processors contain a MMU of some form, ranging from extremely basic to fairly complex. Obviously, NedHAL is limited by the ability of the MMU present, but given adequate facilities it can map at least any 4k virtual region of memory to any physical location.

Unlike most processors, all ARM’s feature a virtual address entry cache which means that cache entries’ location is specified as its virtual address. Hence if you had address &8000 in the cache and you changed to mapping of &8000, reads from &8000 would not accurately reflect the true contents of that location. On write-back cached ARM’s, dirty cache entries belonging to the old mapping even get written the new mapping if they aren’t written out before the remapping. Hence, a cache invalidation of relevant entries must be performed before memory remaps on write-through cached ARM’s and invalidation and cache cleans must be performed on write-back cached ARM’s.

In addition, like most modern processors, the ARM features a Translation Table Look Aside Buffer or TLB for short. This caches translation table walks to prevent unnecessary table walks. Translation table walks are performed when the processor accesses a page of memory it hasn’t accessed yet to see what access permissions that page has and where it maps to in physical memory. It can consume up to two unbursted single word fetches from main memory and so hence is an expensive operation. The TLB caches these walks to allow the processor to execute much faster. However, its presence means that changes to the translation table means the TLB must also be invalidated.

A process’ address space may consist of a read-only portion (the code and static data), a read-write portion (predefined variables) and a zero-initialised portion as defined by the ANSI C specification. If one wanted to implement memory protection to aid program stability and to minimise memory usage, one would:

• Mark the read-only areas as unalterable and shareable (hence the code area can be shared)
• Mark the read-write area as alterable
• Mark the zero-initialised area as faultable (hence memory only gets allocated when a page fault occurs in that area – hence memory isn’t used unnecessarily)

Obviously, all three areas would require placing in separate pages of memory. Furthermore, if a process were a device driver, it would require access to a portion of i/o space belonging to its device. Furthermore again, if the operating system wanted to store process-specific data it might want to store it in a certain guaranteed location within that process’ address space.

NedHAL portably caters for these requirements through the provision of application blocks which essentially are a processor-specific list of address space changes for that application. They can be as long as necessary for that application. For example:

Application blocks are then mapped into and out of memory using NedHAL upper API calls. These perform the following tasks:

1. Clean the cache for the about-to-be-unmapped areas if necessary
2. Invalidate those areas in the cache(s)
3. Invalidate those areas’ TLB entries
4. Merge the new map with the current one, setting old map entries to fault where necessary

Hence one can perform complete memory remaps as quickly as possible. This caters for all the process memory map remapping needs an operating could need in a portable fashion whilst maintaining the lowest possible overhead.

Process exception vector remapping support

Exception vectors exist on all processors. They are vectored to by the processor when an exceptional situation arises, such as interrupt received.

There are four different faults we are concerned with here on the ARM processor – that of:

1. Branch Through Zero
   The Branch Through Zero exception occurs when the processor branches to location zero. This typically happens when code follows an uninitialised pointer. This location obviously is normally the reset vector called on processor reset, so usually an operating system maps RAM to this location and makes it point somewhere to handle an exception instead.
2. Undefined Instruction
   The Undefined Instruction exception occurs when the processor encounters an unknown instruction. This can happen either when the processor has tried executing data (through indirecting through a bad pointer for example) or when it encounters a coprocessor instruction destined for a non-existent coprocessor eg; a maths coprocessor instruction when there is no maths coprocessor. In the latter case, the instruction can be emulated.
3. Abort on Instruction Prefetch
   The Abort on Data Prefetch exception occurs when the processor’s instruction pipeline attempts to load an instruction from a memory location which the MMU says does not exist or there is insufficient privilege to access it. If the operating system implements a virtual memory system, this fault can be used to load the relevant page of memory in off a swap file.
4. Address Exception
   The Address Exception occurs when the processor attempts to access data at a memory location which the MMU says does not exist or there is insufficient privilege to access it. If the operating system implements a virtual memory system, this fault can be used to load the relevant page of memory in off a swap file. However, often it can be because the program erroneously tries to access data that doesn’t exist (eg; a bad pointer).

The process may want to execute a custom handler for these situations rather that die miserably and so the operating system may want to install per-process handlers for these exceptions. The ANSI C library in particular does this, so NedHAL’s upper API layer provides portable support for generic ANSI C library supported exceptions. Its lower API layer provides ARM-specific support.

Remote processor block memory writes

As outlined in chapter X Cache Coherency solutions, support is provided for remote processor cache invalidation. This can be used in conjunction with the DMA controller in the 21285 to perform block memory writes to a remote processor asynchronously to processor operation. Hence the upper layer API of NedHAL provides calls to perform remote processor block memory writes whose use of DMA operations substantially increases the speed of the transfer whilst allowing the local processor to execute other code. The sequence of operations would go as follows:

1. Clean cache entries of memory block within process’ memory map if necessary
2. Instruct remote processor to invalidate the remote processor’s cache entries relating to destination area of memory and mark it as currently unusable, invalidating remote processor TLB entries as necessary
3. Instruct DMA controller to transfer appropriate memory block in physical memory to appropriate location on remote processor’s physical memory
4. Operating system then suspends thread pending completion of DMA transfer (an interrupt is generated by the DMA controller when ready)
5. Operating system executes some other process (requires task swap) or thread within the process
6. Upon completion of DMA transfer, unsuspend thread

Conclusion

The provision of support for these operations will be build-time definable so that simple RTOS style systems need not include the code overhead for unused operations. However, should the operating system need them, it need not make itself unportable as the HAL will provide portable API’s to perform even the most advanced operations.

Niall Douglas

4^th November 1999