<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-8A00E047-3DCE-5D02-9ECE-1396DC99DA4B" xml:lang="en"><title>Kernel

Architecture 2 Architecture</title><shortdesc>The Kernel Architecture 2 component has a modular architecture

that allows ports of it to be created for different phone hardware architectures.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>The parts are: </p>

<ul>

<li id="GUID-C48A58F8-0EE9-5AFB-A855-BDC97AD259E1"><p> <i>Nanokernel</i>:

this handles the most basic thread scheduling, synchronisation and timing

functions. </p> </li>

<li id="GUID-42EFCCA1-C585-5A72-B188-8B6B69B41400"><p> <i>Symbian platform

kernel</i>: this provides the kernel functionality required by Symbian platform

using services provided by the nanokernel. It contains the operating system

objects for such things as threads, processes, chunks, and inter-process communication. </p> </li>

<li id="GUID-290A7566-8CC8-538F-930D-62B85FF73E75"><p> <i>Memory model</i>:

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 platform kernel to be MMU-independent. </p> </li>

<li id="GUID-5324322B-BC5E-5D08-BD9A-DA22EC41CFF4"><p> <i>Variant DLL</i>:

this provides hardware dependent services required by the kernel, for example

timer tick interrupts and Real Time Clock access. Systems based on an ASSP

also have an ASSP DLL, which shares some of the variant DLLs responsibilities.

Board Support Packages provides variant libraries for reference hardware. </p> </li>

<li id="GUID-9B456964-8309-54FA-98C7-757D3A51958F"><p> <i>Extensions and device

drivers</i>: these are used to control peripherals and provide the interface

between peripherals and the rest of Symbian platform. </p> </li>

</ul>

<p>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: </p>

<fig id="GUID-9B3AF7EC-8339-5F92-B4BC-20DD3331F103">

<title>           Kernel architectural relationships          </title>

<image href="GUID-C842C016-0D1B-5462-8B04-49CFE941A964_d0e386668_href.jpg" placement="inline"/>

</fig>

<p>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: </p>

<ul>

<li id="GUID-6A229A4C-7FF8-55B8-8D1D-8B7AE098C7EE"><p>Independent </p> </li>

<li id="GUID-D60D5310-1A2C-5A1A-BF45-BB0F05DD5AFB"><p>Platform </p> </li>

<li id="GUID-94475D54-07DE-5F99-8A56-9C5EEBA32F5D"><p>Model </p> </li>

<li id="GUID-9B564245-E1CB-5CFC-93EB-E0F257114532"><p>CPU </p> </li>

<li id="GUID-7AB71CB5-5BF6-5F75-9C17-7EB2A9F9E40D"><p>and two peripheral layers:

ASSP and Variant. </p> </li>

</ul>

<fig id="GUID-EBB913A8-1694-5C98-B38B-1387F850CDB4">

<title>           Kernel source layers          </title>

<image href="GUID-A480F734-9EDF-5E29-AC96-039B71B22AC3_d0e386707_href.png" placement="inline"/>

</fig>

<p>The following is a brief description of each layer and its purpose. </p>

<section id="GUID-5317DC8F-56A2-4AF1-889D-D8E6F4925A0B"><title>Layer 1: Independent </title><p>This

layer is about 60% of the total source code. It provides all the basic building

blocks of both the nanokernel and the Symbian platform kernel. </p></section>

<section id="GUID-4ABDF396-D282-4DDE-975F-7AEBBBE4C0E0"><title>Layer 2: Platform </title><p>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 platform hardware. The windows emulator

provides a single-process emulation of Symbian platform using the PC’s Win32

API, for software development: the Symbian platform hardware starts as a program

running Win32 DLLs and threads, and interfaces with Win32 services rather

than hardware and devices. </p><p>Key differences between the hardware and

the emulator are: </p><ul>

<li id="GUID-109C7BE4-93C2-5848-8A4F-61474E240BAC"><p>The emulator runs in

a single process, and Symbian platform processes are emulated within this.

This means there is no memory protection between emulated Symbian platform

processes. </p> </li>

<li id="GUID-40B1A70F-1813-50ED-9EA0-9DE4C4067FFB"><p>The emulator file system

maps Z: and C: to subdirectories on the user’s PC, so that programs running

under the emulator do not interfere with the majority of the PC’s file system. </p> </li>

<li id="GUID-6E52C610-8600-520F-9958-185C3BC97294"><p>Delayed function calls

(DFCs) always run immediately on the emulator. </p> </li>

</ul></section>

<section id="GUID-AA29E2F8-D6B2-4C14-B983-3CF340BA17BA"><title>Layer 3: Model </title><p>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: </p><ul>

<li id="GUID-38ACBEB0-C5E9-5F6A-BA8F-F6E0BD4EBA90"><p> <i>Moving</i>: 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. </p> </li>

<li id="GUID-18792718-FE86-566F-A82D-7B090AC48007"><p> <i>Multiple</i>: one

page directory per process. This is intended for ARMv6 CPUs. </p> </li>

<li id="GUID-41AB60A6-4A73-5807-9A1E-A48FAC8EB157"><p> <i>Single</i>: 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. </p> </li>

</ul></section>

<section id="GUID-AD70D1A5-E777-4FF3-B247-4F2E94C1D3C7"> <title>Layer 4: CPU</title><p>This

layer provides code which differs according to the processor the OS is running

on. The nanokernel, memory model and Symbian platform 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). </p><p>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. </p><p>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. </p></section>

<section id="GUID-7BA28980-E4B2-4777-AB38-C25DD0B277A3"><title>Layers 5 and

6: ASSP/Variant </title><p>The variant provides the hardware specific implementation

of the control functions expected by the nanokernel and Symbian platform kernel. </p><p>For

some hardware, it may be appropriate to separate support for a particular

ASSP (Application Specific Standard Product), an off-the-shelf integrated

CPU part, so that multiple variants can be produced using the ASSP. </p></section>

</conbody></concept>