From Symbian Developer Community

This article describes how to create a bootable Symbian ROM image using the Symbian^2 PDK and the iMaker tool. Its purpose is to provide simple instructions for newcomers and experienced developers to get hands-on experience with the Symbian platform.

Contents 1 Key Concepts 2 The real stuff 3 The iMaker tool 3.1 Installing iMaker and associated tools 4 Target ROMs 5 iMaker Syborg scripts 6 Syborg TextShell: Syborg Baseport + TextShell 7 Syborg_FullUI: Syborg baseport + full Symbian UI framework (Avkon) 8 Building an OBY file from scratch - The Puzzle Pieces 9 Booting with the QEMU 10 Going for Symbian^3 UI ROM Images

Key Concepts

System On Chip (SOC)

A single piece of silicon including a Microcontroller (MCU), typically ARM, and a number of other hardware components which connect to external chipsets for GPS, WLAN and power management etc. The components in an SOC typically include System Bus, Direct Memory Access (DMA), memory controllers, display controllers, MMC controllers, USB hardware interfaces, cameras and more general pourpose interfaces like SPI, GPIOs.

An advanced SOC can also include graphics and multimedia accelerators. For example the TI OMAP 3420 SOC includes an ARM Cortex A8 MCU, a 2D/3D hardware accelerator, a multimedia (IVA) accelerator and a lot of additional hardware funtionality.

Hardware Reference Platform (HRP)

A development board comprising an SOC and external chipsets such as displays, Bluetooth, cameras and GPS together with software development tools and reference documentation. Examples include the ZOOM 2 from Texas Instruments , the BeagleBoard and the Zii EGG from ZiiLabs.

Emulator

A software-only runtime executable that emulates an SOC and some peripherals. QEMU & Syborg is a perfect example which emulates an ARM MCU and some basic hardware components.

Kernel Baseport

An "adaptation" of some of the OS level Symbian software packages which allows a PDK to run on a device, an HRP or an emulator.

 

A typical baseport configuration includes the following:

• The hardware adaptation layer components - namely the Symbian kernel, SOC resources support (DMAs, general purpose I/O (GPIO), hardware registers access, etc. ), and SOC and peripherals hardware drivers.
• The Hardware Abstraction Layer (HAL) - A simple HAL with limited functionality, not to be confused with the forthcoming SHAI
• Some power management framework components - This may be a simple adaptation using the power management chipset or may be complex, for example when using DVFS [1] or similar technologies.
• Hardware resources Manager - A component which control certain hardware interfaces, such as GPIOs.
• The file server and file systems - Not always hardware specific but I include them here as they rely on specific driver components related to NAND/NOR/MMC/USB or RAMDISK.

The real stuff

Symbian ROM Image

A Symbian ROM image is a bootable binary file for a specific hardware target. To learn more about the format and contents of a Symbian ROM Image see Symbian OS Internals.

Commercial Symbian device ROMs contain hundreds of binaries, multiple frameworks and a lot of additional files (see the Symbian System Model). That can be quite confusing for starters so for my cooking receipe a will give a very simple vertical view:

• The specific hardware board bootloader
• The Symbian baseport (The Symbian kernel and the drivers)
• Graphics subsystem (This is the start of the serious things. Symbian^2 uses "old" graphics architecture. Symbian^3 uses the New Graphics Architecture (NGA))
• Graphics UI (S60 Avkon, which will be replaced by Qt in Symbian^4)

This is a very simplistic view of the Symbian platform (no comms, no networking, no audio, no multimedia etc.). The reality is rather more complex as there are many dependencies on components out of the scope of those above, but we shall keep it this way for simplicity and easy understanding, and discuss some of the dependencies later.

The iMaker tool

iMaker is a Symbian ROM building tool for creating Symbian ROM images that can be flashed onto hardware or run in QEMU. The tool wraps the buildrom.pl tool.

 usage:
               imaker menu    (for interactive mode) 
               imaker <product_configuration.mk file>  (for a standalone command line)

