1Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com) 2if 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 198