1 |
27 |
unneback |
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
11 |
|
|
|
12 |
|
|
|
13 |
|
|
|
14 |
|
|
|
15 |
|
|
|
16 |
|
|
|
17 |
|
|
|
18 |
|
|
|
19 |
|
|
|
20 |
|
|
|
21 |
|
|
|
22 |
|
|
|
23 |
|
|
|
24 |
|
|
|
25 |
|
|
|
26 |
|
|
|
27 |
|
|
|
28 |
|
|
|
29 |
|
|
|
30 |
|
|
|
31 |
|
|
|
32 |
|
|
|
33 |
|
|
Rebuilding RedBoot
|
34 |
|
|
|
35 |
|
|
Introduction
|
36 |
|
|
rebuilding RedBoot
|
37 |
|
|
RedBootrebuilding
|
38 |
|
|
RedBoot is built as an application on top of eCos. The makefile rules
|
39 |
|
|
for building RedBoot are part of the eCos CDL package, so it's
|
40 |
|
|
possible to build eCos from the Configuration
|
41 |
|
|
Tool, as well as from the command line using
|
42 |
|
|
ecosconfig.
|
43 |
|
|
|
44 |
|
|
Building RedBoot requires only a few steps: selecting the
|
45 |
|
|
platform and the RedBoot template, importing a platform specific
|
46 |
|
|
configuration file, and finally starting the build.
|
47 |
|
|
|
48 |
|
|
The platform specific configuration file makes sure the settings
|
49 |
|
|
are correct for building RedBoot on the given platform. Each platform
|
50 |
|
|
should provide at least two of these configuration files:
|
51 |
|
|
redboot_RAM.ecm for a RAM mode RedBoot
|
52 |
|
|
configuration and redboot_ROM.ecm or
|
53 |
|
|
redboot_ROMRAM.ecm for a ROM or ROMRAM mode
|
54 |
|
|
RedBoot configuration. There may be additional
|
55 |
|
|
configuration files according to the requirements of the particular
|
56 |
|
|
platform.
|
57 |
|
|
|
58 |
|
|
The RedBoot build process results in a number of files in the
|
59 |
|
|
install bin directory. The ELF
|
60 |
|
|
file redboot.elf is the pricipal
|
61 |
|
|
result. Depending on the platform CDL, there will also be generated
|
62 |
|
|
versions of RedBoot in other file formats, such as
|
63 |
|
|
redboot.bin (binary format, good when doing an
|
64 |
|
|
update of a primary RedBoot image, see
|
65 |
|
|
linkend="update-primary-image">), redboot.srec
|
66 |
|
|
(Motorola S-record format, good when downloading a RAM mode image for
|
67 |
|
|
execution), and redboot.img (stripped ELF format,
|
68 |
|
|
good when downloading a RAM mode image for execution, smaller than the
|
69 |
|
|
.srec file). Some platforms may provide additional file formats and
|
70 |
|
|
also relocate some of these files to a
|
71 |
|
|
particular address making them more suitable for downloading using a
|
72 |
|
|
different boot monitor or flash programming tools.
|
73 |
|
|
|
74 |
|
|
The platform specific information in
|
75 |
|
|
linkend="Installation-and-Testing"> should be consulted, as there may
|
76 |
|
|
be other special instructions required to build RedBoot for particular
|
77 |
|
|
platforms.
|
78 |
|
|
|
79 |
|
|
|
80 |
|
|
Rebuilding RedBoot using ecosconfig
|
81 |
|
|
|
82 |
|
|
To rebuild RedBoot using the
|
83 |
|
|
ecosconfig tool, create a temporary
|
84 |
|
|
directory for building RedBoot, name it according to the desired
|
85 |
|
|
configuration of RedBoot, here RAM:
|
86 |
|
|
|
87 |
|
|
$ mkdir /tmp/redboot_RAM
|
88 |
|
|
$ cd /tmp/redboot_RAM
|
89 |
|
|
|
90 |
|
|
|
91 |
|
|
|
92 |
|
|
Create the build tree according to the chosen platform, here
|
93 |
|
|
using the Hitachi Solution Engine 7751 board as
|
94 |
|
|
an example:
|
95 |
|
|
It is assumed that the environment variable
|
96 |
|
|
ECOS_REPOSITORY points to the eCos/RedBoot source tree.
|
97 |
|
|
|
98 |
|
|
$ ecosconfig new se7751 redboot
|
99 |
|
|
U CYGPKG_HAL_SH_7750, new inferred value 0
|
100 |
|
|
U CYGPKG_HAL_SH_7751, new inferred value 1
|
101 |
|
|
U CYGHWR_HAL_SH_IRQ_USE_IRQLVL, new inferred value 1
|
102 |
|
|
U CYGSEM_HAL_USE_ROM_MONITOR, new inferred value 0
|
103 |
|
|
U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM, new inferred value 0
|
104 |
|
|
U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1
|
105 |
|
|
U CYGFUN_LIBC_STRING_BSD_FUNCS, new inferred value 0
|
106 |
|
|
U CYGPKG_NS_DNS_BUILD, new inferred value 0
|
107 |
|
|
|
108 |
|
|
Replace the platform name ("se7751") with the appropriate name for the
|
109 |
|
|
chosen platform.
|
110 |
|
|
|
111 |
|
|
|
112 |
|
|
Then import the appropriate platform RedBoot configuration file,
|
113 |
|
|
here for RAM configuration:
|
114 |
|
|
|
115 |
|
|
$ ecosconfig import ${ECOS_REPOSITORY}/hal/sh/se7751/VERSION/misc/redboot_RAM.ecm
|
116 |
|
|
$ ecosconfig tree
|
117 |
|
|
|
118 |
|
|
Replace architecture ("sh"), platform ("se7751") and version
|
119 |
|
|
("VERSION") with those appropriate for the
|
120 |
|
|
chosen platform and the version number of its HAL package. Also
|
121 |
|
|
replace the configuration name ("redboot_RAM.ecm") with that of the
|
122 |
|
|
appropriate configuration file.
|
123 |
|
|
|
124 |
|
|
|
125 |
|
|
RedBoot can now be built:
|
126 |
|
|
|
127 |
|
|
$ make
|
128 |
|
|
|
129 |
|
|
|
130 |
|
|
|
131 |
|
|
The resulting RedBoot files will be in the associated
|
132 |
|
|
install directory, in this example,
|
133 |
|
|
class="directory">./install/bin.
|
134 |
|
|
|
135 |
|
|
In each platform's
|
136 |
|
|
details are described in the form of shell variables. Using those,
|
137 |
|
|
the steps to build RedBoot are:
|
138 |
|
|
|
139 |
|
|
export REDBOOT_CFG=redboot_ROM
|
140 |
|
|
export VERSION=VERSION
|
141 |
|
|
mkdir /tmp/${REDBOOT_CFG}
|
142 |
|
|
cd /tmp/${REDBOOT_CFG}
|
143 |
|
|
ecosconfig new ${TARGET} redboot
|
144 |
|
|
ecosconfig import ${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm
|
145 |
|
|
ecosconfig tree
|
146 |
|
|
make
|
147 |
|
|
|
148 |
|
|
To build for another configuration, simply change the
|
149 |
|
|
REDBOOT_CFG definition accordingly. Also
|
150 |
|
|
make sure the VERSION variable matches the
|
151 |
|
|
version of the platform package.
|
152 |
|
|
|
153 |
|
|
|
154 |
|
|
|
155 |
|
|
|
156 |
|
|
|
157 |
|
|
Rebuilding RedBoot from the Configuration Tool
|
158 |
|
|
|
159 |
|
|
To rebuild RedBoot from the Configuration
|
160 |
|
|
Tool, open the template window (Build->Templates) and
|
161 |
|
|
select the appropriate Hardware target and in Packages select
|
162 |
|
|
"redboot". Then press OK. Depending on the platform, a number of
|
163 |
|
|
conflicts may need to be resolved before the build can be started;
|
164 |
|
|
select "Continue".
|
165 |
|
|
|
166 |
|
|
Import the desired RedBoot configuration file from the platform HAL
|
167 |
|
|
(File->Import...). Depending on the platform, a number of
|
168 |
|
|
conflicts may need to be resolved before the build can be started;
|
169 |
|
|
select "Continue". For example, if the platform selected is Hitachi
|
170 |
|
|
SE7751 board and the RAM configuration RedBoot should be built, import
|
171 |
|
|
the file
|
172 |
|
|
hal/sh/se7751/VERSION/misc/redboot_RAM.ecm.
|
173 |
|
|
|
174 |
|
|
Save the configuration somewhere suitable with enough disk space
|
175 |
|
|
for building RedBoot (File->Save...). Choose the name according to
|
176 |
|
|
the RedBoot configuration, for example
|
177 |
|
|
redboot_RAM.ecc.
|
178 |
|
|
|
179 |
|
|
Then start the build (Build->Library) and wait for it to
|
180 |
|
|
complete. The resulting RedBoot files will be in the associated
|
181 |
|
|
install directory, for the example this would be
|
182 |
|
|
class="directory">redboot_RAM_install/bin.
|
183 |
|
|
|
184 |
|
|
As noted above, each platform's details are described in
|
185 |
|
|
linkend="Installation-and-Testing">. Use the information provided in
|
186 |
|
|
the shell variables to find the configuration file - the path to it is
|
187 |
|
|
${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm,
|
188 |
|
|
where ECOS_REPOSITORY points to the
|
189 |
|
|
eCos/RedBoot sources, VERSION is the
|
190 |
|
|
version of the package (usually "current") and
|
191 |
|
|
REDBOOT_CFG is the desired configuration,
|
192 |
|
|
e.g. redboot_RAM.
|
193 |
|
|
|
194 |
|
|
|
195 |
|
|
|
196 |
|
|
|
197 |
|
|
Updating RedBoot
|
198 |
|
|
|
199 |
|
|
Introduction
|
200 |
|
|
updating
|
201 |
|
|
RedBoot
|
202 |
|
|
RedBootupdatingRedBoot
|
203 |
|
|
normally resides in an EPROM or, more common these days, a flash
|
204 |
|
|
on the board. In the former case, updating RedBoot necessitates
|
205 |
|
|
physically removing the part and
|
206 |
|
|
reprogramming a new RedBoot image into it using prommer hardware. In
|
207 |
|
|
the latter case, it is often possible to update RedBoot in situ using
|
208 |
|
|
Redboot's flash management commands.
|
209 |
|
|
|
210 |
|
|
The process of updating RedBoot in situ is documented in this
|
211 |
|
|
section. For this process, it is assumed that the target is connected
|
212 |
|
|
to a host system and that there is a serial connection giving access
|
213 |
|
|
to the RedBoot CLI. For platforms with a ROMRAM mode RedBoot, skip to
|
214 |
|
|
.
|
215 |
|
|
|
216 |
|
|
The addresses and sizes included in the below are examples
|
217 |
|
|
only, and will differ from those you will see. This is normal and
|
218 |
|
|
should not cause concern.
|
219 |
|
|
|
220 |
|
|
|
221 |
|
|
Load and start a RedBoot RAM instance
|
222 |
|
|
There are a number of choices here. The basic case is where a RAM
|
223 |
|
|
mode image has been stored in the FIS (flash Image System). To load and
|
224 |
|
|
execute this image, use the commands:
|
225 |
|
|
RedBoot> fis load RedBoot[RAM]
|
226 |
|
|
RedBoot> go
|
227 |
|
|
If this image is not available, or does not work,
|
228 |
|
|
then an alternate RAM mode image must be loaded:
|
229 |
|
|
|
230 |
|
|
RedBoot> load redboot_RAM.img
|
231 |
|
|
Entry point: 0x060213c0, address range: 0x06020000-0x060369c8
|
232 |
|
|
RedBoot> go
|
233 |
|
|
|
234 |
|
|
|
235 |
|
|
This command loads the RedBoot image using the TFTP
|
236 |
|
|
protocol via a network connection. Other methods of loading are
|
237 |
|
|
available, refer to the
|
238 |
|
|
linkend="download-command">load command for more
|
239 |
|
|
details.
|
240 |
|
|
|
241 |
|
|
If you expect to be doing this more than once, it is a
|
242 |
|
|
good idea to program the RAM mode image into the flash. You do this
|
243 |
|
|
using the fis create command after having
|
244 |
|
|
downloaded the RAM mode image, but before you start it.
|
245 |
|
|
Some platforms support locking (write protecting) certain regions of
|
246 |
|
|
the flash, while others do not. If your platform does not support
|
247 |
|
|
locking, simply ignore the fis unlock and
|
248 |
|
|
fis lock steps (the commands will not be
|
249 |
|
|
recognized by RedBoot).
|
250 |
|
|
|
251 |
|
|
|
252 |
|
|
RedBoot> fis unlock RedBoot[RAM]
|
253 |
|
|
... Unlock from 0x00000000-0x00020000: ..
|
254 |
|
|
RedBoot> fis create RedBoot[RAM]
|
255 |
|
|
An image named 'RedBoot[RAM]' exists - continue (y/n)? y
|
256 |
|
|
* CAUTION * about to program 'RedBoot[RAM]'
|
257 |
|
|
at 0x00020000..0x000369c7 from 0x06020000 - continue (y/n)?y
|
258 |
|
|
... Erase from 0x00020000-0x00040000: ..
|
259 |
|
|
... Program from 0x06020000-0x060369c8 at 0x00020000: ..
|
260 |
|
|
... Erase from 0x00070000-0x00080000: .
|
261 |
|
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
262 |
|
|
RedBoot> fis lock RedBoot[RAM]
|
263 |
|
|
... Lock from 0x00000000-0x00020000: ..
|
264 |
|
|
|
265 |
|
|
|
266 |
|
|
|
267 |
|
|
|
268 |
|
|
|
269 |
|
|
|
270 |
|
|
Update the primary RedBoot flash image An
|
271 |
|
|
instance of RedBoot should now be running on the target from RAM. This
|
272 |
|
|
can be verified by looking for the mode identifier in the banner. It
|
273 |
|
|
should be either [RAM] or [ROMRAM].
|
274 |
|
|
|
275 |
|
|
If this is the first time RedBoot is running on the board or if
|
276 |
|
|
the flash contents has been damaged, initialize the FIS directory:
|
277 |
|
|
RedBoot> fis init -f
|
278 |
|
|
About to initialize [format] FLASH image system - continue (y/n)? y
|
279 |
|
|
*** Initialize FLASH Image System
|
280 |
|
|
... Erase from 0x00020000-0x00070000: .....
|
281 |
|
|
... Erase from 0x00080000-0x00080000:
|
282 |
|
|
... Erase from 0x00070000-0x00080000: .
|
283 |
|
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
284 |
|
|
|
285 |
|
|
|
286 |
|
|
|
287 |
|
|
It is important to understand that the presence of a correctly
|
288 |
|
|
initialized FIS directory allows RedBoot to automatically determine
|
289 |
|
|
the flash parameters. Additionally, executing the steps below as
|
290 |
|
|
stated without loading other data or using other flash commands (than
|
291 |
|
|
possibly fis list) allows RedBoot to automatically
|
292 |
|
|
determine the image location and size parameters. This greatly reduces
|
293 |
|
|
the risk of potential critical mistakes due to typographical errors. It is
|
294 |
|
|
still always possible to explicitly specify parameters, and indeed
|
295 |
|
|
override these, but it is not advised.
|
296 |
|
|
|
297 |
|
|
If the new RedBoot image has grown beyond the slot in
|
298 |
|
|
flash reserved for it, it is necessary to change the RedBoot
|
299 |
|
|
configuration option CYGBLD_REDBOOT_MIN_IMAGE_SIZE so the FIS is
|
300 |
|
|
created with adequate space reserved for RedBoot images. In this case,
|
301 |
|
|
it is necessary to re-initialize the FIS directory as described above,
|
302 |
|
|
using a RAM mode RedBoot compiled with the updated
|
303 |
|
|
configuration.
|
304 |
|
|
|
305 |
|
|
Using the load command, download the
|
306 |
|
|
new flash based image from the host, relocating the image to RAM::
|
307 |
|
|
RedBoot> load -r -b %{FREEMEMLO} redboot_ROM.bin
|
308 |
|
|
Raw file loaded 0x06046800-0x06062fe8, assumed entry at 0x06046800
|
309 |
|
|
|
310 |
|
|
|
311 |
|
|
This command loads the RedBoot image using the TFTP
|
312 |
|
|
protocol via a network connection. Other methods of loading are
|
313 |
|
|
available, refer to the command for
|
314 |
|
|
more details.
|
315 |
|
|
|
316 |
|
|
Note that the binary version of the image is being
|
317 |
|
|
downloaded. This is to ensure that the memory after the image is
|
318 |
|
|
loaded should match the contents of the file on the host. Loading SREC
|
319 |
|
|
or ELF versions of the image does not guarantee this since these
|
320 |
|
|
formats may contain holes, leaving bytes in these holes in an unknown
|
321 |
|
|
state after the load, and thus causing a likely cksum difference. It
|
322 |
|
|
is possible to use these, but then the step verifying the cksum below
|
323 |
|
|
may fail.
|
324 |
|
|
|
325 |
|
|
|
326 |
|
|
Once the image is loaded into RAM, it should be checksummed,
|
327 |
|
|
thus verifying that the image on the target is indeed the image
|
328 |
|
|
intended to be loaded, and that no corruption of the image has
|
329 |
|
|
happened. This is done using the
|
330 |
|
|
command:
|
331 |
|
|
RedBoot> cksum
|
332 |
|
|
Computing cksum for area 0x06046800-0x06062fe8
|
333 |
|
|
POSIX cksum = 2535322412 116712 (0x971df32c 0x0001c7e8)
|
334 |
|
|
|
335 |
|
|
Compare the numbers with those for the binary version of the image on
|
336 |
|
|
the host. If they do not match, try downloading the image again.
|
337 |
|
|
|
338 |
|
|
|
339 |
|
|
Assuming the cksum matches, the next step is programming the
|
340 |
|
|
image into flash using the FIS commands.
|
341 |
|
|
|
342 |
|
|
Some platforms support locking (write protecting) certain
|
343 |
|
|
regions of the flash, while others do not. If your platform does not
|
344 |
|
|
support locking, simply ignore the fis unlock and
|
345 |
|
|
fis lock steps (the commands will not be recognized
|
346 |
|
|
by RedBoot).
|
347 |
|
|
|
348 |
|
|
RedBoot> fis unlock RedBoot
|
349 |
|
|
... Unlock from 0x00000000-0x00020000: ..
|
350 |
|
|
RedBoot> fis create RedBoot
|
351 |
|
|
An image named 'RedBoot' exists - continue (y/n)? y
|
352 |
|
|
* CAUTION * about to program 'RedBoot'
|
353 |
|
|
at 0x00000000..0x0001c7e7 from 0x06046800 - continue (y/n)? y
|
354 |
|
|
... Erase from 0x00000000-0x00020000: ..
|
355 |
|
|
... Program from 0x06046800-0x06062fe8 at 0x00000000: ..
|
356 |
|
|
... Erase from 0x00070000-0x00080000: .
|
357 |
|
|
... Program from 0x0606f000-0x0607f000 at 0x00070000: .
|
358 |
|
|
RedBoot> fis lock RedBoot
|
359 |
|
|
... Lock from 0x00000000-0x00020000: ..
|
360 |
|
|
|
361 |
|
|
|
362 |
|
|
|
363 |
|
|
|
364 |
|
|
Reboot; run the new RedBoot image
|
365 |
|
|
Once the image has been successfully written into the flash, simply
|
366 |
|
|
reset the target and the new version of RedBoot should be running.
|
367 |
|
|
When installing RedBoot for the first time, or after updating to
|
368 |
|
|
a newer RedBoot with different configuration keys, it is necessary to
|
369 |
|
|
update the configuration directory in the flash using the
|
370 |
|
|
fconfig command. See
|
371 |
|
|
linkend="Persistent-State-Flash">.
|
372 |
|
|
|
373 |
|
|
|
374 |
|
|
|