One of the features of iMaker is the option to distribute the contents of the ROM image between CORE and VARIANT sub-images to enable variants of the same device to be created:

CORE IMAGE -> ROM+ROFS1

VARIANT -> ROFS2

As an example of variant creation, imagine a mobile device targeted at several regions:

CORE_IMAGE.img -> contains the device specific Symbian core and the generic middleware and applications, etc.

VARIANT_EU.img -> contains European language resources, regional specific applications, etc.

VARIANT_JP.img -> contains Japanese language resources, regional specific applications, etc.

So, depending on whether the product is for sale in Europe or Japan, we flash CORE_IMAGE.img + VARIANT_EU.img or CORE_IMAGE.img + VARIANT_JP.img.

Installing iMaker and associated tools

These instructions assume that you have a Symbian^2 or Symbian^3 source tree installed on your PC hard drive and subst'ed to an independent drive.

• Get a snapshot of the "sftools" source repository and locate the buildrom and the iMaker tools:

Z:\sftools\dev\build\imgtools                                 ( Z: is my "substed" image ) 

• Install the following tools by navigating to the approprate directory and running the sbs command.

1. Buildrom: Z:\sftools\dev\build\imgtools\buildrom\group
2. iMaker: Z:\sftools\dev\build\imgtools\imaker\group
3. iMaker plugins: Z:\sftools\dev\build\imgtools\imaker\buildrom_plugins\group
4. ROM tools: Z:\sftools\dev\build\imgtools\romtools\group
5. Z:\sftools\dev\build\imgtools\iad_rofs\group [--Tw 2: What's this? I can't find a reference in the build package]
6. Imgcheck: Z:\sftools\dev\build\imgtools\imgcheck\group
7. SIS utils: Z:\sftools\dev\build\imgtools\sisutils\group

Target ROMs

The purpose of this article is to give you a building block upon which to build ROMs for your own purposes. I anticipate that most developers will have one of the three (Syborg) ROM building objectives:

• Syborg_TextShell: Syborg Baseport + TextShell

This is a target for a developer working on board porting activities or device drivers, a kernel hacker who wants to write a scheduler or play with threads and priorities, and anyone who simply wants to have a look inside a realtime kernel and learn how it works.

• Syborg_Simple_Graphics : Syborg Baseport + Graphics Framework + TextShell

This target is likely to be useful for testing OS-level functionality with frameworks like graphics or multimedia that do not require a full UI. I imagine that such a target will be ideal for people with new external chipsets such GPS, WLAN, hardware accelerators, sensors or audio.

• Syborg_FullUI: Syborg Baseport + Full UI Framework (Avkon)

This target is for people who want to develop UI applications and customisations, and use UI widgets.

iMaker Syborg scripts

iMaker expects to find configuration files and scripts in epoc32\rom\config. The scripts described in this document are not currently included in PDKs, but a set suitable for Symbian^2 are available in File:Syborg config.zip.

The contents of Z:\epoc32\rom\config are:

               \syborg
               image_conf_buildinfo.mk
               image_conf_naming.mk
               system_languages.mk

Apart from the \syborg directory, the rest are generic top-level configuration files for iMaker. They do not contain specific information for the Syborg platform.

Open the Z:\epoc32\rom\config\Syborg\ directory.

It is useful to think of iMaker as a device creation tool. A target device is based on a hardware platform which, in turn, is based on a processor family. For example:

Omap34xx\Zoom2\my device1

\my device2

