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" explains why porting is necessary and introduces terms and concepts used in this book.
"Component Architecture" describes the architecture and explains which components need to be ported.
"Creating a Board Support Package" is a checklist for creating a board support package (BSP).
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:
A set of generic runtime binaries
A set of boot program sources
A set of device driver sources
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:
A bootstrap program
A driver for the board's host bus bridge
Drivers for the board's other devices
A reboot program
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.
There are three stages to initializing a ChorusOS operating system:
Power-up initialization
Loading the system image
Initializing the ChorusOS operating system, including the system drivers
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.
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.
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.
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.
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:
Kernel initialization
OS service 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.
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.
ChorusOS supports three system reboot scenarios:
Cold reboot
Hot reboot
Boot of the system image loaded by the ChorusOS Boot Monitor
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.
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.
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)".
To create a board support package for a new target, you need to do the following:
Write any target specific device drivers that you require. See the ChorusOS 4.0 Device Driver Framework Guide for information about writing a device driver.
Write the host bus driver for the target. See the ChorusOS 4.0 Device Driver Framework Guide for information about writing a host bus driver.
Design and implement the bootstrap program for your system. See Chapter 3, Booting a ChorusOS System for more information.
Create the ChorusOS operating system configuration file and build a loadable system image. See "Creating the System Image" for more information.
The last two steps are highly interdependent. Therefore, you must decide how the system image should be configured in order to design the bootstrap program.