Documentation/powerpc/SBC8260_memory_mapping.txt

   1 Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
   2 if you have questions, comments or corrections.
   3
   4         * EST SBC8260 Linux memory mapping rules
   5
   6         http://www.estc.com/
   7         http://www.estc.com/products/boards/SBC8260-8240_ds.html
   8
   9         Initial conditions:
  10         -------------------
  11
  12         Tasks that need to be perform by the boot ROM before control is
  13         transferred to zImage (compressed Linux kernel):
  14
  15         - Define the IMMR to 0xf0000000
  16
  17         - Initialize the memory controller so that RAM is available at
  18           physical address 0x00000000.  On the SBC8260 is this 16M (64M)
  19           SDRAM.
  20
  21         - The boot ROM should only clear the RAM that it is using.
  22
  23           The reason for doing this is to enhances the chances of a
  24           successful post mortem on a Linux panic.  One of the first
  25           items to examine is the 16k (LOG_BUF_LEN) circular console
  26           buffer called log_buf which is defined in kernel/printk.c.
  27
  28         - To enhance boot ROM performance, the I-cache can be enabled.
  29
  30           Date: Mon, 22 May 2000 14:21:10 -0700
  31           From: Neil Russell <caret@c-side.com>
  32
  33           LiMon (LInux MONitor) runs with and starts Linux with MMU
  34           off, I-cache enabled, D-cache disabled.  The I-cache doesn't
  35           need hints from the MMU to work correctly as the D-cache
  36           does.  No D-cache means no special code to handle devices in
  37           the presence of cache (no snooping, etc). The use of the
  38           I-cache means that the monitor can run acceptably fast
  39           directly from ROM, rather than having to copy it to RAM.
  40
  41         - Build the board information structure (see
  42           include/asm-ppc/est8260.h for its definition)
  43
  44         - The compressed Linux kernel (zImage) contains a bootstrap loader
  45           that is position independent; you can load it into any RAM,
  46           ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
  47           at its link address of 0x00400000 (4 MB).
  48
  49           Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
  50                 then zImage will skip the step of moving itself to
  51                 its link address.
  52
  53         - Load R3 with the address of the board information structure
  54
  55         - Transfer control to zImage
  56
  57         - The Linux console port is SMC1, and the baud rate is controlled
  58           from the bi_baudrate field of the board information structure.
  59           On thing to keep in mind when picking the baud rate, is that
  60           there is no flow control on the SMC ports.  I would stick
  61           with something safe and standard like 19200.
  62
  63           On the EST SBC8260, the SMC1 port is on the COM1 connector of
  64           the board.
  65
  66
  67         EST SBC8260 defaults:
  68         ---------------------
  69
  70                                 Chip
  71         Memory                  Sel  Bus   Use
  72         ---------------------   ---  ---   ----------------------------------
  73         0x00000000-0x03FFFFFF   CS2  60x   (16M or 64M)/64M SDRAM
  74         0x04000000-0x04FFFFFF   CS4  local  4M/16M SDRAM (soldered to the board)
  75         0x21000000-0x21000000   CS7  60x    1B/64K Flash present detect (from the flash SIMM)
  76         0x21000001-0x21000001   CS7  60x    1B/64K Switches (read) and LEDs (write)
  77         0x22000000-0x2200FFFF   CS5  60x    8K/64K EEPROM
  78         0xFC000000-0xFCFFFFFF   CS6  60x    2M/16M flash (8 bits wide, soldered to the board)
  79         0xFE000000-0xFFFFFFFF   CS0  60x    4M/16M flash (SIMM)
  80
  81         Notes:
  82         ------
  83
  84         - The chip selects can map 32K blocks and up (powers of 2)
  85
  86         - The SDRAM machine can handled up to 128Mbytes per chip select
  87
  88         - Linux uses the 60x bus memory (the SDRAM DIMM) for the
  89           communications buffers.
  90
  91         - BATs can map 128K-256Mbytes each.  There are four data BATs and
  92           four instruction BATs.  Generally the data and instruction BATs
  93           are mapped the same.
  94
  95         - The IMMR must be set above the kernel virtual memory addresses,
  96           which start at 0xC0000000.  Otherwise, the kernel may crash as
  97           soon as you start any threads or processes due to VM collisions
  98           in the kernel or user process space.
  99
 100
 101           Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:
 102
 103           The user application virtual space consumes the first 2 Gbytes
 104           (0x00000000 to 0x7FFFFFFF).  The kernel virtual text starts at
 105           0xC0000000, with data following.  There is a "protection hole"
 106           between the end of kernel data and the start of the kernel
 107           dynamically allocated space, but this space is still within
 108           0xCxxxxxxx.
 109
 110           Obviously the kernel can't map any physical addresses 1:1 in
 111           these ranges.
 112
 113
 114           Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:
 115
 116           During the early kernel initialization, the kernel virtual
 117           memory allocator is not operational.  Prior to this KVM
 118           initialization, we choose to map virtual to physical addresses
 119           1:1.  That is, the kernel virtual address exactly matches the
 120           physical address on the bus.  These mappings are typically done
 121           in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c.  Only
 122           absolutely necessary mappings should be done at this time, for
 123           example board control registers or a serial uart.  Normal device
 124           driver initialization should map resources later when necessary.
 125
 126           Although platform dependent, and certainly the case for embedded
 127           8xx, traditionally memory is mapped at physical address zero,
 128           and I/O devices above physical address 0x80000000.  The lowest
 129           and highest (above 0xf0000000) I/O addresses are traditionally
 130           used for devices or registers we need to map during kernel
 131           initialization and prior to KVM operation.  For this reason,
 132           and since it followed prior PowerPC platform examples, I chose
 133           to map the embedded 8xx kernel to the 0xc0000000 virtual address.
 134           This way, we can enable the MMU to map the kernel for proper
 135           operation, and still map a few windows before the KVM is operational.
 136
 137           On some systems, you could possibly run the kernel at the
 138           0x80000000 or any other virtual address.  It just depends upon
 139           mapping that must be done prior to KVM operational.  You can never
 140           map devices or kernel spaces that overlap with the user virtual
 141           space.  This is why default IMMR mapping used by most BDM tools
 142           won't work.  They put the IMMR at something like 0x10000000 or
 143           0x02000000 for example.  You simply can't map these addresses early
 144           in the kernel, and continue proper system operation.
 145
 146           The embedded 8xx/82xx kernel is mature enough that all you should
 147           need to do is map the IMMR someplace at or above 0xf0000000 and it
 148           should boot far enough to get serial console messages and KGDB
 149           connected on any platform.  There are lots of other subtle memory
 150           management design features that you simply don't need to worry
 151           about.  If you are changing functions related to MMU initialization,
 152           you are likely breaking things that are known to work and are
 153           heading down a path of disaster and frustration.  Your changes
 154           should be to make the flexibility of the processor fit Linux,
 155           not force arbitrary and non-workable memory mappings into Linux.
 156
 157         - You don't want to change KERNELLOAD or KERNELBASE, otherwise the
 158           virtual memory and MMU code will get confused.
 159
 160           arch/ppc/Makefile:KERNELLOAD = 0xc0000000
 161
 162           include/asm-ppc/page.h:#define PAGE_OFFSET    0xc0000000
 163           include/asm-ppc/page.h:#define KERNELBASE     PAGE_OFFSET
 164
 165         - RAM is at physical address 0x00000000, and gets mapped to
 166           virtual address 0xC0000000 for the kernel.
 167
 168
 169         Physical addresses used by the Linux kernel:
 170         --------------------------------------------
 171
 172         0x00000000-0x3FFFFFFF   1GB reserved for RAM
 173         0xF0000000-0xF001FFFF   128K IMMR  64K used for dual port memory,
 174                                  64K for 8260 registers
 175
 176
 177         Logical addresses used by the Linux kernel:
 178         -------------------------------------------
 179
 180         0xF0000000-0xFFFFFFFF   256M BAT0 (IMMR: dual port RAM, registers)
 181         0xE0000000-0xEFFFFFFF   256M BAT1 (I/O space for custom boards)
 182         0xC0000000-0xCFFFFFFF   256M BAT2 (RAM)
 183         0xD0000000-0xDFFFFFFF   256M BAT3 (if RAM > 256MByte)
 184
 185
 186         EST SBC8260 Linux mapping:
 187         --------------------------
 188
 189         DBAT0, IBAT0, cache inhibited:
 190
 191                                 Chip
 192         Memory                  Sel  Use
 193         ---------------------   ---  ---------------------------------
 194         0xF0000000-0xF001FFFF   n/a  IMMR: dual port RAM, registers
 195
 196         DBAT1, IBAT1, cache inhibited:
 197