OpenMoko/fr

From Openmoko

NOTE: Traduction en cours de réalisation.

OpenMoko est une distribution que nous avons créée pour le GTA01. Ci-après l'architecture logicielle :

http://people.openmoko.org/sean/specifications/images/software_stack2007.png

La version imprimable peut être téléchargée ici.

NOTE: Ce articke doit être mis à jour pour refléter l'architecture actuelle.

Contents 1 Kernel Space 1.1 Bootloader / chargeur d'amorçage 1.2 Kernel / Noyau 1.2.1 Flash 1.2.2 Sound / Son 1.2.3 Backlight / Rétroéclairage 1.2.4 Keypad / Clavier 1.2.5 Touch Screen / Ecran Tactile 1.2.6 USB 1.2.7 NFS Root Support 1.2.8 Bluetooth 1.2.9 TS07.10 1.2.10 Vibration 1.3 Power Management / Alimentation 2 User Space / Espace Utilisateur 2.1 Linux Core Services 2.1.1 sshd 2.1.2 udev 2.1.3 bluez 2.1.4 dbus 2.1.5 GSM 2.1.6 GPS 2.2 Linux User Interface 2.2.1 Matchbox 2.2.2 KDrive 2.2.3 libX11 2.2.4 GTK+ 2.3 OpenMoko Application Framework 2.3.1 Applications Natives 2.3.1.1 Finger-Based Applications 2.3.1.2 Stylus-Based Applications 2.3.2 X11 Applications 3 Environnement de développement 3.1 Build Environment 3.2 Development Tools 3.3 Development Server 3.4 Build Server 3.5 Developer Workstations 3.5.1 Setting up an OpenMoko SDK

Kernel Space

Le Kernel Space contient le chargeur d'amorçage (Bootloader), le noyau (Kernel) et la gestion de l'alimentation.

Bootloader / chargeur d'amorçage

Le chargeur d'amorçage est u-boot. Nous fixons les exigences suivantes :

• Firmware Update – Nécessaire pour télécharger le code en utilisant USB DFU
• RAM Loader – Fournit une méthode pour exécuter le code directement dans la RAM du périphérique
• Secure Memory Interface – Fournit une méthode pour sécuriser l'interface d'écriture dans la RAM et la FLASH. Ceci pour que l'utilisateur final puisse empécher que d'autres utilisateurs modifient leur propre combiné. N'est pas destiné à le bloquer sur un réseau (lock-in).
• Backup – Fournit une méthode de sauvegarde des données depuis/vers la mémoire flash. Ceci peut aussi permettre aux utilisateurs de partager des images entre eux.

Kernel / Noyau

Le noyau est basé sur les bases de la 2.6.x utilisant les patch (correctifs) moko. Il été prévu d'utiliser les patches TomTom comme ce fut fait avec le processeur applicatif Samsung 2410 et ajouter un support pour les cartes SD. Currently their patches will allow support for almost all vendors’ SD cards. Kernel work is divided into the following components:

Flash

La mémoire Flash pourra être accédée comme une MTD (Memory Technology Device) linux standard. Le système de fichiers retenu pour la totalité de la mémoire flash est JFFS2. Nous aimerions disposer de quelques types d'encryptage de données utilisateur. Ceci sera configurable dans l'interface utilisateur dans les livraisons finales. Pour l'instant, nous devons créer le framework.

Sound / Son

Le pilote sonore sera conforme à l'architecture ALSA (Advanced Linus Sound Architecture). Ceci est un standard pour les cartes son linux.

Backlight / Rétroéclairage

Il y aura un pilote LCD rétroéclairage.

Keypad / Clavier

Le pilote du clavier utilisera l'entrée standard /dev/input.

Touch Screen / Ecran Tactile

Le pilote de l'écran tactile utilise l'entrée standard /dev/input/touchscreen0.

USB

Il nous faut une connexion hôte/client pour linux, OS X et Windows. Qui devrait posséder les caractéristiques suivantes :

• Mass Storage – Etre chargeable et accessible depuis un autre périphérique
• Host Network – Fournir un support réseau par USB
• Linux USB Gadget – Utiliser les méthodes standard pour avoir un périphérique esclave

NFS Root Support

This will serve as one of our methods to develop code for the device. It will allow us to have a filesystem larger than the actual flash size.

Bluetooth

Le support du Bluetooth se basera sur le standard Linux appelé Bluez. Nous supporterons les profils suivants :

• Headset – Pour les casques sans fil
• OBEX – Pour le transfert de fichiers
• HID – Pour les claviers et l'émulation Bluetooth (tels que les télécommandes...)
• Network Emulation – Pour le support des réseaux Bluetooth

TS07.10

Il s'agit de l'interface GSM. Elle est basée sur l'idée de créer de multiple périphériques série à partir d'un unique périphérique série physique. Ce code fonctionnera sur les bases du projet OpenEZX et sur l'architecture Motorola d'origine. Il fournira aussi des tunnels ipsec pour la connexion à des VPN sécurisés. Les diagrammes suivants présentent l'architecture générale :

http://people.openmoko.org/sean/specifications/images/gsm_interface.png

Une version imprimable est disponible ici.

Vibration

Nous devons définir notre propre interface. Actuellement il n'existe pas de standard linux pour ce point précis. Mickey would propose (ab)using the new LED class interface.

Power Management / Alimentation

