diff options
-rw-r--r-- | Documentation/powerpc/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/powerpc/SBC8260_memory_mapping.txt | 197 |
2 files changed, 0 insertions, 199 deletions
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 3be84aa38dfe..29d839ce7327 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX | |||
@@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt | |||
20 | - MPC5200 Device Tree Bindings | 20 | - MPC5200 Device Tree Bindings |
21 | ppc_htab.txt | 21 | ppc_htab.txt |
22 | - info about the Linux/PPC /proc/ppc_htab entry | 22 | - info about the Linux/PPC /proc/ppc_htab entry |
23 | SBC8260_memory_mapping.txt | ||
24 | - EST SBC8260 board info | ||
25 | smp.txt | 23 | smp.txt |
26 | - use and state info about Linux/PPC on MP machines | 24 | - use and state info about Linux/PPC on MP machines |
27 | sound.txt | 25 | sound.txt |
diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt deleted file mode 100644 index e6e9ee0506c3..000000000000 --- a/Documentation/powerpc/SBC8260_memory_mapping.txt +++ /dev/null | |||
@@ -1,197 +0,0 @@ | |||
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 | |||