ia64/linux-2.6.18-xen.hg

annotate Documentation/arm/Porting @ 524:7f8b544237bf

netfront: Allow netfront in domain 0.

This is useful if your physical network device is in a utility domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Tue Apr 15 15:18:58 2008 +0100 (2008-04-15)
parents 831230e53067
children
rev   line source
ian@0 1 Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html
ian@0 2
ian@0 3 Initial definitions
ian@0 4 -------------------
ian@0 5
ian@0 6 The following symbol definitions rely on you knowing the translation that
ian@0 7 __virt_to_phys() does for your machine. This macro converts the passed
ian@0 8 virtual address to a physical address. Normally, it is simply:
ian@0 9
ian@0 10 phys = virt - PAGE_OFFSET + PHYS_OFFSET
ian@0 11
ian@0 12
ian@0 13 Decompressor Symbols
ian@0 14 --------------------
ian@0 15
ian@0 16 ZTEXTADDR
ian@0 17 Start address of decompressor. There's no point in talking about
ian@0 18 virtual or physical addresses here, since the MMU will be off at
ian@0 19 the time when you call the decompressor code. You normally call
ian@0 20 the kernel at this address to start it booting. This doesn't have
ian@0 21 to be located in RAM, it can be in flash or other read-only or
ian@0 22 read-write addressable medium.
ian@0 23
ian@0 24 ZBSSADDR
ian@0 25 Start address of zero-initialised work area for the decompressor.
ian@0 26 This must be pointing at RAM. The decompressor will zero initialise
ian@0 27 this for you. Again, the MMU will be off.
ian@0 28
ian@0 29 ZRELADDR
ian@0 30 This is the address where the decompressed kernel will be written,
ian@0 31 and eventually executed. The following constraint must be valid:
ian@0 32
ian@0 33 __virt_to_phys(TEXTADDR) == ZRELADDR
ian@0 34
ian@0 35 The initial part of the kernel is carefully coded to be position
ian@0 36 independent.
ian@0 37
ian@0 38 INITRD_PHYS
ian@0 39 Physical address to place the initial RAM disk. Only relevant if
ian@0 40 you are using the bootpImage stuff (which only works on the old
ian@0 41 struct param_struct).
ian@0 42
ian@0 43 INITRD_VIRT
ian@0 44 Virtual address of the initial RAM disk. The following constraint
ian@0 45 must be valid:
ian@0 46
ian@0 47 __virt_to_phys(INITRD_VIRT) == INITRD_PHYS
ian@0 48
ian@0 49 PARAMS_PHYS
ian@0 50 Physical address of the struct param_struct or tag list, giving the
ian@0 51 kernel various parameters about its execution environment.
ian@0 52
ian@0 53
ian@0 54 Kernel Symbols
ian@0 55 --------------
ian@0 56
ian@0 57 PHYS_OFFSET
ian@0 58 Physical start address of the first bank of RAM.
ian@0 59
ian@0 60 PAGE_OFFSET
ian@0 61 Virtual start address of the first bank of RAM. During the kernel
ian@0 62 boot phase, virtual address PAGE_OFFSET will be mapped to physical
ian@0 63 address PHYS_OFFSET, along with any other mappings you supply.
ian@0 64 This should be the same value as TASK_SIZE.
ian@0 65
ian@0 66 TASK_SIZE
ian@0 67 The maximum size of a user process in bytes. Since user space
ian@0 68 always starts at zero, this is the maximum address that a user
ian@0 69 process can access+1. The user space stack grows down from this
ian@0 70 address.
ian@0 71
ian@0 72 Any virtual address below TASK_SIZE is deemed to be user process
ian@0 73 area, and therefore managed dynamically on a process by process
ian@0 74 basis by the kernel. I'll call this the user segment.
ian@0 75
ian@0 76 Anything above TASK_SIZE is common to all processes. I'll call
ian@0 77 this the kernel segment.
ian@0 78
ian@0 79 (In other words, you can't put IO mappings below TASK_SIZE, and
ian@0 80 hence PAGE_OFFSET).
ian@0 81
ian@0 82 TEXTADDR
ian@0 83 Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.
ian@0 84 This is where the kernel image ends up. With the latest kernels,
ian@0 85 it must be located at 32768 bytes into a 128MB region. Previous
ian@0 86 kernels placed a restriction of 256MB here.
ian@0 87
ian@0 88 DATAADDR
ian@0 89 Virtual address for the kernel data segment. Must not be defined
ian@0 90 when using the decompressor.
ian@0 91
ian@0 92 VMALLOC_START
ian@0 93 VMALLOC_END
ian@0 94 Virtual addresses bounding the vmalloc() area. There must not be
ian@0 95 any static mappings in this area; vmalloc will overwrite them.
ian@0 96 The addresses must also be in the kernel segment (see above).
ian@0 97 Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the
ian@0 98 last virtual RAM address (found using variable high_memory).
ian@0 99
ian@0 100 VMALLOC_OFFSET
ian@0 101 Offset normally incorporated into VMALLOC_START to provide a hole
ian@0 102 between virtual RAM and the vmalloc area. We do this to allow
ian@0 103 out of bounds memory accesses (eg, something writing off the end
ian@0 104 of the mapped memory map) to be caught. Normally set to 8MB.
ian@0 105
ian@0 106 Architecture Specific Macros
ian@0 107 ----------------------------
ian@0 108
ian@0 109 BOOT_MEM(pram,pio,vio)
ian@0 110 `pram' specifies the physical start address of RAM. Must always
ian@0 111 be present, and should be the same as PHYS_OFFSET.
ian@0 112
ian@0 113 `pio' is the physical address of an 8MB region containing IO for
ian@0 114 use with the debugging macros in arch/arm/kernel/debug-armv.S.
ian@0 115
ian@0 116 `vio' is the virtual address of the 8MB debugging region.
ian@0 117
ian@0 118 It is expected that the debugging region will be re-initialised
ian@0 119 by the architecture specific code later in the code (via the
ian@0 120 MAPIO function).
ian@0 121
ian@0 122 BOOT_PARAMS
ian@0 123 Same as, and see PARAMS_PHYS.
ian@0 124
ian@0 125 FIXUP(func)
ian@0 126 Machine specific fixups, run before memory subsystems have been
ian@0 127 initialised.
ian@0 128
ian@0 129 MAPIO(func)
ian@0 130 Machine specific function to map IO areas (including the debug
ian@0 131 region above).
ian@0 132
ian@0 133 INITIRQ(func)
ian@0 134 Machine specific function to initialise interrupts.
ian@0 135