The iMaker directories are organized like this (see the #includes in the .mk files), to provide a structured way of creating different final images for various devices and hardware platforms based on the same source code.

Syborg is relatively simple as the MCU, platform and target device are the same. That's why the most of the .mk files are empty. ☺

Z:\epoc32\rom\config\Syborg\platform directory

This is more interesting as it contents the important configurations files:

                image_conf_Syborg.mk
                image_conf_Syborg_tshell.mk

Those are Imaker configuration scripts. There is two separate files one for every image target. One is for create the textshell image and another one is for create the UI image ( the only reason to create those files here and not in the upper directories is because seems the imaker menu try to find those here so now the imaker menu should display the two options under the PRODUCTS label.

               syborgMasterFullUI.oby       -----> for image_conf_syborg.mk
               syborgMasterTextShell.oby  ----->  for image_conf_syborg_tshell.mk

Those are called inside the .mk files and defines the rom contents, there is two differents as the contents of the rom are quite different.

Other Baseports

It is possible to add different baseports without mixing any of them, directories should be added here in Z:\epoc32\rom\config , as the scripts are inside the folders, we can generate images for every target on a very stand alone way without affecting each other, so one snapshoot on how should looks like as an example:

               \Beagleboard
               \confml
               \Syborg
               \Zoom2
               image_conf_buildinfo.mk
               image_conf_naming.mk
               system_languages.mk

Syborg TextShell: Syborg Baseport + TextShell

syborgMasterTextShell.oby

The .oby file is the master file that describes the contents of the image. Here is a simplified version of the file, together with some comments, to help you understand the contents.

 
include "./Header/header.iby"                       - EABI and DEBUG_DIR defines for iMaker
include "./baseport/syborg_baseport.iby"       - Bootloader, Symbian kernel, debug, trace systems and drivers
include" ./F32/F32.iby"                                 - File server, file systems, Symbian domain manager
include "./baseport/syborg_textshell.iby"       - Syborg textshell
 

The Syborg baseport is quite simple. It requires a fairly standard kernel, user library and screendriver (for UI ROMs). The rest, like the starter, is Syborg specific.

Using the iMaker menu

• 2 to select the tshell script that will use the syborgMasterTextShell.oby.
• t3 to indicate we want a core image.
• Toggle u to indicate if we want urel/udeb/udeb full ( urel should be fine ).
• S To create the image Symbols for debug later.
• Enter

If everything is correct the image Syborg.rom.img is created in Z:\epoc32\rombuild\Syborg\core and is ready to run on QEMU.

The scripts also work for Symbian^3. There is an issue which affects the building of UI ROMs. SYMBIAN_FEATURE_MANAGER is defined by default in Symbian_OS.hrh in v3.0b and must be undefined to build a UI ROM.

Syborg_FullUI: Syborg baseport + full Symbian UI framework (Avkon)

Overview

This is more interesting as it enables the build and boot of Symbian ROM image with a fully functioning UI. There are some differences in the process from the textshell build, but most of the differences are in the OBY file.

The image requires a lot more content and small changes to some components to boot in the QEMU emulator.

OBY contents

All of the components must have exported their IBY files (the files that locate their exports in a ROM image) correctly to Z:\epoc32\rom\include. In practice it might be necessary to find some IBY files and move them manually! (Or see File:Missing ibys.zip for some suggested changes)

There are binary dependencies between components which mean that some DLLs require other DLLs to be in the image even if their primary functionality is not required. iMaker has a tool to check for dependencies so it is quite simple to trace any missing DLLs and add their IBY files to the OBY file.

There are two ways to create an OBY file with the UI content for a ROM:

Method 1

Include all of the IBY files in Z:\epoc32\rom\include and its subdirectories in the OBY file.

This puts all of the components available in the System Model into the ROM. Gareth Long, also from the Foundation, uses this aproach to create a full UI ROM image for Zoom2. This method can be semi-automated using a script to search for IBY files.

Method 2 

Build the OBY file from scratch.

This is what I did. I built a custom OBY file based on the just the components that I needed and resolved all of the dependencies between the DLLs. I wanted to control what is in the image and, more importantly, to learn how to "strip down" the Symbian platform and find how the system can be optimized from a software architecture point of view.

My objective was to create a minimal system, able to launch the splash screen, the S60 menu (matrix menu), move between icons and start some simple applications like Calculator and Calendar. That should have required only a minimal number of components but I ended up with quite a large component list, including many whose functions I did not require.

There are some reasons for this. One is Avkon (the S60 Graphics and application framework) itself. The Avkon components are part of the Classic UI package and some of them have a lot of binary dependencies on DLLs spread over all the system model, including some which appear to be completely unrelated. For example the Skin Server is dependant on DRM (Digital Rights Management) DLLs

Such interdependency might be acceptable if Avkon, as a middleware (mw) component, were only dependant on components at the same or lower levels, but I found that it is dependant on the messaging package in the application (app) level.

Further issues include AknCapserver (one of the main core components of S60 apps) starting the telephony subsystem, and UI widgets, like the clocks status pane, controlling hardware (lights) directly through a connection to the hardware resource manager.

I found that the S60 Matrix Menu and apparently simple apps like Calendar (and even Calculator) are not easy to cut out from architecture point of view. For instance Matrix Menu is a complex app which relies on several subsystems for controlling menu contents and listening for system signals like battery level and or network strength. Calendar seems to be quite a big framework as it provides a full calendar engine to control alarms, events, and notes for other apps.

Such hardware and software dependencies are justifiable as the target for S60 is a mobile device with a battery, lights, an antenna and a full suite of applications. However, for people who want to disable or remove some parts ofS60 it is not straighforward, and in some cases even requires hacking the source code. So there is plenty of interesting stuff to have a look at! ☺

An interesting project, which is possible now that Symbian is open source, is some "cleaning or reinspection" of the "old" avkon architecture to make the framework more "agile", remove some depencies and make it more "plugable" to separate the UI.

Avkon itself is a complete framework that, with good hardware acceleration, could do more. But there is a mix of UI layers with Avkon, Eikon and Cone that makes it a little difficult to follow how the UI is constructed. The combination of device dependencies, like telephony and hardware, together with the distribution of the UI between frameworks makes UI system behaviour difficult to follow even for simple processing, and I am quite suspicious that many extra messages going here and there are affecting the UI response time and things like device startup.

Building an OBY file from scratch - The Puzzle Pieces

Here is my OBY file:

syborgMasterFullUI.oby

 
#include "./Header/header.iby"                         
#include "./baseport/Syborg_baseport.iby"                
#include "./F32/F32.iby"                                  
#include "./systemModel/os.iby"
#include "./systemModel/mw.iby"
#include "./systemModel/app.iby" 
 

This began the same as the texshell version. The noticeable differences are the use of a proper screendriver for Syborg, and the S60 content based on the "Symbian Foundation System Model".

The Symbian platform is defined by a System Model based on three different levels. I tried to follow this organization as closely as possible, but there are some internal dependancies in \epoc32\rom\include. Go and inspect the content of the os.iby, mw.iby and app.iby. I know there are some things to do here to make the things more clearly but, hey, this is a proof of concept ☺.

The starter files

Symbian launches the S60 UI through a component called "Sysstart". If we go back to the textshell example, there is a Syborg specificn "Sysstart" that launches the textshell only.

For S60 there are more sopisticated components in Z:\sf\os\devicesrv\sysstatemgmt. The components depending on the version of Symbian:

• Symbian^2: Starter
• Symbian^3: System State Manager

As this example is based on Symbian^2 I will focus on the starter component.

The starter component uses the starter_arm.rss file, located in Z:\sf\os\devicesrv\sysstatemgmt\starter\starterserver\data, to determine the the sequence of components to be started. The emulator seems to use the starter.rss. The starter is based in a state machine launching the proper processes list depending on the selected booting sequence.

As before the starter_arms.rss file is based on a mobile device , so there several "starting" modes like Normal Mode, Test Mode, Off Line Mode, Alarm Mode, etc. the interesting for me is the "Normal Mode" sequence:

//SSSC_INFO
       //    {
       //    sssc = r_pre_ui_services_sssc;
       //    },
       SSSC_INFO
           {
           sssc_state = EStrtStartingUiServices;
           sssc_mode = EStrtModeNormal;
           sssc = r_start_ui_services_sssc;
           },

RESOURCE SSSC r_start_ui_services_sssc
   {
   items =
       {
       r_ssc_item_sysagt
    //Emilio , r_ssc_item_rfsfirstboot
    //Emilio  , r_ssc_item_rfsdeep
    //Emilio  , r_ssc_item_rfspreui
     , r_ssc_item_fbsrv
     , r_ssc_item_wserv_arm
     , r_ssc_item_tzsrv
     , r_ssc_item_cntsrv
    // , r_ssc_item_dbrecovery
     , r_ssc_item_hwrm
    // , r_ssc_item_accsrv
     , r_ssc_item_mediator
     , r_ssc_item_setpalette
     , r_ssc_item_splash
     , r_ssc_item_randsrv
     , r_ssc_item_apparc
     , r_ssc_item_akncapsrv
    // , r_ssc_item_rfspostui
       };
   }

RESOURCE SSSC r_critical_apps_normal_sssc
   {
   items =
       {
       r_ssc_item_menu
    //   ,r_ssc_item_idle
       ,r_ssc_item_startup
    // , r_ssc_item_sysap
    // , r_ssc_item_phone
    // , r_ssc_item_nitz
    // , r_ssc_item_touchscreen
    // , r_ssc_item_touchplg
    // , r_ssc_item_profmon
       };

You can see here how i "customized" my startup .rss file , at first i don't need those preui or first boot processes as those seems to cause some resets on QEMU Syborg uses just a RAM Disk as C: drive so it could be this is the reason.

My focus is on a Graphics UI , so i don't want things like Accesory server or launch more than the Matrix Menu. At first Matrix Menu launchs in the background so the startup component is needed to show the S60 wellcome application and put the menu at the front.

NOTE: I think it would be also interesting to launch the idle app. The idle app is the front application 
that could be seen in a S60 device. My ROM oby is not complete so i could not be able to boot the app 
as probably some component at runtime is missing, but once those components are found  and put in 
the ROM , the app should run properly.

Now you know how to customize the startup for Symbian^2. I guess once the AknCapserver is running , is possible to replace the rest with another S60 applications like an OpenGL Demo , or a custom desktop demo. By instance one interesting exercise is include the QT libraries and run some nice graphics demo :).

So to put this starting sequence to work you need to recompile the startup component with the sbs-c armv5 command.

NOTE: Seems that the file sysutilinternalpskeys.h is missing or not exported properly so after fix it it should compile fine

Windows Server Configuration Files

z\syborg\system\data\wservu_qvga.ini

Another file that needs to be configure is the windows server .ini file. Basically any name is fine, as long as is properly referenced in the oby file as this:

data=DATAZ_\syborg\system\data\wservu_qvga.ini            system\data\wsini.ini

This file is the place were the windows server defines the screen parameters affecting the layouts by instance together some other windows server features.

I defined my screen as QVGA 320x240 Portrait Mode

[SCREEN0]
SCR_WIDTH1 240
SCR_HEIGHT1 320
SCR_ROTATION1 0
//SCR_TWIP_WIDTH1 2235
//SCR_TWIP_HEIGHT1 3973 
S60_SCR_STYLE_NAME1 QVGA 
.
SCR_WIDTH2 320
SCR_HEIGHT2 240
SCR_ROTATION2 270
//SCR_TWIP_WIDTH2 3973
//SCR_TWIP_HEIGHT2 2235
//S60_SCR_SOFTKEY_LOCATION2 right
S60_SCR_STYLE_NAME2 QVGA 

NOTE: It is possible to play with the resolution of the screen. But make sure that there is a proper 
  layout for it include it in the Oby file  those are included in the mw.iby file , i did not tried so much with 
  another ones ,so not sure if works or not  but  those not used can be removed and save some space 
  in the ROM image
.
#include <.\core\mw\AknLayout2_double.iby>
#include <.\core\mw\AknLayout2_hvga.iby>
#include <.\core\mw\AknLayout2_low.iby>
#include <.\core\mw\AknLayout2_nhd.iby>
#include <.\core\mw\AknLayout2_hvga_touch.iby>
#include <.\core\mw\AknLayout2_qhd_touch.iby>
#include <.\core\mw\AknLayout2_qvga_touch.iby>
#include <.\core\mw\AknLayout2_qvga1.iby>
#include <.\core\mw\AknLayout2_qvga2.iby>
#include <.\core\mw\AknLayout2_vga3.iby>
#include <.\core\mw\AknLayout2_vga.iby>
#include <.\core\mw\AknLayout2_vga_touch.iby>

Windows Server WSINI Reference: [2]

SVGEngine

SVG Engine , is the component in charge of draw many of the UI stuff like skins, icons, decorations, etc. Not sure about the avkon widgets and controls like panels, labels and so on but probably this is the component in charge of that.

There is two working modes of the SVG Engine , one is in top of the OpenVG libraries ( hardware accelerated or based in a software implementation of the OpenVG ) or using SVG Engine internal 2D rasterizers. There are some defines in the components to enable those options, so depends how the compile wants to be used you need to define those macros and recompile.

As Symbian^2 officially does not have OpenVG software implementation i will use the SVG Engine as stand alone providing a OpenVG Stub dll's to solve some binary dependencies with another component called nvgrecognizer used for some other special icons and images.

NOTE: There is a OpenVG reference software implementation based on Khronos somewhere in the FCL. Sucesfully made to 
work for another guys in the foundation and i think will be part of some future Symbian^2 PDK

Italic text

Booting with the QEMU

Launch QEMU as follow

Z:\symbian-qemu-0.9.1\bin>arm-none-symbianelf-qemu-system.exe -kernel Z:\epocrombuild\Syborg\core\Syborg.rom.img 
          -M Z:\symbian-qemu-0.9.1\bin\syborg.dtb

Here it is the Symbian Logo

Here it comes the S60 Wellcome Animation

A nice Matrix Menu

Calendar app running

NOTES:

The good news is besides the shoots , the graphics looks exactly same as a real device , the speed it could do better ( by instance there is some flickering in the S60 animation or movign between icons ) but is very acceptable to be an emulation. so i am quite surprise how well it behaves :)

The bad news is that is not so straighforward to boot, currently as it is if i did not forget to record some changes it could be possible to get the Symbian logo on the screen , for avkon and the matrix menu i had to make some more extra changes

AknCapServer Changes in ClassicUI package

Uikon

The first thing you will find without any modification will be a EIKON PANIC 82 error , this is because a HAL::SET function is called several times , and the assert seems is not correct.

eikvcurs.cpp 
 void TEikVirtualCursor::SwitchOffEmulationAndBitmap(CCoeEnv& aEnv)
 #ifdef _DEBUG
  TInt error=HAL::Set(HAL::EMouseState, HAL::EMouseState_Invisible);
  //Emilio __ASSERT_DEBUG((error==KErrNone || error==KErrNotSupported),Panic(EEikPanicVirtualCursorUndefinedError));
 #else
    HAL::Set(HAL::EMouseState, HAL::EMouseState_Invisible);
 #endif

SoundThread

- Avkon itself has a thread that takes care of the key tones . I had some problems here to make it work , in practice seems some dlls were missing or i could not find those or something else, so i manually disable in the code this part.

AknNoteDialog.cpp
EXPORT_C void CAknNoteDialog::PlayTone()
   {
    #ifdef AVKON_RDEBUG_INFO
   RDebug::Print(_L("CAknNoteDialog::PlayTonez"));
   #endif
   if (iTone != 0 && SoundSystem())
       {
       //Emilio SoundSystem()->PlaySound(iTone);
       }
   }

Eikkeysoundserver.cpp 
Some changes in the server  to cheat a litle bit :) 
void CEikKeySoundSession::DispatchMessageL(const RMessage2& aMessage)
void CEikKeySoundSession::ServiceL(const RMessage2& aMessage)

