Porting an OS to a SoC

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)
  
  

  Direct Hit!

  Applies To: Embedded programmers USP: Understand components of an embedded OS in more detail, how to port it to a SoC, and the career opportunities offered by this space Primary Link: N/A Keywords: N/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.