How to port an OS to a SoC?

BANGALORE, INDIA: In the article “Making of a SoC”, in PCQ, Oct 2008, I gave an overview of the System-on-Chip solutions which are essentially an integration of almost all components of a computer into a single integrated circuit. We also saw that the software is an essential component of a SoC.

Today's SoCs power most handheld devices that we see around, including mobile phones, MP3 players, navigation devices etc. The visible parts of the software in these devices are the user interface and applications. But there are other essential software components which are hidden, or embedded inside, which take up substantial development and integration effort. One of the main components is the Operating System.

The Operating System provides an abstraction of the underlying hardware by providing a consistent interface to the user and the application programmer. For example, consider the two implementations of Windows CE 6.0 on a SoC (with similar performance) based on:

• MIPS CPU core with a USB 2.0 HW IP from Vendor A
• ARM CPU core with a USB 2.0 HW IP from Vendor B (which is quite different from Vendor A)

In both cases, the user experience will be same because the GUI will be uniform. But the biggest advantage is for the application programmer who writes the top level applications for it, e.g. an application to display photos from a USB pen drive.

The programmer doesn't need to bother about the differences in CPU or the USB HW IP, because Windows CE 6.0 provides a consistent middleware interface to access files on the USB drive, which show up as a disk drive with a uniform file system across all drives (which include hard disks, flash memory cards, pen drives etc.). Also, the display mechanism remains consistent through the MFC library, Win32 APIs, or the DirectDraw APIs, irrespective of the display hardware (LCD controller, graphics accelerator etc.).

The consistency of the Operating Systems comes from the underlying BSP and device driver layers. These layers are ported to every new HW platform or SoC by OS Porting engineers. Let's take a more detailed look into the Operating Systems from the point of view of an OS Porting team.

Types of Operating Systems
Depending on the application, one can choose between two types of OSs. One is RTOS, or real time operating systems like VxWorks or uITRON.

These essentially consist of a real time kernel which provides memory management, scheduling and interrupt handling. Protocol stacks, GUIs and other middleware and applications are usually not a part of these OSs. Typical applications include low end phones and mission critical applications in defence and aerospace.

The other type is a High Level OS, which has features resembling desktop computers. These may or may not have a real time kernel, but usually include protocol stacks, middleware, rich GUI, and many applications. They provide elaborate memory management (virtual memory), scheduling, multitasking and interrupt handling. They are used in feature rich phones and other hand held devices.

Examples include Microsoft Windows CE/Windows Mobile, Symbian, Embedded Linux, etc.

Components of an
Operating System
Broadly speaking, a high level OS as described above has five components. These are the boot loader, Board Support Package or BSP, device drivers, middleware, and finally the UI and applications. It's important to know the function of these components before you can do OS porting.

Boot Loader
This is a piece of software that resides on the non volatile or persistent memory of a computer system, which is responsible for loading the main OS. The need for a boot loader comes from the fact that non volatile memory such as ROM is limited in size and the entire OS run-time image cannot fit into it.

Also, the computer hardware alone (without software) cannot handle complex file-systems and peripherals such as those on hard-disks and flash memories. So, in a typical system, after a power-on or a reset, the CPU starts executing the boot loader code residing in the ROM. The boot loader contains code to initialize peripherals of the CPU to a minimal extent – just enough to obtain the OS run-time image from a peripheral device to the main memory (RAM) and transfer the control to the OS start code.

The boot loader can obtain the OS Image from a local storage device such as a hard disk, compact flash card or download it via a serial connection, Ethernet connection or an USB interface. The boot loader may have to uncompress the OS Image in case it is stored in compressed form.

Modern boot loaders, such as UBOOT (used mostly for Linux) and EBOOT (used for Windows CE) contain a host of other features such as supports multiple CPUs (ARM, PPC, MIPS, X86), Execute from Flash (NOR Flash), File download from serial, Ethernet, USB etc. Some OS terminology may include boot loader as a part of the Board Support Package (BSP).

Board Support Package
The BSP for an operating system is an implementation specific code for a given HW board containing the CPU and other peripheral devices such as memory and memory controllers, timers, interrupt controllers, USB, Ethernet etc. In case of a SoC, a large part of the 'board' is inside the IC, on the same silicon chip as the CPU core itself.

The BSP provides an abstraction of the hardware (CPU and peripherals) to the generic OS interfaces. It facilitates communication between the OS and target HW device and includes code to manage memory, handle interrupts, timers, power management, bus abstraction, generic I/O control codes (IOCTLs), and so on.

The BSP is one of the most complex parts of the OS porting and integration effort and contains code for the following essential OS services:

