Club Amiga de Montreal

home *** CD-ROM | disk | FTP | other *** search

/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 624a.lha / MMU / MMU.txt < prev

Wrap

Text File | 1992-03-23 | 14.5 KB | 323 lines

MMU Role in Amiga 3000 system by L.Vanhelsuwé © 26-AUG-1991 ----------------------------- ----------------------------- The 68030 inside an Amiga 3000 contains an on-chip MMU (Memory Management Unit). MMUs are used in computer systems to translate 'logical' addresses (LAs) to 'physical' addresses (PAs). Logical addresses are those addresses that the CPU core generates during the course of program execution, in other words you, the application programmer, work with logical addresses (if you get to use pointers). These addresses might be real physical (external) addresses, but most often are not because they are translated (mapped, moved) to different physical addresses. In the course of this mapping the MMU can detect accesses to memory which does not (yet) map to real physical memory. It is via this mechanism that many big operating systems (UNIX) implement demand paged virtual memory systems. Unfortunately on the Amiga the MMU is not (at present) used to implement virtual memory, instead the MMU is used by Exec to ensure that programs which access CHIP RAM or I/O address ranges (Zorro space, CIAs, battery-backed RTC) do continue to operate correctly. While the two seperate on-chip caches (for data and instruction) improve performance of programs they can also break programs were it not for the fact hat the MMU can define areas of memory which should never be cached or even written to ! Additionaly, if your system loads the Kickstart image from hard disk, then the MMU is also used to map the standard ROM address range $F80000-$FFFFFF to wherever Kickstart has been loaded in your 32-bit wide RAM. The MMU programming model is quite complicated. It consists of only a few on-chip registers and one or more MMU data tables located in main RAM. The structure of the data tables (called translation tables) is very flexible and is the source of the model's complexity. A detailed description is beyond the scope of this article (see the official MC68030UM/AD Motorola publication for an in-depth discussion). The on-chip MMU registers on the other hand are simple enough: Mnemonic Full name Size Description -------- --------- ---- ----------- TC Translation Control 32 Controls various aspects of the MMU. CRP CPU Root Pointer 64 Basically contains a pointer to the translation table for user mode programs SRP Supervisor Root Pointer 64 Basically contains a pointer to the translation table for supervisor mode programs (only when enabled in TC). TT0,TT1 Transparent Translation 32 These are identical registers which define zero, one or two optional memory ranges that are not translated. MMUSR MMU Status Register 16 Contains status information of a trans- lation as initiated by a PTEST instr. This register does NOT contain the MMU "status" as does the SR for the 680x0. The following analysis has been carried out on an Amiga 3000 with the following memory/OS configuration: - 2Mb of CHIP RAM located at $00000000-$001FFFFF (first 2Mb in 4Gb space) - 3Mb of FAST RAM located at $07D00000-$07FFFFFF - Kickstart v37.147 If you decide to follow the text with your own 030-based Amiga, be warned that the values you find in your Amiga will be different if your configuration and OS version aren't the same as mine. Using a simple little program like the one below you can read out the contents of your MMU registers. Use a debugging program to actually view the results produced (display memory $200 onwards). *************************************************************************** ** 68030 MMU register read-out program. *************************************************************************** START: move.l 4,a6 lea in_supermode,a5 EXEC Supervisor ;call Exec's Supervisor() function rts in_supermode lea $200,a0 ;-> ROM Wack scratch area pmove TC,(a0) ;get TC contents pmove CRP,$10(a0) ;idem CRP pmove TT0,$20(a0) ;idem TT0 pmove TT1,$30(a0) ;idem TT1 rte ;**!! NOT RTS **!! ;-- END On my Amiga the TC (Translation Control) register contains the following: $80F08630 This breaks down into the following fields: 1000 0000 1111 0000 1000 0110 0011 0000 | || ---- ---- ---- ---- ---- ---- | || | | | | | | | || | | | | | TID = 0 (No 'D' level) | || | | | | ---- TIC = 3 (C table indexed by 3 LA bits | || | | | --------- TIB = 6 (B table indexed by 6 LA bits | || | | -------------- TIA = 8 (A table indexed by 8 LA bits | || | ------------------- IS = 0 (No Initial Shift) | || ------------------------ PS = 32K Page Size | |--------------------------- FCL = 0 (Function Code Lookup disabled) | ---------------------------- SRE = 0 (Supervisor RP disabled) ----------------------------------- E = 1 (MMU translation enabled) From the values of this TC register we can see that the MMU is active (E=1), i.e. it is constantly translating logical addresses (LAs) to physical addresses. 32-Bit LAs are broken down as follows for translation table indexing purposes: 31 15 0 | | | aaaa aaaa bbbb bb cc c ooo oooo oooo oooo _________ _______ ____ __________________ A-FIELD B-FIELD C-F Remaining Offset a = 8 bits to select one of 256 16Mb blocks within the full 4Gb LA range |____________________ | b = 6 bits to select one of 64 256K blocks within a 16Mb LA range |____________________ | c = 3 bits to select one of 8 32K pages within a 256K LA range |_________________________ | o = 15 bits of page offset (32K addressing range inside a 32K page) Only one translation tree is used for both user and supervisor modes (SRE=0). This means that the CRP register points to both the user and supervisor space translation tables. The 64-bit CRP (CPU Root Pointer) register contains the following: $000F0002 $07FFF140 For the most significant LONG word this breaks down to: 0000 0000 0000 1111 0000 0000 0000 0010 |------------------ -- | | | | | DT = 2 (Valid 4-byte descriptors for A tab) | ------------------------ LIMIT= 15 (max index for A level table) ----------------------------------- U/L = 0 (LIMIT field is an upper limit) From this register we see that the top level pointer table contains short- format descriptors and that just the first 16 entries are valid (The TC register specified an 'A' level table of upto 256 entries because TIA=8, but LIMIT=15 chops the size of the table down to 16 entries). The second long word contains the physical address of the translation table. Here's a quick unformatted view of the MMU translation table in memory: 07FF140: 07FFF18A 01000019 02000019 03000019 Level A: 16 LONGs of short- 07FF150: 04000019 05000019 06000019 07FFF28A format descriptors. 07FF160: 08000019 09000019 0A000019 0B000019 07FF170: 0C000019 0D000019 0E000019 0F000019 07FF180: 00000059 00040059 00080059 000C0059 Level B (table 1) 07FF190: 00100059 00140059 00180059 001C0059 64 LONGs of short-format 07FF1A0: 00200019 00240019 00280019 002C0019 descriptors describing first 07FF1B0: 00300019 00340019 00380019 003C0019 16Mb of LA range 07FF1C0: 00400019 00440019 00480019 004C0019 07FF1D0: 00500019 00540019 00580019 005C0019 07FF1E0: 00600019 00640019 00680019 006C0019 07FF1F0: 00700019 00740019 00780019 007C0019 07FF200: 00800019 00840019 00880019 008C0019 07FF210: 00900019 00940019 00980019 009C0019 07FF220: 00A00019 00A40019 00A80019 00AC0019 07FF230: 00B00019 00B40019 00B80019 00BC0059 CIA space ! 07FF240: 00C00019 00C40019 00C80019 00CC0019 07FF250: 00D00019 00D40019 00D80019 00DC0059 Custom chips space ! 07FF260: 00E00059 00E40059 00E80059 00EC0059 Expansion boards space ! 07FF270: 00F00019 00F40019 07F8001D 07FC001D ROM space ! 07FF280: 07000018 07040018 07080018 070C0018 Level B (table 2) 07FF290: 07100018 07140018 07180018 071C0018 Another 64 LONGs of short- 07FF2A0: 07200018 07240018 07280018 072C0018 format descriptors. 07FF2B0: 07300018 07340018 07380018 073C0018 07FF2C0: 07400018 07440018 07480018 074C0018 07FF2D0: 07500018 07540018 07580018 075C0018 07FF2E0: 07600018 07640018 07680018 076C0018 07FF2F0: 07700018 07740018 07780018 077C0018 07FF300: 07800018 07840018 07880018 078C0018 07FF310: 07900018 07940018 07980018 079C0018 07FF320: 07A00018 07A40018 07A80018 07AC0018 07FF330: 07B00018 07B40018 07B80018 07BC0018 07FF340: 07C00019 07C40018 07C80018 07CC0018 07FF350: 07D00019 07D40019 07D80019 07DC0019 $07D0 0000 (start of 3 Mb RAM) 07FF360: 07E00019 07E40019 07E80019 07EC0019 07FF370: 07F00019 07F40019 07F8001D 07FC001D All three tables (Level A and the two level B tables) contain mostly early termination page descriptors. There is no level C table, which is surprising since the TC register does specify that any level C tables are indexed using TIC=3 bits of the LA. The level A table "routes" all LAs to 16Mb block descriptions. Since the 68030 has a 32-bit address bus, table A should have 256 entries (256*16M = 4Gb) to fully map the entire logical space of the CPU. Currently the Amiga doesn't use the address space above $07 FFFFFF. In other words only the first 8 16Mb blocks are used. That's why table A doesn't contain the full 256 entries but just 16, twice as much as really needed. Except for entry #0 and #7, the entire table doesn't contain further table descriptors but early termination page descriptors instead. Let's have a look at entry #1 for example (all others are the same except for the page base address). $01000019 The top 24 bits encode the 24 Msb page address bits : $010000xx The lower byte encodes the following: 0001 1001 ($19) | | ||-- | | || | | | || - DT = 1 (Descriptor Type = Page descriptor) | | ||-- WP = 0 (Write Protect OFF) | | |--- U = 1 (accessed) | |----- M = 1 (modified) |------- CI = 0 (Cache Inhibit OFF) So the whole entry just translates any LA in the range $01xxxxxx into the same physical address without access restrictions. In fact, since there is no physical memory at these addresses, the bus controler of the 68030 will, when outputting this physical address, generate a bus error. Note that what this entry effectively defines is a transparent mapping from LA to PA; so transparent ranges can be defined like this too. Entries #0 and #7 do point to level B tables. Entry #0 points to a table for the first 16Mb of the entire 4Gb space. Entry #7 points to a table for the eighth 16Mb block : $07 000000 to $07 FFFFFF. The lowest 16Mb of the logical address space are the only addresses that a 68000 can generate, only having a 24-bit address bus ($00xxxxxx). In this address range reside the Amiga's most interesting address ranges since the original Amiga 1000 was designed around a 68000. The table descriptor $07FFF18A breaks down as follows: The most significant 28 bits ($07FFF180) point to the level B table. Lowest 4 bits ($A): 1010 ($A) ||-- || |- DT = 2 (Valid 4 byte) ||--- WP = 0 (Write Protect OFF) |---- U = 1 (accessed) These lower four bits just mean that this entry is a table pointer and not an early termination page descriptor like the other ones. Since TIB=6 table B contains a maximum of 64 (2^6) entries; in this case it does so exactly (no LIMIT set). These 64 entries further brake down the first 16 Megabytes of the 68030 into 64 256K blocks. All entries are early termination page descriptors. The first 8 define the 2 Mb of CHIP RAM. These descriptors all have the lower byte set to $59 which means: 0101 1001 ($59) | | ||-- | | || | | | || - DT = 1 (Page descriptor) | | ||-- WP = 0 (Write Protect OFF) | | |--- U = 1 (accessed) | |----- M = 1 (modified) |------- CI = 1 (Cache Inhibit ON) Since custom chip DMA write cycles are interleaved with normal processor cycles (even in Blitter nasty mode), any CHIP RAM read by the 68030 should NEVER be cached on the on-chip data OR instruction caches. This ensures that the 68030 always picks up the "latest" data from CHIP RAM. Similarly, address ranges $00BC0000-$00BFFFFF (which contains the CIA chips), $00DC0000-$00DFFFFF (the custom chips) and $00E00000-$00EFFFFF (the expansion slots) have the Cache Inhibit bit set so I/O registers never get cached. All other page descriptors for the address range $00200000-$00F7FFFF have their lower byte set to $19, which is just the same as $59 but with the CI bit clear, in other words read data can be cached from these addresses. Apart from these range attributes, the entries don't translate the LAs to different PAs; LAs are used unmodified. For the address range $00F80000-$00FFFFFF the table actually does specify a real address translation: this 512K range is mapped to $07F80000, the top 512K in an Amiga 3000 expanded with 3 Mb of FAST RAM. This mapping allows easy upgrades of the Kickstart system software as follows: a Kickstart image is loaded into a 512K block of free 32-bit RAM and then all references to the "old" Kickstart "ROM" re-routed to the faster RAM. Note that the low byte of the page descriptions are $1D this time: 0001 1101 ($1D) | | ||-- | | || \- DT = 1 | | ||--- WP = 1 (Write Protect ON) | | |---- U = 1 | |------ M = 1 --------- CI = 0 The only bit that's different this time is the WP (Write Protect) bit. So, although this 512K is part of your FAST RAM expansion, it behaves as ROM since it's write protected (WP=1). The second B level table is concerned with the 16Mb LA range $07xxxxxx. In this range (at physical addresses $07D0 0000 - $07FF FFFF) 3Mb of FAST RAM is decoded. As you can see from the table, most of the 16Mb block has attributes $18 which means DT=0, ie Invalid Descriptor. When an LA reaches one of these descriptors, the processor will generate a bus error exception. For logical addresses $07D0 0000 and upwards the descriptors are page descriptors which pass the LA through untranslated and unrestricted. The only point to note is that the top 512K of this 3Mb of RAM has a different attribute byte ($1D instead of $19) which just has the WP (Write Protect) bit set, thus rendering the RAM Kickstart copy immune from write hits. One last detail: note that the MMU translation table itself is located inside this protected 512K area and thus can not be corrupted by mistake.