test

ChorusOS 4.0 Porting Guide

Chapter 1 ChorusOS System Architecture

This chapter provides an overview of the low-level architecture of a ChorusOS operating system, and explains how to add support for other target boards by porting the ChorusOS operating software. This chapter also:

Introduction

Sun Embedded Workshop provides reference implementations of the ChorusOS operating system as a set of binary products, each one for a specific target family of processors. The processors within a target family are electronically different but are identical in their interactions with the operating system. The binary product for a given family consists of:

The generic runtime is compiled for the given family of processors. For example, the ChorusOS operating system for PPC60x generic runtime will work with the PowerPC 603[ev], 604[ev], and 750 processors. The generic runtime needs to be complemented with board-specific components in order to produce a system that can boot and do useful work. In particular, you need to add a boot program and a set of device drivers. The set of items that you need to add to support a specific board is called the board support package (BSP).

The set of boot programs and device drivers provided with the binary product will work with the reference platforms. However, you might need to customize these components to, for example, optimize your system.

When you have selected the board on which you will run your system, choose the reference implementation from the board family that most closely resembles your target board. Use this reference implementation as the basis for your ChorusOS operating system, porting the components as necessary.

To create a BSP for a specific target board, you need to provide four components:

The boot program and host bus driver are heavily dependent on the board, and need to be re-written. However, using the Sun Embedded Workshop device driver framework, you might be able to reuse existing drivers for managing the board's other devices. See ChorusOS 4.0 Device Driver Framework Guide for information about writing device drivers and using the device driver framework.

Initializing a ChorusOS System

There are three stages to initializing a ChorusOS operating system:

Power-up Initialization

When the board is powered up or reset, the processor starts executing code at a fixed address. This code sets up the minimum hardware environment required by the system loader. The initialization code is stored in non-volatile physical memory.

Loading the System Image

The last action of the power-up initialization code is to hand control to the initial loader, which loads the system image into physical memory and jumps to the image entry point.

If the system image is already stored in non-volatile memory on the board, the initial loader is not required, and the initialization code terminates by jumping to the entry point of the system image.

Firmware

Most development boards are provided with a standard firmware power-up initialization code and loader in PROM. This firmware is able to download a system image from a local device or from the network.

Sun Embedded Workshop provides tools to build the ChorusOS system image in the format required by the firmware loaders supported.

ChorusOS Boot Monitor

The Boot Monitor is the initial loader provided with ChorusOS for use with the ChorusOS operating system. It is able to download the system image from the network.

The Boot Monitor is implemented as an aplication on top of a minimal ChorusOS configuration.

Initializing the ChorusOS Kernel and OS

ChorusOS boots from the system image. The system image contains binary executable files of the bootstrap program, debug agent, microkernel, drivers, OS servers and possibly applications. It can also contain a set of data files such as networking configuration files.

System image files are organized in one or more memory banks. Each memory bank can be formatted as a file system volume (for example, FAT12) and exported through the microkernel API as a memory device. Thus a system image file can be viewed as a file in a file system volume on a memory device.

The ChorusOS operating system is initialized in two stages:

  1. Kernel initialization

  2. OS service initialization

Kernel Initialization

The kernel is the minimal ChorusOS operating system comprising the microkernel and the built-in drivers.

The bootstrap program starts the microkernel. The microkernel then starts the built-in drivers.

OS Initialization

The OS is implemented on top of the kernel as a set of actors that provide services such as file systems and networking protocols.

The kernel starts the OS services by creating the initial subset of OS actors from the system image binary files. The OS can then activate additional system services by loading actors from files located on the system image memory, or local or remote devices.

Rebooting a ChorusOS system

ChorusOS supports three system reboot scenarios:

A system reboot can be initiated by either the operating system sysShutdown() call, by the system failure recovery procedure, or by some special system applications such as the ChorusOS Boot Monitor.

All system reboot scenarios will use the sysReboot() micro-kernel call. sysReboot() calls the emergency stop services of all registered drivers and then transfers control to a board-specific reboot program.

When performing a cold reboot, the reboot program will reset the hardware and the system life-cycle will be re-started from the power-up intialization program.

In the case of a hot reboot, the system boots from the system image, originally deployed by the cold reboot. For further information on this, see the "Hot Reboot".

Finally, if one ChorusOS system (that is, the Boot Monitor) boots another ChorusOS system (that is, the system image loaded by the Boot Monitor) then the new system image is installed at the required address and the reboot program will jump to it. For further information on this, see "Rebooting The New System Image"

For more information on booting a ChorusOS operating system, see Chapter 4, Rebooting ChorusOS.

Component Architecture

In Figure 1-1, the elements drawn with dotted lines are the elements that must be modified or replaced when porting a ChorusOS operating system. Elements shown with unbroken lines are not usually changed when porting the system to another target.

Figure 1-1 Component Architecture

Graphic

DDI is the device driver interface. DKI is the device-kernel interface. Both these interfaces are described in detail in the ChorusOS 4.0 Device Driver Framework Guide. BKI is the boot-kernel interface. This is described in "The Boot-Kernel Interface (BKI)".

Creating a Board Support Package

To create a board support package for a new target, you need to do the following: