]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | Kernel Memory Layout on ARM Linux |
2 | ||
3 | Russell King <[email protected]> | |
4 | May 21, 2004 (2.6.6) | |
5 | ||
6 | This document describes the virtual memory layout which the Linux | |
7 | kernel uses for ARM processors. It indicates which regions are | |
8 | free for platforms to use, and which are used by generic code. | |
9 | ||
10 | The ARM CPU is capable of addressing a maximum of 4GB virtual memory | |
11 | space, and this must be shared between user space processes, the | |
12 | kernel, and hardware devices. | |
13 | ||
14 | As the ARM architecture matures, it becomes necessary to reserve | |
15 | certain regions of VM space for use for new facilities; therefore | |
16 | this document may reserve more VM space over time. | |
17 | ||
18 | Start End Use | |
19 | -------------------------------------------------------------------------- | |
20 | ffff8000 ffffffff copy_user_page / clear_user_page use. | |
21 | For SA11xx and Xscale, this is used to | |
22 | setup a minicache mapping. | |
23 | ||
24 | ffff1000 ffff7fff Reserved. | |
25 | Platforms must not use this address range. | |
26 | ||
27 | ffff0000 ffff0fff CPU vector page. | |
28 | The CPU vectors are mapped here if the | |
29 | CPU supports vector relocation (control | |
30 | register V bit.) | |
31 | ||
32 | ffc00000 fffeffff DMA memory mapping region. Memory returned | |
33 | by the dma_alloc_xxx functions will be | |
34 | dynamically mapped here. | |
35 | ||
36 | ff000000 ffbfffff Reserved for future expansion of DMA | |
37 | mapping region. | |
38 | ||
39 | VMALLOC_END feffffff Free for platform use, recommended. | |
40 | ||
41 | VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. | |
42 | Memory returned by vmalloc/ioremap will | |
43 | be dynamically placed in this region. | |
44 | VMALLOC_START may be based upon the value | |
45 | of the high_memory variable. | |
46 | ||
47 | PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region. | |
48 | This maps the platforms RAM, and typically | |
49 | maps all platform RAM in a 1:1 relationship. | |
50 | ||
51 | TASK_SIZE PAGE_OFFSET-1 Kernel module space | |
52 | Kernel modules inserted via insmod are | |
53 | placed here using dynamic mappings. | |
54 | ||
55 | 00001000 TASK_SIZE-1 User space mappings | |
56 | Per-thread mappings are placed here via | |
57 | the mmap() system call. | |
58 | ||
59 | 00000000 00000fff CPU vector page / null pointer trap | |
60 | CPUs which do not support vector remapping | |
61 | place their vector page here. NULL pointer | |
62 | dereferences by both the kernel and user | |
63 | space are also caught via this mapping. | |
64 | ||
65 | Please note that mappings which collide with the above areas may result | |
66 | in a non-bootable kernel, or may cause the kernel to (eventually) panic | |
67 | at run time. | |
68 | ||
69 | Since future CPUs may impact the kernel mapping layout, user programs | |
70 | must not access any memory which is not mapped inside their 0x0001000 | |
71 | to TASK_SIZE address range. If they wish to access these areas, they | |
72 | must set up their own mappings using open() and mmap(). |