Getting started with FShell

Note: This guide is in the process of being migrated to the wiki, here: http://developer.symbian.org/wiki/index.php/Fshell/Getting_Started

Retreiving the FShell Source Code

fshell is hosted on the Symbian Foundation here: http://developer.symbian.org/main/source/packages/fshell

To clone the MCL repository, do:

    hg clone https://developer.symbian.org/oss/MCL/sf/os/fshell/

Building FShell

FShell is normally distributed in source code form, and so needs to be compiled before it can be used. The conventional Symbian build tools -- either SBSv1 (aka abld) or SBSv2 (aka Raptor) -- are used. Currently three Symbian OS based platforms are supported:

Each of these platforms have a separate directory within \fshell\build. For some platforms there may be further separate sub-directories for specific variants of the platform. You need to identify a suitable directory (that contains a file named bld.inf) from which to build from. For example to build for the Symbian^3 release you need to build from \fshell\build\sf\3. Open a command prompt and cd to this directory.

You also need to identify the type of binaries you want to build. Common ones are:

Lastly, you need to identify the build variant you plan to use, either debug (udeb) or release (urel). Commonly, udeb is used on the emulator whereas urel is used on target hardware. For the purposes of this introduction we will assume that you will be building winscw udeb and armv5 urel.

SBSv1 (aka abld)

  M:\fshell\build\s60\3>bldmake bldfiles
  M:\fshell\build\s60\3>abld build winscw udeb
  M:\fshell\build\s60\3>abld build armv5 urel

SBSv2 (aka Raptor)

  M:\fshell\build\sf\2>sbs -c armv5_urel
  M:\fshell\build\sf\2>sbs -c winscw_udeb

Note: There are currently some concurrency issues in the build process that mean we don't recommend building multiple platforms in a single invocation of sbs. Ie do the above rather than sbs -c armv5_urel -c winscw_udeb. In some cases you may even need to add the option -j 1 to sbs to have it run completely single-threaded. We'll fix this as soon as we can!

Notes on building for GCC

Fshell has only been tested to build with GCC-E 4.4.1, and the legacy 3.4.2.

Note: The SF website appears to be out of date with regards to how to build with GCC-E on Raptor - at the time of writing the way to build is as follows:

  S:\fshell\build\sf\3>set SBS_GCCE432BIN=Nothing
  S:\fshell\build\sf\3>set SBS_GCCE433BIN=Nothing
  S:\fshell\build\sf\3>set SBS_GCCE441BIN=c:/apps/gcce/bin
  S:\fshell\build\sf\3>sbs -c arm.v5.urel.gcce4_4_1

You may also need to update the compiler support libraries - I had to unzip rt_3_1_bin.zip from \sf\os\kernelhwsrv\kernel\eka\compsupp from a different baseline. (Unzip over \epoc32\release\armv5). The working libraries I used had datestamp of 28/1/2009, the non-working ones were 1/1/2009.

There's one final gotcha if you want to build with GCC-E - at the time of writing the makefiles produced by SBS for PIPS executables is incorrect, therefore you need to add #define FSHELL_NO_PIPS_SUPPORT to \fshell\build\sf\platform_shared.mmh. Hopefully this is a temporary measure.

Installation

Having performed a build, you should have a full set of binaries in your \epoc32 tree. If you want to run fshell on the emulator, no further action is necessary. If you want to run fshell on the simulator or target hardware, then the fshell binaries need to be either added to a ROM image or installed at runtime.

Adding FShell to a ROM Image

This is probably the easiest approach, assuming you have a means of reprogramming the ROM of the hardware you plan to use. By putting fshell in the ROM, the complexities of platform security are normally avoided.

Detailed instructions for building a ROM image for your hardware are outside of the scope of this document, however adding fshell fundamentally boils down to adding \epoc32\rom\include\fshell.iby to your ROMBUILD scripts. Often the easiest way to do this is to add the following line to your main .oby file:

  #include <fshell.iby>

