]> nv-tegra.nvidia Code Review - linux-2.6.git/commitdiff
Documentation: remove old sbc8260 board specific information
authorPaul Gortmaker <paul.gortmaker@windriver.com>
Mon, 28 Jul 2008 18:50:31 +0000 (14:50 -0400)
committerKumar Gala <galak@kernel.crashing.org>
Mon, 28 Jul 2008 19:24:40 +0000 (14:24 -0500)
This file contains 8 yr. old board specific information that was for
the now gone ppc implementation, and it pre-dates widespread u-boot
support.  Any of the technical details of the board memory map would be
more appropriately captured in a dts if I revive it as powerpc anyway.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Documentation/powerpc/SBC8260_memory_mapping.txt [deleted file]

index 3be84aa38dfe11fdeb544b76956ac4c01bfb0892..29d839ce7327a01ad8ba24437b8840dcf9b70919 100644 (file)
@@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt
        - MPC5200 Device Tree Bindings
        - info about the Linux/PPC /proc/ppc_htab entry
        - MPC5200 Device Tree Bindings
        - info about the Linux/PPC /proc/ppc_htab entry
-       - EST SBC8260 board info
        - use and state info about Linux/PPC on MP machines
        - use and state info about Linux/PPC on MP machines
diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt
deleted file mode 100644 (file)
index e6e9ee0..0000000
+++ /dev/null
@@ -1,197 +0,0 @@
-Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
-if you have questions, comments or corrections.
-       * EST SBC8260 Linux memory mapping rules
-       http://www.estc.com/ 
-       http://www.estc.com/products/boards/SBC8260-8240_ds.html
-       Initial conditions:
-       -------------------
-       Tasks that need to be perform by the boot ROM before control is
-       transferred to zImage (compressed Linux kernel):
-       - Define the IMMR to 0xf0000000
-       - Initialize the memory controller so that RAM is available at
-         physical address 0x00000000.  On the SBC8260 is this 16M (64M)
-         SDRAM.
-       - The boot ROM should only clear the RAM that it is using.
-         The reason for doing this is to enhances the chances of a
-         successful post mortem on a Linux panic.  One of the first
-         items to examine is the 16k (LOG_BUF_LEN) circular console
-         buffer called log_buf which is defined in kernel/printk.c.
-       - To enhance boot ROM performance, the I-cache can be enabled.
-         Date: Mon, 22 May 2000 14:21:10 -0700
-         From: Neil Russell <caret@c-side.com>
-         LiMon (LInux MONitor) runs with and starts Linux with MMU
-         off, I-cache enabled, D-cache disabled.  The I-cache doesn't
-         need hints from the MMU to work correctly as the D-cache
-         does.  No D-cache means no special code to handle devices in
-         the presence of cache (no snooping, etc). The use of the
-         I-cache means that the monitor can run acceptably fast
-         directly from ROM, rather than having to copy it to RAM.
-       - Build the board information structure (see 
-         include/asm-ppc/est8260.h for its definition)
-       - The compressed Linux kernel (zImage) contains a bootstrap loader 
-         that is position independent; you can load it into any RAM, 
-         ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
-         at its link address of 0x00400000 (4 MB).
-         Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
-               then zImage will skip the step of moving itself to 
-               its link address.
-       - Load R3 with the address of the board information structure
-       - Transfer control to zImage
-       - The Linux console port is SMC1, and the baud rate is controlled
-         from the bi_baudrate field of the board information structure.
-         On thing to keep in mind when picking the baud rate, is that
-         there is no flow control on the SMC ports.  I would stick
-         with something safe and standard like 19200.
-         On the EST SBC8260, the SMC1 port is on the COM1 connector of
-         the board.
-       EST SBC8260 defaults:
-       ---------------------
-                                Chip
-        Memory                  Sel  Bus   Use
-        ---------------------   ---  ---   ----------------------------------
-       0x00000000-0x03FFFFFF   CS2  60x   (16M or 64M)/64M SDRAM
-       0x04000000-0x04FFFFFF   CS4  local  4M/16M SDRAM (soldered to the board)
-       0x21000000-0x21000000   CS7  60x    1B/64K Flash present detect (from the flash SIMM)
-       0x21000001-0x21000001   CS7  60x    1B/64K Switches (read) and LEDs (write)
-       0x22000000-0x2200FFFF   CS5  60x    8K/64K EEPROM
-       0xFC000000-0xFCFFFFFF   CS6  60x    2M/16M flash (8 bits wide, soldered to the board)
-       0xFE000000-0xFFFFFFFF   CS0  60x    4M/16M flash (SIMM)
-       Notes:
-       ------
-       - The chip selects can map 32K blocks and up (powers of 2)
-       - The SDRAM machine can handled up to 128Mbytes per chip select
-       - Linux uses the 60x bus memory (the SDRAM DIMM) for the 
-         communications buffers.
-       - BATs can map 128K-256Mbytes each.  There are four data BATs and
-         four instruction BATs.  Generally the data and instruction BATs
-         are mapped the same.
-       - The IMMR must be set above the kernel virtual memory addresses,
-         which start at 0xC0000000.  Otherwise, the kernel may crash as
-         soon as you start any threads or processes due to VM collisions 
-         in the kernel or user process space.
-         Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:
-         The user application virtual space consumes the first 2 Gbytes
-         (0x00000000 to 0x7FFFFFFF).  The kernel virtual text starts at
-         0xC0000000, with data following.  There is a "protection hole"
-         between the end of kernel data and the start of the kernel
-         dynamically allocated space, but this space is still within
-         0xCxxxxxxx.
-         Obviously the kernel can't map any physical addresses 1:1 in
-         these ranges.
-         Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:
-         During the early kernel initialization, the kernel virtual
-         memory allocator is not operational.  Prior to this KVM
-         initialization, we choose to map virtual to physical addresses
-         1:1.  That is, the kernel virtual address exactly matches the
-         physical address on the bus.  These mappings are typically done
-         in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c.  Only
-         absolutely necessary mappings should be done at this time, for
-         example board control registers or a serial uart.  Normal device
-         driver initialization should map resources later when necessary.
-         Although platform dependent, and certainly the case for embedded
-         8xx, traditionally memory is mapped at physical address zero,
-         and I/O devices above physical address 0x80000000.  The lowest
-         and highest (above 0xf0000000) I/O addresses are traditionally 
-         used for devices or registers we need to map during kernel 
-         initialization and prior to KVM operation.  For this reason, 
-         and since it followed prior PowerPC platform examples, I chose 
-         to map the embedded 8xx kernel to the 0xc0000000 virtual address.
-         This way, we can enable the MMU to map the kernel for proper 
-         operation, and still map a few windows before the KVM is operational.
-         On some systems, you could possibly run the kernel at the 
-         0x80000000 or any other virtual address.  It just depends upon 
-         mapping that must be done prior to KVM operational.  You can never 
-         map devices or kernel spaces that overlap with the user virtual 
-         space.  This is why default IMMR mapping used by most BDM tools 
-         won't work.  They put the IMMR at something like 0x10000000 or 
-         0x02000000 for example.  You simply can't map these addresses early
-         in the kernel, and continue proper system operation.
-         The embedded 8xx/82xx kernel is mature enough that all you should 
-         need to do is map the IMMR someplace at or above 0xf0000000 and it 
-         should boot far enough to get serial console messages and KGDB 
-         connected on any platform.  There are lots of other subtle memory 
-         management design features that you simply don't need to worry 
-         about.  If you are changing functions related to MMU initialization,
-         you are likely breaking things that are known to work and are 
-         heading down a path of disaster and frustration.  Your changes 
-         should be to make the flexibility of the processor fit Linux, 
-         not force arbitrary and non-workable memory mappings into Linux.
-       - You don't want to change KERNELLOAD or KERNELBASE, otherwise the
-         virtual memory and MMU code will get confused.
-         arch/ppc/Makefile:KERNELLOAD = 0xc0000000
-         include/asm-ppc/page.h:#define PAGE_OFFSET    0xc0000000
-         include/asm-ppc/page.h:#define KERNELBASE     PAGE_OFFSET
-       - RAM is at physical address 0x00000000, and gets mapped to 
-         virtual address 0xC0000000 for the kernel.
-       Physical addresses used by the Linux kernel:
-       --------------------------------------------
-       0x00000000-0x3FFFFFFF   1GB reserved for RAM
-       0xF0000000-0xF001FFFF   128K IMMR  64K used for dual port memory,
-                                 64K for 8260 registers
-        Logical addresses used by the Linux kernel:
-       -------------------------------------------
-       0xF0000000-0xFFFFFFFF   256M BAT0 (IMMR: dual port RAM, registers)
-       0xE0000000-0xEFFFFFFF   256M BAT1 (I/O space for custom boards)
-       0xC0000000-0xCFFFFFFF   256M BAT2 (RAM)
-       0xD0000000-0xDFFFFFFF   256M BAT3 (if RAM > 256MByte)
-       EST SBC8260 Linux mapping:
-       --------------------------
-       DBAT0, IBAT0, cache inhibited:
-                                Chip
-        Memory                  Sel  Use
-        ---------------------   ---  ---------------------------------
-        0xF0000000-0xF001FFFF   n/a  IMMR: dual port RAM, registers
-        DBAT1, IBAT1, cache inhibited: