Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | Kernel Memory Layout on ARM Linux |
| 2 | |
| 3 | Russell King <rmk@arm.linux.org.uk> |
Russell King | 02b3083 | 2005-11-17 22:43:30 +0000 | [diff] [blame] | 4 | November 17, 2005 (2.6.15) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |
Linus Walleij | e624859 | 2009-07-27 22:11:59 +0100 | [diff] [blame] | 24 | ffff4000 ffffffff cache aliasing on ARMv6 and later CPUs. |
| 25 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 26 | ffff1000 ffff7fff Reserved. |
| 27 | Platforms must not use this address range. |
| 28 | |
| 29 | ffff0000 ffff0fff CPU vector page. |
| 30 | The CPU vectors are mapped here if the |
| 31 | CPU supports vector relocation (control |
| 32 | register V bit.) |
| 33 | |
Nicolas Pitre | 5f0fbf9 | 2008-09-16 13:05:53 -0400 | [diff] [blame] | 34 | fffe0000 fffeffff XScale cache flush area. This is used |
| 35 | in proc-xscale.S to flush the whole data |
Linus Walleij | 1dbd30e | 2010-07-12 21:53:28 +0100 | [diff] [blame] | 36 | cache. (XScale does not have TCM.) |
| 37 | |
| 38 | fffe8000 fffeffff DTCM mapping area for platforms with |
| 39 | DTCM mounted inside the CPU. |
| 40 | |
| 41 | fffe0000 fffe7fff ITCM mapping area for platforms with |
| 42 | ITCM mounted inside the CPU. |
Nicolas Pitre | 5f0fbf9 | 2008-09-16 13:05:53 -0400 | [diff] [blame] | 43 | |
Rob Herring | 836a241 | 2014-07-02 02:01:15 -0500 | [diff] [blame] | 44 | ffc00000 ffefffff Fixmap mapping region. Addresses provided |
Nicolas Pitre | 5f0fbf9 | 2008-09-16 13:05:53 -0400 | [diff] [blame] | 45 | by fix_to_virt() will be located here. |
| 46 | |
Rob Herring | c279443 | 2012-02-29 18:10:58 -0600 | [diff] [blame] | 47 | fee00000 feffffff Mapping of PCI I/O space. This is a static |
| 48 | mapping within the vmalloc space. |
| 49 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 50 | VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. |
| 51 | Memory returned by vmalloc/ioremap will |
| 52 | be dynamically placed in this region. |
Nicolas Pitre | 0536bdf | 2011-08-25 00:35:59 -0400 | [diff] [blame] | 53 | Machine specific static mappings are also |
| 54 | located here through iotable_init(). |
| 55 | VMALLOC_START is based upon the value |
| 56 | of the high_memory variable, and VMALLOC_END |
Nicolas Pitre | 6ff0966 | 2015-09-13 03:25:26 +0100 | [diff] [blame] | 57 | is equal to 0xff800000. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 58 | |
| 59 | PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region. |
| 60 | This maps the platforms RAM, and typically |
| 61 | maps all platform RAM in a 1:1 relationship. |
| 62 | |
Fenkart/Bostandzhyan | 18fe1ca | 2010-02-07 21:48:38 +0100 | [diff] [blame] | 63 | PKMAP_BASE PAGE_OFFSET-1 Permanent kernel mappings |
| 64 | One way of mapping HIGHMEM pages into kernel |
| 65 | space. |
| 66 | |
| 67 | MODULES_VADDR MODULES_END-1 Kernel module space |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 68 | Kernel modules inserted via insmod are |
| 69 | placed here using dynamic mappings. |
| 70 | |
| 71 | 00001000 TASK_SIZE-1 User space mappings |
| 72 | Per-thread mappings are placed here via |
| 73 | the mmap() system call. |
| 74 | |
| 75 | 00000000 00000fff CPU vector page / null pointer trap |
| 76 | CPUs which do not support vector remapping |
| 77 | place their vector page here. NULL pointer |
| 78 | dereferences by both the kernel and user |
| 79 | space are also caught via this mapping. |
| 80 | |
| 81 | Please note that mappings which collide with the above areas may result |
| 82 | in a non-bootable kernel, or may cause the kernel to (eventually) panic |
| 83 | at run time. |
| 84 | |
| 85 | Since future CPUs may impact the kernel mapping layout, user programs |
| 86 | must not access any memory which is not mapped inside their 0x0001000 |
| 87 | to TASK_SIZE address range. If they wish to access these areas, they |
| 88 | must set up their own mappings using open() and mmap(). |