Alternatively, depending on how you're building the ROM you can specify additional .oby or .iby files as command line arguments. For example:

Installing fshell at Runtime

Another product of the fshell build is \epoc32\fshell\fshell.unsigned.sis. This is a Symbian OS install file that contains precisely the same set of files that fshell.iby refers to. There are however some additional hurdles that need to be negotiated in order to be able to install the SIS file.

  1. Most production handset will not allow unsigned SIS files to be installed. The SIS file that the fshell build process produced must therefore be signed first. The Symbian Foundation provide a tool called signsis.exe to perform the signing, however you need to get hold of a suitable certificate to sign with. Refer to http://www.symbiansigned.com/ for more details. Building on some platforms may automatically generate a signed SIS file \epoc32\fshell\fshell.sis if there is a standard certificate for the platform.

  2. By default the fshell build produces binaries that use all security capabilities (including TCB). When they are installed at ROM build time, this isn't a problem. However, SIS files are generally restricted in the set of security capabilities that they can be signed for. To cater for this, you will need to restrict the fshell build to the set of capabilities that you are able to sign for. This is done by editing your platform's platform.mmh (or in the case of platforms that support multiple variants, platform_(generic|shared).mmh). You'll need to replace the following line:

      #define FSHELL_CAP_ALL

    The file \fshell\build\common\common.mmh contains definitions of the complete set of platform security macros that the fshell build system supports. For example, suppose you have access to all the user capabilities, your would replace the above line with:

      #define FSHELL_CAP_MMP_MAX localservices location networkservices readuserdata userenvironment writeuserdata

      #define FSHELL_CAP_LOCALSERVICES
  #define FSHELL_CAP_LOCATION
  #define FSHELL_CAP_NETWORKSERVICES
  #define FSHELL_CAP_READUSERDATA
  #define FSHELL_CAP_USERENVIRONMENT
  #define FSHELL_CAP_WRITEUSERDATA

    The macro FSHELL_CAP_MMP_MAX should be set to all the capabilities that you have access to. There is another macro FSHELL_CAP_MMP_NORMAL which is what most DLLs and EXEs in fshell actually use. The difference is only important if you can sign for all capabilities (ie FSHELL_CAP_MMP_MAX is All) - in this case FSHELL_CAP_MMP_NORMAL is set to All -TCB to make sure you can link against normal DLLs.

    The act of defining the above macros may cause certain fshell binaries not to be built (for example, if the bianry can't do anything useful unless a particular capability is available). However, fshell.iby and fshell.unsigned.sis should automatically accommodate for the missing binaries without any further action on your part. If they don't, please contact the maintainers of fshell because that's probably a bug!

  3. Depending on the configuration of the target handset's certificate store and the key you are signing with, you may also need to use UIDs from the non-protected range. By default the fshell builds with UIDs from the protected range. To change this, remove the definition of FSHELL_PROTECTED_UIDS from your platform's platform.mmh. Note however, that currently the fshell's non-protected UIDs are not properly allocated UIDs. Rather they are the protected UID values but with the top nibble changed from 0x1 to 0xE. It is therefore possible (albeit pretty unlikely) that they could clash with UIDs used in other software.

If you needed to change your platform.mmh to satisfy platform security requirements, you'll need to perform a re-build of the source. It's advisable to run abld reallyclean (or sbs reallyclean) before doing this to ensure that everything is fully re-built.

Having built and signed a SIS file, it can be installed by copying it to a memory card and inserting this in the target hardware. Details of how to do this for your particular hardware are outside of the scope of this document, but normally there's a File Manager type application that can be used to launch the SIS file. Alternatively, some handsets provide a PC Connectivity Suite that can be used to install SIS files from your PC.

Running FShell

Once fshell has been installed, the following icons should appear in the menu application*:

* Note, the folder in which the icons can be found varies between hardware and software platforms. For S60, try looking in "Installations", "Installed", "Applications" or "Applications->My Own".

Copyright

Copyright (c) 2008-2010 Accenture. All rights reserved.