Symbian Kernel &

Hardware Adaptation
Mark Wilcox
Technology Manager Kernel & Base
Symbian Foundation

1
What am I talking about?
 What is hardware adaptation?
 Terminology
 The current situation
 Where are we now?
 Competitive position
 Technical challenges & advantages
 Business challenges & advantages
 The Symbian Kernel
 A brief history
 Present and future
 SMP & hardware adaptation
 Steps to more supported hardware
 SHAI
 Stem Kit

2
Why should we care?
 Much of the Symbian OS layer is technically better suited to
mobile & embedded systems than the alternatives

 If you can build apps with Qt and they run on multiple

 Current challenges with Symbian hardware adaptation can

3
What is hardware adaptation?
 Hardware adaptation is the software which enables a
platform or operating system to run on a specific piece of
hardware.
 It’s useful to think of it as consisting of essential adaptation
and device or feature enablers.
 Essential adaptation consists of the drivers and initialization code
required to get a device to boot and run the operating system kernel.
 Device and feature enablers are drivers and other hardware specific
code needed to support things like telephony, Bluetooth, WiFi, GPS,
memory cards, hardware graphics acceleration, audio and video.
 This code is typically implemented by the silicon vendors to
support their components.
 Hardware adaptation code is specific to both the hardware
and the software platform.

4
Terminology
 Hardware components are integrated on a
Printed Circuit Board (PCB) – we call this
PCB populated with components a “board”.
 The main CPU(s) are typically integrated
with other peripheral devices in one chip
known as an Application Specific Standard
Product (ASSP) or System on Chip (SoC).
 On Symbian the essential adaptation is
called a baseport. It should be reusable
between boards with the same SoC.*
 Devices connected to the main SoC are
external peripherals. A board with a specific
SoC and set of external peripherals is
sometimes referred to as a “Variant”.
 All of the adaptation code for a specific board
is known as a Board Support Package (BSP).
This term is common across platforms.

* With minor modifications depending on thing like

5
The Current Situation

6
Where are we now?
 There are 3 boards with some level of
publically available BSP for Symbian:
 OMAP Zoom II (binary only)
 BeagleBoard
 NEC NaviEngine
 The first two have almost identical SoCs.
 There are other boards with closed source
BSPs used in existing phones but…
 None of these other BSPs are currently
available to new OEMs.
 There are BSPs being developed for more
modern hardware that should eventually be
available for licensing.

7
Competitive Position
 Silicon vendors typically write Linux adaptation code for
their hardware as part of the development process.
 Several competing platforms are Linux-based so
development effort and hardening is shared.*
 As a result almost all components targeted at mobile
devices have Linux adaptation code available, although it
often isn’t product quality.
 There is some legal uncertainty around closed source
adaptation for Linux, not obviously acting as a deterrent.
 Microsoft pays to have hardware adaptation created for its
mobile platforms.

* Or it would be if Google hadn’t forked the Linux kernel for Android! However, see
Linaro for an excellent shared development initiative in this area.

8
Technical Challenges
 Linux kernel is C, Symbian is C++ and the driver model
is different. This makes it quite difficult to port
adaptation code from Linux to Symbian.
 There are very few publicly available examples of good
Symbian adaptation code, so it’s hard to get started.
 There’s room for improvement in the usability and
documentation of several Symbian platform
development tools.
 Dependencies between subsystems
mean a lot of adaptation work is
required to get the UI to boot.
This impacts development and
testing schedules negatively.

9
Technical Advantages
 Symbian can achieve good performance on less
powerful hardware than a similar Linux-based device.
 Symbian’s real-time kernel can support a cellular
protocol stack on the same core as the applications
without the need for hypervisor technology.
 Symbian has a much smaller ROM & RAM footprint than
a typical mobile Linux distribution.
 Symbian has always worked closely
with ARM and so the code takes
better advantage of the ARM
processors found in almost all
mobile devices. This advantage
extends further on SMP systems.

10
Business Challenges
 As Nokia is the predominant Symbian device manufacturer,
there is limited interest in writing Symbian adaptation code
without a strong interest to conduct business from Nokia.
 Due to its commercial history, there’s shortage of low-level
Symbian development skills in the open market.
 It is only economically viable for an OEM to develop the
adaptation themselves only if they plan to ship in large
volumes.
 Chicken and egg – limited number of OEMs without good
hardware adaptation offering, and limited hardware
adaptation without attractive OEM demand.

11
Business Advantages
 The technical advantages listed before mean lower BoM
cost and therefore cheaper devices, more profit or both.
 Symbian’s EPL licensing and patent policy allow genuinely
free use of the platform, no additional components are
effectively mandatory to license. Binary drivers are clearly
permitted with the EPL whilst this isn’t clear with the GPL.
 You can fork anything or use alternate components as long
as you retain the compatibility of the public APIs. This
allows differentiation almost anywhere in the platform and
hardware.
 No central authority mandates specific hardware.
 Genuinely open source development model means that
changes can be integrated and no single OEM gets the
latest code significantly ahead of everyone else.

12
We’ll discuss how to overcome
the challenges at the end, but
first, lets remind ourselves
why we should make the
effort…

13
The Symbian Kernel

14
A Brief History (Part I)
 The first incarnation of the current Symbian kernel goes
back to Psion in 1990 – it was part of EPOC16 and shipped
in the Psion Series 3 devices.
 This product range was sold from 1991