• Memory Management: The OS may use virtual memory to manage the RAM. The BSP contains code to initialize the Memory Management Unit (MMU) and provide an interface to the higher level OS layers to setup the memory access data structures such as page tables.
• Timer: The OS uses the timer for many functions including task scheduling – which is vital for its functioning. The BSP contains code to initialize the timer hardware as per the needs of the OS.
• Interrupt Handler: All peripherals to the CPU, such as Serial Bus, USB, Camera Interface etc. typically use interrupts to signal the CPU about data availability or data transfer completions. The CPU then executes the appropriate Interrupt service routines (ISR) to take the necessary actions. The BSP initializes the Interrupt mechanism.
• Power Management: The OS needs to conserve power on most devices by providing power saving modes such as Full Power, Hibernation, Sleep etc. When the system restarts, it needs to invoke the correct code to handle the wake-up. The BSP initializes the power management system of the SoC.

Many more functionalities related to the OS operations are a part of the BSP, which need to be implemented or ported in order to make the OS utilize all features of the underlying SoC.

Device Drivers
These are software components that provide an interface to the hardware peripherals connected to the CPU. Each peripheral will have its own device driver. The device driver allows the setting of various parameters associated with the operation of a peripheral, transfer data from CPU to the peripheral or vice-versa, provides polling or interrupts based signalling mechanism for initiation/completion of operation.

It also implements the ISR for the peripheral.For example, the device driver for a camera interface may implement the following functionality:

• Setting the resolution: the camera may supports two resolutions – 320x240 pixels, 640x480 pixels, and the device driver will allow applications to choose between these two modes. For this purpose the driver usually accesses a HW register provided by the Camera Interface, which contains bits to set the resolution.

The driver in turn provides an API through the OS to the applications which is independent of the camera hardware.

• Data transfer: copy the captured image data from the camera interface's memory to the CPU's main memory for further processing.
• Interrupt the CPU, to indicate capture of a frame or multiple frames, and implement the ISR.
  Developing a device driver requires a thorough understanding of the hardware peripheral, including its register set, the data transfer mechanism and the interrupt mechanism.

Drivers are critical components which operate very close to the OS kernel and run in privileged modes. Any bug in a device driver can cause unwanted operation or even crash the system. In addition, each OS provides its own device driver architecture and developers need to understand and adhere to these specifications.

Middlewar
Today's high level operating systems provide a rich set of middleware components which greatly shorten the time taken to develop complex applications. The Middleware components include:

• Protocol Stacks for USB, Ethernet, IEEE 1394 etc.
• Multimedia frameworks such as DirectX on Windows CE and V4L on Linux
• Telephony stacks for interfacing with UMTS/GSM/CDMA Modems.
• 2D Graphics and Windowing System components such as DirectDraw and GDI
• 3D Graphics Libraries such as OpenGL-ES or Direct3D-M

The middleware components may require minor porting to the new HW platform which includes modifications for any changes to device driver interfaces.

UI and Applications
High level OSs also provide rich GUI components and many basic applications such as word processors, telephone applications, address books, media players etc.

Usually the applications are insulated from HW related nuances and may not require any modifications. Presence of the GUI components and applications save a lot of development time and also provide a richer experience to the end-user.

Porting an Operating System
The work involved in porting of an OS to a new HW platform or SoC is complex and time consuming. It requires in-depth knowledge of the HW platform and also the architecture of the OS being ported.

E.g. Linux and Windows CE greatly differ in their kernel and device driver architectures. The OS porting process typically involves the following steps:

Port the boot loader : use a boot loader from a similar SoC platform and modify it to suit the new SoC.

Port the BSP : clone an existing BSP for a similar CPU architecture and modify as needed

Device Drivers : if the peripheral has been available in previous versions of the SoC, the device drivers can be ported to the new SoC with minor changes. But if a new peripheral is introduced in the SoC, then a device driver may have to be developed from scratch

The newly ported system will require thorough testing and may be followed by certification from the OS vendor before it can be released for production use.The task of OS porting is further complicated due to the new releases from OS vendors with substantial changes in architecture. Some updates to the OS version can be as frequent as every 15 days. In order to reduce the time-to-market for products, many times, the OS porting engineers have to work with beta versions of the OS. A stable OS is critical to the success of any HW platform or SoC.

Opportunities in OS Porting
The complexity of OS porting projects requires excellent knowledge and skills and there is a shortage of good engineering resources in this area. Engineering students can make extra effort to focus on Operating Systems and Computer Architecture courses to enter into the field of OS Porting. The resources to learn and practice OS porting for Linux and Windows CE are easily available, free of cost or at a nominal cost. Linux, being open source, is easily available for many popular HW platforms with extensive documentation on kernel porting and device driver architecture.Microsoft Windows CE documentation is available online on the MSDN website and the tools for developing Windows CE BSP, device driver and applications are available for download for free (180 days licence). The tools include Visual Studio 2005 with Platform Builder Plug-in. This comes with a device emulator, which allows prototyping on a PC environment.