1 |
3 |
xianfeng |
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
|
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 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 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 |
|
|
|