<?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 OS 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_d0e365435_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_d0e365474_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 OS hardware. The windows emulator provides a single-process

emulation of Symbian OS using the PC’s Win32 API, for software development:

the Symbian OS 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 OS processes are emulated within this. This

means there is no memory protection between emulated Symbian OS 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>