mirror of
				https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
				synced 2025-10-31 05:14:38 +00:00 
			
		
		
		
	 1dbd30e989
			
		
	
	
		1dbd30e989
		
	
	
	
	
		
			
			This changes the TCM handling so that a fixed area is reserved at 0xfffe0000-0xfffeffff for TCM. This areas is used by XScale but XScale does not have TCM so the mechanisms are mutually exclusive. This change is needed to make TCM detection more dynamic while still being able to compile code into it, and is a must for the unified ARM goals: the current TCM allocation at different places in memory for each machine would be a nightmare if you want to compile a single image for more than one machine with TCM so it has to be nailed down in one place. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
		
			
				
	
	
		
			94 lines
		
	
	
		
			3.2 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			94 lines
		
	
	
		
			3.2 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 		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.
 | |
| 
 | |
| fff00000	fffdffff	Fixmap mapping region.  Addresses provided
 | |
| 				by fix_to_virt() will be located here.
 | |
| 
 | |
| ffc00000	ffefffff	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.
 | |
| 
 | |
| 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().
 |