Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | Kernel Memory Layout on ARM Linux |
2 | ||
3 | Russell King <rmk@arm.linux.org.uk> | |
02b30839 | 4 | November 17, 2005 (2.6.15) |
1da177e4 LT |
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. | |
02b30839 RK |
40 | VMALLOC_END must be aligned to a 2MB |
41 | boundary. | |
1da177e4 LT |
42 | |
43 | VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. | |
44 | Memory returned by vmalloc/ioremap will | |
45 | be dynamically placed in this region. | |
46 | VMALLOC_START may be based upon the value | |
47 | of the high_memory variable. | |
48 | ||
49 | PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region. | |
50 | This maps the platforms RAM, and typically | |
51 | maps all platform RAM in a 1:1 relationship. | |
52 | ||
53 | TASK_SIZE PAGE_OFFSET-1 Kernel module space | |
54 | Kernel modules inserted via insmod are | |
55 | placed here using dynamic mappings. | |
56 | ||
57 | 00001000 TASK_SIZE-1 User space mappings | |
58 | Per-thread mappings are placed here via | |
59 | the mmap() system call. | |
60 | ||
61 | 00000000 00000fff CPU vector page / null pointer trap | |
62 | CPUs which do not support vector remapping | |
63 | place their vector page here. NULL pointer | |
64 | dereferences by both the kernel and user | |
65 | space are also caught via this mapping. | |
66 | ||
67 | Please note that mappings which collide with the above areas may result | |
68 | in a non-bootable kernel, or may cause the kernel to (eventually) panic | |
69 | at run time. | |
70 | ||
71 | Since future CPUs may impact the kernel mapping layout, user programs | |
72 | must not access any memory which is not mapped inside their 0x0001000 | |
73 | to TASK_SIZE address range. If they wish to access these areas, they | |
74 | must set up their own mappings using open() and mmap(). |