From Symbian Developer Community

Contents 1 Introduction 1.1 The Symbian base architecture 1.1.1 Kernel architectural relationships 2 What is a base port? 2.1 CPU port 2.2 ASSP port 2.3 Variant port 3 The base porting process

Introduction

The Symbian base architecture

The low-level code that forms the Symbian base (also known as EKA2) has a modular architecture that allows ports of it to be created for different phone hardware architectures. A detailed explanation can be found here but the key parts are:

• Nanokernel: this handles the most basic thread scheduling, synchronisation and timing functions.
• Symbian kernel: this provides the kernel functionality using services provided by the nanokernel. It contains the operating system objects for such things as threads, processes, chunks, and inter-process communication.
• Memory model: this provides per-process address spaces and inter-process data transfer, and governs how memory is allocated and mapped. It encapsulates access to the hardware Memory Management Unit (MMU), allowing the nanokernel and the Symbian kernel to be MMU-independent.
• Variant DLL: this provides hardware dependent services required by the kernel, for example timer tick interrupts and Real Time Clock access. Systems based on an ASSP (Application Specific Standard Part) also have an ASSP DLL, which shares some of the variant DLLs responsibilities. Board Support Packages provides variant libraries for reference hardware.
• Extensions and device drivers: these are used to control peripherals and provide the interface between peripherals and the rest of Symbian OS.

The following diagram shows how the place of the kernel between the low-level user side code, such as the user library, and the device hardware.

Kernel architectural relationships

The implementation of these parts is split into code that is hardware independent, and code that is dependent on the hardware platform. Hardware dependent code is divided into a number of layers to aid its portability to new hardware. The diagram below shows how the kernel source is split into four kernel layers:

• Independent
• Platform
• Model
• CPU
• two peripheral layers: ASSP and Variant.

Layer 1: Independent
This layer is about 60% of the total source code. It provides all the basic building blocks of both the nanokernel and the Symbian OS kernel.

Layer 2: Platform
This layer is concerned with executable images, whether on the emulator or real hardware. Only the memory model has code in this layer. It defines two platforms: the windows emulator and the real Symbian device hardware. The windows emulator provides a single-process emulation of Symbian OS using the PC’s Win32 API, for software development: the Symbian device hardware starts as a program running Win32 DLLs and threads, and interfaces with Win32 services rather than hardware and devices.

Layer 3: Model
This layer provides supports for the organisation of per process memory. Only the memory model has code at this level. There are three types of memory model supported:

• Moving: a single page directory is used and page directory entries are moved between the home and run sections at address space switch time. This is intended for ARMv4 and ARMv5 CPUs.
• Multiple: one page directory per process. This is intended for ARMv6 CPUs.
• Single: a single address space for the whole system. This can be used either for MMU-less CPUs or to allow incremental porting to a new MMU-aware CPU.

Layer 4: CPU
This layer provides code which differs according to the processor it is running on. The nanokernel, memory model and Symbian kernel all have code in this layer. This is the layer where assembly code belongs. Current possibilities for the CPU layer are X86 (real X86 port to PC hardware), ARM (devices) and Win32 (for the emulator).

The nanokernel in this layer contains most of the realisation of the core CPU architecture, such as the exception/interrupt handling, context-switching mechanism, etc. It also contains some functionality which is conceptually part of the independent layer, but has been assembler coded for improved performance, for instance, DFC handling and timer handling on ARM-based hardware.

The bottom layer of the memory model is both CPU-specific as well as specific to the type of memory model. It presents interfaces used by the lower layers (ASSP and variant), and by the memory model and independent layer.

Layers 5 and 6: ASSP/Variant
The variant provides the hardware specific implementation of the control functions expected by the nanokernel and Symbian kernel. For some hardware, it may be appropriate to separate support for a particular ASSP, an off-the-shelf integrated CPU part, so that additional variants can be produced using the same ASSP. Where this occurs, an ASP layer implementation is likely to be provided by a silicon vendor for use with multiple different variants.

What is a base port?

The base code of the Symbian platform is structured so that generic code is separated from hardware-specific code. This means that porting Symbian to new hardware requires modification or creation of hardware-specific code only. This is what is known as a base port, and typically it includes:

• ASSP code for a specific ASIC (Application Specific Integrated Circuit)
• Variant code (board specific)
• Device drivers
• Media drivers

A base port does not require changes to the kernel, file server or user library.

There are three types of base port:

CPU port

Porting Symbian to a new CPI requires a new tool chain, compiler, scheduler, memory management unit, and so on, and is usually done in close collaboration with Symbian or an experienced services supplier.

ASSP port

