<?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_d0e381087_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_d0e381126_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>