모임 때 잠깐 언급되었던 메모리 맵에 대해 설명이 된 짧은 문서가 마침 눈에 띄어 긁어 올립니다.

출처는  

"커널 소스 디렉토리Documentationarmmemory.txt" 와  

"커널 소스 디렉토리DocumentationarmPorting" 입니다.

(폰트에 따라 정렬이 제대로 안 되어서 알아보기 힘들 수 있으니, 위의 문서를 직접 열어 보시는

게 좀 더 알아보기 편할 겁니다. )

(밑에 파일 첨부합니다.)

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

  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.  Free for other usage on non-XScale.

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.

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().

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------- 

Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html

Initial definitions
-------------------

The following symbol definitions rely on you knowing the translation that
__virt_to_phys() does for your machine.  This macro converts the passed
virtual address to a physical address.  Normally, it is simply:

  phys = virt - PAGE_OFFSET + PHYS_OFFSET

Decompressor Symbols
--------------------

ZTEXTADDR
 Start address of decompressor.  There's no point in talking about
 virtual or physical addresses here, since the MMU will be off at
 the time when you call the decompressor code.  You normally call
 the kernel at this address to start it booting.  This doesn't have
 to be located in RAM, it can be in flash or other read-only or
 read-write addressable medium.

ZBSSADDR
 Start address of zero-initialised work area for the decompressor.
 This must be pointing at RAM.  The decompressor will zero initialise
 this for you.  Again, the MMU will be off.

ZRELADDR
 This is the address where the decompressed kernel will be written,
 and eventually executed.  The following constraint must be valid:

  __virt_to_phys(TEXTADDR) == ZRELADDR

 The initial part of the kernel is carefully coded to be position
 independent.

INITRD_PHYS
 Physical address to place the initial RAM disk.  Only relevant if
 you are using the bootpImage stuff (which only works on the old
 struct param_struct).

INITRD_VIRT
 Virtual address of the initial RAM disk.  The following  constraint
 must be valid:

  __virt_to_phys(INITRD_VIRT) == INITRD_PHYS

PARAMS_PHYS
 Physical address of the struct param_struct or tag list, giving the
 kernel various parameters about its execution environment.

Kernel Symbols
--------------

PHYS_OFFSET
 Physical start address of the first bank of RAM.

PAGE_OFFSET
 Virtual start address of the first bank of RAM.  During the kernel
 boot phase, virtual address PAGE_OFFSET will be mapped to physical
 address PHYS_OFFSET, along with any other mappings you supply.
 This should be the same value as TASK_SIZE.

TASK_SIZE
 The maximum size of a user process in bytes.  Since user space
 always starts at zero, this is the maximum address that a user
 process can access+1.  The user space stack grows down from this
 address.

 Any virtual address below TASK_SIZE is deemed to be user process
 area, and therefore managed dynamically on a process by process
 basis by the kernel.  I'll call this the user segment.

 Anything above TASK_SIZE is common to all processes.  I'll call
 this the kernel segment.

 (In other words, you can't put IO mappings below TASK_SIZE, and
 hence PAGE_OFFSET).

TEXTADDR
 Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.
 This is where the kernel image ends up.  With the latest kernels,
 it must be located at 32768 bytes into a 128MB region.  Previous
 kernels placed a restriction of 256MB here.

DATAADDR
 Virtual address for the kernel data segment.  Must not be defined
 when using the decompressor.

VMALLOC_START
VMALLOC_END
 Virtual addresses bounding the vmalloc() area.  There must not be
 any static mappings in this area; vmalloc will overwrite them.
 The addresses must also be in the kernel segment (see above).
 Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the
 last virtual RAM address (found using variable high_memory).

VMALLOC_OFFSET
 Offset normally incorporated into VMALLOC_START to provide a hole
 between virtual RAM and the vmalloc area.  We do this to allow
 out of bounds memory accesses (eg, something writing off the end
 of the mapped memory map) to be caught.  Normally set to 8MB.

Architecture Specific Macros
----------------------------

BOOT_MEM(pram,pio,vio)
 `pram' specifies the physical start address of RAM.  Must always
 be present, and should be the same as PHYS_OFFSET.

 `pio' is the physical address of an 8MB region containing IO for
 use with the debugging macros in arch/arm/kernel/debug-armv.S.

 `vio' is the virtual address of the 8MB debugging region.

 It is expected that the debugging region will be re-initialised
 by the architecture specific code later in the code (via the
 MAPIO function).

BOOT_PARAMS
 Same as, and see PARAMS_PHYS.

FIXUP(func)
 Machine specific fixups, run before memory subsystems have been
 initialised.

MAPIO(func)
 Machine specific function to map IO areas (including the debug
 region above).

INITIRQ(func)
 Machine specific function to initialise interrupts.

--------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

끝