Comms Framework

- I wanted to cut just only the UI , so i also disable in the code the parts were the C32 servers and the code is started

EIKSRVUI.cpp
#if 0 // Emilio ,. WE dont want comms 
   TInt err = StartC32();
   if (err != KErrNone && err != KErrAlreadyExists)
       {
       User::Leave(err);
       }
   
   err = User::LoadPhysicalDevice(COMMS_PDD_NAME);
   if (err != KErrNone && err != KErrAlreadyExists && err != KErrNotFound)
       {
       User::Leave(err);
       }
       
   err = User::LoadLogicalDevice(COMMS_LDD_NAME);
   if (err != KErrNone && err != KErrAlreadyExists && err != KErrNotFound)
       {
       User::Leave(err);
       }
#endif //Emilio 

Hardware Resource Manager - Hardware Lights

- That was more harder to find , there are some problems on this call:

  iLight = CHWRMLight::NewL( this );

This is used in several components also in MatrixMenu but in avkon is here:

 AknSkinnableClock.cpp
 AknStatuspanedigitalclock.cpp
 AknAnimKeySound.cpp

Really not sure if there is some missings dlls or what , but the imaker seems to complain as well in

2) ..\..\..\..\epoc32\rom\include\core\os\HWResourceManager.iby(74): 
                                          Missing fie: '\epoc32\data\Z\private\101f7a02\HWRMLightsPolicy.ini' 

