Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

1 files changed, 135 insertions, 0 deletions

diff --git a/Documentation/arm/Porting b/Documentation/arm/Porting
new file mode 100644
index 00000000000..a492233931b
--- /dev/null
+++ b/Documentation/arm/Porting
@@ -0,0 +1,135 @@
+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.
+