to 1998 with as little as 256kB RAM
running for up to 35 hours on 2 AA cells.
 In 1994 development started on a 32-bit rewrite of the
operating system in C++ with similar design philosophy.
EPOC32 shipped in 1997 on Psion Series 5 devices running
in 4-16MB RAM with a full app suite.
 These were the first ARM-based EPOC
devices. They had a 640x240 touch
screen (although only 16 greyscale).

15
A Brief History (Part II)
 In 1998 Symbian Software Ltd was formed and the OS
formerly known as EPOC32 became “Symbian OS”.
 The same year a new architecture for the kernel was
conceived to ease porting to new hardware and enable real-
time guarantees to support a cellular protocol stack.
 EPOC Kernel Architecture 2 (EKA2) introduced a new nano-
kernel within the existing microkernel.
 Many, many smartphones shipped with the original kernel
architecture between 2000 (Ericsson R380) and 2006.
 The first products using the new kernel shipped in 2006
with Symbian OS v9.1 and S60 3rd Edition, introducing
a new platform security architecture and a new ARM
ABI at the same time.

16
Present and Future
 The major new kernel features in recent Symbian
versions are demand paging and symmetric multi-
processing (SMP).
 Demand paging allows the kernel to load code and data
when it’s needed, paging relatively unused sections out
to Flash – this enables products to include significantly
less RAM than they would need otherwise.
 SMP is supported via a new nano-
kernel. Intended to conserve
power while increasing peak
performance.
 New 64-bit support in file server.
 ARM are working on support for
their new Cortex-A15 processor.

17
Challenges Experienced with
SMP Hardware Adaptation
 Demand paging exposed several timing-related bugs in existing
code. Assumptions about thread execution order based on priority
were falsified when a thread could be suspended after a page
fault, waiting for the appropriate page to be loaded.
 Hardware adaptation developers avoided this pain because the
kernel and drivers cannot be paged.*
 SMP brings the same challenges to low-level code, only worse!
Code now runs on multiple CPUs at the same time.
 Device driver threads can run on different cores to their ISRs. This
can cause significant problems with the cancellation of NTimers
and TDfcs. New synchronous cancellation APIs have been added
to fix this.
 These paging and SMP migration problems are common across
platforms. They are typically less painful on Symbian because of
the event-driven design of most of the system.

* Although drivers need to be extremely careful about accessing paged memory.

18
Steps to More Supported Hardware…
 What can be done to resolve the current
situation and provide choice in off-the-
shelf hardware adaptation for Symbian
platform OEMs?
1. Make it easier to write new hardware adaptation
2. Make it easier to port existing hardware
adaptation code from Linux
3. Make it easier to test/evaluate Symbian on less
complete hardware adaptation
4. Fund the creation of selected new hardware
adaptations
 What is being done now?
1. SHAI – Symbian Hardware Abstraction Interface
2. Much talk about Linux portability layer or use of
virtualization technology – not much action yet
3. Stem Kit – project to break dependencies
between subsystems to create vertical UI slices
4. Open source foundation can’t select and fund
silicon vendors, this must come from OEMs

19
SHAI
 This initiative is aimed at standardising Symbian hardware
abstraction interfaces and moving them closer to the
hardware where appropriate.
 This means less new adaptation code has to be written and
investment is preserved across devices and OS versions.
 In many areas Nokia is opening the source to common
adaptation code to fill the gap.
 The APIs are being defined and agreed by a working group
at the Symbian Foundation.
 When there has been sufficient experience implementing
them they will become public APIs under change control.
 Details of specific SHAI APIs and current status is here:
developer.symbian.org/wiki/Kernel:SHAI/SHAI_API_Proposals
 Documentation is migrating to a new portal at:
kernel.symbian.org

20
Stem Kit
 The Stem Kit project aims to break dependencies between
subsystems in the platform so that you can bring up parts
of the UI with a minimal baseport then add more of the
platform in discrete chunks when its supporting adaptation
code is available.
 Amongst other benefits this should speed up the product
development process, reduce risk to projects and allow
early evaluation of new hardware platforms.
 The “Stem” is the core minimal subsystem supporting some
UI and preferably basic networking (running a browser).
 Other subsystems such as telephony, multimedia, location,
bluetooth etc. should be modular additions to Stem.
 For more details on what’s being done and why see:
developer.symbian.org/wiki/Stem_Kit_Incubator_Project

21
Questions?

22
Appendix - Driver Migration Advice
 The first thing to do before migrating to SMP hardware is to test
the drivers on a single core with the “crazy scheduler” and fix any
bugs revealed by this testing!
 To assist with migration there is a flag for the kernel build which
locks all kernel threads to CPU0. This is currently the default but
that will be changed in the near future.
 Restore it by setting SMPLOCKKERNELTHREADSCPU0(on) in the
relevant iby file for your baseport/BSP, then you can unlock
individual threads for testing/fixing by setting their CPU affinity to
KCpuAffinityAny manually.
 All interrupts are also currently locked to CPU0 but this is planned
to change with the implementation of interrupt balancing. You can
future proof your driver code against this feature by using “crazy
interrupts”. To do this CRAZYINTERRUPTS(on) can be set in your
iby file.
 Much more info, advice and common patterns available at:
developer.symbian.org/wiki/Kernel:Device_Driver_SMP_Safe_Migration_Guide

23