| ================================= | |
| Kernel Memory Layout on ARM Linux | |
| ================================= | |
| Russell King <rmk@arm.linux.org.uk> | |
| November 17, 2005 (2.6.15) | |
| This document describes the virtual memory layout which the Linux | |
| kernel uses for ARM processors. It indicates which regions are | |
| free for platforms to use, and which are used by generic code. | |
| The ARM CPU is capable of addressing a maximum of 4GB virtual memory | |
| space, and this must be shared between user space processes, the | |
| kernel, and hardware devices. | |
| As the ARM architecture matures, it becomes necessary to reserve | |
| certain regions of VM space for use for new facilities; therefore | |
| this document may reserve more VM space over time. | |
| =============== =============== =============================================== | |
| Start End Use | |
| =============== =============== =============================================== | |
| ffff8000 ffffffff copy_user_page / clear_user_page use. | |
| For SA11xx and Xscale, this is used to | |
| setup a minicache mapping. | |
| ffff4000 ffffffff cache aliasing on ARMv6 and later CPUs. | |
| ffff1000 ffff7fff Reserved. | |
| Platforms must not use this address range. | |
| ffff0000 ffff0fff CPU vector page. | |
| The CPU vectors are mapped here if the | |
| CPU supports vector relocation (control | |
| register V bit.) | |
| fffe0000 fffeffff XScale cache flush area. This is used | |
| in proc-xscale.S to flush the whole data | |
| cache. (XScale does not have TCM.) | |
| fffe8000 fffeffff DTCM mapping area for platforms with | |
| DTCM mounted inside the CPU. | |
| fffe0000 fffe7fff ITCM mapping area for platforms with | |
| ITCM mounted inside the CPU. | |
| ffc00000 ffefffff Fixmap mapping region. Addresses provided | |
| by fix_to_virt() will be located here. | |
| fee00000 feffffff Mapping of PCI I/O space. This is a static | |
| mapping within the vmalloc space. | |
| VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. | |
| Memory returned by vmalloc/ioremap will | |
| be dynamically placed in this region. | |
| Machine specific static mappings are also | |
| located here through iotable_init(). | |
| VMALLOC_START is based upon the value | |
| of the high_memory variable, and VMALLOC_END | |
| is equal to 0xff800000. | |
| PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region. | |
| This maps the platforms RAM, and typically | |
| maps all platform RAM in a 1:1 relationship. | |
| PKMAP_BASE PAGE_OFFSET-1 Permanent kernel mappings | |
| One way of mapping HIGHMEM pages into kernel | |
| space. | |
| MODULES_VADDR MODULES_END-1 Kernel module space | |
| Kernel modules inserted via insmod are | |
| placed here using dynamic mappings. | |
| 00001000 TASK_SIZE-1 User space mappings | |
| Per-thread mappings are placed here via | |
| the mmap() system call. | |
| 00000000 00000fff CPU vector page / null pointer trap | |
| CPUs which do not support vector remapping | |
| place their vector page here. NULL pointer | |
| dereferences by both the kernel and user | |
| space are also caught via this mapping. | |
| =============== =============== =============================================== | |
| Please note that mappings which collide with the above areas may result | |
| in a non-bootable kernel, or may cause the kernel to (eventually) panic | |
| at run time. | |
| Since future CPUs may impact the kernel mapping layout, user programs | |
| must not access any memory which is not mapped inside their 0x0001000 | |
| to TASK_SIZE address range. If they wish to access these areas, they | |
| must set up their own mappings using open() and mmap(). |