kernel/linux/arch/cris/arch-v10/README.mm

   1 Memory management for CRIS/MMU
   2 ------------------------------
   3 HISTORY:
   4
   5 $Log: README.mm,v $
   6 Revision 1.1.1.1  2005/04/29 01:40:42  echo
   7 Project for BCMDT_3.0
   8
   9 Revision 1.1  2001/12/17 13:59:27  bjornw
  10 Initial revision
  11
  12 Revision 1.1  2000/07/10 16:25:21  bjornw
  13 Initial revision
  14
  15 Revision 1.4  2000/01/17 02:31:59  bjornw
  16 Added discussion of paging and VM.
  17
  18 Revision 1.3  1999/12/03 16:43:23  hp
  19 Blurb about that the 3.5G-limitation is not a MMU limitation
  20
  21 Revision 1.2  1999/12/03 16:04:21  hp
  22 Picky comment about not mapping the first page
  23
  24 Revision 1.1  1999/12/03 15:41:30  bjornw
  25 First version of CRIS/MMU memory layout specification.
  26
  27
  28
  29
  30
  31 ------------------------------
  32
  33 See the ETRAX-NG HSDD for reference.
  34
  35 We use the page-size of 8 kbytes, as opposed to the i386 page-size of 4 kbytes.
  36
  37 The MMU can, apart from the normal mapping of pages, also do a top-level
  38 segmentation of the kernel memory space. We use this feature to avoid having
  39 to use page-tables to map the physical memory into the kernel's address
  40 space. We also use it to keep the user-mode virtual mapping in the same
  41 map during kernel-mode, so that the kernel easily can access the corresponding
  42 user-mode process' data.
  43
  44 As a comparision, the Linux/i386 2.0 puts the kernel and physical RAM at
  45 address 0, overlapping with the user-mode virtual space, so that descriptor
  46 registers are needed for each memory access to specify which MMU space to
  47 map through. That changed in 2.2, putting the kernel/physical RAM at
  48 0xc0000000, to co-exist with the user-mode mapping. We will do something
  49 quite similar, but with the additional complexity of having to map the
  50 internal chip I/O registers and the flash memory area (including SRAM
  51 and peripherial chip-selets).
  52
  53 The kernel-mode segmentation map:
  54
  55         ------------------------                ------------------------
  56 FFFFFFFF|                      | => cached      |                      |
  57         |    kernel seg_f      |    flash       |                      |
  58 F0000000|______________________|                |                      |
  59 EFFFFFFF|                      | => uncached    |                      |
  60         |    kernel seg_e      |    flash       |                      |
  61 E0000000|______________________|                |        DRAM          |
  62 DFFFFFFF|                      |  paged to any  |      Un-cached       |
  63         |    kernel seg_d      |    =======>    |                      |
  64 D0000000|______________________|                |                      |
  65 CFFFFFFF|                      |                |                      |
  66         |    kernel seg_c      |==\             |                      |
  67 C0000000|______________________|   \            |______________________|
  68 BFFFFFFF|                      |  uncached      |                      |
  69         |    kernel seg_b      |=====\=========>|       Registers      |
  70 B0000000|______________________|      \c        |______________________|
  71 AFFFFFFF|                      |       \a       |                      |
  72         |                      |        \c      | FLASH/SRAM/Peripheral|
  73         |                      |         \h     |______________________|
  74         |                      |          \e    |                      |
  75         |                      |           \d   |                      |
  76         | kernel seg_0 - seg_a |            \==>|         DRAM         |
  77         |                      |                |        Cached        |
  78         |                      |  paged to any  |                      |
  79         |                      |    =======>    |______________________|
  80         |                      |                |                      |
  81         |                      |                |        Illegal       |
  82         |                      |                |______________________|
  83         |                      |                |                      |
  84         |                      |                | FLASH/SRAM/Peripheral|
  85 00000000|______________________|                |______________________|
  86
  87 In user-mode it looks the same except that only the space 0-AFFFFFFF is
  88 available. Therefore, in this model, the virtual address space per process
  89 is limited to 0xb0000000 bytes (minus 8192 bytes, since the first page,
  90 0..8191, is never mapped, in order to trap NULL references).
  91
  92 It also means that the total physical RAM that can be mapped is 256 MB
  93 (kseg_c above). More RAM can be mapped by choosing a different segmentation
  94 and shrinking the user-mode memory space.
  95
  96 The MMU can map all 4 GB in user mode, but doing that would mean that a
  97 few extra instructions would be needed for each access to user mode
  98 memory.
  99
 100 The kernel needs access to both cached and uncached flash. Uncached is
 101 necessary because of the special write/erase sequences. Also, the
 102 peripherial chip-selects are decoded from that region.
 103
 104 The kernel also needs its own virtual memory space. That is kseg_d. It
 105 is used by the vmalloc() kernel function to allocate virtual contiguous
 106 chunks of memory not possible using the normal kmalloc physical RAM
 107 allocator.
 108
 109 The setting of the actual MMU control registers to use this layout would
 110 be something like this:
 111
 112 R_MMU_KSEG = ( ( seg_f, seg     ) |   // Flash cached
 113                ( seg_e, seg     ) |   // Flash uncached
 114                ( seg_d, page    ) |   // kernel vmalloc area
 115                ( seg_c, seg     ) |   // kernel linear segment
 116                ( seg_b, seg     ) |   // kernel linear segment
 117                ( seg_a, page    ) |
 118                ( seg_9, page    ) |
 119                ( seg_8, page    ) |
 120                ( seg_7, page    ) |
 121                ( seg_6, page    ) |
 122                ( seg_5, page    ) |
 123                ( seg_4, page    ) |
 124                ( seg_3, page    ) |
 125                ( seg_2, page    ) |
 126                ( seg_1, page    ) |
 127                ( seg_0, page    ) );
 128
 129 R_MMU_KBASE_HI = ( ( base_f, 0x0 ) |   // flash/sram/periph cached
 130                    ( base_e, 0x8 ) |   // flash/sram/periph uncached
 131                    ( base_d, 0x0 ) |   // don't care
 132                    ( base_c, 0x4 ) |   // physical RAM cached area
 133                    ( base_b, 0xb ) |   // uncached on-chip registers
 134                    ( base_a, 0x0 ) |   // don't care
 135                    ( base_9, 0x0 ) |   // don't care
 136                    ( base_8, 0x0 ) );  // don't care
 137
 138 R_MMU_KBASE_LO = ( ( base_7, 0x0 ) |   // don't care
 139                    ( base_6, 0x0 ) |   // don't care
 140                    ( base_5, 0x0 ) |   // don't care
 141                    ( base_4, 0x0 ) |   // don't care
 142                    ( base_3, 0x0 ) |   // don't care
 143                    ( base_2, 0x0 ) |   // don't care
 144                    ( base_1, 0x0 ) |   // don't care
 145                    ( base_0, 0x0 ) );  // don't care
 146
 147 NOTE: while setting up the MMU, we run in a non-mapped mode in the DRAM (0x40
 148 segment) and need to setup the seg_4 to a unity mapping, so that we don't get
 149 a fault before we have had time to jump into the real kernel segment (0xc0). This
 150 is done in head.S temporarily, but fixed by the kernel later in paging_init.
 151
 152
 153 Paging - PTE's, PMD's and PGD's
 154 -------------------------------
 155
 156 [ References: asm/pgtable.h, asm/page.h, asm/mmu.h ]
 157
 158 The paging mechanism uses virtual addresses to split a process memory-space into
 159 pages, a page being the smallest unit that can be freely remapped in memory. On
 160 Linux/CRIS, a page is 8192 bytes (for technical reasons not equal to 4096 as in
 161 most other 32-bit architectures). It would be inefficient to let a virtual memory
 162 mapping be controlled by a long table of page mappings, so it is broken down into
 163 a 2-level structure with a Page Directory containing pointers to Page Tables which
 164 each have maps of up to 2048 pages (8192 / sizeof(void *)). Linux can actually
 165 handle 3-level structures as well, with a Page Middle Directory in between, but
 166 in many cases, this is folded into a two-level structure by excluding the Middle
 167 Directory.
 168
 169 We'll take a look at how an address is translated while we discuss how it's handled
 170 in the Linux kernel.
 171
 172 The example address is 0xd004000c; in binary this is:
 173
 174 31       23       15       7      0
 175 11010000 00000100 00000000 00001100
 176
 177 |______| |__________||____________|
 178   PGD        PTE       page offset
 179
 180 Given the top-level Page Directory, the offset in that directory is calculated
 181 using the upper 8 bits:
 182
 183 extern inline pgd_t * pgd_offset(struct mm_struct * mm, unsigned long address)
 184 {
 185         return mm->pgd + (address >> PGDIR_SHIFT);
 186 }
 187
 188 PGDIR_SHIFT is the log2 of the amount of memory an entry in the PGD can map; in our
 189 case it is 24, corresponding to 16 MB. This means that each entry in the PGD
 190 corresponds to 16 MB of virtual memory.
 191
 192 The pgd_t from our example will therefore be the 208'th (0xd0) entry in mm->pgd.
 193
 194 Since the Middle Directory does not exist, it is a unity mapping:
 195
 196 extern inline pmd_t * pmd_offset(pgd_t * dir, unsigned long address)
 197 {
 198         return (pmd_t *) dir;
 199 }
 200
 201 The Page Table provides the final lookup by using bits 13 to 23 as index:
 202
 203 extern inline pte_t * pte_offset(pmd_t * dir, unsigned long address)
 204 {
 205         return (pte_t *) pmd_page(*dir) + ((address >> PAGE_SHIFT) &
 206                                            (PTRS_PER_PTE - 1));
 207 }
 208
 209 PAGE_SHIFT is the log2 of the size of a page; 13 in our case. PTRS_PER_PTE is
 210 the number of pointers that fit in a Page Table and is used to mask off the
 211 PGD-part of the address.
 212
 213 The so-far unused bits 0 to 12 are used to index inside a page linearily.
 214
 215 The VM system
 216 -------------
 217
 218 The kernels own page-directory is the swapper_pg_dir, cleared in paging_init,
 219 and contains the kernels virtual mappings (the kernel itself is not paged - it
 220 is mapped linearily using kseg_c as described above). Architectures without
 221 kernel segments like the i386, need to setup swapper_pg_dir directly in head.S
 222 to map the kernel itself. swapper_pg_dir is pointed to by init_mm.pgd as the
 223 init-task's PGD.
 224
 225 To see what support functions are used to setup a page-table, let's look at the
 226 kernel's internal paged memory system, vmalloc/vfree.
 227
 228 void * vmalloc(unsigned long size)
 229
 230 The vmalloc-system keeps a paged segment in kernel-space at 0xd0000000. What
 231 happens first is that a virtual address chunk is allocated to the request using
 232 get_vm_area(size). After that, physical RAM pages are allocated and put into
 233 the kernel's page-table using alloc_area_pages(addr, size).
 234
 235 static int alloc_area_pages(unsigned long address, unsigned long size)
 236
 237 First the PGD entry is found using init_mm.pgd. This is passed to
 238 alloc_area_pmd (remember the 3->2 folding). It uses pte_alloc_kernel to
 239 check if the PGD entry points anywhere - if not, a page table page is
 240 allocated and the PGD entry updated. Then the alloc_area_pte function is
 241 used just like alloc_area_pmd to check which page table entry is desired,
 242 and a physical page is allocated and the table entry updated. All of this
 243 is repeated at the top-level until the entire address range specified has
 244 been mapped.
 245
 246
 247