|  | 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. | 
|  |  | 
|  | 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.) | 
|  |  | 
|  | ffc00000	fffeffff	DMA memory mapping region.  Memory returned | 
|  | by the dma_alloc_xxx functions will be | 
|  | dynamically mapped here. | 
|  |  | 
|  | ff000000	ffbfffff	Reserved for future expansion of DMA | 
|  | mapping region. | 
|  |  | 
|  | VMALLOC_END	feffffff	Free for platform use, recommended. | 
|  | VMALLOC_END must be aligned to a 2MB | 
|  | boundary. | 
|  |  | 
|  | VMALLOC_START	VMALLOC_END-1	vmalloc() / ioremap() space. | 
|  | Memory returned by vmalloc/ioremap will | 
|  | be dynamically placed in this region. | 
|  | VMALLOC_START may be based upon the value | 
|  | of the high_memory variable. | 
|  |  | 
|  | 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. | 
|  |  | 
|  | TASK_SIZE	PAGE_OFFSET-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(). |