An ASSP port occurs when a new system-on-chip is available, or a new ASIC is produced

Variant port

A variant port deals with the hardware aspects of development or product design that lay outside the ASSP.

On Symbian, the ASSP and variant functionality can be kept as separate layers or can be combined into one unit. Thus each port is a superset of the previous - a CPU port includes an ASSP port and variant port.

The base porting process

(1) Set up your development environment

The first thing to do is to set up your environment for building, downloading onto your hardware, and testing that the port works. See our quick start article and links for further information.

(2) Acquire a template port

See Template_Base_Ports_for_Symbian^3 for more information.

(3) Code the Bootstrap

The bootstrap is a program that the phone runs after a hardware reset. The task of the bootstrap is to prepare a basic environment for the Kernel to run. If the phone uses NAND Flash, then the NAND Flash Core Loader loads and starts the bootstrap. The Symbian bootstrap is divided into a platform independent layer that can be used with any ARM device, and a platform specific layer that you must implement for a particular ASSP and variant.

The generic source and header files for the bootstrap are all written using the ARM assembler syntax, as are the source files for the template and example ports. However the bootstrap can be built using the GNU assembler; source files are translated from ARM to GNU assembler syntax automatically. The platform-specific source code can also be written in GNU assembler syntax or ARM assembler syntax.

Platform specific bootstrap code must implement a set of standard functions that are called by the generic bootstrap code. It also needs to provide a set of standard MMU permission/cache attribute definitions. Standard functions are organised into:

• a set of public functions that the Symbian OS generic source links to directly
• a set of functions that are contained in a table, known as the boot table.
• a set of entries that define MMU and cache attributes to be used for standard memory and I/O areas; this set of entries is also contained in the boot table.

Note that all bootstrap source code should be position independent, because the bootstrap uses relative address offsets so it can run from any location (Flash, RAM etc).

Further information is given in the Bootstrap Implementation Tutorial in the product reference library.

Further information about Symbian's boot processes is available in Chapter 16 of Symbian OS Internals, the wiki version of which can be found here. The chapter explains the boot sequence that takes the hardware from an uninitialized, powered-off state to one in which the system is fully ready for action, for devices that run Symbian from execute-in-place (XIP) Flash memory, such as NOR Flash. The chapter also describes the differences needed to support non-XIP media, such as NAND Flash.

(4) Implement the Asic class

The Kernel requires that the ASSP/variant part of the base port provides an implementation of the Asic class, defined in ..\e32\include\kernel\arm\assp.h, which contains a number of pure virtual functions.

Where there is an ASSP/Variant split, the ASSP layer should derive a concrete implementation from the Asic class. The most convenient way of implementing the Variant layer is to further derive from this ASSP class. Only the Variant DLL is declared as ‘variant’ in the ROM – the ASSP is declared as an extension. If there is no ASSP/Variant split, then the Variant is simply a concrete implementation of the Asic class.

The ASSP layer can, itself, define additional functions to be implemented in the Variant layer. For example, the ASSP layer defines the pure virtual function VideoRamSize() which the Variant layer provides to map the video frame buffer.

The Product Reference Library contains an Asic Class Tutorial that provides a work through to help you port an Asic implementation to the template variant.

(5) Implement the interrupt dispatcher

An interrupt is a condition that causes the CPU to suspend normal execution, enter interrupt handling state and jump to a section of code called an interrupt handler. The ASSP/variant part of the base port must implement an interrupt dispatcher class to manage interrupts from basic hardware features such as timers.

Further information about interrupts can be found here with additional material (for Symbian Foundation members) in the Product Reference Library here.

(6) Port the Hardware Abstraction (HAL)

The Hardware Abstraction (HAL) component provides a simple interface for programs to read and set hardware-specific settings, for example, the display contrast. A base port must define the attributes that clients can use on a phone, and implement any functions that are required to get and set the attributes. Further information about SHAI, the Symbian Hardware Abstraction Interface, can be found in the dedicated wiki category here.

(7) Port other drivers

Device drivers are DLLs that allow code running in Symbian OS to communicate with peripheral hardware devices, such as comms ports and user input devices, and with other Kernel software that directly manages hardware. User side code, such as applications, do not communicate directly with hardware, but use the interface implemented by the relevant driver.

Device driver DLLs are loaded into the kernel process, and run on the kernel side and use the kernel heap. They may be execute-in-place (XIP) or loaded into RAM. Most drivers are loaded after the Kernel has booted, though some need to be loaded as part of the Kernel boot, in which case they are referred to as kernel extensions.

You can find out more about Symbian's device driver architecture in the Symbian OS Internals wiki book chapter here.

Comments

Sign in to comment…