This file is not exported correctly in the build. This could be reason why the call crashes. i was just playing around in the code so , i hack this parts in the components. but probably is worth to fine the correct fix here :)

Matrix Menu in Homescreen Package Changes

The Matrix menu is in the Homescreen package in App level in the Symbian Foundation platform, basically here:

Our old friend is found in the hierarchyNavigator component used by the Matrix Menu to "navigate" between the menus:

        hnengine.cpp
        iLight = CHWRMLight::NewL(this);

and also something related with my cut with the comms , telephony and so on , the matrix menu has a widget to show the SAT signal levels and also showing the operator names, so it creates a connection with a component called SATSERVER in charge of this.

The components dealing with this are not in the app level , indeed are part of a MW package calle homescreensrv

so , here:

Z:\sf\mw\homescreensrv\menucontentsrv\extsrc\mcsathandler.cpp
void CMcsSatHandler::ConstructL()
   {
   //Emilio iSatSession.ConnectL();
   //Emilio iSatIcon.OpenL( iSatSession ); 
   }

and here:

Z:\sf\mw\homescreensrv\menucontentsrv\srvsrc\menusrvappscanner.cpp
//Emilio	iMcsSatNotifier = CMcsSatNotifier::NewL( this, KCRUidMenu, KMenuShowSatUI );

and thats all , i guess now the matrixmenu should show in the QEMU but buzz me if there is still some issues that i did not documented here :)

Going for Symbian^3 UI ROM Images

Moved here:

http://developer.symbian.org/wiki/index.php/Creating_Symbian_S60_UI_ROM_Images_for_QEMU_using_Imaker_Tool_II[3]

Comments

Contents 1 Arunabha said… 2 William roberts said… 3 Mkujalowicz said… 4 William roberts said… 5 Emilio Jose Coronado Lopez said… 6 Elves said…

Arunabha said…

William roberts said…

Mkujalowicz said…

William roberts said…

Emilio Jose Coronado Lopez said…

Elves said…

Sign in to comment…