OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [hal-exception-handling.html] - Blame information for rev 300

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 28 unneback 
<!-- Copyright (C) 2003 Red Hat, Inc.                                -->
2 
<!-- This material may be distributed only subject to the terms      -->
3 
<!-- and conditions set forth in the Open Publication License, v1.0  -->
4 
<!-- or later (the latest version is presently available at          -->
5 
<!-- http://www.opencontent.org/openpub/).                           -->
6 
<!-- Distribution of the work or derivative of the work in any       -->
7 
<!-- standard (paper) book form is prohibited unless prior           -->
8 
<!-- permission is obtained from the copyright holder.               -->
9 
<HTML
10 
><HEAD
11 
><TITLE
12 
>Exception Handling</TITLE
13 
><meta name="MSSmartTagsPreventParsing" content="TRUE">
14 
<META
15 
NAME="GENERATOR"
16 
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
17 
"><LINK
18 
REL="HOME"
19 
TITLE="eCos Reference Manual"
20 
HREF="ecos-ref.html"><LINK
21 
REL="UP"
22 
TITLE="The eCos Hardware Abstraction Layer (HAL)"
23 
HREF="the-ecos-hardware-abstraction-layer.html"><LINK
24 
REL="PREVIOUS"
25 
TITLE="SMP Support"
26 
HREF="hal-smp-support.html"><LINK
27 
REL="NEXT"
28 
TITLE="Vectors and VSRs"
29 
HREF="hal-vectors-and-vsrs.html"></HEAD
30 
><BODY
31 
CLASS="CHAPTER"
32 
BGCOLOR="#FFFFFF"
33 
TEXT="#000000"
34 
LINK="#0000FF"
35 
VLINK="#840084"
36 
ALINK="#0000FF"
37 
><DIV
38 
CLASS="NAVHEADER"
39 
><TABLE
40 
SUMMARY="Header navigation table"
41 
WIDTH="100%"
42 
BORDER="0"
43 
CELLPADDING="0"
44 
CELLSPACING="0"
45 
><TR
46 
><TH
47 
COLSPAN="3"
48 
ALIGN="center"
49 
>eCos Reference Manual</TH
50 
></TR
51 
><TR
52 
><TD
53 
WIDTH="10%"
54 
ALIGN="left"
55 
VALIGN="bottom"
56 
><A
57 
HREF="hal-smp-support.html"
58 
ACCESSKEY="P"
59 
>Prev</A
60 
></TD
61 
><TD
62 
WIDTH="80%"
63 
ALIGN="center"
64 
VALIGN="bottom"
65 
></TD
66 
><TD
67 
WIDTH="10%"
68 
ALIGN="right"
69 
VALIGN="bottom"
70 
><A
71 
HREF="hal-vectors-and-vsrs.html"
72 
ACCESSKEY="N"
73 
>Next</A
74 
></TD
75 
></TR
76 
></TABLE
77 
><HR
78 
ALIGN="LEFT"
79 
WIDTH="100%"></DIV
80 
><DIV
81 
CLASS="CHAPTER"
82 
><H1
83 
><A
84 
NAME="HAL-EXCEPTION-HANDLING">Chapter 10. Exception Handling</H1
85 
><DIV
86 
CLASS="TOC"
87 
><DL
88 
><DT
89 
><B
90 
>Table of Contents</B
91 
></DT
92 
><DT
93 
><A
94 
HREF="hal-exception-handling.html#HAL-STARTUP"
95 
>HAL Startup</A
96 
></DT
97 
><DT
98 
><A
99 
HREF="hal-vectors-and-vsrs.html"
100 
>Vectors and VSRs</A
101 
></DT
102 
><DT
103 
><A
104 
HREF="hal-default-synchronous-exception-handling.html"
105 
>Default Synchronous Exception Handling</A
106 
></DT
107 
><DT
108 
><A
109 
HREF="hal-default-interrupt-handling.html"
110 
>Default Interrupt Handling</A
111 
></DT
112 
></DL
113 
></DIV
114 
><P
115 
>Most of the HAL consists of simple macros or functions that are
116 
called via the interfaces described in the previous section. These
117 
just perform whatever operation is required by accessing the hardware
118 
and then return. The exception to this is the handling of exceptions:
119 
either synchronous hardware traps or asynchronous device
120 
interrupts. Here control is passed first to the HAL, which then passed
121 
it on to eCos or the application. After eCos has finished with it,
122 
control is then passed back to the HAL for it to tidy up the CPU state
123 
and resume processing from the point at which the exception occurred.</P
124 
><P
125 
>The HAL exceptions handling code is usually found in the file
126 
<TT
127 
CLASS="FILENAME"
128 
>vectors.S</TT
129 
> in the architecture HAL.  Since the
130 
reset entry point is usually implemented as one of these it also deals
131 
with system startup.</P
132 
><P
133 
>The exact implementation of this code is under the control of the HAL
134 
implementer. So long as it interacts correctly with the interfaces
135 
defined previously it may take any form.  However, all current
136 
implementation follow the same pattern, and there should be a very
137 
good reason to break with this. The rest of this section describes
138 
these operate.</P
139 
><P
140 
>Exception handling normally deals with the following broad areas of
141 
functionality:</P
142 
><P
143 
></P
144 
><UL
145 
><LI
146 
><P
147 
>Startup and initialization.</P
148 
></LI
149 
><LI
150 
><P
151 
>Hardware exception delivery.</P
152 
></LI
153 
><LI
154 
><P
155 
>Default handling of synchronous exceptions.</P
156 
></LI
157 
><LI
158 
><P
159 
>Default handling of asynchronous interrupts.</P
160 
></LI
161 
></UL
162 
><DIV
163 
CLASS="SECTION"
164 
><H1
165 
CLASS="SECTION"
166 
><A
167 
NAME="HAL-STARTUP">HAL Startup</H1
168 
><P
169 
>Execution normally begins at the reset vector with
170 
the machine in a minimal startup state. From here the HAL needs to get
171 
the machine running, set up the execution environment for the
172 
application, and finally invoke its entry point.</P
173 
><P
174 
>The following is a list of the jobs that need to be done in
175 
approximately the order in which they should be accomplished. Many
176 
of these will not be needed in some configurations.</P
177 
><P
178 
></P
179 
><UL
180 
><LI
181 
><P
182 
>  Initialize the hardware. This may involve initializing several
183 
  subsystems in both the architecture, variant and platform
184 
  HALs. These include:
185 
  </P
186 
><P
187 
></P
188 
><UL
189 
><LI
190 
><P
191 
>       Initialize various CPU status registers. Most importantly, the CPU
192 
        interrupt mask should be set to disable interrupts.
193 
        </P
194 
></LI
195 
><LI
196 
><P
197 
>       Initialize the MMU, if it is used. On many platforms it is
198 
        only possible to control the cacheability of address ranges
199 
        via the MMU. Also, it may be necessary to remap RAM and device
200 
        registers to locations other than their defaults. However, for
201 
        simplicity, the mapping should be kept as close to one-to-one
202 
        physical-to-virtual as possible.
203 
        </P
204 
></LI
205 
><LI
206 
><P
207 
>       Set up the memory controller to access RAM, ROM and I/O devices
208 
        correctly. Until this is done it may not be possible to access
209 
        RAM. If this is a ROMRAM startup then the program code can
210 
        now be copied to its RAM address and control transferred to it.
211 
        </P
212 
></LI
213 
><LI
214 
><P
215 
>       Set up any bus bridges and support chips. Often access to
216 
        device registers needs to go through various bus bridges and
217 
        other intermediary devices. In many systems these are combined
218 
        with the memory controller, so it makes sense to set these up
219 
        together. This is particularly important if early diagnostic
220 
        output needs to go through one of these devices.
221 
        </P
222 
></LI
223 
><LI
224 
><P
225 
>       Set up diagnostic mechanisms. If the platform includes an LED or
226 
        LCD output device, it often makes sense to output progress
227 
        indications on this during startup. This helps with diagnosing
228 
        hardware and software errors.
229 
        </P
230 
></LI
231 
><LI
232 
><P
233 
>       Initialize floating point and other extensions such as SIMD
234 
        and multimedia engines. It is usually necessary to enable
235 
        these and maybe initialize control and exception registers for
236 
        these extensions.
237 
        </P
238 
></LI
239 
><LI
240 
><P
241 
>       Initialize interrupt controller. At the very least, it should
242 
        be configured to mask all interrupts. It may also be necessary
243 
        to set up the mapping from the interrupt controller's vector
244 
        number space to the CPU's exception number space. Similar
245 
        mappings may need to be set up between primary and secondary
246 
        interrupt controllers.
247 
        </P
248 
></LI
249 
><LI
250 
><P
251 
>       Disable and initialize the caches. The caches should not
252 
        normally be enabled at this point, but it may be necessary to
253 
        clear or initialize them so that they can be enabled
254 
        later. Some architectures require that the caches be
255 
        explicitly reinitialized after a power-on reset.
256 
        </P
257 
></LI
258 
><LI
259 
><P
260 
>       Initialize the timer, clock etc. While the timer used for RTC
261 
        interrupts will be initialized later, it may be necessary to
262 
        set up the clocks that drive it here.
263 
        </P
264 
></LI
265 
></UL
266 
><P
267 
>    The exact order in which these initializations is done is
268 
    architecture or variant specific. It is also often not necessary
269 
    to do anything at all for some of these options. These fragments
270 
    of code should concentrate on getting the target up and running so
271 
    that C function calls can be made and code can be run. More
272 
    complex initializations that cannot be done in assembly code may
273 
    be postponed until calls to
274 
    <TT
275 
CLASS="FUNCTION"
276 
>hal_variant_init()</TT
277 
> or
278 
    <TT
279 
CLASS="FUNCTION"
280 
>hal_platform_init()</TT
281 
> are made.
282 
    </P
283 
><P
284 
>    Not all of these initializations need to be done for all startup
285 
    types. In particular, RAM startups can reasonably assume that the
286 
    ROM monitor or loader has already done most of this work.
287 
    </P
288 
></LI
289 
><LI
290 
><P
291 
>    Set up the stack pointer, this allows subsequent initialization
292 
    code to make proper procedure calls. Usually the interrupt stack
293 
    is used for this purpose since it is available, large enough, and
294 
    will be reused for other purposes later.
295 
    </P
296 
></LI
297 
><LI
298 
><P
299 
>    Initialize any global pointer register needed for access to
300 
    globally defined variables. This allows subsequent initialization
301 
    code to access global variables.
302 
    </P
303 
></LI
304 
><LI
305 
><P
306 
>    If the system is starting from ROM, copy the ROM template of the
307 
    <TT
308 
CLASS="FILENAME"
309 
>.data</TT
310 
> section out to its correct position in
311 
    RAM. (<A
312 
HREF="hal-linker-scripts.html"
313 
>the Section called <I
314 
>Linker Scripts</I
315 
> in Chapter 9</A
316 
>).
317 
    </P
318 
></LI
319 
><LI
320 
><P
321 
>    Zero the <TT
322 
CLASS="FILENAME"
323 
>.bss</TT
324 
> section.
325 
    </P
326 
></LI
327 
><LI
328 
><P
329 
>    Create a suitable C call stack frame. This may involve making
330 
    stack space for call frames, and arguments, and initializing the
331 
    back pointers to halt a GDB backtrace operation.
332 
    </P
333 
></LI
334 
><LI
335 
><P
336 
>    Call <TT
337 
CLASS="FUNCTION"
338 
>hal_variant_init()</TT
339 
> and
340 
    <TT
341 
CLASS="FUNCTION"
342 
>hal_platform_init()</TT
343 
>. These will perform any
344 
    additional initialization needed by the variant and platform. This
345 
    typically includes further initialization of the interrupt
346 
    controller, PCI bus bridges, basic IO devices and enabling the
347 
    caches.
348 
    </P
349 
></LI
350 
><LI
351 
><P
352 
>    Call <TT
353 
CLASS="FUNCTION"
354 
>cyg_hal_invoke_constructors()</TT
355 
> to run any
356 
    static constructors.
357 
    </P
358 
></LI
359 
><LI
360 
><P
361 
>    Call <TT
362 
CLASS="FUNCTION"
363 
>cyg_start()</TT
364 
>. If
365 
    <TT
366 
CLASS="FUNCTION"
367 
>cyg_start()</TT
368 
> returns, drop into an infinite
369 
    loop.
370 
    </P
371 
></LI
372 
></UL
373 
></DIV
374 
></DIV
375 
><DIV
376 
CLASS="NAVFOOTER"
377 
><HR
378 
ALIGN="LEFT"
379 
WIDTH="100%"><TABLE
380 
SUMMARY="Footer navigation table"
381 
WIDTH="100%"
382 
BORDER="0"
383 
CELLPADDING="0"
384 
CELLSPACING="0"
385 
><TR
386 
><TD
387 
WIDTH="33%"
388 
ALIGN="left"
389 
VALIGN="top"
390 
><A
391 
HREF="hal-smp-support.html"
392 
ACCESSKEY="P"
393 
>Prev</A
394 
></TD
395 
><TD
396 
WIDTH="34%"
397 
ALIGN="center"
398 
VALIGN="top"
399 
><A
400 
HREF="ecos-ref.html"
401 
ACCESSKEY="H"
402 
>Home</A
403 
></TD
404 
><TD
405 
WIDTH="33%"
406 
ALIGN="right"
407 
VALIGN="top"
408 
><A
409 
HREF="hal-vectors-and-vsrs.html"
410 
ACCESSKEY="N"
411 
>Next</A
412 
></TD
413 
></TR
414 
><TR
415 
><TD
416 
WIDTH="33%"
417 
ALIGN="left"
418 
VALIGN="top"
419 
>SMP Support</TD
420 
><TD
421 
WIDTH="34%"
422 
ALIGN="center"
423 
VALIGN="top"
424 
><A
425 
HREF="the-ecos-hardware-abstraction-layer.html"
426 
ACCESSKEY="U"
427 
>Up</A
428 
></TD
429 
><TD
430 
WIDTH="33%"
431 
ALIGN="right"
432 
VALIGN="top"
433 
>Vectors and VSRs</TD
434 
></TR
435 
></TABLE
436 
></DIV
437 
></BODY
438 
></HTML
439 
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.