Development environment
The development environment for maemo running on the desktop is called maemo SDK. It will only install and run on a Linux operating system. Supported Linux distributions for maemo SDK are currently Debian and Ubuntu, but installing maemo SDK is also possible for other distributions. On other operating systems such as Windows, a VMWare image can be used to provide a working Linux environment.
1. Maemo Software Development Kit
The maemo SDK creates a sandboxed maemo development environment on a GNU/Linux desktop system largely built on a tool called Scratchbox. In most ways, this environment behaves like the operating system on the device, but with added development tools. This means that the development process is very similar to a normal desktop GNU/Linux, and the kinks of embedded development, such as cross-compiling, are handled transparently by Scratchbox.
Scratchbox is a specially packaged "sandbox" environment, providing the necessary tools and also isolating the development efforts from the real Linux system. Scratchbox also makes it easy to perform cross-compiling, which means building the software into a binary format that is executable in the target device.
The name "Scratchbox" comes from "Linux from scratch" + "chroot jail" (sandbox). This also tells something about its implementation and intended use. While working inside Scratchbox, programs will be running in a changed root environment (chroot). In Linux systems, it is possible to change the part of file paths that a process will see. Scratchbox uses this mechanism on start to switch its root directory (/) to something other than the real root. This is part of the isolation technique used. Because of this, the environment is called a sandbox, a private area where it is possible to play around without disturbing the environment, and without all the mess that real sand would cause. The other parts of the isolation technique are library call diversions (using LD_PRELOAD), wrapping of compiler executables and other commands.
Scratchbox:
- Is a software package to implement development sandboxes (for isolation)
- Contains easy-to-use tools to assist cross-compilation
- Supports multiple developers using the same development system
- Supports multiple configurations for each developer
- Supports executing target executables on the hardware target, via a mechanism called sbrsh
- Supports running non-native binaries on the host system via instruction set emulators (Qemuis used).
Besides these main features, it is possible to develop own software packages that can be installed and used inside a Scratchbox environment. Scratchbox also includes some integration for Debian package management, so that once the source files are set up correctly and a couple of configuration files have been written, binary distribution packages can be created for various architectures (similar to .msi-files in Windows, or .rpm-files in Fedora Core, RHEL and SUSE). These tools are also used to provide the environment with a packaging database, so that other development packages can be installed over the Internet when needed (by using standard Debian package management tools).
The Internet Tablet also uses a similar packaging system, and this means that packages built using Scratchbox and the SDK can be installed on the real device.
Scratchbox is licensed under the GPL and it is open for outside contributions. For an in-depth coverage on Scratchbox capabilities please see the website.
This material discusses only the Scratchbox capabilities that are necessary to use the maemo SDK.
Hardware architectures
Maemo SDK supports two architectures, X86 and ARMEL and provides development environment for both. In Fremantle, X86 environment is used for active devleopment and has better tool suport through native execution without the need for emulation. ARMEL target is used only for cross-compilation of applications to work on the actual device. There are currently issues with the user mode qemu which prevent the UI framework from starting up in the ARMEL target.
Once your application compiles, runs and behaves as expected on the X86 target, the next step is to compile it on the ARMEL target. The process of compilation and packaging is exactly the same as in X86, albeit a bit slower, because some of the required software is emulated. The . Scratchbox will handle cross-compilation, so the developers need not concern themselves with cross-compilation.
The applications thus compiled on the ARMEL target can be run directly on the device without further modifications. This is possible because of the emulation provided by the maemo SDK. The emulation however is not complete , so the actual testing must be performed on the device.
Scratchbox In-Depth
Scratchbox is maemo SDK's cross-compiling environment. The default Scratchbox installation works as-is under most conditions, but some details are good to know for more specialized usage.
The target inside Scratchbox contains a root file system that is being worked on. When a new target inside Scratchbox is created, a toolchain must be specified for it. Using this toolchain, applications are built for the target. Examples of a target are X86 and ARMEL, which are provided by the maemo SDK on top of Scratchbox.
Host tools are native to the host provided for convenience and speed. They are always preferred over target tools and transparently for example cross-compile applications to the target architecture. Host tools consist of devkits and toolchains.
A toolchain provides the minimal set of tools for compiling binaries for the target. One and only one toolchain must be selected for every Scratchbox target.
CPU transparency methods take care of running the applications on an emulator, target device or directly on the host transparently to the user. The available CPU transparency methods come from a special devkit called cputransp. For each of maemo SDK's pre-defined targets, a CPU transparency method is selected and defined.
A toolchain is a collection of tools used to produce binaries for the target environment. In addition to a compiler (gcc), it contains a linker (ld) and other binutils, such as strip, objdump and strings.
A devkit is a collection of tools native to the host. A toolkit can be selected or disabled for a target. An example of a devkit is doctools devkit, which provides tools (like doxygen) for building documentation.
A rootstrap is a root file system for the target device. Maemo SDK provides root file systems for both targets (X86 and ARMEL) inside Scratchbox. Note that the user's home directory is shared for all targets. The /tmp directory is shared for all targets and also with the host.
From Scratchbox's point of view, maemo SDK is a set of preconfigured targets and root file systems. One set is provided for both X86 and ARMEL architectures on top of a working Scratchbox installation.
More Scratchbox information can be found at it's website.
Development on Maemo SDK
The maemo SDK provides all of its development tools inside Scratchbox. Also the Hildon Desktop is started with a single command af-sb-init start inside Scratchbox. However, the Hildon Desktop needs a secondary X server of proper size and bitdepth to be displayed on.
As an exception to the rule, the X server such as Xephyr must be started on the host Linux environment, instead of being started inside Scratchbox. The use of Xephyr is described in section 3.4.
Development Tools on Scratchbox
As the Scratchbox environment is practically a full GNU/Linux system, it includes the standard GNU/Linux development tools. Debugging is performed with tools like GDB, valgrind, ltrace and strace. Performance profiling can be performed with tools like htop, oprofile and time, and compiling with the GCC toolchain. Some of these tools offer graphical user interfaces, which can also be used. Naturally, this is not a comprehensive list of the tools, and if the tools shipped with the SDK do not suit to needs or personal preferences, most utilities can be easily run practically unchanged in Scratchbox.
Other Programming Languages
Currently C is the only official programming language for maemo. But thanks to the community, unofficial support exist for several other languages. To name a few, the SDK itself compiles C++, and by adding hildonmm bindings, Hildon applications can be created the C++ way. Python scripting language also has a good support in form of pymaemo.
2 Installing SDK
There is a special feature that the kernel needs to support in order for the instruction emulator in sbox to work properly. This is the binfmt_misc-feature. It is normally built as a module, so verify that it is loaded in Linux (no root access needed for this):
user@system:~$ lsmod | grep binfmt
binfmt_misc 12936 0
If you do not see a line of output, attempt to do a modprobe binfmt_misc as root (or with sudo). If this still does not work, you will have to find the module somewhere, or even recompile the kernel. On most Debian-based systems (Debian, Ubuntu), the module is included, so there should not be any problems, unless you have built your own kernel. It is also possible that the feature has been built inside the kernel directly, instead of a module.
Also a pseudo X server should be installed to act as an X client to the real system. It will be necessary to run the applications that are developed, after installing the SDK.
There are a few options for this purpose, but this material will cover the usage of Xephyr. Xephyr is a Kdrive-based X server/client that can emulate 16-color depth for its clients even if it is acting as a client to an 24-bit depth real X server. It also implements modern X protocol extensions.
The concept of having a program that is both X server and a client may seem weird. However, there is no reason to worry, as it is a tested technology and works quite well. If, on the other hand, it does not make any sense, revisit the X Window System introduction in the previous chapter.
To install Xephyr to Debian based Linux:
- Issue the command sudo apt-get install xserver-xephyr on your real Linux system.
- Verify installation status by issuing the command 'dpkg -l | grep xephyr' (as non-root).
As mentioned before, maemo SDK uses scratchbox as the cross compilation environment. Therefore, it is essential to install scratchbox first before attempting to install the SDK. The preferred way to install scratchbox and SDK is to use the automated installation scripts though manual installation steps are provided. Have a look at the installation instructions for details.
Starting Virtual X Server (Xephyr)
Open another terminal emulator (do not close your sbox session).
Start up the server with:
user@system:~$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac &
The first parameter is the Display number (:2) that X server should start on (and provide to clients). :2 is used here, since it is normally unused in regular Linux desktop environments.
The screen parameters tells Xephyr how large the screen should be (in pixels), and how many bits to use for color-information (16). This is the resolution in pixels of Maemo compatible device. -dpi 96 tells the server to tell its clients that the logical to physical size mapping should be done with 96 dots-per-inch setting (should the client request that information). The DPI setting is mainly important when dealing with fonts and text.
-ac tells Xephyr that any client may connect to it. This means that the networking environment should be treated with extreme caution, so that rogue users will not target your Xephyr with their own clients.
When Xephyr starts, it will connect to the X server given in the DISPLAY environmental variable that it sees. Do not modify or touch your real DISPLAY variable that Xephyr sees.
By default, the server will have one screen, and it will be filled by the default X server background pattern (a tight braid made out of white pixels on black).
N.B. The terminal emulator (more specifically, the shell that the emulator started) is waiting for Xephyr to end. If all the graphical applications running in the SDK ever need to be killed, it can be done easily by just closing Xephyr. This will leave the daemons running inside sbox (D-Bus and friends). Normally this is not a good idea. To ask the foreground process to terminate itself, use Ctrl+c. Inside sbox this same technique can be used to terminate a graphical client that was started from the command line (as will be done shortly).
Directing Client to Virtual Server
Now that there is an X server running, it is time to switch back to sbox.
The first step is to set the environmental variable so that X server knows to use a local domain socket, and tell all X clients to connect to Display number 2, since that is where the Xephyr was just started:
[sbox-FREMANTLE_X86: ~] > export DISPLAY=:2
Starting Application Framework
To start the Application Framework, it is possible to use a handy script that comes with the SDK:
[sbox-FREMANTLE_X86: ~] > af-sb-init.sh start
The start and stop parameters are used to start and stop the graphical environment. If everything works, it should show a screen resembling this one:
