So far, it has been assumed that the operating system or real-time
kernel is already running on the target board. While this is sometimes true, it
is not always the case. The operating system may not be available for the
target board or the hard-ware may be a custom design.
One way to solve this problem is to buy the operating system software
already configured for a particular board.
Many software suppliers have a list of supported platforms — usually the
most popular boards from the top suppliers — where their software has been
ported to and is available off the shelf. For many projects, this is a very
good way to proceed as it removes one more variable from the development chain.
Not only do you have tested hardware, but you also have preconfigured and
Rebuilding kernels for new configurations
What happens if you cannot use a standard package or if you need to make
some modifications? These changes can be made by rebuilding the operating
system or kernel. This is not as difficult as it sounds and is more akin to a
linking operation, where the various modules that comprise the operating system
are linked together to form the final version.
This was not always the case. Early versions of operating systems
offered these facilities but took several hours to com-plete and involved the
study of tens of pages of tables to set various switches to include the right
modules. Those of you who remember the SYSGEN command within VersaDOS will
understand the problem. It did not simply link together mod-ules, it often
created them by modifying source code files and patching object files! A long
and lengthy process and extremely prone to errors.
This procedure has not gone away but has become quicker and easier to
manage. Through the use of reusable modules and high level languages, operating
systems are modified and built using a process which is similar to
compi-lation. User created or modified modules are compiled and then linked
with the basic operating system to form the final version. The various
parameters and software switches are set by various header files — similar to
those used with C pro-grams — and these control exactly what is built and where
it is located.
As an example of this process, consider how VXWorks performs this task.
VXWorks calls this process configuration and it uses several files to control
how the kernel is configured. The process is very similar to the UNIX make
command and uses the normal compilation tools used to generate tasks.
The three configuration files are called configAll.h, config.h and
usrConfig.c. The first two files are header
files, which supply parameters to the modules
specified in the usrConfig.c file.
Specifying these parameters without add-ing the appropriate statement in the usrConfig.c file will cause the build to fail.
This file contains all the fundamental options and pa-rameters for
kernel configurations, I/O and Networking File System parameters, optional
software modules and device controllers or drivers. It also contains cache
modes and ad-dresses for I/O devices, interrupt vectors and levels.
This is where target specific parameters are stored, such as interrupt
vectors for the system clock and parity errors, target specific I/O controller
addresses, interrupt vectors and levels, and information on any shared memory.
This contains a series of software include statements which are used to
omit or include the various software mod-ules that the operating system may need.
This file would select which Ethernet driver to use or which serial port driver
was needed. These modules use parameters from the previous two configuration
files within the rebuilding process.
Several standard make files are supplied which will create bootable,
standalone versions of the operating system, as well as others that will embed
tasks into the standalone version. These are used by the compiler and linker to
control the building process. All the requisite files are stored in several
default library directories but special directories can also be used by adding
further options to the make file.
The diagrams show the basic principles involved. A standard build
process usually involves modification of the normal files and a simple rebuild.
New modules are extracted from the library files or directories as required to
build the new version of the operating system.
The second diagram shows the basic principles behind including user
tasks into the operating system. User tasks are usually included at the make or
link level and are added to the list of object files that form the operating
Note that this process is not the same as building an embedded
standalone version. Although the tasks have been embedded, the initialisation
code is still the standard one used to start up the operating system only. The
tasks may be present, but the operating system is not aware of their existence.
This version is often used as an intermediate stage to allow the tasks to be
embedded but started under the control of a debugging shell or task.
To create a full embedded version, the user must supply some
initialisation routines as well as the tasks themselves. This may involve
changing the operating system start point to that of the user’s own routine
rather than the default operating system one. This user routine must also take
care of any variable initialisation, setting up of the vector table, starting
tasks in the correct order and allocating memory correctly.
Other options that may need to be included are the addition of any
symbol tables for debugging purposes, multi-processor communication and
Rebuilding operating systems is not difficult, once a basic
understanding of how the process works and what needs to be changed is reached.
The biggest problem faced by the user and by software suppliers is the sheer
number of different parameters and drivers that are available today. With
hun-dreds of VMEbus processor boards and I/O modules avail-able, it is becoming
extremely difficult to keep up with new product introductions. In an effort to
reduce this problem, more user friendly rebuilding systems, such as pSOSystem+,
are becoming available which provide a menu driven ap-proach to the problem.
The basic options are presented and the user chooses from the menu. The program
then automatically generates the changes to the configuration file and builds
the new version automatically.