patch-2.4.0-test2 linux/Documentation/powerpc/SBC8260_memory_mapping.txt

• Lines: 198
• Date: Mon Jun 19 17:59:35 2000
• Orig file: v2.4.0-test1/linux/Documentation/powerpc/SBC8260_memory_mapping.txt
• Orig date: Wed Dec 31 16:00:00 1969

diff -u --recursive --new-file v2.4.0-test1/linux/Documentation/powerpc/SBC8260_memory_mapping.txt linux/Documentation/powerpc/SBC8260_memory_mapping.txt
@@ -0,0 +1,197 @@
+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 phsical 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:
+