CodeSpriteEmbedded software consultancy
specializing in
ARM Powered systems
HomeSite MapClientsContact
Search this site 
powered by FreeFind

Free Software Downloads

ARM MMU Table Generator

Mmugen is a utility program that creates MMU tables for ARM’s cached processors. The program reads a text file describing the target system’s memory map and generates a binary file containing level-one and level-two MMU page tables. This program may also be found in ARM's ADS software development toolkit, in the 'Examples' directory.

book and floppy disk graphic
Download
mmugen.zip

As supplied, MMUgen may be compiled as a native application on any system with an ANSI standard compiler, or may be run on ARMulator, using Semihosting to read data from the rules text file and to write back the binary MMU tables on the Host system.

MMUgen could also be adapted to generate MMU tables on a target system at run time. This reduces the ROM requirements dramatically, since the rule files are much smaller than the generated MMU tables, and can be compressed still further by encoding the rules as C-structures (MMUgen does this encoding as an interim step in its current form).

These notes should be read in conjunction with the example scripts in the downloadable zip file.

Please note that although the program generates working MMU tables, it does NOT perform 100% error checking on the scripts. It is intended that this program is a guide for creating MMU tables, and no responsibility is accepted for any costs or liabilities no matter how incurred, arising from its use.

MMUgen features

MMUgen sets all level-one entries to "domain 0" and assumes that domain zero is set up for client-permissions. MMUgen could be readily extended to allow domains to be specified for each memory region.

The MMUgen rules file allows the user to specify for each region of the virtual address space:

  • The corresponding physical address for the region
  • Whether the region exists or if the MMU should generate an exception if the region is accessed
  • The access permissions for the region:
    • FULL_ACCESS (any process can read or write in that region)
    • SVC_READWRITE (privileged modes have full access, user mode has no access)
    • NO_USR_WRITE (privileged modes have full access, user mode has only read access)
    • NO_ACCESS (neither privileged or user modes have read or write access to the region)
  • Whether the region is cacheable
  • Whether the Write Buffer is enabled for the region.

MMUgen Rules file format

The general format of a rules file is:

BASE_ADDRESS     .....
LEVEL 1
.....
.....
LEVEL 2
.....
.....
POSTPROCESS     .....

BASE_ADDRESS

The BASE_ADDRESS entry must be specified; this is the address at which your MMU table will be placed in the physical memory map. This address must be on a 16K byte boundary. The base address is used when generating level-1 table entries that refer to level-2 page tables.

LEVEL 1

In the LEVEL 1 section, the complete 4 gigabyte address space is specified. MMUgen uses the descriptions in this section to generate 4096 table entries, each of which describes one megabyte in the virtual address space. The virtual and physical addresses in this section must therefore be on one megabyte boundaries. Typical entries are:

/* 1MB FLASH mapped to RAM */ VIRTUAL 0x00000000 TO 0x000FFFFF PHYSICAL 0xC0400000 PAGES
/* External hardware */ VIRTUAL 0x50200000 TO 0x503FFFFF PHYSICAL 0x50200000 SECTION FULL_ACCESS NOT CACHEABLE AND NOT BUFFERABLE
/* Gap to 0x80000000 */ VIRTUAL 0x60100000 TO 0x7FFFFFFF PHYSICAL 0x60100000 FAULT

There would be other entries between the ones shown here; it is important that the entries in the Level 1 section are in virtual-address order, and that no gaps are left in the description of the memory map, otherwise an incorrect table will be generated.

Note that regions marked with the PAGES keyword should be exactly one megabyte long, but SECTION and FAULT regions can describe larger regions.

The first entry describes a megabyte of virtual memory space that will be mapped onto RAM starting at 0xC0400000. In the system that this example is taken from, the RAM is not contiguous, so we have to specify further information (in the Level 2 section) that allows us to close up the gaps in the physical memory space. We tell MMUgen we want to specify further information by using the word "PAGES". This may also be required if we want to set different access permissions for regions of memory smaller than 1 megabyte, or if the physical memory present is smaller than a 1 megabyte chunk.

The second entry corresponds to a 2 megabyte region of hardware expansion space. This is one-to-one mapped, has full access permissions for both privileged and user mode applications, and is not cached or write-buffered.

The third entry describes a region of virtual memory for which no corresponding physical memory exists. The physical address specified is not important; the FAULT keyword will generate table entries that will cause the MMU to signal an abort exception to the ARM processor for any access to this memory region.

LEVEL 2

This section is required only if any "PAGES" regions have been specified in the LEVEL 1 section. Remember that each "PAGES" region in the LEVEL 1 section must describe exactly one megabyte of the virtual address space. The corresponding entries in the LEVEL 2 section also describe exactly one megabyte, and are defined in the same order that they appear in the LEVEL 1 section.

These rules allow MMUgen to calculate where the corresponding level 2 page tables will be placed in the output file while generating the level 1 page table entries.

It’s worth noting that the level 1 table generated by MMUgen will occupy 16K bytes of memory, and each PAGES reference in the rules table LEVEL 1 section will cause a further level 2 page table to be generated, occupying another 1K bytes of memory.

Typical Level 2 rules file entries would be:

/* FLASH shadow image */ VIRTUAL 0x00000000 TO 0x0007FFFF PHYSICAL 0xC0400000 LARGEPAGES FULL_ACCESS CACHEABLE AND BUFFERABLE
/* FLASH shadow image */ VIRTUAL 0x00080000 TO 0x000FFFFF PHYSICAL 0xC0500000 LARGEPAGES FULL_ACCESS CACHEABLE AND BUFFERABLE
/* Video RAM RAM bank0*/ VIRTUAL 0x0C000000 TO 0x0C00FFFF PHYSICAL 0xC0000000 LARGEPAGES FULL_ACCESS CACHEABLE AND BUFFERABLE
/* Video RAM RAM bank1*/ VIRTUAL 0x0C010000 TO 0x0C0FFFFF PHYSICAL 0x0C010000 LARGEPAGES NO_ACCESS NOT CACHEABLE AND NOT BUFFERABLE
/* RAM disk - RAM bank0*/ VIRTUAL 0x0D000000 TO 0x0D06FFFF PHYSICAL 0xC0010000 LARGEPAGES FULL_ACCESS CACHEABLE AND BUFFERABLE
/* RAM disk - RAM bank1*/ VIRTUAL 0x0D070000 TO 0x0D0EFFFF PHYSICAL 0xC0100000 LARGEPAGES FULL_ACCESS CACHEABLE AND BUFFERABLE
/* RAM disk - no RAM */ VIRTUAL 0x0D0F0000 TO 0x0D0FFFFF PHYSICAL 0x0D0F0000 LARGEPAGES NO_ACCESS NOT CACHEABLE AND NOT BUFFERABLE

In the level-2 tables, LARGEPAGES specifies a 64K byte granularity in virtual to physical mapping, SMALLPAGES specifies a 4K byte granularity. We haven't implemented the 'Tiny Pages' feature that appeared in ARM920, it has since been dropped from all new ARM cached cores.