|author||Linus Torvalds <firstname.lastname@example.org>||2005-04-16 15:20:36 -0700|
|committer||Linus Torvalds <email@example.com>||2005-04-16 15:20:36 -0700|
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!
Diffstat (limited to 'Documentation/powerpc/SBC8260_memory_mapping.txt')
1 files changed, 197 insertions, 0 deletions
diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt
new file mode 100644
@@ -0,0 +1,197 @@
+Please mail me (Jon Diekema, firstname.lastname@example.org or email@example.com)
+if you have questions, comments or corrections.
+ * EST SBC8260 Linux memory mapping rules
+ 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)
+ - 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 <firstname.lastname@example.org>
+ 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:
+ 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)
+ - 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 <email@example.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
+ Obviously the kernel can't map any physical addresses 1:1 in
+ these ranges.
+ Details from Dan Malek <firstname.lastname@example.org> 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:
+ Memory Sel Use
+ --------------------- --- ---------------------------------
+ 0xF0000000-0xF001FFFF n/a IMMR: dual port RAM, registers
+ DBAT1, IBAT1, cache inhibited: