Changeset 0eb595a8 in rtems


Ignore:
Timestamp:
Aug 22, 2008, 4:38:00 PM (11 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.9, master
Children:
29910dec
Parents:
a78df7b
Message:

2008-08-22 Joel Sherrill <joel.sherrill@…>

  • bsp_howto/Makefile.am, bsp_howto/init.t, bsp_howto/intro.t, bsp_howto/makefiles.t, bsp_howto/support.t: Update initialization sequence. Add another figure.
  • bsp_howto/BSPInitFlowchart-49.eps, bsp_howto/BSPInitFlowchart-49.png: New files.
Location:
doc
Files:
2 added
6 edited

Legend:

Unmodified
Added
Removed
  • doc/ChangeLog

    ra78df7b r0eb595a8  
     12008-08-22      Joel Sherrill <joel.sherrill@oarcorp.com>
     2
     3        * bsp_howto/Makefile.am, bsp_howto/init.t, bsp_howto/intro.t,
     4        bsp_howto/makefiles.t, bsp_howto/support.t: Update initialization
     5        sequence. Add another figure.
     6        * bsp_howto/BSPInitFlowchart-49.eps, bsp_howto/BSPInitFlowchart-49.png: New files.
     7
    182008-08-21      Joel Sherrill <joel.sherrill@oarcorp.com>
    29
  • doc/bsp_howto/Makefile.am

    ra78df7b r0eb595a8  
    2020COMMON_FILES += $(top_srcdir)/common/cpright.texi
    2121
    22 PNG_FILES = Developer-User-Timeline.png
     22PNG_FILES = Developer-User-Timeline.png BSPInitFlowchart-49.png
    2323
    2424if USE_HTML
  • doc/bsp_howto/init.t

    ra78df7b r0eb595a8  
    11@c
    2 @c  COPYRIGHT (c) 1988-2002.
     2@c  COPYRIGHT (c) 1988-2008.
    33@c  On-Line Applications Research Corporation (OAR).
    44@c  All rights reserved.
     
    1919as interrupt vector table and chip select initialization.
    2020
    21 Most of the examples in this chapter will be based on the gen68340 BSP
    22 initialization code.  Like most BSPs, the initialization for this
    23 BSP is divided into two subdirectories under the BSP source directory.
    24 The gen68340 BSP source code is in the following directory:
     21Most of the examples in this chapter will be based on the SPARC/ERC32 and
     22m68k/gen68340 BSP initialization code.  Like most BSPs, the initialization
     23for these BSP is divided into two subdirectories under the BSP source
     24directory.  The BSP source code for these BSPs is in the following
     25directories:
    2526
    2627@example
    2728c/src/lib/libbsp/m68k/gen68340
    28 @end example
    29 
    30 The following source code files are in this subdirectory.
    31 
    32 @itemize @bullet
    33 
    34 @item @code{start340}: assembly language code which contains early
    35 initialization routines
    36 
    37 @item @code{startup}: C code with higher level routines (RTEMS
    38 initialization related)
    39 
    40 @end itemize
    41 
    42 @b{NOTE:} The directory @code{start340} is simply named @code{start} or
    43 start followed by a BSP designation.
    44 
    45 In the @code{start340} directory are two source files.  The file
    46 @code{startfor340only.s} is the simpler of these files as it only has
    47 initialization code for a MC68340 board.  The file @code{start340.s}
     29c/src/lib/libbsp/sparc/erc32
     30@end example
     31
     32Both BSPs contain startup code written in assembly language and C.
     33The gen68340 BSP has its early initialization start code in the
     34@code{start340} subdirectory and its C startup code in the @code{startup}
     35directory.  In the @code{start340} directory are two source files.
     36The file @code{startfor340only.s} is the simpler of these files as it only
     37has initialization code for a MC68340 board.  The file @code{start340.s}
    4838contains initialization for a 68349 based board as well.
    4939
     40Similarly, the ERC32 BSP has startup code written in assembly language
     41and C.  However, this BSP shares this code with other SPARC BSPs.
     42Thus the @code{Makefile.am} explicitly references the following files
     43for this functionality.
     44
     45@example
     46../../sparc/shared/start.S
     47../../sparc/shared/bspclean.c
     48@end example
     49
     50@b{NOTE:} In most BSPs, the directory named @code{start340} in the
     51gen68340 BSP would be simply named @code{start} or start followed by a
     52BSP designation.
     53
    5054@section Required Global Variables
    5155
    5256Although not strictly part of initialization, there are a few global
    53 variables assumed to exist by many support components.  These
    54 global variables are normally not defined by the BSP since the RTEMS
    55 Project strives to avoid duplication as much as possible.
    56 The following is a list of these global variables:
    57 
    58 @itemize @bullet
    59 @item @code{Configuration} is the RTEMS Configuration Table generated
    60 by @code{<rtems/confdefs.h>}.
    61 
    62 @end itemize
     57variables assumed to exist by reusable device drivers.  These global
     58variables should only defined by the BSP when using one of these device
     59drivers.
     60
     61The BSP author probably should be aware of the @code{Configuration}
     62Table structure generated by @code{<rtems/confdefs.h>} during debug but
     63should not explicitly reference it in the source code.  There are helper
     64routines provided by RTEMS to access individual fields.
     65
     66In older RTEMS versions, the BSP included a number of required global
     67variables.  We have made every attempt to eliminate these in the interest
     68of simplicity.
    6369
    6470@section Board Initialization
     
    6672This section describes the steps an application goes through from the
    6773time the first BSP code is executed until the first application task
    68 executes.  The routines invoked during this will be discussed and
    69 their location in the RTEMS source tree pointed out.
     74executes.  The following figure illustrates the program flow during
     75this sequence:
     76
     77@ifset use-ascii
     78IMAGE NOT AVAILABLE IN ASCII VERSION
     79@end ifset
     80
     81@ifset use-tex
     82@image{BSPInitFlowchart-49,6in,,Initialization Sequence,.png}
     83@c      @image{FILENAME[, WIDTH[, HEIGHT[, ALTTEXT[, EXTENSION]]]]}
     84@end ifset
     85
     86@ifset use-html
     87@html
     88<center>
     89<IMG SRC="BSPInitFlowchart-49.png" WIDTH=800 ALT="Initialization Sequence">
     90</center>
     91@end html
     92@end ifset
     93
     94The above figure illustrates the flow from assembly language start code
     95to the shared @code{bootcard.c} framework then through the C Library,
     96RTEMS, device driver initialization phases, and the context switch
     97to the first application task.  After this, the application executes
     98until it calls @code{exit}, @code{rtems_shutdown_executive}, or some
     99other normal termination initiating routine and control is returned
     100to @code{bootcard.c} which allows the BSP to perform some clanup in C
     101(@code{bsp_cleanup}) and then @code{boot_card} returns to the assembly
     102language which initially invoked it.
     103
     104The routines invoked during this will be discussed and their location
     105in the RTEMS source tree pointed out as we discuss each.
    70106
    71107@subsection Start Code - Assembly Language Initialization
    72108
    73 The assembly language code in the directory @code{start} is
    74 the first part of the application to execute.  It is
    75 responsible for initializing the processor and board enough to execute
    76 the rest of the BSP.  This includes:
     109The assembly language code in the directory @code{start} is the first part
     110of the application to execute.  It is responsible for initializing the
     111processor and board enough to execute the rest of the BSP.  This includes:
    77112
    78113@itemize @bullet
     
    83118@end itemize
    84119
    85 The general rule of thumb is that the
    86 start code in assembly should do the minimum necessary to allow C code
    87 to execute to complete the initialization sequence. 
     120The general rule of thumb is that the start code in assembly should
     121do the minimum necessary to allow C code to execute to complete the
     122initialization sequence.
    88123
    89124The initial assembly language start code completes its execution by
     
    91126
    92127The label (symbolic name) associated with the starting address of the
    93 program is typically called @code{start}.  The start object file
    94 is the first object file linked into the program image so it is insured
    95 that the start code is at offset 0 in the @code{.text} section.  It is
    96 the responsibility of the linker script in conjunction with the
    97 compiler specifications file to put the start code in the correct location
    98 in the application image.
     128program is typically called @code{start}.  The start object file is the
     129first object file linked into the program image so it is ensured that
     130the start code is at offset 0 in the @code{.text} section.  It is the
     131responsibility of the linker script in conjunction with the compiler
     132specifications file to put the start code in the correct location in
     133the application image.
    99134
    100135@subsection boot_card() - Boot the Card
    101136
    102 The @code{boot_card()} is the first C code invoked.  Most of the BSPs
    103 use the same shared version of @code{boot_card()} which is located in
    104 the following file:
     137The @code{boot_card()} is the first C code invoked.  This file is the
     138core component in the RTEMS BSP Initialization Framework and provides
     139the proper sequencing of initialization steps for the BSP, RTEMS and
     140device drivers. All BSPs use the same shared version of @code{boot_card()}
     141which is located in the following file:
    105142
    106143@example
     
    112149@itemize @bullet
    113150
    114 @item invokes the BSP specific routine @code{bsp_start()},
    115 
    116 @item invokes the RTEMS directive @code{rtems_initialize_executive_early()}
    117 to initialize the executive, C Library, and all device drivers but
    118 return without initiating multitasking or enabling interrupts,
    119 
    120 @item invokes the shared @code{main()} in the same file as
    121 @code{boot_card()} which does not return until the
    122 @code{rtems_shutdown_executive} directive is called, and
    123 
    124 @item invokes the BSP specific routine @code{bsp_cleanup()} to perform
    125 any necessary board specific shutdown actions.
     151@item It disables processor interrupts.
     152
     153@item It sets the global program name and command line argument variables
     154for later use by the application.
     155
     156@item If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined, it
     157will invoke the BSP specific @code{bsp_get_work_area} function to obtain
     158information on the amount and location of BSP RAM that is available to
     159be allocated to the C Program Heap and RTEMS Workspace.  If the amount
     160of memory available for the RTEMS Workspace is less than that required
     161by the application (e.g. @code{rtems_configuration_get_work_space_size()},
     162then a message is printed using @code{printk}, @code{bsp_cleanup} is
     163invoked, and -1 is return to the assembly language start code.  BSPs which
     164use this memory allocation functionality in @code{bootcard.c}
     165must invoke the RTEMS specific autoconf macro
     166@code{RTEMS_BSP_BOOTCARD_HANDLES_RAM_ALLOCATION} in the BSP's
     167@code{configure.ac} file.
     168
     169@item It invokes the BSP specific routine @code{bsp_start()} which is
     170written in C and thus able to perform more advanced initialization.
     171Often MMU and bus initialization occurs here.
     172
     173@item It invokes the RTEMS directive
     174@code{rtems_initialize_data_structures()} to initialize the RTEMS
     175executive to a state where objects can be created but tasking is not
     176enabled.
     177
     178@item If the macro is BSP_BOOTCARD_HANDLES_RAM_ALLOCATION is defined,
     179it will calculate the memory available for the C Program Heap and invoke
     180the initialization routine for the C Library with this information.
     181
     182@item It invokes the BSP specific routine @code{bsp_pretasking_hook}. On
     183most BSPs which utilize the framework, this routine does nothing.
     184
     185@item If @code{RTEMS_DEBUG} is enabled, then the RTEMS debug mask level
     186is inialized appropriately.
     187
     188@item It invokes the RTEMS directive
     189@code{rtems_initialize_before_drivers()} to initialize the MPCI Server
     190thread in a multiprocessor configuration and execute API specific
     191extensions.
     192
     193@item It invokes the BSP specific routine @code{bsp_predriver_hook}. For
     194most BSPs, the implementation of this routine does nothing.  However,
     195on some BSPs, required subsystems which utilize the C Library
     196(e.g. @code{malloc} in particular) may be initialized at this point.
     197
     198@item It invokes the RTEMS directive
     199@code{rtems_initialize_device_drivers()} to initialize the statically
     200configured set of device drivers in the order they were specified in
     201the Configuration Table.
     202
     203@item It invokes the BSP specific routine @code{bsp_postdriver_hook}. For
     204most BSPs, the implementation of this routine does nothing.  However, some
     205BSPs use this hook and perform some initialization which must be done at
     206this point in the initialization sequence.  This is the last opportunity
     207for the BSP to insert BSP specific code into the initialization sequence.
     208
     209@item It invokes the RTEMS directive
     210@code{rtems_initialize_start_multitasking()} which starts multitasking and context switches to the first task.  @code{boot_card()} will not return until the application is shutdown.  As part of this sequence the following actions occur:
     211
     212@itemize @bullet
     213
     214@item RTEMS will context switch to the first application task.  As a
     215side-effect of this context switch, processor interrupts will be enabled.
     216This is often the source of a fatal error during BSP development because
     217the BSP did not clear and/or disable all interrupt sources and a spurious
     218interrupt will occur .
     219
     220@item When in the context of the first task but before its body has been
     221entered, any C++ Global Constructors will be invoked.
    126222
    127223@end itemize
    128224
    129 It is important to note that the executive and much of the
    130 support environment must be initialized before invoking @code{main()}.
     225@item Finally after the application shutsdown RTEMS and control is
     226return to @code{boot_card()} from RTEMS, it invokes the BSP specific
     227routine @code{bsp_cleanup()} to perform any necessary board specific
     228shutdown actions.
     229
     230@end itemize
     231
     232That's it.  We just went through the entire sequence.
    131233
    132234@subsection bsp_start() - BSP Specific Initialization
     
    181283
    182284The precise placement of when @code{main()} is invoked in the
    183 RTEMS initialization sequence insures that C Library and non-blocking
     285RTEMS initialization sequence ensures that C Library and non-blocking
    184286calls can be made in global C++ constructors.
    185287
  • doc/bsp_howto/intro.t

    ra78df7b r0eb595a8  
    5656in the RTEMS documentation set.
    5757
     58The gen68340 BSP is a good example of the life of an RTEMS BSP.  It is
     59based upon a part not recommended for new designs and none of the core RTEMS
     60Project team members have one of these boards.  Thus we are unlikely to
     61perform major updates on this BSP.  So as long as it compiles and links all
     62tests, it will be available. 
     63
     64The RTEMS Project team members are always trying to identify common
     65code across BSPs and refactoring the code into shared routines.
     66As part of this effort, the we will enhance the common BSP Framework.
     67Not surprisingly, not every BSP takes advantage of every feature in
     68the framework.  The gen68340 does not take advantage of as many features
     69as the ERC32 BSP does.  So in many ways, the ERC32 is a better example
     70BSP at this point.  But even the ERC32 BSP does not include examples
     71of every driver template and framework available to the BSP author.
     72So in this guide we will try to point out good examples from other BSPs.
     73
     74Our goal is for you to be able to reuse as much code as possible and
     75write as little board specific code as possible.
     76
  • doc/bsp_howto/makefiles.t

    ra78df7b r0eb595a8  
    11@c
    2 @c  COPYRIGHT (c) 1988-2002.
     2@c  COPYRIGHT (c) 1988-2008.
    33@c  On-Line Applications Research Corporation (OAR).
    44@c  All rights reserved.
     
    2828@end ifset
    2929
    30 
    3130@ifset use-tex
    3231@image{Developer-User-Timeline,6in,,Developer User Timeline,.png}
    3332@c      @image{FILENAME[, WIDTH[, HEIGHT[, ALTTEXT[, EXTENSION]]]]}
    34 
    3533@end ifset
    3634
  • doc/bsp_howto/support.t

    ra78df7b r0eb595a8  
    1919@example
    2020@group
    21 %rename cpp old_cpp
    22 %rename lib old_lib
    2321%rename endfile old_endfile
    2422%rename startfile old_startfile
    2523%rename link old_link
    2624
    27 *cpp:
    28 %(old_cpp) %@{qrtems: -D__embedded__@} -Asystem(embedded)
    29 
    30 *lib:
    31 %@{!qrtems: %(old_lib)@} %@{qrtems: --start-group \
    32 %@{!qrtems_debug: -lrtemsall@} %@{qrtems_debug: -lrtemsall_g@} \
    33 -lc -lgcc --end-group  ecrtn%O%s \
    34 %@{!qnolinkcmds: -T linkcmds%s@}@}
    35 
    3625*startfile:
    37 %@{!qrtems: %(old_startfile)@} %@{qrtems:  ecrti%O%s \
    38 %@{!qrtems_debug: startsim.o%s@} \
    39 %@{qrtems_debug: startsim_g.o%s@}@}
     26%@{!qrtems: %(old_startfile)@} \
     27%@{!nostdlib: %@{qrtems: ecrti%O%s rtems_crti%O%s crtbegin.o%s start.o%s@}@}
    4028
    4129*link:
    42 %@{!qrtems: %(old_link)@} %@{qrtems: -Qy -dp -Bstatic \
    43 -T linkcmds%s -e _start -u __vectors@}
     30%@{!qrtems: %(old_link)@} %@{qrtems: -Qy -dp -Bstatic -e _start -u __vectors@}
     31
     32*endfile:
     33%@{!qrtems: %(old_endfile)@} %@{qrtems: crtend.o%s ecrtn.o%s@}
    4434@end group
    4535@end example
     
    5141@code{-qrtems_debug} option is specified. 
    5242
    53 The @code{*cpp} definition specifies that when @code{-qrtems}
    54 is specified, predefine the preprocessor symbol @code{__embedded__}.
    55 
    56 The @code{*lib} section insures that the RTEMS library, BSP specific
    57 linker script, gcc support library, and the EABI specific @code{ecrtn}
    58 file are used.
    59 
    6043The @code{*startfile} section specifies that the BSP specific file
    61 @code{startsim.o} will be used instead of @code{crt0.o}.  In addition,
    62 the EABI specific file @code{ecrti.o} will be linked in with the
    63 executable.
    64 
    65 The @code{*link} section specifies the arguments that will be passed to
    66 the linker.
     44@code{start.o} will be used instead of @code{crt0.o}.  In addition,
     45various EABI support files (@code{ecrti.o} etc.) will be linked in with
     46the executable.
     47
     48The @code{*link} section adds some arguments to the linker when it is
     49invoked by GCC to link an application for this BSP.
    6750
    6851The format of this file is specific to the GNU Compiler Suite.  The
    6952argument used to override and extend the compiler built-in specifications
    70 is relatively new to the toolset.  The @code{-specs} option is present
    71 in all @code{egcs} distributions and @code{gcc} distributions starting
    72 with version 2.8.0.
     53is available in all recent GCC versions.  The @code{-specs} option is
     54present in all @code{egcs} distributions and @code{gcc} distributions
     55starting with version 2.8.0.
    7356
    7457@section README Files
     
    127110in the linker script (@code{linkcmds}).
    128111
    129 There are a number of fields in this file that are used only by the
    130 RTEMS Test Suites.  The following is a list of these:
     112@section tm27.h Include File
     113
     114The @code{tm27} test from the RTEMS Timing Test Suite is designed to measure the length of time required to vector to and return from an interrupt handler. This test requires some help from the BSP to know how to cause and manipulate the interrupt source used for this measurement.  The following is a list of these:
    131115
    132116@itemize @bullet
    133 @item @code{MAX_LONG_TEST_DURATION} - the longest length of time a
    134 "long running" test should run.
    135 
    136 @item @code{MAX_SHORT_TEST_DURATION} - the longest length of time a
    137 "short running" test should run.
    138 
    139117@item @code{MUST_WAIT_FOR_INTERRUPT} - modifies behavior of @code{tm27}.
    140118
     
    153131
    154132@end itemize
     133
     134All members of the Timing Test Suite are designed to run @b{WITHOUT}
     135the Clock Device Driver installed.  This increases the predictability
     136of the tests' execution as well as avoids occassionally including the
     137overhead of a clock tick interrupt in the time reported.  Because of
     138this it is sometimes possible to use the clock tick interrupt source
     139as the source of this test interrupt.  On other architectures, it is
     140possible to directly force an interrupt to occur.
    155141
    156142@section Calling Overhead File
     
    169155the Timing Suite.
    170156
     157There is a shared implementation of @code{coverhd.h} which sets all of
     158the overhead constants to 0.  On faster processors, this is usually the
     159best alternative for the BSP as the calling overhead is extremely small.
     160This file is located at:
     161
     162@example
     163c/src/lib/libbsp/shared/include/coverhd.h
     164@end example
     165
    171166@section sbrk() Implementation
    172167
    173 If the BSP wants to dynamically extend the heap used by the
    174 C Library memory allocation routines (i.e. @code{malloc} family),
    175 then this routine must be functional.  The following is the
    176 prototype for this routine:
     168Although nearly all BSPs give all possible memory to the C Program Heap
     169at initialization, it is possible for a BSP to configure the initial
     170size of the heap small and let it grow on demand.  If the BSP wants
     171to dynamically extend the heap used by the C Library memory allocation
     172routines (i.e. @code{malloc} family), then the@code{sbrk} routine must
     173be functional.  The following is the prototype for this routine:
    177174
    178175@example
     
    181178
    182179The @code{increment} amount is based upon the @code{sbrk_amount}
    183 parameter passed to the @code{RTEMS_Malloc_Initialize} during system
    184 initialization.
    185 See @ref{Initialization Code RTEMS Pretasking Callback} for more
    186 information.
    187 
    188 There is a default implementation which returns an error to indicate
    189 that the heap can not be extended.  This implementation can be
    190 found in @code{c/src/lib/libbsp/shared/sbrk.c}.  Many of the BSPs
    191 use this shared implementation.  In order to use this implementation,
    192 the file @code{Makefile.am} in the BSP's @code{startup} directory
    193 must be modified so that the @code{$VPATH} variable searches
    194 both the @code{startup} directory and the shared directory.  The following
    195 illustates the @code{VPATH} setting in the PowerPC psim BSP's
    196 @code{startup/Makefile.am}:
    197 
    198 @example
    199 VPATH = @@srcdir@@:@@srcdir@@/../../../shared
    200 @end example
    201 
    202 This instructs make to look in all of the directories in the @code{VPATH}
    203 for the source files.  The directories will be examined in the order
    204 they are specified.
     180parameter passed to the @code{bsp_libc_init} during system initialization.
     181Historically initialization of the C Library was done as part of the
     182BSP's Pretasking Hook but now the BSP Boot Card Framework can perform
     183this operation.
     184
     185If your BSP does not want to support dynamic heap extension, then you do not have to do anything special.  However, if you want to support @code{sbrk}, you must provide an implementation of this method and define @code{CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK} in @code{bsp.h}.  This informs @code{rtems/confdefs.h} to configure the Malloc Family Extensions which support @code{sbrk}.
    205186
    206187@section bsp_cleanup() - Cleanup the Hardware
     
    216197The @code{bsp_cleanup()} routine can be used to return to a ROM monitor,
    217198insure that interrupt sources are disabled, etc..  This routine is the
    218 last place to insure a clean shutdown of the hardware.
     199last place to insure a clean shutdown of the hardware.  On some BSPs,
     200it prints a message indicating that the application completed execution
     201and waits for the user to press a key before resetting the board.
     202The PowerPC/gen83xx and PowerPC/gen5200 BSPs do this when they are built
     203to support the FreeScale evaluation boards.  This is convenient when
     204using the boards in a development environment and may be disabled for
     205production use.
    219206
    220207@section set_vector() - Install an Interrupt Vector
    221208
    222 The @code{set_vector} routine is responsible for installing an interrupt
    223 vector.  It invokes the support routines necessary to install an
    224 interrupt handler as either a "raw" or an RTEMS interrupt handler.  Raw
    225 handlers bypass the RTEMS interrupt structure and are responsible for
    226 saving and restoring all their own registers.  Raw handlers are useful
    227 for handling traps, debug vectors, etc..
    228 
    229 The @code{set_vector} routine is a central place to perform
    230 interrupt controller manipulation and encapsulate that information. 
    231 It is usually implemented as follows:
     209On targets with Simple Vectored Interrupts, the BSP must provide
     210an implementation of the @code{set_vector} routine.  This routine is
     211responsible for installing an interrupt vector.  It invokes the support
     212routines necessary to install an interrupt handler as either a "raw"
     213or an RTEMS interrupt handler.  Raw handlers bypass the RTEMS interrupt
     214structure and are responsible for saving and restoring all their own
     215registers.  Raw handlers are useful for handling traps, debug vectors,
     216etc..
     217
     218The @code{set_vector} routine is a central place to perform interrupt
     219controller manipulation and encapsulate that information.  It is usually
     220implemented as follows:
    232221
    233222@example
     
    252241@end example
    253242
    254 
    255 @b{NOTE:}  @code{set_vector} is provided by the majority of BSPs but
    256 not all.  In particular, the i386 BSPs use a different scheme. 
    257 
     243@b{NOTE:}  The i386, PowerPC and ARM ports use a Programmable
     244Interrupt Controller model which does not require the BSP to implement
     245@code{set_vector}.  BSPs for these architectures must provide a different
     246set of support routines.
     247
Note: See TracChangeset for help on using the changeset viewer.