L'alimentation s'interface avec l'interface noyau standard I2C. Les états de transitions actuels ne sont pas encore spécifiés.

User Space / Espace Utilisateur

NOTE: Nous utiliserons glibc (et non uClibC) et libX11 (complet et pas allégé) pour la première mouture du produit. L'alternative permettrait de gagner plus de place et d'être plus optimisé, mais nous n'en sommes pas encore à avoir des migraines dues à l'intégration. Ce choix sera reconsidérer dans les prochaines versions.

Linux Core Services

La plupart des services core sont inclus en tant que démon ou bibliothéque.

sshd

sshd permet une connexion distante au shell par le réseau.

udev

udev est responsable de la gestion des noeuds du périphérique dans le système de fichiers /dev.

bluez

bluez est une implémentation de la pile Bluetooth sur Linux.

dbus

dbus est un sous-système de communication interprocessus.

GSM

• GSM - gère la communication avec le module GSM.
• gsmd - est responsable de la gestion du périphérique GSM.
• libgsm - communique avec le gsmd et propose une API aux applications.

GPS

• GPS - gère la communication avec le module GPS.
• gpsd - est le démon de gestion du périphérique GPS. Il possède une interface gpsd standard. Un plugin est disponible pour supporter l'interface matériel du Neo1973.

Linux User Interface

Matchbox

Un gestionnaire de fenêtres légé de O-Hand

KDrive

Kdrive-fbdev est un serveur X11 allégé qui tourne directement sur un framebuffer Linux.

libX11

La bibliothéque X11.

GTK+

GTK+ est une boite à outils graphique très riche. C'est la base du Projet Gnome

OpenMoko Application Framework

• Cf. OpenMokoFramework

Applications Natives

Finger-Based Applications

Compléter les spécifications pour toutes les applications Finger-Based trouvées ici.

Stylus-Based Applications

Compléter les specifications pour toutes les applications Stylus-Based trouvées ici.

X11 Applications

(Reste à définir)

Environnement de développement

L'environnement de développement consiste en un Environnement d'assemblage, des outils de développement, serveurs de développement, des serveurs d'assemblage et des stations de développement.

Build Environment

The entire system will be built using Open Embedded. Using Open Embedded we get a great package system. It uses something called a “feed” to manage collections of packages. Feeds are basically the equivalent of Debian’s sources. Open Embedded will give us a complete PDA-like system for free. We can then spend all our time concentrating on phone-specific applications and overall user interface integration.

Development Tools

Development tools will help us standardize our working methods both internally and externally with the rest of the world. Since we are trying to use as much free software as possible, we should, naturally, use free software for our development tools, too. The following is a description of each major work area and the specific tools we will need:

• Kernel Development – Kernel work will use Git. This is the current standard for Linux kernel. Harald will do almost all the kernel work. He will release patches that will go into our Open Embedded tree.
• Application / All Other Development – Development for the main phone applications and just about any other component besides the kernel will use Subversion.
• Developer Communication – All communication between developers need to be done through a mailing list. We will use Mailman for this purpose.
• Bug Tracking – Buzilla will be used for both bug and issue tracking.
• Documentation – Project documentation will be written as either a Wiki or using Doxygen. The Wiki will be used for more general project level information. Doxygen will be used to document the individual libraries and core APIs.

Development Server

FIC Taipei will host the main development server. This will run Debian Sarge. It will be used for checking out development code, Bug tracking, and running the Mailing Lists. Subversion will run on this server using the following connection types:

• https – Will be used for developers checkouts
• http – Will be used for read-only checkouts

Build Server

FIC Taipei will host the main build server. This will also run Debian Sarge. All main developers will have an account. It will be used for providing a daily build of the entire code base and documentation. After each build, the results will be emailed to the Developers Mailing List. Daily builds will be stored on the server for as long as storage permits. After that point is reached, DVDs will be burned for archiving.

Developer Workstations

Individual developers should use some Debian-derived distro. We are currently using both Ubuntu (6.06) and Debian (3.1). We create a base package for all the main development tools. Developers will work off of a daily build from the Build Server. They either load their code into flash or simply use the provided script to create an NFS root filesystem from the daily build image. When needed, they can rebuild the modified packages using their personal Open Embedded. These packages will then be added to the developer’s personal feed and can be committed, if ready, back to the main feed.

The current development version of OpenMoko can be obtained via rsync (broken currently)

# rsync fic@buildhost.openmoko.org:deploy/
Password: openmoko

You can create (and/or update) a local mirror of packages by using this rsync access.

There is also http access available at http://buildhost.openmoko.org/tmp/deploy/

Setting up an OpenMoko SDK

• Follow the instructions based on your Distro or look at the more general OE Getting Started guide.
• Note that for now you need a fixed revision from OpenEmbedded to make the build succeed. The most recent tested revision is:

 f499733e6db527846e1a48cf70f9862d6b3798ae hrw@openembedded.org 2006-12-18T22:35:31

• local.conf for the build directory should look like that:

 MACHINE = "fic-gta01"
 DISTRO = "openmoko"
 BUILD_ARCH = "i686"

• Download the OpenMoko metadata directory from svn
• Set the environment variables accordingly:

 export OMDIR=$PWD
 export OEDIR=$PWD/openembedded
 export BBPATH=$OMDIR:$OMDIR/build:$OMDIR/metadata:$OMDIR/openembedded

• Depending on your environment you may have to edit metadata/conf/site.conf accordingly.