Porting kernels

Porting kernels

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.

Board support

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 tested software.

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.

configAll.h

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.

config.h

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.

usrConfig.c

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 system.

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 networking support.

pSOSystem+

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.