Openmoko - User contributions [en]

Booting from SD/fr

2009-03-11T22:01:37Z

Starox: /* Démarrage à partir de la SDHC */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23. Les versions officielles de u-boot pour le Neo1973 ne supportent pas les SDHC.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:45:41Z

Starox: /* Désactivation du montage automatique de udev */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23. Les versions officielles de u-boot pour le Neo1973 ne supportent pas les SDHC. Il est cependant possible de booter sur SDHC en patchant et recompilant soi-même u-boot }}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:45:21Z

Starox: /* Démarrage automatique à partir de la SDHC */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23. Les versions officielles de u-boot pour le Neo1973 ne supportent pas les SDHC. Il est cependant possible de booter sur SDHC en patchant et recompilant soi-même u-boot }}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:44:00Z

Starox: /* Démarrage à partir de la SDHC */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23. Les versions officielles de u-boot pour le Neo1973 ne supportent pas les SDHC. Il est cependant possible de booter sur SDHC en patchant et recompilant soi-même u-boot }}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:41:54Z

Starox: /* Démarrage à partir de la SDHC */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:40:55Z

Starox: /* Rajout de l'entrée au menu de démarrage uboot */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:38:27Z

Starox: /* Partitionnement de la carte SD */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:37:41Z

Starox: /* Choix 2 : Créer un fichier tar en utilisant OpenEmbedded */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:37:16Z

Starox: /* Paramètres associés au système de fichier racine */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:36:45Z

Starox: /* Chargement du noyau */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Booting from SD/fr

2009-03-11T21:35:56Z

Starox: /* Remplissage de la carte SD */

== Démarrage à partir d'une carte SDHC / problème de mise en veille ==

Tout d'abord un avertissement : Un bogue très ancien ayant pour origine probable le noyau Linux détruit la table des partitions des cartes SD de capacité élevée. Voir le bogue [https://docs.openmoko.org/trac/ticket/1802 #1802] et le [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| fil de discussion] pour une explication détaillée sur la gestion des cartes SD de haute capacité. Une bonne précaution est de conserver une version papier de la table des partitions au cas où elle devrait être recréée.

== Comment ça marche ==

Sur le FR, [[u-boot]] fournit un mécanisme équivalent à celui de 'grub' sur un PC. U-boot charge l'image du noyau en mémoire et le déclenche avec une liste de paramètres noyau. Ces paramètres indiquent entre autres choses le périphérique sur lequel le système de fichiers racine se trouve.

Lorsque le noyau démarre, il prépare le matériel et met en place le système de fichiers racine. Le noyau déclenche alors "/sbin/init", qui s'occupe du reste de la séquence de démarrage (avec l'affichage de l'image de démarrage et la barre de progression).

Ceci fonctionne de manière identique que l'on démarre à partir de la mémoire Flash interne ou de la carte SD. La différence réside dans la manière dont le noyau est chargé et quel périphérique est utilisé comme système racine.

Les sections suivantes fournissent des détails complémentaires.

=== Choix du menu ===

Les choix du menu U-boot sont définis par les variables d'environnment nommées "menu_X" (avec X un nombre). La valeur de la variable d'environnement est une chaîne "<nom>:<commande>", où <nom> est le texte montré sur l'écran et <commande> est une séquence de commandes u-boot (séparées par le caractère ';') exécutées lorsque le choix du menu est sélectionné. Lorsqu'on entre une chaîne de commandes, les caractères ';' et '$' doivent être protégés par un antislash : "\;" et "\$".

=== Chargement du noyau ===

Deux commandes u-boot sont nécessaires pour le chargement du noyau à partir d'une carte SD. La première est "mmcinit" qui permettra à u-boot de détecter la carte. La seconde est la commande de chargement d'un fichier en mémoire, soit "fatload" soit "ext2load" en fonction du type de système de fichiers sur lequel se trouve le noyau.

La syntaxe de la commande est la suivante :

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

où est le numéro de partition, et <filepath> est le chemin vers le fichier qui doit être chargé.

{{Note| La commande "ext2load" ne fonctionne pas avec les version de u-boot antérieures à la "20080723", y compris celle fournie avec les premiers lots de FreeRunners. Ces vieux u-boot sont touchés par le bug [http://docs.openmoko.org/trac/ticket/799 #799]. Si vous mettez à jour votre U-Boot et votre noyau vous pouvez utilisez directement ext2 / 3 boot avec une seule partition pour tout.}}

{{Warning | Soyez prudent en mettant à jour u-boot sur un Neo1973 sachant qu'il existe un risque de plantage (sauf avec un debug board). Ce n'est pas un problème avec le FreeRunner puisqu'il dispose d'une copie protégée de u-boot dans sa mémoire flash NOR. }}

{{Note| U-Boot gère le protocole SDHC uniquement sur le FreeRunner : sur le Neo1973, u-boot est incapable d'accéder aux cartes SDHC (4G ou plus). Le noyau dispose du support SDHC avec le Neo1973, il est possible de placer le système racine sur la SDHC et le noyau sur la mémoire flash NAND pour contourner ce défaut. }}

=== Paramètres associés au système de fichier racine ===

Le contenu de la variable d'environnement "bootargs" est envoyé au noyau. Bootargs est constitué de définitions "nom=valeur" séparées par des espaces. Les définitions associées au processus de démarrage sur carte SD sont "root", "rootfstype" et "rootdelay".

Par exemple, les paramètres suivants indiqueraient au noyau de monter la troisième partition de la carte SD en tant que système de fichiers ext3 :

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

Le paramètre "rootdelay" génère un temps d'attente du noyau le temps que la carte SD soit prête.

Le noyau doit intégrer en statique (pas en module donc) la gestion des systèmes de fichiers indiqués au paramètre "rootfstype". Les configuration du noyau Openmoko par défaut intègrent le support de ext2 et ext3. Vous pouvez vérifier les systèmes de fichiers disponibles avec la commande Linux :

less /proc/filesystems

Il n'est pas possible d'utiliser FAT comme système de fichiers racine.

==== ext2 comparé à ext3 ====

Les opinions varient sur le meilleur système de fichiers à utiliser pour le système de fichiers racine. Ext3 est généralement considéré comme étant meilleur parce que c'est un système de fichiers journalisé qui ne nécessite pas une longue commande 'fsck' après un arrêt non planifié. Ceci dit, utilisé sur une carte qui n'intègre pas de gestion d'usure des blocs ext3 peut provoquer une usure prématurée des blocs sur lesquels se trouve le fichier journal. Les cartes SD sont censées intégrer un système de gestion d'usure, mais ce n'est pas garanti pour toutes les marques.

== Récupération d'un fichier racine (rootfs) compressé ==

Deux possibilités existent pour récupérer un fichier image rootfs en archive tar. Vous pouvez en créer un en utilisant la distribution OpenEmbedded ou en télécharger un directement depuis le serveur de création d'images openmoko.

=== Choix 1 : Télécharger les fichiers tar rootfs/kernel du serveur Openmoko ===
Choissisez la combinaison rootfs/kernel que vous désirez installer sur la page des [http://wiki.openmoko.org/wiki/Latest_Images Dernières Images Générées].

=== Choix 2 : Créer un fichier tar en utilisant OpenEmbedded ===

Une autre possibilité pour obtenir une archive tar de votre rootfs est de la construire vous-même avec l'environnement OpenEmbedded.

Pour construire OM-2007.2 vous devez ajouter "tar" aux types d'images dans votre fichier ''local.conf'' :

IMAGE_FSTYPES = "jffs2 tar"

Après cela vous pouvez construire une nouvelle image avec la commande :

bitbake openmoko-devel-image

Ou si vous utilisez le MokoMakefile :

make openmoko-devel-image

Une fois que la commande aura été exécutée vous disposerez d'une fichier ''Openmoko-....tar'' dans le répertoire deploy qui correspondra à votre nouvelle archive rootfs.

=== Choix 3 : Convertissez une image jffs2 en fichier tar ===

Consultez la page [[Userspace root image]] pour de plus amples informations sur la manière d'accéder au contenu d'une image jffs2.

== Préparation de la carte SD ==

=== Partitionnement de la carte SD ===

u-boot pre-2008-07-23 peut uniquement démarrer de système de fichiers FAT; si vous mettez à jour u-boot, vous pourrez démarrer de systèmes FAT ou ext2.
Cet exemple montre comment créer une partition type en utilisant l'outil système fdisk. N'importe quel autre gestionnaire de partitions fonctionnerait aussi.

fdisk /dev/mmcblk0

{{Note| Le fichier spécial associé au périphérique peut être différent sur votre configuration. Si vous n'êtes pas sûr, vous pouvez utiliser la commande ''dmesg'' pour répérer le bon nom dans les messages de démarrage du noyau.}}

Nous allons maintenant créer une partition de 8Mo pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

<pre>Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
</pre>
''On devrait probablement aussi changer le type de la première partition en FAT16 ?''

si le message suivant apparaît à la sortie du programme fdisk :

Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

lancez la commande

umount /dev/mmcblk0p1

à partir d'une autre console et essayez de nouveau.

=== Formatage de la carte SD ===

Lancez la commande suivante pour créer un système de fichier FAT :

mkfs.vfat /dev/mmcblk0p1
{{Note|Si vous ne disposez pas de mkfs.vfat vous le trouverez dans le paquet "dosfstools". Ce paquet ne semble pas être disponible en ipk, mais une version non officielle peut être téléchargée à http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk}}

La deuxième partition doit être formattée en ext3 (sauf si vous avez inclus les modules ext2 dans votre noyau) :

mkfs.ext3 /dev/mmcblk0p2

== Remplissage de la carte SD ==

Votre carte SD est maintenant prête à être remplie avec le système de fichiers rootfs et le noyau nécessaires au démarrage du FR.

Montez la seconde partition de votre carte SD et placez l'image rootfs dessus :

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

{{Note| Comme toujours dans ce guide, veuillez à ajuster le nom de périphérique et du fichier rootfs à vos besoins.}}

{{Note| Il faut porter attention à un point particulier si vous utilisez le démon automount de votre système d'exploitation hôte. Certains systèmes montent ces périphériques amovibles avec l'option "nodev" par défaut pour des raisons de sécurité. Si l'image que vous décompressez dispose d'un répertoire /dev rempli, les fichiers spéciaux ne seront pas créés. Si vous montez automatiquement la carte SD sur votre PC, vérifiez qu'il n'y a pas d'options de montage inadaptées en utilisant la commande "mount" pour lister les points de montage.}}

La prochaine étape est de monter la première partition de la carte SD et d'installer le noyau dessus.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Ou pour certaines version de u-boot sur la mémoire flash NOR :

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage

(oui, en minuscules et sans extension)

Faites bien attention que votre noyau soit nommé ''uImage.bin'' (ou ''uimage'' pour certaines version de u-boot en mode NOR). Si le programme u-boot ne trouve pas le fichier noyau lors du démarrage, [[Bootloader#Using usbtty from Linux| connectez-vous au bootloader]] avec ''[http://www.airs.com/ian/uucp.html cu]'', montez la partition avec mccinit et vérifiez la présence et le nom de l'image du noyau avec ''fatls mmc 1:1'' pour un système de fichier FAT ou ''ext2ls mmc 1:1'' pour un système de fichiers ext2. Comparez le résultat avec soin avec la sortie de la commande ''printenv sd_image_name''. N'oubliez pas que vous pouvez modifier l'environnement de la flash NAND mais pas de la flash NOR, donc si vous voulez démarrez à partir de la flash NOR vous devez faire correspondre le nom de fichier à la variable d'environnement et non l'inverse.

Démontez la partition rootfs et la partition noyau et faites bien attention que les données en cache soient bien écrites sur le disque :

umount /mnt/moko
umount /mnt/mokokernel
sync

== Rajout de l'entrée au menu de démarrage uboot ==

En fonction du lot du téléphone et du type de partition que vous utilisez, il peut être nécessaire de rajouter une entrée dans le menu de démarrage pour pouvoir démarrer le système à partir de la carte mémoire. Si vous utilisez le FreeRunner et avez créé un noyau sur FAT avec une partition rootfs ext2 vous devriez pouvoir démarrer à partir de la carte immédiatement puisqu'une entrée pour cela devrait déjà exister dans le menu de démarrage NOR/NAND. Pour les autres cas vous devriez au moins vérifier que les entrées nécessaires existent dans votre menu avant de poursuivre. Vous aurez besoin de vous connecter au shell uboot du menu NAND pour cela. Une description de la procédure est disponible dans l'article [[Uboot#Bootloader_prompt]]. Des détails sur la manière de vous connecter au menu NAND sont disponibles [[Booting#Log_into_U-Boot_in_the_NAND_Flash| ici]].

Après avoir consulté ces deux articles, vous devriez être connecté avec le shell sur uboot en mode NAND. La première chose à faire est de régler le délai de déconnexion du menu de démarrage à une valeur très élevée. Si vous ne faites pas cela, le gestionnaire de démarrage continuera le chargement après le délai par défaut (60 secondes) même si vous êtes connecté au shell uboot. Entrez la commande suivante :

setenv boot_menu_timeout 99999

Cela règlera le délai à 99999 secondes ce qui devrait vous donner le temps de lancer toutes les commandes que vous voulez dans le shell de démarrage.

Maintenant, nous allons vérifier qu'une option du menu pour démarrer sur la carte SD est bien disponible et la créer si ce n'est pas le cas. Vous pouvez afficher l'environnement de démarrage du gestionnaire de démarrage avec la commande :

printenv

Si le résultat est une ligne commençant par ''menu_'' suivi des commandes qui sont listées dans ce guide, vous n'avez pas besoin de créer de nouvelle entrée dans le menu. Dans tous les autres cas veuillez suivre les instructions suivantes :

Vérifiez que vous utilisez la bonne configuration à partir des décisions que vous avez prises auparavant. Pour plus d'informations sur les commandes uboot, utilisez :
help
help <commande>
et [[Bootloader]] ainsi que [[Bootloader commands]].

{{Note| Les antislashes (\) sont très importants en mode uboot pour enregistrer la commande en tant que nouvelle variable d'environnement plutôt que de l'exécuter immédiatement après l'appui sur la touche entrée.}}

{{Note| Les touches copier et coller peuvent être inopérantes en fonction de l'émulateur de terminal utilisé. Commi fonctionne ou vous pouvez utiliser l'émulateur de terminal [[NeoCon|neocon]] en rajoutant un délai d'attente entre les caractères. Autrement, vous devrez retapez les lignes de commande à la main.}}

Il est important de tenir compte des type de partitions FAT ou ext du noyau ainsi que des types ext2 ou ext3 de la partition racine.

Vérifiez les numéros de partition dans les commandes suivantes. Il peut être nécessaire en particulier de changer root=/dev/mmcblk0p'''#''' et fatload mmc '''#''' ou ext2load mmc '''#''' en fonction des partitions dans lesquelles se trouvent respectivement le noyau et le rootfs. Les numéros commencent à 1.

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext3 :'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour le noyau sur FAT et le rootfs sur ext2:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

ou : avec option noyau 'init=/sbin/init' (nécessaire pour certaines images) :
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau sur ext2 et rootfs sur ext2: (nécessite un u-boot récent)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Entrée du menu pour noyau et rootfs sur la même partition ext2 (testé avec Qtopia/nécessite un u-boot récent)'''
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000
Vous avez bientôt fini. Lancez une commande

printenv

et vérifiez que votre choix de menu récemment créé est affiché correctement (sans que les antislashes soient affichés cette fois).

Si tout se passe bien, entrez :

saveenv

en ligne de commande et tapez entrée. La nouvelle configuration devrait alors être enregistrée dans la mémoire flash NAND.

Eteignez votre Neo avec la commande suivante :

neo1973 power-off

Après avoir redémarré le Neo et vous être reconnecté en mode NAND vous devriez pouvoir sélectionner votre choix récemment créé et pouvoir démarrer avec le système de fichiers racine de votre carte SD.

----

Voyez aussi [[Moving current system from flash to SD]] qui indique comment copier le système en flash vers la carte SD pour garder une sauvegarde et pouvoir démarrer avec.

----

== Annexes ==

=== Démarrage à partir de la SDHC ===

{{Note|le texte suivant a été écrit pour le Neo1973. Les cartes SDHC et SD devraient fonctionner avec un FreeRunner si votre version de u-boot est au moins 2008-07-23.}}

Sachant que les SDHC ne fonctionnent pas avec des versions plus anciennes de u-boot, vous ne pouvez pas utiliser ce qui est indiqué dans le guide Booting from SD.
Mais il existe une sorte de contournement qui permet d'avoir au moins votre rootfs sur la microSDHC :

Tout d'abord vous pouvez suivre l'étape 1 pour obtenir une image de noyau intégrant les support mmc et ext2. Mais au lieu de copier l'image sur le rootfs vous allez la flasher sur la mémoire NAND interne (en utilisant [[Dfu-util]]).
Vous pouvez maintenant continuer à l'étape 2 (comme indiqué auparavant vous n'avez pas à copier votre uImage dans le rootfs) puis suivre les instructions de l'étape 3.
Au lieu de la commande setenv indiquée en étape 3, vous allez indiquer la commande suivante :

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Et c'est tout !

Maintenant vous pouvez utiliser l'option "Boot from SDHC" que vous venez de rajouter pour démarrer le noyau en utilisant le système de fichiers racine présent sur la microSDHC.

=== Démarrage automatique à partir de la SDHC ===

Si vous voulez démarrer automatiquement sur la carte SDHC :
Ajoutez une entrée au menu pour démarrer de la mémoire NAND

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Puis éteignez le FR et testez la nouvelle entrée du menu. Si vous pouvez démarrer depuis la NAND, éteignez, entrez dans le menu de démarrage, connectez-vous au bootloader et définissez la commande (auto)bootcmd pour démarrer de la carte SDHC :

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Maintenant vous démarrerez de la SDHC à chaque fois que vous appuierez le bouton Marche-Arrêt ou que vous redémarrerez le FR. Si vous désirez de nouveau démarrer à partir de la NAND, utilisez l'option NAND du menu de démarrage.

=== Désactivation du montage automatique de udev ===

udev monte automatiquement la carte SD au point de montage /media/mmcblk0p1. Vous pouvez désactiver cela avec la commande suivante :

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarques sur les paramètres noyau ===

==== loglevel ====

Certaines personnes suggèrent de rajouter :

loglevel=8

au paramètres du noyau. SI vous avez aussi le paramètre "console=tty0" dans la ligne de commande du noyau cela rend le démarrage du FR extrèmement lent parce que le framebuffer (l'affichage du neo en mode texte) doit afficher des tas de lignes de message de deboguage du genre :

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

Download

2009-03-05T18:14:43Z

Starox: /* SHR images (Stable Hybrid Release) */ fix wrong url for gta01

{{Languages|Download}}
This page lists various images you can try out on your Openmoko supported smartphone and some [[#Other downloads]].

See [[Distributions]] for a more descriptive comparison. Then see [[Development Branches Policy]] when you want to know where the really bleeding edge is.

{|align=right
|__TOC__
|}

== Installation instructions ==

See [[Flashing the Neo FreeRunner]] for installation instructions. Neo 1973 users: [[Getting Started with your Neo1973]]. If you want to install a system to a microSD card, see [[Booting from SD]].

The release directories can contain up to four files:

* a Root FileSystem image. These are the files with '''rootfs''' in their name. They come both as a .jffs2 ready-to-flash image, and as a .tar.gz ready-to-cp tarball.
* a Kernel image (files with '''uimage''' in their name).
* a u-boot bootloader (file with '''u-boot''' in the name).
* a splash image file.

Also, the archive directory contains two identical versions of most files, one having the date in the filename. For those convenience ?

One usually needs only to flash the phone with the root filesystem and the kernel image. The splash image is eyecandy. The u-Boot bootloader is a critical component, you don't want to install a new version of that systematically, but there have been improvements since the one released in shipping phones.

== Openmoko Inc. driven release targets ==
=== Om 2008.12 ===
Om 2008.12 is an updated release of Om 2008.8.
You can download the image [http://downloads.openmoko.org/distro/releases/Om2008.12/ here]

{{Main|Om 2008.12 Update}}

=== Om 2008.9 (ASU) ===

Om 2008.9 is an updated release of Om 2008.8.
You can download the image [http://downloads.openmoko.org/distro/releases/Om2008.9/ here]

{{Main|Om 2008.9 Update}}

'''Neo FreeRunner images'''

There is no need to reflash if you have installed Om 2008.8 and used ''opkg update && opkg upgrade''.
Comment about naming scheme on the [http://lists.openmoko.org/pipermail/community/2008-September/031003.html community mailinglist]

=== The bleeding edge: Om "base / empty" images ===

The ''org.openmoko.dev'' branch does not have any applications preinstalled other than settings and installer, and it is unstable for now.

Images for ''testing'' are at:
http://downloads.openmoko.org/distro/unstable/
To get packages from ''testing'', use this ''/etc/opkg/testing.conf'' :
<pre>
src/gz testing-all http://downloads.openmoko.org/repository/testing/all
src/gz testing-arm http://downloads.openmoko.org/repository/testing/armv4t
src/gz testing-neo http://downloads.openmoko.org/repository/testing/neo1973
src/gz testing-gta02 http://downloads.openmoko.org/repository/testing/om-gta02
</pre>


''unstable'' comes from the same branch, compiled with the AUTOREV flag. There are no images, but packages are at http://downloads.openmoko.org/repository/unstable/

Reference: See [http://lists.openmoko.org/pipermail/community/2008-August/027997.html "Repository and Images" announcement] for details on other "Base image", "testing" and "unstable".

Once you have this base image, you can install the GTK+ telephony apps including gsmd, or Qtopia, or Mickey's framework. Check out the [[FDOM]] page for an idea of what to install.

=== Om 2007.2 images (GTK) ===

{{Main|Om 2007.2}}

Openmoko '''discontinued support''' for this release.
Two external developers still offer their own builds.

==== Celtune ====

Celtune offers different Images and a huge amount of packages (2007.2, pyneo, fso) for neo1973, freerunner and others. Celtune images can be found [http://rabenfrost.net/celtune/ here].

==== ScaredyCat ====

[http://blog.automated.it/category/openmoko/ Andy Powell] maintains images based on the 2007.2 software stack for the gta01 and gta02. A. Powell's ScaredyCat images can be found [http://buildhost.automated.it/OM2007.2/ here].

=== FSO images (freesmartphone.org) ===

{{Main|OpenmokoFramework}}

The file system will be in a jffs2 "summary" file. A file with the extension ".jffs2.summary" can be flashed to the FreeRunner just like an ordinary jffs2 file.

* [http://git.freesmartphone.org/ Browse the source]

* [[OpenmokoFramework/Status_Update_6|newest status update]]

* [http://downloads.freesmartphone.org/fso-stable/milestone5/ Downloads]

=== Android ===
Android now can run on Openmoko FreeRunner.
About the Image, you can check [[Android]] page , to get the detail information.
Android imagescan be found [http://people.openmoko.org/sean_mcneil/ here].

== Openmoko Community driven release targets ==

=== FDOM ===

{{Main|FDOM - a Fat and Dirty OM based distribution}}

Download images: http://compartida.net/openmoko/FDOM/

=== SHR images (Stable Hybrid Release) ===
{{Main|SHR}}
The Stable Hybrid Release (SHR) is intended to be a community driven distribution composed of the FSO and some basic applications, that can be configured to use several different graphical toolkits, for example GTK or EFL. SHR is based on the FSO build. At first, SHR was introduced in order to use the Openmoko2007.2 GTK software in combination with the new FSO, but things have changed.

Download images (unstable currently recommended):
* [http://build.shr-project.org/shr-testing/images/om-gta02 Neo Freerunner testing]
* [http://build.shr-project.org/shr-testing/images/om-gta01 Neo 1973 testing]
* [http://build.shr-project.org/shr-unstable/images/om-gta02 Neo Freerunner unstable]
* [http://build.shr-project.org/shr-unstable/images/om-gta01 Neo 1973 unstable]

== Non-Openmoko distributions ==

=== Qt Extended (formerly Qtopia) images ===

:''Main article: [[Qtopia / Qt Extended on FreeRunner|Qt Extended]]''

Images are available on the [http://qtextended.org/modules/mydownloads/viewcat.php?cid=6&orderby=dateD Qt Extended download page], make sure your browser sends referrer Header when downloading. (Note: direct linking to the files does not work.)

'''Neo FreeRunner'''

* Qt Extended flash image for FIC Neo Freerunner (gta02) version 4.4.2 can be downloaded [http://qtextended.org/modules/mydownloads/visit.php?lid=98 here]. (The tarball contains rootfs and kernel)
* If you need to also download mwester's daily kernel (needed for previous version 4.4.1) you can find it [http://moko.mwester.net/dl.html#kernels here].

'''Neo 1973'''

* Qt Extended flash image for FIC Neo 1973 (gta01) version 4.4.2 can be downloaded [http://qtextended.org/modules/mydownloads/visit.php?lid=99 here]. (The tarball contains rootfs and kernel)

* A alternate Neo 1973 image can be downloaded [http://buildhost.automated.it/OM2007.2/openmoko-qtopia-image-om-gta01.tar.gz here]

'''More Qtopia downloads'''

Addtional packages can be added from the Trolltech feed for this image, found at
http://qtopia.net/packages/feed/4.3.2/neo/
To get to these packages, you need to add the feed as a source in the Qtopia package manager.

=== Debian images ===

{{Main|Debian}}

=== Hackable:1 images ===

{{Main|Hackable:1}}

== Other downloads ==

=== Applications repositories ===

If you are looking for a specific application instead of a full filesystem image:
* {{Main|Community Repository}}
* {{Main|Users Repositories}}

=== CAD files ===
You can download CAD files [http://downloads.openmoko.org/developer/CAD/ here].

=== Schematics ===

You can download the schematics of [[Neo 1973]] (GTA01) and [[Neo FreeRunner]] (GTA02) [http://downloads.openmoko.org/developer/schematics/ here]

=== Press material ===

Download Neo FreeRunner photos in various sizes for print and web use [http://openmoko.com/press-press-material.html here]

=== Tiddlywiki version of wiki.openmoko.org ===
If you want to carry this wiki along with you and to use it offline, then download
it [http://om-tiddlywiki.projects.openmoko.org/openmokowiki.html here] and store it locally, then browse through the pages which you think you need to have, click "save changes", so next time you open it all articles you have fetched previously will be available to you.

[[Category:Distributions]]

Neo1973 Debug Board v2/Unbricking

2009-01-13T21:15:27Z

Starox: nand createbbt waits for Y not y

This page describes a manual procedure for recovering a "bricked" Neo1973 GTA01Bv4 phone, using the [[Neo1973 Debug Board v2]]. You may prefer to use the [[Devirginator]] to perform an automatic version of this procedure.

=== Preconditions ===

Please read and understand this entire procedure before performing any of the steps.

==== Charged Battery ====

First, make sure that your problem really is related to u-boot or its environment. The most common cause of an unresponsive Neo1973 is a deeply-discharged battery. See [[Neo1973_Battery_Charger#Neo1973_emergency_charging]] for more information.

==== Debug Board ====

Please connect your debug board as described on the [[Neo1973 Debug Board v2]] page. This procedure will refer to the following terminal windows:

===== openocd console =====

This is the window in which you are using "telnet localhost 4444" to connect to the openocd program.

===== serial console =====

This is the window in which you are using a terminal emulator to connect to /dev/ttyUSB1.

===== USB console =====

This is the window in which you are using a terminal emulator to connect to /dev/ttyACM0. Note that this device is only present when u-boot is running, so you will have to connect and dis-connect your terminal program at the appropriate times.

==== Images ====

Before starting this procedure you should collect the software images that you will write to the Neo1973:

===== u-boot =====

You should use a recent version of u-boot, and it must be the one for your model of phone (e.g. gta01bv4). The actual filename will be similar to "u-boot-gta01bv4-1.3.0+git20071214+svnr3648-r1.bin" but this procedure will refer to it as "u-boot.bin"

A tested version of u-boot is available from [http://buildhost.vanille.de/fic-gta01/tmp/deploy/glibc/images/neo1973/u-boot-gta01bv4-1.3.1%2bgit0ec595243dc99edcd248bbcfbfd5a1dc860bde89%2bsvn3817-r1.bin] (released on 2008-01-13). This u-boot (and newer) includes an endian change for the framebuffer, so there is a minor cosmetic issue if it is used with an older splash.gz.

NOTE - this procedure assumes that you are using a modern u-boot in which the default console is on USB. Older versions have a default console on the serial port, so some (hopefully fairly obvious) modifications to the procedure would be required.

===== lowlevel_foo =====

You need a version of this package that matches your u-boot. The actual filename will be similar to "lowlevel_foo-gta01bv4-1.3.0+git20071214+svnr3648-r1.bin" but this procedure will refer to it as "lowlevel.bin".

===== splash.gz =====

This is a compressed splash-screen image.

===== uImage and rootfs =====

These are the standard kernel and root-filesystem images that you will flash to your phone at the end of the procedure.

=== Procedure ===

The unbricking steps are shown below. You should be watching the '''serial console''' throughout this process, although you will not actually use it to enter any text.

From the '''openocd console''', first reset and halt the CPU.

> reset halt
> Target 0 halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled

Next, the lowlevel.bin image must be used to initialize the Neo1973's RAM controller:

> load_binary lowlevel.bin 0
280 byte written at address 0x00000000
downloaded 280 byte in 0s 102067us
> bp 0x33f80000 4 hw
breakpoint added at address 0x33f80000
> resume
Target 0 resumed
> Target 0 halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x33f80000
MMU: disabled, D-Cache: disabled, I-Cache: enabled

Load the u-boot image into RAM:

> load_binary u-boot.bin 0x33000000
214860 byte written at address 0x33000000
downloaded 214860 byte in 16s 533236us

Hold down the Neo's Aux button (to prevent the Neo from trying to boot the kernel) and run u-boot:

> resume 0x33000000
Target 0 resumed

At this point you should see some output like the following on the '''serial console''':

U-Boot 1.3.1+git20071214+svnr3648 (Dec 14 2007 - 09:36:50)

DRAM: 128 MB
NAND: 64 MiB
*** Warning - bad CRC or NAND, using default environment

Video: 640x480x8 31kHz 59Hz
USB: S3C2410 USB Deviced
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
mtdparts variable not set, see 'help mtdparts'
Clearing SETUP_END
Clearing SETUP_END

and you should also see a small penguin on the Neo1973 screen. If not, go back to the "reset halt" step and try again.

Now connect to the '''USB console'''. The first thing to do here is to clear your entire NAND flash and update the bad-block table.

{{warning|This will erase your entire device, although it should preserve your existing bad-block table. See [[NAND_bad_blocks]] for more information}}

GTA01Bv4 # nand createbbt
Create BBT and erase everything ? <y/N>
Skipping bad block at 0x03ff0000
Skipping bad block at 0x03ff4000
Skipping bad block at 0x03ff8000
Skipping bad block at 0x03ffc000

Press Y and Enter...

Creating BBT. Please wait ...

Next, create the environment variable that defines the NAND partition table:

GTA01Bv4 # dynpart
mtdparts mtdparts=neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash),0x03d1c000(rootfs)

Next, copy the u-boot image from RAM to its flash partition:

GTA01Bv4 # nand write.e 0x33000000 u-boot

NAND write: device 0 offset 0x0, size 0x40000

Writing data at 0x3fe00 -- 100% complete.
262144 bytes written: OK

Set and confirm the environment offset:

GTA01Bv4 # dynenv set u-boot_env
device 0 offset 0x40000, size 0x4000
45 4e 56 30 - 00 00 04 00
GTA01Bv4 # dynenv get
0x00040000

This step was successful if the 'dynenv get' result is equal to the 'offset' shown above. The actual values may differ from what is shown here.

Now temporarily set the "bootdelay" environment variable to disable auto-boot, then save the environment:

GTA01Bv4 # setenv bootdelay -1
GTA01Bv4 # saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done

Disconnect from the USB console. From the '''openocd console''', reboot the Neo1973.

> reset
> Target 0 halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> resume
Target 0 resumed

You should again see some text on the serial console, and a penguin on the screen. You now have a DFU-capable device, so you can load the remaining images:

./dfu-util -R -a splash -D ./splash.gz
./dfu-util -R -a kernel -D ./uImage-neo1973-latest.bin
./dfu-util -R -a rootfs -D ./openmoko-devel-image-fic-gta01.jffs2

The final step is to go back into the '''USB console''' and set some more environment variables:

GTA01Bv4 # setenv splashimage nand read.e 0x32000000 splash\;unzip 0x32000000 0x33d00000 0x96000
GTA01Bv4 # setenv bootargs_base rootfstype=jffs2 root=/dev/mtdblock4 console=tty0 loglevel=8
GTA01Bv4 # setenv quiet 1
GTA01Bv4 # setenv bootdelay 5
GTA01Bv4 # saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done

Now disconnect from the USB console. From the '''openocd console''', reboot the device one more time to ensure that it now boots successfully:

> reset
> Target 0 halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> resume
Target 0 resumed

You should see the regular splash screen, followed by the kernel boot messages and (eventually) the Openmoko GUI. You may now shut the phone down and disconnect it from the debug board. Remember to remove the USB cables and the battery before disconnecting the FPC cable.

[[Category:System Developers]]
[[Category:Debug Board]]

Building FSO

2008-09-18T19:50:24Z

Starox: Update links to freesmartphone.org

{{FSO}}

The freesmartphone.org (FSO) image is based on the OpenEmbedded distribution. OpenEmbedded is not part of Openmoko, and targets many different devices.

FSO's source tree, documentation and bug tracker are not hosted at openmoko.org. This wiki page simply points to the relevant portions of OpenEmbedded's documentation. Openembedded.org and freesmartphone.org contain more complete documentation.

= FsoMakefile =

There are two ways to build an FSO image.

The first approach uses FsoMakefile to automatically download and configure the build environment, and is the easiest way to build an image:

wget http://downloads.freesmartphone.org/Makefile
make fso-testing-image

This is the process used by the build servers to create new images.

Ubuntu can throw up errors [[Talk:MokoMakefile]]

See http://downloads.freesmartphone.org/ for more information. Note that FsoMakefile and [[MokoMakefile]] are separate entities, and target different images.

You can access the FsoMakefile directly from the git repository with this command (there is no difference between this and the above once the build starts):

git clone git://git.freesmartphone.org/fso-makefile common
ln -s common/Makefile Makefile
make fso-testing-image

= Building manually =

While convenient, building with FsoMakefile does not tell you much about what is going on under the hood. FsoMakefile automatically downloads an OpenEmbedded build tree, configures it to build FSO and then builds the image.

OpenEmbedded's manual build directions at http://wiki.openembedded.net/index.php/Getting_Started describe the process in more detail. They also explain how to build individual packages, and describe bitbake, which manages OpenEmbedded builds.

OpenEmbedded targets a number of devices, and their package database can produce a number of different images. Therefore, as you follow their directions, you will need to modify them to build FSO for your device.

First, when you edit the targets in local.conf, you need to set it to build an Openmoko distribution.

If you wanted to build FSO for a Neo1973, you would write this:

BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta01"

To build FSO for a FreeRunner, you would write this:

BBFILES = "/stuff/org.openembedded.dev/packages/*/*.bb"
DISTRO = "openmoko"
MACHINE = "om-gta02"

If you want to build FSO's unstable branch then include the following two lines at the end of local.conf:

require conf/distro/include/fso-autorev.inc
require conf/distro/include/moko-autorev.inc

These two .inc files tell bitbake to use the most recent versions of each package, instead of the (hopefully tested) preferred versions.

Once you've finished setting up the build environment, you can build the FSO image with the command:

cd /stuff/build && bitbake fso-image

= Configuration =
{{Note|This section should be it's own page...}}
== GTK ==

Currently GTK is not well supported in the FSO build. To use GTK applications you'll most likely have to install the gtk library, and the Openmoko theme.

'''Step 1) Install the ipk-packages'''

opkg install moko-gtk-theme
opkg install openmoko-icon-theme-standard2
opkg install moko-gtk-engine

'''Step 2) Enable Theme'''

vi /etc/gtk-2.0/gtkrc

Add this line to the top:

include "/usr/share/themes/Moko/gtk-2.0/gtkrc"

'''Step 3) Set icon theme'''

vi /etc/gtk-2.0/gtkrc

Add the line:
gtk-icon-theme-name="openmoko-standard"

'''Step 4) Third party themes (optional)'''

Add one line per 'third-party' gtk theme you've installed. For example, openmoko-mediaplayer is not packaged with FSO:

include "/usr/share/themes/Moko/gtk-2.0/openmoko-mediaplayer"

'''Step 5) Other tweaks

To get "2007.2-style" icons (no text, smaller), so that all the terminal buttons fit on the screen at once:

gtk-toolbar-style = GTK_TOOLBAR_ICONS
gtk-icon-sizes = "gtk-button=32,32:gtk-small-toolbar=16,16:gtk-large-toolbar=24,24"

And make any other changes you like. I don't like double arrows on the tops and bottoms of sliders:

GtkScrollbar::has_secondary_backward_stepper = 0
GtkScrollbar::has_secondary_forward_stepper = 0

Look at existing gtkrc files for more options (if you find the manual, add a link).

[[category:FSO]]

Wish List

2008-02-25T08:23:42Z

Starox: /* Fuel Log */

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [http://wiki.openmoko.org/wiki/Category:Ideas that have a category of 'Ideas'].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation (apt-get install openmoko)
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform three particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== Joe's Goals ====

It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information ( spritmonitor.de, anything else ?)
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Context based TO-DO list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Faster access to task list ====
Click on the date to add a new task.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/contacts/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/]

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:
* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.
** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

===== Automatic timezone changing (GPS) =====

Check the timezone with GPS and adapt them.

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Lenght
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== TV Guide/Remote Control ====

Use your Phone to easily program your VCR using EPGs.

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.

==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC client ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.
=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

== GPS Software ==
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes

 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== Dedicated Power / Charger Pinout ===

Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea.

Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.

The main question is just deciding on where to take power from if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry.

This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now".

I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

=== SD Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space.

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.

: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)

: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

[[User:Cfriedt|Cfriedt]] 12:40, 24 February 2008 (CET) -- I completely agree with a more accessible SD card slot. It should be made external for quick removal / insertion. I realize that would mean program data shouldn't reside on the SD, but really 256 MB of on-board flash is plenty. Mirco or normally-sized, a regular-sized SD is still trivial to implement in terms of solder pads and traces.

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.

:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.

:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.

[[Category:User]]
[[Category:Ideas| ]]

User:Starox

2008-02-22T13:05:39Z

Starox:

Hello,

I'm an happy gta01 owner. I buyed it to replace my phone and my pda, knowing it's a developpement platform.
So, I wan't to replace these application on palmos :

- pfuel - keep track of vehicule tanking
- sudoku
- bincalc - a bin/hex/dec simple calculator
- easycalc - an advanced calculator
- memo
- cocoboot (I'm jocking :))
- metro
- plucker - use fbreader ?

I already start write a fuel manage named mokofuel.

You can contact me at "fredo __replace_this_with_at__ starox.org"

Fuel Log

2008-02-22T12:58:49Z

Starox:

[[User:starox|I]] started a project named Mokofuel on openmoko to replace pfuel on palmos.
If you're interested in, please contact me at "fredo __please_replace_this_with_at_ starox.org".

Technically, it uses an ui glade file for ui and I'm digging sqlite for backend. One database file per vehicle.
I hope using .glade files, allow me to keep the same codebase to develop both pda and desktop application.

I'had moved, and currently, I'm without internet connection. But I can read and write mail as well surfing at work.

I'll be back asap and keep maintaining this page.

If you will or you had started a similar project, please inform me.

Wish List

2008-02-22T12:48:46Z

Starox: /* Fuel Log */

This article is a place to collect various thoughts about the future of the [[OpenMoko]] software platform. Most wish list ideas have been linked from this page, but you may also wish to check all pages [http://wiki.openmoko.org/wiki/Category:Ideas that have a category of 'Ideas'].

== Development ==
=== Painless SDK installation & Setup ===
Our goal should be a completely painless setup for somebody wanting to develop using [[OpenMoko]]

* one command for installation (apt-get install openmoko)
* one command to start Xnest (openmoko-xephyr?)
* one command to start an i386 shell (openmoko-386-shell)
* one command to start an armel shell (openmoko-armel-shell)

No extra configuration required.

==== IDE Plugins ====
People like to see plugins for
* [http://anjuta.sourceforge.net Anjuta]
* [http://www.eclipse.org Eclipse] (some things are possible - see [[Development with Eclipse]].
* [http://www.netbeans.org NetBeans]
* Game engine - Game Creation plugins
evaluate eclipse project [http://www.eclipse.org/dsdp/index.php Device Software Development Platform Project from eclipse] and subproject [http://www.eclipse.org/proposals/tml/ Tool for Mobile Linux]
* [http://www.kdevelop.org KDevelop]
* [http://developer.apple.com/tools/xcode/ XCode]
* [http://msdn.microsoft.com/vstudio/ Microsoft Visual Studio 2005]

==== UI Designer ====
Glade code generation is deprecated, so we don't want to use it. The Gtk+ powers told me that the plan is to have gtk 2.12 (out early 2007) with support for GtkBuilder, a libglade derivative which breaks a bit the XML definition in order to support all the new widgets and properties; as soon as it's in the other ui builders will add support for this format. See also [http://bugzilla.gnome.org/show_bug.cgi?id=172535 the relevant bug entry]
* Possibly a Landscape (rotated) view for the screen (480x640 *or* 640x480)?

==== Built-in Scripting Language ====
{{Main|Wishlist:BuiltInScriptingLanguage}}
There was a [http://lists.openmoko.org/pipermail/community/2007-January/001909.html fruitful discussion about a built-in scripting language on the mailing list in January.] Many people feel that it is very important for OpenMoko to choose a scripting language to ship as default in the standard OpenMoko firmware.
==== Easy build of the existing autotools - based packages ====
In the ideal case OpenMoko should exist on the top of the usual ./configure - make workflow which is typical for the majority of the C/C++ based open source projects. It should not require to rewrite or even replace the existing Makefile.am files of the project being ported, and it should allow to pass the needed parameters to the project configure script. Maybe OpenMoko project could be a bigger project having one or more (if some are libraries) autotools - based packages in its separate folders and include the proper documentation how to "wire" the standard autotools based package to the OpenMoko infrastructure.

===Foreign Widget Set Bindings ===
==== Qt Integration ====
The Trolltech folks have a great widget library. I'd like to interface OpenMoko with Qt4, so that we can write Qt4 applications for the phone which don't look alienated.

==== Maemo Integration ====
The Maemo folks have created a successful standard for Webpad applications. I'd like to have a set of MaemoMoko and MokoMaemo wrapper classes that allow me add support for running OpenMoko applications on Maemo and vice versa. Perhaps we can get help from the Nokia OSS folks for that.

==== wxWidgets Integration ====
wxWidgets is a cross-platform application framework that's very popular (I'd say, #3 after Qt and Gtk+). On Linux, wxWidgets uses Gtk+ to implement the widgets. It shouldn't be hard to add support for the additional OpenMoko classes to wxWidgets hence supporting the native OpenMoko look and feel for wxWidgets applications.

wxWidgets team wants OpenMoko classes too and we (wxWidgets) plan to include this project as one of our ideas for [http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html GSoC 2007]

==== SDL Integration ====
SDL is ''the'' game developer library. There are tons of SDL games out there. We should add OpenMoko support into SDL.

==== Cocoa / GNUstep ====
Allows to use MacOS X as a development platform.

=== Software: Language bindings ===
==== Python bindings ====
Python bindings seem to be a commonly requested feature.

[[User:Mickey]] says, "They are kind of usable on the [http://www.maemo.org Nokia 770], but it's at the lower end of being bearable. We should keep this in mind -- Gtk+ already comes with Python Bindings, so we "just" would need to wrap libmoko*. I would prefer to leave this to the community do though, since it doesn't make sense to start wrapping the API until we have a stable API -- and I can imagine it will take us a couple of months after going open until we can start with stabilizing the libmoko API."

==== C++ bindings ====
There is a whole skilled C++ community coming from the [http://qtopia.net Qtopia] and [http://opie.handhelds.org Opie] projects. If we would consider basing OpenMoko C++ Bindings on [http://www.gtkmm.org/ Gtkmm], then we could drag these guys in.

==== Ruby bindings ====
Ruby and ruby-(gtk|glade) already ported to OpenMoko according to [http://lists.openmoko.org/pipermail/openmoko-apps/2007-May/000040.html this ] and [http://groups.google.de/group/comp.lang.ruby/browse_thread/thread/6bee9970cf055504 this] mesages. It just have to be included to distribution (only 4.9 MB!)

==== Java bindings ====
People who concentrate on Java programming would like to have the OpenMoko port of some java virtual machine. GNU Classpath team a lot of great work in the past creating easily portable implementation. Sun's recently open sourced code could also be ported.
==== Other bindings ====
* Perl
* C#
* I think you could skip a bunch of these by binding to Dbus; most languages already have Dbus bindings

== Community Support ==

=== [http://projects.openmoko.org projects.openmoko.org] ===
Infrastructure for developers with
* One bugzilla for all projects (makes moving bugs forth and backwards between projects ''very'' easy)
* One mailing list for project

== Platform ==
=== Community Images ===
In the future there could be complete, unofficial "product images" that are created by the community, for example maybe one that incorporates only free software (in the GNU or OSI sense). Or images build with a particular niche market in mind -- a student for example.

=== Wishlist voting ===
There could be a kind of voting system like they have at one of those big computer manufacturers homepage. Then the community could vote for the ideas that are most important to them. This would especially make sense for the hardware wishlist, because the hardware is still the part which can't be done by the community that easily.

Here: [http://www.fevote.com/openmoko OpenMoko suggestion board]

== Software: Additional features ==

===PDA Mode===

There are times when you wish to power up the device and not power up the gsm/cellphone portion of the phone. For example in meetings you might wish to access the PDA side with wifi as is the case for example on an aircraft. On booting some method of booting to pda mode would be good - several other phones offer this feature.

===Driving Mode===

It may be forbidden in many countries, but many people use their cell phones while driving. With the touchscreen phones
this is very dangerous: You have to stare at the tiny numbers on the screen and try to hit them with your thumb or try to decipher tiny script of contacts, while steering with the other hand. There should be a configurable driving mode where the interface has a reduced functionality (e.g. only contacts and dialing) with HUGE interface buttons that are easy to use with limited attention.

===Calling===

==== Mask ID based on dialed numbers ====
It would be nice if my number only showed up when I call people in my address book and was otherwise masked. The phone I have now either always shows my number or never or can be set on a per call basis. Having it done automatically based on the number dialed would be good.

==== Use calling cards and similar routing techniques for lower-cost calling ====
Many people use calling cards, low-cost numbers and similar ways of reducing the costs of their calls. It would be nice to have a single panel that would allow you to configure the rules of dialing a number taking in to account such systems.

==== Outgoing black/white lists ====
The ability to allow or deny outoging calls to certain numbers can be useful in a number of situations (e.g. the holder of the 'phone is a child, untrusted, etc.). This could be related to entries in the contact list, for example a user is only allowed to call people who are in their contact list.

Also lists for incoming calls? Some friends always come through, unknown numbers get rejected automatically.

==== Time-based blocking/unblocking of calls ====
Allowing or disallowing outgoing calls at certain times of the day could be useful, e.g. blocking a business phone from making calls outside of business hours.

====Speaker-phone====
* A speaker-phone is more than simply connecting the speakers to GSM audio, it's also echo cancellation, and eliminating the feedback that will otherwise happen between the speakers and the mic. This software has not been written.

====Advanced Airtime Tracking====
Many phone users have complicated plans, things like unlimited incoming, 100 anytime minutes, 1000 evening minutes, etc. It would be nice if a user could input the various monthly airtime chunks their plan gives them, and then the phone could track how much is left in each chunk, i.e. How much anytime minutes are left this month? Optionally, the software could warn when someone is close to the monthly limit, to help avoid bigger bills.
On (at least some) prepaid [http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data USSD] can be used to check current balance.

==== Anti-stutter software ====
Delayed Auditory Feedback (DAF) has shown to reduce stuttering in individuals by 70%. By using the microphone, it should be pretty simple to implement this on the OpenMoko. The DAF functionality should also be present during phone calls. See http://en.wikipedia.org/wiki/Delayed_auditory_feedback for more information.

====Minimize In-Call mode (check address book while in call)====
On my locked phones I always find it annoying that one can not use other features while a call is in progress. In particular, I'd like to access the address book so that we can (1) give a caller someone else's phone number (or other info) and (2) lookup a phone number when using a calling card or some other proxy.

Similar request when using the browser (lookup passwords, todo list, etc).

====Hold Music (Ringback Tone)====
On some cellphone networks you can pay to change the normal [http://en.wikipedia.org/wiki/Ringback_tone Ringback Tone] that the caller hears when ringing, to a customised sound.
This can partially be implemented on the phone.
Issues are:
*In countries where callers pay, this will make you unpopular.
*In countries where the called party pays, it will use your minutes, or cost you money.
**A list of people to activate this function for would alleviate this.
*[[GPRS]] internet connection will stall while the hold music is being played.
*Extra battery used when playing music.

Also see [[Answering Machine]].

====Play sound clips over the air====
Dialer could have a tab with big buttons which, when push, send sound clips over GSM to the person on the other end of the call. This feature is included in GizmoProject and is called sound blasts: http://support.gizmoproject.com/index.php?_a=knowledgebase&_j=questiondetails&_i=104
The buttons can have default sounds, but also have the ability to be customized.

It would also be useful for notifying people why you can't talk (for example, having an "I can't talk tight now - I'm in the library - this is a pre-recorded message" would be good. Also perhaps you could loop a pre-recorded sound in the background so you can lie about where you are, and have the ability to simulate a really bad connection.

==== DTMF Landline Dialing ====
The ability to hold the Neo near the microphone of a landline handset and have the Neo dial the landline by sounding DTMF tones. The DTMF tones could be generated in software or be pre-recorded files.

Graphically this could be done by adding a 'DTFM dial' button to a context menu. The user would select a contact then presses the 'DTMF dial' button to start the process. A small delay could also be added to allow time to put the Neo near the landline handset.

For the Neo to know which area code to use (or not use) the current or last GPS coordinates could be utilised.

==== Conversation Recorder ====

An option to record phone conversations. Would be helpful to have the device always recording for every call, with the sound data encoded to low quality Ogg Vorbis or SPEEX and stored in RAM. At the end of the conversation the user would have the option to save to flash or discard the conversation. This idea could also be applied to voicemail so you could save voicemails locally.

====Unlicensed Mobile Access (UMA)====
T-Mobile recently rolled out a UMA service that hands off calls between the GSM network and WiFi access points. Only a few phones support it right now, this could be a rather unique feature if OpenMoko can implement it.

This can be combined with a GPS map to show where local free hubs are.

==== Ignore-Call Button ====
{{Main|Wishlist:Ignore Call Button}}

Shut up a ringing phone, without accepting or rejecting the call.

Another alternative might be to use microphone to recognize when the user gives an audible "Shhh!" command. This could prove difficult to determine with the simultaneous ringing, and possible in-pocket shuffling noises.

A really usable feature is to "reject with SMS/text message" - letting the user reply the caller choosing a previously setup template or typical response: "I'm in a meeting - I'll call you later" or "Can't take your call now, please call back in 10 minutes". This feature typically is a much better way to get your co-workers (ie boss) to back off, than to silently ignore the call.

==== Voice Mailbox ====
{{Main|Voice Mailbox}}
On-Phone voice mailbox that records calls on the phone and retrieves voice messages from your mobile service provider's voice mailbox and saves them locally.
Can act profile-dependent.

==== Hold Button ====

Similar to mute, but plays a sound file for the user on the other end while they wait. The sound file could be chosen in some setup beforehand.

==== Unanswered Call, Fast Call ====

In Greece because of the various bill programs some people call a mobile phone, rings one time and then hangup.
Then the user of the mobile phone calls the other user(using the CallerID recognition).

===Audio===

==== Ambient Noise Detection ====
{{Main|Wishlist:Software:Ambient Noise Detection}}

Using the microphone to detect ambient noise the ringtone volume could be adjusted automatically.

Detection of ambient noise could also be used to subtract the noise from the audio signal. However this approach is best performed using two Microphones, one for the voice and the other to detect the noise.

==== Active noise control ====

Using the microphone to do [http://en.wikipedia.org/wiki/Anti-noise active noise control] on media player playback or telephone calls. This should be an independent module/library which can be used by any application which might require this feature. also provide a way to easily alter the parameters of the active noise control.

==== Hear Impaired Mode ====

Hearing impaired people need louder speaker(but with less volume than hands free) and equalized sound, based on their hearing problems(example 20dB hearing loss from 2KHz to 4KHz).
Older people 50+ years old need slower speech rate(time stretch, cut the big speech gups) and cleaner voice.

Please note also the Hearing Aid Compatibility regulations in the US. I have tried to summarize and clarify them [http://quux.wiki.zoho.com/WhereAreHACphones.html here]. I haven't yet discovered whether the FIC device is M or T rated. For many hearing impaired users, a tcoil coupling to their hearing aid (t3/T4 rating) would be preferable to manipulating sound output in other ways.

==== Mute Button ====

Button to temporarily disable microphone while talking for applications such as telephone, audio recording and (when available) movie recording.

===Web Browser===

==== Full-page Zoom Support ====
Full page zoom is a very good feature. If possible, people would want to browse the internet with normal layout than a distorted one. It's best if I could double-tap a text or image block and zoom to a fit size.

The [[BigPageWidget]] proposal suggests 'Full Page Zoom' should be implemented as a widget available to all applications.

* If the processor and memory could afford, it is good to just use [http://www.mozilla.org/projects/firefox/3.0a8/releasenotes/ Firefox 3] in OpenMoko. It has implemented latest gecko's full-page-zoom ability. With certain modification, we could do the same zoom like iPhone's Safari.
* Firefox 3 may be a big eater. A cut-down version of it may be good enough.
* If this is not practical, Minimo with full-page-zoom ability is good.

==== Plugins Support ====
* While an extensive browser plugin system would be costly to the efficacy of the platform three particular browser plugins as poplularized by Mozilla firefox should be adapted to the web-browser, namely: [http://noscript.net/ noscript], [http://adblockplus.org/en/ adblock plus], [http://www.greasespot.net/ greasemonkey] and [http://www.foxmarks.com/ foxmarks].
* Careful use of these can dramatically reduce bandwidth, page space, and rendering costs even if it comes at the risk of some hard drive space in the form of block lists.
* Greasemonkey, in particular, gives users control to set up scripts for commonly traveled pages to further reduce unnecessary or unwanted content.

==== Widget support ====
Built-in browser with the ability to install widget shortcuts (aka links) in the main phone menu, also some apis for interfacing with the other functionality of the phone like adding contacts, reading contacts, reading gps-psoition etc.. (maybe there is some defacto widget standard that could be used)

There is a [http://www.w3.org/TR/widgets/ W3C spec] being developed, which may not be exactly what the original proposal had in mind, but it is about writing simple applications with HTML, SVG and JavaScript. It is mainly Opera's work, and while most [http://widgets.opera.com/ developed widgets are not very useful], there are some that are, and it creates a very nice development platform, especially for mobile devices. So, I think it makes an awful lot of sense for OpenMoko to support this spec.

===Media===
====Music/Video Software====
A real good programming area for competition with the iPhone, a singular video/music player would be great for multimedia. A seamless integration system, a la iTunes and iPod, would be extremely popular.

Using the Wi-Fi connectivity, a separate music program that supports wireless music sharing/ streaming (similar to what can be done when two computer running iTunes that are both on the same network) and that also supports internet radio.

It would also be nice to have some kind of "announce your musical taste" mode. This could be implemented using last.fm profiles, such that when e.g. in a crowded place a user nearby has a similar musical taste, both users get notified so they can share their music files with each other (perhaps using a photo for id). Great for discovering new music - and making friends!

- Possible copyright issues sharing music files?

Sure, but that's the user's concern, not the developer's. There's no way for us to know which audio files the user is permitted/not permitted to share.

==== Reading Support ====
It would be really great to be able to read :

*PDF
*Open Document files
*Text / RTF files
*fb2 files (fbreader)
*MS Office files
*Aportis Doc (pdb)
*DjVu
*...

In both landscape and portrait

==== Wikipedia Mirror ====
{{Main|Wishlist:Wikipedia_Mirror}}

==== Blog ScribblePad ====

Draw an image (and maybe add some text), then post to your blog.

==== E-Book Reader ====
* Neos brilliant ultra-sharp screen makes for a very good e-book reading device. All it takes is a good e-book reader with touch-screen page turning / scrolling (see the [[BigPageWidget]] proposal). FBReader could probably be adjusted easily by an experienced GTK hacker. Note that e-book reading is different to pure text/pdf displaying as it requires at least auto-bookmarking of the last read page, proper text and image scaling and text formatting.

==== Personal Wiki ====
{{Main|Wishlist:PersonalWiki}}

Display the notes database as a Wiki. Inspiration: [http://www.acrocat.com/AcroWiki/default.asp?lang=en AcroWiki].

[http://www.didiwiki.org/ Didiwiki]

==== Dictionary, thesaurus, translator and flashcards ====
Native lookup dictionary and thesaurus and foreign translation dictionaries, also with support for Asian languages. Optional custom configurable (though preconfigured) interface with on-line versions of dictionaries, thesaurus and translation services.

'''Dictionary'''
Something like [http://www-user.tu-chemnitz.de/~fri/ding/ ding]:

advantages:
* small
* very efficient + useful
* only limited to really needed functions

Support for vocabulary training with flashcard system (also usable for other content than foreign language words!)

==== Flickr uploader ====
A simply, drag & drop uploader, tagger and organizer to upload images on phone to [http://flickr.com Flickr], with support for various languages. A good base could be the cross-platform uploader [http://juploadr.org/ jUploadr], written in Java and working on Windows, Mac and Linux. But, most of all, the best '''GPL''' program which actually do this work is '''[http://mobilepushr.jottit.com/ Mobile Pushr]''', written in C and Cocoa for iPhone, must be probably ported in python to work on OpenMoko.

===PIM (Personal Information Managment)===
====Context Sensitivity====
Any email or sms message or application that contains a telephone number should be click to dial, eg [http://123567890 1234567890]. Addresses link to mapping software too?

==== Notes ====

Something for taking notes would be a nice feature:
[http://www.gnome.org/projects/tomboy/ Tomboy] has some nice syncing features and is gtk based.

Some Screenshots are [http://www.gnome.org/projects/tomboy/images/ here].

==== Calendar ====

A nice calendar application should be implemented in OpenMoko. This tool should have a syncing feature with your desktop computer.
The tool should have a reminder feature and other features like other mobile phones already have.

I think synchronization sould be handled by computer with opensync+syncml based tool, not by calendar itself. --[[User:Antono|Antono]] 12:25, 7 January 2008 (CET)

* If this cellphone is thought also as a PDA, of course it needs a calendar. But I would like to see something better than just a calendar, I was thinking that there could be some application using "fisheye" view. Just like [http://www.cs.umd.edu/hcil/datelens/], though that example seem a bit chaotic. --[[User:Yprum|Yprum]] 22:27, 21 February 2008 (CEST)

==== Address Book ====

* Option to search not just the stored list of addresses, but one or more of the online phonebooks. Probably should be modular to make adding/changing phonebook sites easy. Also allows for future integration with LDAP
servers or whatever.
* Also the possibility to search all info on the contact, like number, email, postal address and so on, in case someone asks you to identify a known number.
* Web-based map-lookup. 'How do I get there from here? (here = current GPS location)' This could also be done
by integrating with whatever on-phone GPS mapping software the Neo ends up using.
* Random text input 'notes' about a contact
* Overall, this should more resemble a Palm-pilot's address-book than your average cellphone's
* Automated Daily backup of phone book to a website archive (similar to Verizon's Back-up Assistant
*Ability to integrate address book with web-based email (such as gmail) account, for those who use web based email as their primary account
* '''[[Wishlist:Tagging|Tagging]]''' Place tags for contacts. Enhance message application to send messages to all contacts tagged with ... . Enhance other application(GPS, ...) with tags.
* Support for:
**[http://en.wikipedia.org/wiki/SyncML SyncML]
**[http://en.wikipedia.org/wiki/Ldap LDAP] address book
**[http://en.wikipedia.org/wiki/LDIF LDIF], [http://en.wikipedia.org/wiki/Xml XML] and [http://en.wikipedia.org/wiki/Comma-separated_values CSV] export and import (when possible).
*Store Bluetooth IDs of friends and notify (configurable only on this device or on both devices) when a one of these Bluetooth ID has been detected (this is more a separate application but has requirements on the address book. Should also be able to create an address book entry from a Bluetooth ID. Could be used as a nice tool to detect people who you're avoiding.

==== Database/List Display/Edit ====
{{Main|Wishlist:PilotDB}}

One of the most useful apps on my Palm Pilot for me is [http://pilot-db.sourceforge.net/ pilot-db]. It's GPL'd.

==== Joe's Goals ====

It'd be nice to have something like [http://www.joesgoals.com Joe's Goals] always available, like my phone is, even when I'm disconnected from the net.

==== Workout ====

Use your phone instead of your notebook while at the gym, and get pretty graphs to admire after you're done.

==== Shopping List ====
keep Track of Prices in different shops and the products you have/don't have. Ideally using a barcode reader and gps.
If it was made aware of recipes it could even tell you what to buy without entering a shoppinglist manually.

==== [[Fuel Log]] ====
File data about fueling your car (date/time, liters, price, mileage, ...) and display some information (costs per month, average consumption, ...).
Advanced features could include:
* Automatically storing the GPS coordinates of the place where the car has been fueled (can be deactivated)
* Sending the data to a central server which collects the information
* Let the OpenMoko receive fuel logs per SMS (e.g. if my wife with a non-openmoko mobile fuels the car and wants to file the data using her mobile phone)
* Let the OpenMoko device act as SMS gateway for non-openmoko devices to easily send the data to the central server
* Also support for air log for divers. Not that you will take this device under water but for the crew at the surface.

==== Keep in touch reminder ====
A background application which keeps track of your friends and reminds you when you have not talked, SMS, IM or mailed a person for more than # days.

==== Menstruation period timer ====
Fill in statistics and compute probabilities for menstruation, fertility, mood.
See http://www.getjar.com/products/48/MyGirls

==== Tagging ====
{{Main|Wishlist:Tagging}}
Tags can be used by various applications. Requirement is interoperability for further enhancement.
Tags should be applied to calendar events, mail/sms, calls, places(GPS) and files.
http://tracker-project.org has all needed tagging-and-searching functionality and ready to be used on low-resourced devices.

==== Context based TO-DO list ====
{{Main|Wishlist:context based to-do list}}

If I arrive home and there are "@home" things in the to-do list, the Context based to-do list reminds me of that.

==== Faster access to task list ====
Click on the date to add a new task.

==== Exchange Integration ====

Once there is good TCP/IP connectivity on this phone, integration with corporate email/calendar/to do/etc servers would be a big advantage... near-real-time automatic email downloads and automatic bi-directional syncing are productivity boosters that you have to experience to appreciate. It turns your phone from a 'nice gadget to fiddle with' to a natural-feeling extension of your day-to-day life.

* Is the time right to name names ? Add as your liking...
** Plugin/integration to & from Kontact
** Same with Evolution - Thunderbird - Seamonkey
** ?? Google Calendars ?? (this one is tough)
** Ms Exchange

==== An electronic wallet ====

A database which stores securely PIN codes, login data, bank and email accounts, membership informations, and other valuable and private data. Entries can be ordered in a folder-like manner. Access to the database is given by a master password. The database as well as the master password are stored with strong encryption. For security reasons, the program asks again for entry of the master password after a certain period of inactivity. The database can be synchronized with a PC application (ideally written in Java for cross platform compatibility).

Examples: KWallet [http://docs.kde.org/stable/en/kdeutils/kwallet/index.html], Viskeeper [http://www.sfr-software.de/cms/EN/pocketpc/viskeeperpro/index.html], KeePass [http://keepass.info/]

==== Easy business card sharing for a small group (in the same room) over bluetooth or WIFI ====

Six Neo1973 owners are having a chat in a cafe. They agree to split but meet later. They want to exchange their numbers with each other before they go.... The normal way to do this is for a rather longwinded repeating of numbers to each other, or half the people manually inputting numbers before phoning/texting the other half to complete the process. All in all its a fair number of button presses to get it sorted.

Instead the NEO could have a small app where the phones link up in a small peer to peer Bluetooth network and share automatically with one person initiating a request and the other detected NEOS agreeing/acknowledging the share. The initiating NEO would then sync the mini-group automatically by interrogating each phone and then sending the table of results. The NEOs would have to be clever about checking for duplicates in the address book and offering a choice to the user if there are any conflicts.

PROS:
*genuine saving in time for social and business situations

CONS:
*I am sure there are some security hassles to be pondered....
*not going to be used every day... definitely not an immediate priority.....
*only at geek conferences will all have a neo....

==== SMS Counter ====

An application which shows on the today-screen how many SMS i've already sent in this actual month. Some have for example 150 free SMS to write each month. With that program you can see all the time how many SMS are left until the end of the period. As an alternative it could be a counter which counts backwards from a predefined number over a defined period.

===Profiles===
{{Main|Wishlist:Profiles}}

The Wishlist:Profiles page documents many possible profiles - ways to configure the phone. Including ways to respond to calls, wifi and GPS events.
And how to automatically switch between them.

===Text Messaging===
For '''Text Input related ideas''' see [[Wishlist:Text_Input]]. Bear in mind that T9 can not be included
For current development status of the messaging-app see: [[Messages]].

There are many useful options that now can be used to full capacity:
* '''Acknowledge/status SMS'''
In GSM networks so-called acknowledge-SMS are sent back to the SMS's dispatcher in order to indicate that the primal sms was received (as message delivery is only best effort and is not guaranteed). So in the SMS dialog there could be equal sized buttons with captions as 'send only', 'send and receive delivery status message' and 'send and notify (e.g. ring) when delivery succeeded'.
** '''Special handling of status-SMS'''
Related to the previous entry, these acknowledgment-sms' should be handled in a different way than normal SMS'. Most Motorola do this, while Samsung SGH series don't & clog the inbox, warn of a "new" message upon Status notification: Delivery Status Messages should be stored in a separate menu so they don't bloat the received-folder and you are able to quickly review the status of the messages you had sent.
* '''SMS at time/date''' You could be able to set up messages that are sent at a certain time/date
* '''Binary SMS''' Send binary SMS. Could be used to feign WAP pushes. [http://en.wikipedia.org/wiki/Multimedia_Messaging_Service] See:
** Resource for SMS encoding: [http://web.archive.org/web/20021016104345/www.dreamfabric.com/sms/] [http://web.archive.org/web/20060411222332/] [http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html] [http://www.ihub.com/Binary%20Messages.htm]
** [http://www.gammu.org www.gammu.org] - you can use Gammu/Gammu+ source for this software and/or understanding various SMS formats including EMS, WAP, Nokia Smart Messaging, Siemens & Alcatel encoding ([[User:Marcin|I could]] eventually help)
** Resource for SMS encoding (German): http://de.wikipedia.org/wiki/SMS-Kodierung
** The infamous pocketpc-attack: http://www.mulliner.org/pocketpc/
* '''Profile-override-SMS''' SMS that start with a certain code word override the silent profile and have the phone ring. So someone could alert you in case of some emergency.
* '''Codeword-SMS''' An expansion of the above: check for code words and allow selectable tones for matches. E.g. "Server Down!" has a loud klaxon, "Disk Warning" has a quiet chirp.
* '''(De-)Abreviation-script''' Implement a script that de-abbreviates: "hi m8 u k?-sry i 4gt 2 cal u lst nyt-y dnt we go c film 2moz" becomes "Hi mate. Are you okay? I am sorry that I forgot to call you last night. Why don't we go and see a film tomorrow?" (taken from: [http://en.wikipedia.org/wiki/SMS_language])
** Implement a script that abbreviates :-)
* '''Anti-Spam''' ...feature for SMS. May be it's possible to port some Bayesian based application like bogofilter.
* '''Rule based authorizations''' ...for received messages. For example, delete messages from one source between 9h00 and 18h00 (workday) allow them otherwise (to get alerting messages).
* '''Enable chat-like SMS-viewing''' SMS-Email-like: retain SMS app, but store 'conversations' rather than pile-up. Group/archive conversations by Caller Group (Work / Friends / Home / any user-defined Caller Group). Show appropriate icon from either Caller Group or Caller ID at the source of conversations panel
* '''Searching''' allow full-text search or string search.
* '''Massive SMS Deletion''' based on Conversation, author, before-date-xx.xx.xxxx, caller group, [[Wishlist:Tagging|tags]]...
* '''Call Back''' Prompt 'Call Back' alongside other first-line options (Delete, Save number,.. this kind of options) that appear when reading an SMS.
* '''Non-destructive deletion''', deleted messages goes to trash, and are recoverable.
* '''SMS-EMail-Gateway'''
SMS comes in, gets forward to your inbox, like any other piece of mail. Appropriate alerts and etc occur - again, just like for email. A simple SMTPD running on 127.0.0.1 that is hooked to an email-to-SMS translator that will send email addressed to 'SMS@localhost' (or whatever special address) out via SMS
* '''SMS-filter chain''', for stuff like Codeword-SMS above, Theft-mode activation, auto-response (reply with gsm-position for "Where are you?"), auto-substitution (like replace $POS with gsm-position in outgoing SMS).
* '''SCROOGE-SMS''' This is an intelligent SMS router. When you write your SMS you get the option of how to send it
** By standard carrier SMS - cost 10cents
** By OpenMoko SCROOGE SERVER - this will send your SMS to the OpenMoko Community SCROOGE SERVER next time you have WiFi - the phone will remind you to turn on WiFi when it knows you are in places where you have WiFi access. The person you are sending to picks up when they come into WiFi Range. This comes with an intelligent reminder that tells you that message has still not been delivered in 24 hours and would you now like to send it by a paymethod. This is better than IM because both parties do not have to have WiFi at the same time. - cost FREE
** By email/Wifi - cost FREE
** By email/GPRS - cost ???? Do Carriers allow this?
** Too many options!!!
** Alternatively SCROOGE SERVER could auto launch IM client if it detects both parties have WiFi at the same time (Status kept on SCROOGE SERVER?) to allow instant reply..... Person who receives has the option to reply in SMS or in IM or in VOIP phone.

=== Text input ===
{{Main|Wishlist:Text Input}}
There are many good suggestions for text input on the specific text input ideas page.

=== More/Custom Input Method Widgets ===
{{Main|Wishlist:More/Custom_Input_Method_Widgets}}
Additional and customizable Input Method Widgets (similar to virtual keyboard).
This could add soft-key functionality to games or other applications such as:
*D-Pads
*buttons
*virtual trackballs
*...
Personalized layouts could be associated with each application.

=== Games ===
{{Main|Wishlist:Games}}

=== Mesh Networking ===
{{Main|Wishlist:Mesh Networking}}

=== Printing Support ===
It would be really neat to be able to print over either bluetooth, Wifi, or USB. I can imagine wanting to print:

* Notes
* Maps
* Email
* Calendars
* ...

Cups contains a bluetooth printing backend, so (in theory) once you have your data in postscript format, you could hand it to cups and it'll do the rest. In practice, it depends on

# GTK+'s printing support
# Making cups run on a really small system

{{note| GTK+'s printing support seems to be very immature in 2.6 (which we need to use for some time). Gtk+ 2.10 contains much better printing support -- once we can use this, it should be more easy.}}

There's always the possibility to render postscript ourselves, but this is not a piece of cake -- in general, printing is much harder than one would imagine.

Further details:
* [http://groups.osdl.org/apps/group_public/download.php/2205/print-summit-gtk.pdf#search=%22gtk%2B%20printing%20API%22 osdl.org]
* [http://www.gnome.org/~alexl/presentations/guadec2006-printing.pdf#search=%22gtk%2B%20printing%20API%22 gnome.org]
* [http://www.j5live.com/?p=204 j5live.com]

===Misc Software===
====Clocks/timers/Activity meters====
===== Sport tracker =====
{{Main|Wishlist:Sport_tracker}}
Sport tracker can be used to measure the distance/velocity from point A to point B (or it could have several intermediate stopping points) using GPS. This would be extremely useful for running, biking, hiking, etc.

===== Standby clock =====
{{Main|Wishlist:Standby_clock}}
A quick way to see what time it is.

===== Egg Timer =====
{{Main|Wishlist:EggTimer}}

Very simple (one click) count up / count down timers are very useful.

===== Cycle Computer =====
As already mentioned by [http://wiki.openmoko.org/wiki/User_talk:Technil Technil], a cycle computer could be created using gps. The sensor at the bike's wheel could transmit data via bluetooth or some cable that would be attached to an openmoko device. In order to save power, one could switch off the gps and only use the bike's sensor.
* Just another idea that came to me: Why don't have sensor's transmit cable plug into the headphone/microphone plug? A tool reads the signals created by the induction of the passing magnet, then gives them to the cycle-computer-app :) --[[User:Minime|Minime]] 19:50, 12 April 2007 (CEST)

===== NTP Server =====

Run the [http://www.ntp.org NTP] daemon using the GPS chipset as a reference clock, so that the Neo would have a very accurate time-of-day clock and would be able to serve time to other networked devices.

I don't know what it would take to implement this. Items to consider would be the availability of a 1 pulse-per-second hardware signal, the accuracy of timestamps delivered in NMEA messags, etc. Dealing with power-management issues (such as the device going to sleep) would also be challenging.

===== Reality check reminder =====
{{Main|Wishlist:Reality check reminder}}

A tool to [http://www.phrack.org/issues.html?issue=64&id=16 hack your brain]

====Calculators====
===== A Universal Unit Converter Tool =====

One never knows when one may have to convert acre-feet into deciliters. A unit conversion tool makes all engineers and engineer wannabes much happier. And not only the engineers.

Ideas what kind of conversions a converter tool could do:

Lenght
- Acceleration
- Angle
- Angular Velocity
- Area
- Capacitance
- Radioactivity
- Currency
- Charge
- Computer Memory
- Conductance
- Density
- Energy
- Illumination
- Power
- Force
- Flow
- Pressure
- Speed
- Temperature
- Time
- Torque
- Viscosity
- Volume
- Weight

Roman Numerals
- ASCII, Hex
- Cooking
- BMI
- Clothing Sizes

Money Converter based on current rates from Internet...
e. g. Dollar <-> Euro

Physical and Mathematical Constants
GPS conversions

- link to or integration of a scientific calculator
- link to or integration of a simple calculator

A good basis for such a converter tool could be the Palm program "units" from
François Pessaux [http://francois.pessaux.neuf.fr/files/units1_11.tgz]. The GPL'd program comes with full documentation.

For GPS conversions see gpsbabel [http://www.gpsbabel.org]

===== An Postfix Notation (RPN) calculator =====

Many engineers, computer scientists and other groups who have grown to enjoy the simplicity and ease of an postfix notation calculator will miss them when they give up other platforms to move to OpenMoko. A RPN calculator will increase adoption by providing one of the tools that other platforms have provided for many years.

==== Windows CE Emulator ====

On ARM machine, Windows CE API emulator, like Wine on x86 machines.

==== PalmOS Emulator ====

The Access group is probably coming out with their Linux platform any time soon. One of the components is a PalmOS emulator which I'd like to see working on OpenMoko as well. There are literally thousands of PalmOS apps.

I'd like to see a Windows CE Emulator with active sync support.

==== TV Guide/Remote Control ====

Use your Phone to easily program your VCR using EPGs.

==== Alcohol meter ====
Give the phone some info about your body (gender, size, weigth) and when/what you drink and it will compute an approximation of the amount of alcohol in your blood. Updates automatically, could have an alarm, when you are probably sober again.
See, for example (German text) http://www.misterio-online.de/promille.htm

==== Interaction with LEGO Mindstorm ====
With the accelerometers, GPS and good CPU, the phone could be used to control/serve as input with robots built with LEGO Mindstorm, which can be accessed by USB and Bluetooth.

==== Flashlight ====
Simple finger application that makes every pixel on the entire screen white to be as bright as possible until you tap the screen again to turn it off. This way, you can use your Neo as a (short term) flashlight!

==== Wii Controller Emulator ====
Use the accelerometers and buttons on screen to work as a Wii controller via Bluetooth.

==== FUSE support ====
Ability to use FUSE to mount larger file systems over wireless. (even gmailfs, sshfs, etc.)

=== Accessibility ===
Accessibility features for the visually impaired.
* High Contrast Themes.
* Screen Magnifier. Features should include automatic cursor tracking when navigating menus and entereing text and provide manual controls to zoom in on other section of the screen.
* Text to speech. The software should read out menu item ,contact lists ,text messages etc. Would also be useful for operating the phone while driving. see: [[Wishlist:Speech synthesis]]

==== VOIP ====
Ability to use the phone for VOIP over wi-fi such as Vonage. They currently have 2 different pieces of software for pc . Basically software creates a mac address which is paired with your Vonage account. Skype could also be implemented but I prefer Vonage. Only available when connected to wi-fi with a good connection. Phone treats calls the same as a cellular call, could keep a separate log of minutes, ability to record conversations, etc. Option to use VOIP if connection is available automaticly or manually. Small icon to show when call is using VOIP.
* A standard SIP client would probably fit better into the "free and open" philosophy.
* Ideally a SIP client that includes ZRTP/SRTP for secure communications.
(Note: Vonage will not give you your SIP credentials, so you cannot log into their network with a non-approved softphone. Other VoIP providers have different policies.)

''This seems very similar to what [http://en.wikipedia.org/wiki/Generic_Access_Network UMA] offers.''

Asterisk is a great communication platform that can run on small devices. I have an Asterisk server running on a Nokia 770 and I read about running Asterisk on an iPhone. With the crosscompiler available it sould be possible to compile it and run Asterisk on an openmoko phone and let it take care of almost everything on the wishlist below.
Edw/

==== Power Meter ====
If the power bar is clicked on it will show time left on charge and if charging it will show time until full.

=== Accelerometer wishes ===
==== Flick interface ====
Ability to "flick" the phone for page up/down by simply and rapidly tilting the phone back-and-forth for up and forth-and-back for down. The same motion can be implemented for sideways motion. This will take advantage of the 2 3d accelerators.

Sensitivity of the scrolling should be configurable and a test option provided.

==== Reading navigation of documents enhanced by accelerometers ====
If the two accelerometers in Neo1973 allows it, it will be nice if when you're reading, give a newspaper, you can move up, down, left and to the right the viewing of the document just moving the phones to the corresponding direction.

I don't know if this is possible (haven't seen the project in detail yet) but this feature could be very attractive for final users (and this is good). (sorry for my english but i'm italian)

==== Wand UI ====
In keeping with the requests to think outside of the box... the dual 3d accelerometers should enable a 'magic wand'-style UI for certain uses. Macros could be recorded and edited, or presets could be used. For example, flipping the device playfully could initiate a game mode or could signal the end of the work day.

==== Shake-to-Wake ====
Giving the phone a shake enables voice commands for a few seconds.
Usage Examples:

* {Shake} "Call" ''ContactName'' ''PhoneType''
* {Shake} "Call John Mobile" (Calls John's mobile)
* {Shake} ''ApplicationName''
* {Shake} "Reader" (Opens the e-book application)

Would require a method of inputting voice tags for applications and contacts and obviously will only work for P2 (accelerometers)
But lets get voice command functionality working before P2 (just by pressing a button on the screen instead of shaking)

I think that is possibly to replace "Shake" with double hit with finger in the side of phone. Proper algorithms(with accelerometers) should recognize any similar activities.

==== Emergency call ====
When the accelerometer detects a great acceleration (i.e. 5G) start a countdown sequence, if it is not stopped make a call to a preconfigured emergency number. If the data from the GPS is accurate give it.

A first version could use a recorded message (an audio file). In next version it could use a synthesizer, so it can give more information (add GPS information when it is ready).

:I would worry that most such events would be false positives, and hard to distinguish from the real thing. A user dropping their phone (an event very common in the life of any cellphone) is far more likely than a user being in a car accident with their phone, and the clatter of a cell phone on asphalt could reach 5G. Additionally, it has to be very hard to distinguish hitting pavement from hitting a windshield, as from a physics standpoint the two are the same thing. [[User:Hashbrowncipher|Hashbrowncipher]] 02:06, 26 October 2007 (CEST)
::It could use the gps data to calculate the speed it is traveling with. Let's say it has been moving for more than 50 km/h for more than 10 seconds. Then it could activate the "emergency call if more than 5g" function. Aside from the countdown timer, it could increase the volume to max and warn the user that an automatic emergency call will take place in x seconds. While it is counting down it could listen for "Never mind, I'm fine, phone" and stop the countdown in case it hears that. It could also output the warning sound to the attached bluetooth headset and let the user talk to emergency services if the user is still conscious. [[User:Tommy|Tommy]] 17:48, 8 January 2008 (CET)

==== Movement detection ====
By detecting that the owner is walking a user defined profile can be activated with a specific set of notification settings. For example you may wish to use a cheap old sounding ringtone so you don't attract attention from muggers. Or you may wish to have a louder ringtone if you carry your phone in a bag where it can't be so easily heard.

==== Games ====
Imagine a first person shooter that you look around by turning your body.

==== Sloshing battery indicator ====
Shaking the phone will produce a sloshing sound, as if it contained a liquid. As the battery loses charge, so the sound produced on being shaken, will replicate a decreasingly empty container. [http://mobile.slashdot.org/article.pl?sid=07/11/28/1342248] for an example.

==== Others ====
Also see the pages[[Wishlist:Auto Align Map]], [[Wishlist:Determine Position]], [[Distance Measuring]], [[Wishlist:Computer Mouse]], [[Wishlist:Dynamic Screen Orientation]].

=== Connectivity ===

==== VNC client ====
A good, stylus friendly VNC client/host combo would be easy to add and terribly useful.

==== Networked X-Windows ====

Whether it's running true X-Windowing over the network, or your bog-standard VNC connection as mentioned above, the ability to have your phone's screen available on your laptop or palmtop would be most desirable.

==== NX client ====

A form of X-windows forwarding optimized for performance over slow, or high-latency links, which could prove extremely useful. Capable of streaming a good quality, full desktop session over modem speeds. The protocol and at least one implementation is gpl'd. [http://en.wikipedia.org/wiki/NX_technology wikipedia]

==== OpenOffice Presenter Control ====

I Think it is a good idea to control your OO Presentation with Openmoko about WLAN or Bluetooth.
I think it needs some buttons to go back or forward and control the mouse to show something and take normal mouse clicks.
But with the mouse clicks I think that we need a short time between the clicks in example 1 second. Because when you make a mouse
click than to fast than you must go back.

==== Amarok and other Media Player remote control ====

Control Amarok or any other Media Player with OpenMoko (as a remote control). Bluetooth or WLAN could be used as protocol to send and receive the data. Maybe a WebInterface of Amarok is a start. Can be used on parties for a mobile music management.

==== Read informations with SMS ====
Send a SMS with Code to the OpenMoko (from a specific number).
For example to send get the GPS coordinates from a stolen Neo (or if you don't know where your Neo is).

=== Security ===

==== General Filesystem Encryption ====

If anyone wants to get your private data saved on your OpenMoko device, he should have to get through a high security mechanism like dm-crypt. The question is how much CPU power would be needed.
Would it be an idea to encrypt only the private data like phone numbers, preferences, address book etc. (like /home/$USER).

http://luks.endorphin.org

==== My Account ====
{{Main|My Account}}
A way to securely store information about the phone, and ensure that a phone you may be considering purchasing is not stolen.

==== [http://zfoneproject.com/ Zfone] or similar ====

Something that allows the user to speak with another person securely.

==== GSM Encryption ====

This software application would allow GSM encrypted calls to be made using the GSM Data Call Channel.

[[OSvS]]

==== My Voice is my Passport ====
Use voice recognition to unlock the phone. "Hi. My name is ... My voice is my passport. Verify me."

==== Firewall ====
A network firewall

==== Full Mac Support ====
Full mac support, preferably with full software and full sync capabilities with iCal and iMail

==== Anti Theft Application ====

This application would enter the phone into an [[Anti-Theft Mode]] which activates particular security features to reduce the risk of theft and also to ensure a higher probability of recovery of a stolen handset.

====RFID based personal alerts====
Assuming an RFID reader is available: You'd put an RFID tag on your keys, wallet, etc and train a program on the phone to give you a soft or hard alert when one of them leaves detection range. That way, if you're walking away from one of them, the phone could alert you.

====OpenVPN Client====
This application allows to configure the device as an OpenVPN client using the GUI including support for X.509 certificates.

=== Integrated Help System ===

A help system that is either on or off. It could be activated and deactivated by a [[five-second-press]] on a button, for example the AUX button. When the help system is activated, it will explain the use of any item you touch on screen (with stylus or finger). Example: if you touch the battery icon, it will explain that this shows battery level / remaining time. If you touch the date / time icon, it will explain that this icon shows date and time, and that if you press it, you can set date and time. Primarily, this help system should be able to explain all user interface elements in the main screen, but if it proves popular, it could be expanded to cover other applications as well.

===Performance optimisation===
==== Use DMA engine in CPU for blitter ====
The DMA engine in the CPU can substantially speed up moving of large areas of screen in some cases.

==== Use virtual screen to optimise scrolling ====
In some other cases, the hardware supported virtual screen may also speed it up.
===Reusable Display/UI Widgets===
====Use BigPage for full page zoom, scroll, scale in many apps====
The [[BigPageWidget]] Page decribes a widget that could bring full natural page viewing, scaling, scrolling to the OM platform - allowing all applications to make intuitive UIs. A good way to read documents of any type without reformatting them massively increases the utility of a device with a small screen

==Bluetooth==

=== Voice Dialing ===

Dial by voice commands.
 Dial by dictating phone number. This way we can voice dial any number even if not in our contact list.

=== Music through Bluetooth Headset ===

Music can be played through a Bluetooth headset, but would stop playing when a call comes in.

=== Walkie Talkie ===

Let OpenMoko devices connect to one another via bluetooth or another connection method (GPRS for long distance but high latency, probably Wifi on P2), and hold a conversation.

Features for this applications can be:
* Push To Talk (PTT) button
* Voice Activated Control (VAC) which will set it in transmit mode when input has is detected above a certain predefined level.
* Optionally a full duplex mode
* Different channels to choose from
* Monitor different (preselected or all) channels for traffic.
* Content encryption
* Active noise control
* Allow zero config use (units can talk without any access point helping)
* Overview of all connected people trough sending GPS data to everyone who is in the Walkie Talkie channel

Local (non-GPRS) use cases include chatting while biking
or motorcycling in a group; perhaps also in a car caravan.
This application could also be used as a baby-phone to monitor your siblings.

This would be more useful if the Neo had Class 1 bluetooth, though probable Wifi on P2 will also offer more range.

(One thumbs up from me) Jackcday

=== Automatic Sync ===

Automatically synchronize with desktop computer (or with any [http://en.wikipedia.org/wiki/SyncML SyncML] server) when within range based on user profile. This may require the use of a secure data transfer.

=== GPS Assisted Bluetooth Management ===

Allow Bluetooth to automatically turn off after loosing connectivity and to automatically turn back on based upon GPS location.

A Bluetooth device is configured for automatic reacquisition based on the following profiles:
* Manual - only when Bluetooth is on
* Non-mobile - the target device is not mobile, periodically attempt reacquisition when in the general area of the device.
* Mobile - the target device is mobile, periodically attempt reacquisition when in the general area of the device.

Each target device is configured as follows:
* Automatic acquisition at last known location: enable/disable
* Automatic acquisition at these locations: list of nickname + coordinates + range

==== Non-mobile devices ====

Examples devices include: computers

The location and range of the target device is determined via training. Periodically, the current GPS coordinates and Bluetooth signal strength are logged. Additionally, connectivity loss events are logged. An algorithm uses these logs to determine the device location and range.

Connection attempts are made when in a configurable proximity to the device. The first attempt when entering the proximity and further attempts at a configurable interval.

==== Mobile devices ====

Example devices include: automobiles

Mobile devices are configured to have two types of locations:
# Last known location
# Non-mobile locations (homes)

===== Last known location =====

A car is mobile, ideally, when you leave your car, the phone should note the car's location when connectivity is lost and then attempt to reacquire the car when you return to the location of the car.

===== Non-mobile locations (homes) =====

As mobile devices may have multiple users, it is not sufficient to always use the last known location. In this case, the device may additionally have multiple homes. For example, a car might have as its homes: home garage and work parking lot.

=== Bluetooth neighbor detection and multiuser apps ===

Like the [http://en.wikipedia.org/wiki/One_laptop_per_child one laptop per child] (OLPC) interface, keep a number in the status bar that represents a count of other openmoko or compatible bluetooth devices in the area. Allow for the spontaneous initiation of a chatroom or multiplayer game or file trading with any moko in the area.

=== Bluetooth environment detection ===

Capability to detect when a predetermined bt device enters/leaves bt range and launch a system-wide event accordingly. This would feed not only the "Neighbour detection" idea described above, but also the "Profiles", "Context based TO-DO list" and "Location-based reminders" ideas. Reminders could be set to trigger in the presence of a specific person X (with BT device Y). Profiles can take into account which devices are present around the phone (car kit, for ex.). To-do list could also change according to present devices.

=== Remote control ===

==== Wireless presenter ====
Use the phone to run your OpenOffice.org Impress presentation remotely using Bluetooth. Cool features:
* Display the text notes for the presenter on the phone's display and update it whenever the slide is changing.
** OO.org has implemented support for [http://www.openoffice.org/issues/show_bug.cgi?id=12719 dual monitor]/[http://www.openoffice.org/issues/show_bug.cgi?id=18486 presenter mode] that can be used as a starting point
* A small timer showing the time passed (and perhaps remaining if the presentation app supports such a feature).
* If you want to be super-cool, you give a preview of the notes of the next slide in the show.
* At the end of a presentation, a "navigator" could allow to easily jump to any slide in the presentation by clicking on it on the phone.
** When you right-click in a running OO.org Impress presentation, you can choose "got o slide..." and select any slide to jump to.

==== Initiated from another device ====
Remote control over Bluetooth from other devices to control media player (play, pause, next, previous, volume control), camera (capture image), etc.
==== Directed at another device ====
Remote control over Bluetooth to other devices to control media player, lights in your house, etc.

[http://mjr.iki.fi/software/remote-0.9.0.tar.gz Remote] is my draft of a python-based remote control app that allows you to define button sets and commands to run on the local or a remote host (through ssh, for instance). Error handling and command interface need work.--[[User:Mjr|Mjr]] 11:14, 18 October 2007 (CEST)

Z-wave uses web-browser control of devices that is said to be compatible with mobile phone browsers so should work with openmoko browser. [http://www.z-wave.com www.z-wave.com]

=== Bluetooth Car Connection ===

Have a deeper connection to the car than just handsfree speakerphone. For instance a transceiver with challenge/response systems to open, possibly even start the car. Possibly go as far as OBD connection to monitor car status on screen/log for later.

Could be done with a port of [https://garage.maemo.org/projects/carman/ Carman] or similar that can connect to an OBD2 adapter via USB or Bluetooth and display various information collect from the car, GPS, and accelerometers. --[http://wiki.openmoko.org/wiki/User:Bmk789 bmk789]

==== Dude, Where's My Car? ====

When in range of the car navigation system, remember the position (perhaps check with the car GPS). When not in range, assumme that you are not in the car, and offer the opportunity to navigate to the car's last known position. That way, you can find your car e.g. on a large parking lot.

=== [[Bluetooth powered Multi-SIM support]] ===

As the Neo1971 does not come with dual-SIM support this could be solved by joining your old bluetooth-enabled mobile to your OpenMoko-phone.

Let SIM card A be in your OpenMoko-phone and SIM card B in your old mobile:
* Incoming call on SIM card B - the OpenMoko-phone acts as a headset(Bluetooth Headset profile)
* Calling out via SIM card B - the OpenMoko-phone acts again as a headset
* Same for Short Messages/MMS/Internet
This way you'd have your old phone switched silent and connected to your OpenMoko-phone that handles all the calls and one can select which SIM card to use.
Advantage: No 'switching' between cards
Disadvantage: Second mobile needs to be in range(e.g. handbag) and charged every once in a while.

===Internet Gateway===

If the device could function as a Bluetooth router/gateway to the internet via the GPRS/data connector, then you could use it to get network connectivity from your laptop and other devices while on the road. Many smartphones can be configured as modems via Bluetooth for use as Dial-Up Networking connectors, and that should be the minimum target. Ideally, if the WiFi functionality was used so the OpenMoko could be an 802.11 router or peer to peer gateway for a laptop, this would be even better. The full bandwidth of GPRS or whatever network is available would then be available.

=== Social Networking ===

Anybody running the social networking app will be broadcasting a profile, and when certain keywords are matched with other users who are also running the application, an alert is sounded. Each mokoid can be added as a hexstring to a profile page, and xml filters can be developed for each social service to convert various keywords and interests to moko-friendly format.

=== Give userspace api control over bluetooth signal strength ===

I have tried bluetooth handsfree sets with other phones and don't get perfect reception due to low signal strength. I suppose the reason the signal is so weak is because the manufacturer wants the battery to last long on its latest charge. Can you please make the strength setting configurable by the user of the phone through an api and perhaps even through the phones gui? I would gladly waste some battery time in exchange for stronger bluetooth signal strength.

== WiFi ==

=== Industrial grade Wifi management ===
One annoyance I've had with Wifi enabled gadgets is that they simply keep the connections in a dumb list. What I'd like to see is more granular connection management, which enables me to specify whether a given connection is friend & family (mom's place), professional client (joe's copies and coffee), commercially available (panera), onetime use, or anything else, as well as managing router config backups, firmware images, and security keys.
=== Captive portal auto-login support ===
Having a nice front-end to some sort of script that checks the authenticity of a captive portal login page (SSL cert), then passes your username and password login information to automatically log you into your account would be very nice as well. This can be done with curl, but it is difficult to make it work on all captive portals out there. Perhaps just a field that you can specify "once I am connected to this AP, run this script: ".

== Wireless Piggyback ==

HSDPA support and the like, so that users can connect directly with the internet with G3/G4 mobile service providers at speeds at or above 3.6 Mb/s.

== Other ==

=== Auto Update ===

A small tool which is configurable to download the latest OpenMoko and OpenMoko related software. Maybe if any internet connection is available or a minimum of bandwith is available then the auto update would download only security related or the whole system etc. .

=== Vibrate Pattern Recorder ===

An application that would allow the user to define their own vibration patterns, and possibly link them to audio files. Recording would be done in real time initiated with a "Record" button, optionally playing the associated sound file in sync with recording). While recording, the user would press and hold a button to define the timing and duration of vibration. The user would press "Stop" when finished. Vibration patterns would have the option of being looped(would terminate at some global ringtone length maximum).

One simple suggested vibration file format would be a sort of run-length encoding: First byte defines the length of a "time-slice" in milliseconds, which would determine the overall tempo(actually the inverse of tempo). The next byte would define the number of time-slices to leave the vibration on, and then another byte for how long to pause after. Continue alternating these on/off bytes until the entire pattern is defined.

- or just use MIDI, using a separate channel for the vibrator.

An implementation of RTTL could also be used to define vibration patterns.

=== PC Input Device ===

Provide a method to use the touchscreen as input device for a nearby desktop machine. Could connect over USB or bluetooth.

=== Advanced Notification And Ringtone Manager ===
{{Main|Wishlist-ANARM}}

ANARM would be an application for handling all event-based audible notifications from an OpenMoko device.

=== Location based reminders ===
{{Main|Wishlist:Location_based_reminders}}
Location based reminders can be used to notify users of various events or reminders that are location based.

=== Synergy Client ===
A synergy client would enable the user to place the device next to a desktop PC and share the desktop`s mouse, keyboard and clipboard over a TCP/IP network. [http://synergy2.sourceforge.net/ Synergy]

=== Next device ===
List features for your fantasy device to come from FIC (or anyone else, for that matter). Define the GTA03 here ;-)

==== There is no device ====
From [http://wurp.blogspot.com/2008/01/teh-future.html Wurp's blog]:

Clearly the Next Big Thing has to be for the device to go away altogether. I know the basic idea for wearables has been around forever, but it seems to me that the time has come.

I wanna wear a bluetooth earpiece and cool shades, possibly with [ here's where my imagination is failing me :-( ] gloves, or fingerless gloves, or (ew) wristbands, and let any surface, including my hand, or no surface, be my interface. Tap the earpiece when you get a phone call, see a dial pad on your palm and tap out the number with the other hand, watch movies on a giant screen hovering in the air...

(equipment list: bluetooth earpiece, some brick in my pocket or on my belt, glasses w/ minute camera, painted video display, & variable darkness lenses, and gloves)

Why the hell do I want to dig out a device every time I want mindless entertainment or superficial conversation?

Ideally, you could then sell any little doohickey with whatever interface you want (switches, knobs, g-spots, ...) and all it needs to do is network with some software on the brick to be anything at all...

== GPS Software ==
*Providing GPS Support also for outdoor users in addition to ordinary street navigation features
** Overlay of satellite images with existing streetmaps
** Incorporating SRTM digital elevation model: for example using the VRML/X3D as data format (see http://www.ai.sri.com/geovrml/) which is interesting for e.g. mountaineering: using a 3d browser rendering VRML/X3D Model, displaying the current position and track (possibly also other gps-tracks of the different routes to a summit downloaded before could be mapped onto the 3d model), (what about 3d hardware support? there is nothing written in the hardware specs about graphics: thinking of OpenGL for embedded systems (see http://www.khronos.org/opengles/)
** Using sth like a tracking mode to allow certain people to determine the current position and track (for rescue missions - like they have for example at http://www.steiger-stiftung.de (a German beneficence for rescue issues) There you can register your mobile phone so the rescue service is able to track you immediately if necessary. The interesting thing: It seems like some mobile phones with GPS have special support for this issue. If your phone is registered, the rescue service is able to get your GPS coordinates directly from the phone without any user assistance. Openmoko should also support this! )
* Implementation of 3dTracking's (http://free.3dtracking.net/) tracking software or equivalent.
* "Geomark" function: if you have to save the current time with your current location, only hit one button...
** You also should be able to navigate with a small "compass" and the distance should be displayed to your saved point (maybe where you parked your car on a big car parking area)...
* '''Measure the distance between two points (air line or walked way) -> no need for a tape measure'''
**I think it would be good if you could either use Bluetooth, GPRS or AdHoc Wifi, and see near Neo1972 on the GPS map so you could see where your friends are, e.g "You want to know if you friend is on the bus behind" You would need a strong wifi and GPRS would be too expensive.
*A bicycle sat-nav would be cool, speciayl designed for bicycles, e.g. cycle routes

 [[Community Based Traffic Information]]

== Hardware ==
{{Main|Wish List - Hardware}}

It could be use for beepway Online service too
[http://www.beepway.com]

=== Tactile feedback via buzzer ===
Assuming the hardware has a vibrator/buzzer for silent calls, use a lightly pulsed version of that to simulate tactile feedback when dragging finger across buttons on-screen. Implemented properly, it would almost feel as if the buttons were real.
: 25 ms bump on the buzzer feels about right. Does this harm the vibrator motor? --[[User:Sagacis|Sagacis]] 05:15, 2 October 2007 (CEST)
:: Created a patch to do this [[User:Sagacis/ForceFeedback]] --[[User:Sagacis|Sagacis]] 05:05, 3 October 2007 (CEST)

=== Detachable keyboard ===
Hardware keyboard that can be attached with magnets to a future version of the Neo.

A bluetooth mini-qwerty keyboard that straps to my wrist!

=== SD Slot ===
I think the Neo1973 should have a normal SD card slot as the micro is too small, and the SDs have more space.

: This is not true. Now you can find 2GB micros at the price of 20-30 euros. Too small for what?? --[[User:V0n0|V0n0]] 22:06, 28 December 2007 (CET)

: Think of putting a few '''movies''' on that SD memory card. It could really help if it was a little bigger (8GB, 16GB, 32GB). Also think of going '''offline''' for 1-2 weeks, far away from any computer you can access and then wanting to listen to some music. What you get in turn with a 2 GB memory slot is the same music over and over. Or you have to switch memory a cards a lot.
: This situation is far more common than one would think: going in the mountains, going offshore (on a cruise ship). Or simply you may want to store many types of music, and '''share''' your device with friends. --[[User:Bogdanbiv|Bogdanbiv]] 13:47, 10 January 2008 (EEST)
: Well, it can be micro SD, but why to put it so deep inside, under the battery and even under the SIM card? I would suggest to have a simple slot on the side where we could insert/remove the SD card equally easily as we swap CD's in computer. [[User:AudriusA|AudriusA]] 16:36, 12 January 2008 (CET)

=== IR port ===
Remote control applications

Would be great to use openmoko as a Harmony remote controller.

:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.

:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.

:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.

[[Category:User]]
[[Category:Ideas| ]]

How to run OpenMoko Apps on PC

2008-01-13T15:15:10Z

Starox:

[[Image:Screenshot.png|thumb|500px|''Running OpenMoko Stylus Demo on Ubuntu compared with OpenMoko on qemu'']]
===Install dependencies===

* use aptitude, apt-get, urpmi, or whatever your distro supports
* you will probably need
** gtk-dev
** pango-dev
** atk-dev
** qmake from Qt4 (libqt4-dev on Debian) -- this is optional and required only if you do not use Autotools method

* Under Ubuntu for using GNU Autotools:

sudo apt-get install libgtk2.0-dev libecal1.2-dev automake1.10 libxosd-dev

* Under Debian for using GNU Autotools:

sudo apt-get install libgtk2.0-dev libecal1.2-dev automake libxosd-dev

===Build the binaries===
====Build using GNU Autotools====

=====Build libgsmd=====

You need to have libtool installed

sudo apt-get install libtool

cd <svn-checkout>/src/target/gsm
./autogen.sh
make
sudo make install

This will build and install libgsmd required by the next step.

=====Set up the environment=====

export OPENMOKODIR=<svn-checkout>/src/target/OM-2007
cd $OPENMOKODIR/openmoko-libs
./autogen.sh
make
sudo make install

This will install the libraries in /usr/local/lib. If you prefer a non-system location, edit autogen.sh (and remember that an SVN update may undo that) to add a "--prefix=MYDIR" option for where you want to put the compiled stuff. You can the run "make install" without sudo. One approach is to put stuff at the source root, by appending the option: "--prefix=$OPENMOKODIR".

=====Compiling sample apps=====

cd $OPENMOKODIR/examples/<sample app>
./autogen.sh
make
sudo make install

If you used --prefix in the previous step to place the libraries elsewhere, make sure you edit autogen.sh to reflect that. I guess the proper way to do this is to set the PKG_CONFIG_PATH variable. You can of course drop the sudo then.

...
export PKG_CONFIG_PATH=$OPENMOKODIR/lib/pkgconfig
./configure ...

====Build using QMake (the mickeyl way)====
{{Note|qmake is Mickey's preferred build tool, it probably doesn't work if you're not him. Please use autotools...}}

=====Build everything in one run using Qmake=====

cd <svn-checkout>/src/target/OM-2007
. ./makevars.sh
qmake
make

Now the applications should be found in ./bin.

===Run the examples===

====Set your theme to OpenMoko====

Set the GTK2_RC_FILES variable before running OpenMoko applications:

export GTK2_RC_FILES=$OPENMOKODIR/artwork/themes/openmoko-standard/gtk-2.0/gtkrc

Or edit $HOME/.gtkrc-2.0 to something like this:

include "<PATH-to-svn-checkout>/src/target/OM-2007/artwork/themes/openmoko-standard/gtk-2.0/gtkrc"

However, this will make all Gtk2 apps run with the OpenMoko theme.

==== Naked execution ====

bin/openmoko-stylus-demo
bin/openmoko-finger-demo
bin/openmoko-chordmaster

==== Execution within Xoo ====

Adjust svn://src/target/OM-2007/devel/scripts/launch-xoo to your needs (you may need to build some dependencies forehand)
Then set DISPLAY=:1 and run the examples

Also, see [[Getting Openmoko working on host with Xoo]].

{{Languages|How_to_run_OpenMoko_Apps_on_PC}}
[[Category:User]]
[[Category:Developer software]]
[[Category:Guides]]

Debug board

2008-01-04T15:21:40Z

Starox: switch to v3 debug board

#REDIRECT [[Neo1973 Debug Board v3]]

Talk:MokoMakefile

2007-12-03T12:52:22Z

Starox: /* Building OpenMoko with chroot */

== Ubuntu Edgy: Update git-1.4.x to 1.5.x! ==
With old git-1.4.x, fetching uboot does not work: Use 1.5.x:
<pre>
NOTE: package uboot-gta01-1.2.0+svnnow-r4_14da5f7675bbb427c469e3f45006e027b6e21db9_0_1811: task do_fetch: started
fatal: corrupted pack file .git/objects/pack/pack-a146bcbc18f4826d6bf2a7f63be5dd77bbb5b2f5.pack
</pre>

== Fails on a 32bit machine - try again without ccache? ==

<pre>/bin/sh ./libtool --mode=compile ccache gcc -DHAVE_CONFIG_H -I.... -W... -O2 -c -o libbfd.lo build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c
ccache gcc -DHAVE_CONFIG_H -I... -W... -O2 -c /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o t shift count >= width of type
make[5]: *** [libbfd.lo] Error 1
</pre>

Any insight here? --[[User:Adam|Adam]] 23:10, 15 May 2007 (CEST)
: Try without ccache (did you get it compiled meanwhile or can we remove this?) --[[User:BernhardKaindl|BernhardKaindl]] 23:05, 19 September 2007 (CEST)

== Building on Fedora Core 6 ==

Install stuff needed for OpenMoko:
# yum install python m4 make wget curl ftp cvs monotone subversion \
tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html \
diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds \
docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git \
quilt groff linuxdoc-tools patch compat-gcc-34 lynx netpbm
(notice ''compat-gcc-34'' wich was needed for FC6 (gcc 4 installed), and ''lynx'' which is needed by ''qemu'' (no fallback to ''wget'', ''curl'', or ''links'' at the moment and no check for it, resulting in strange "sleep" errors when trying to build without ''lynx'').

Build it:
$ make setup
$ make openmoko-devel-image
$ unset LD_LIBRARY_PATH
$ make update-makefile && make update && make setup && make openmoko-devel-image

I have also done a
$ unset LD_LIBRARY_PATH; make update-makefile && nice make update && nice make setup && nice make all
(This takes several hours)

Build qemu:
$ make qemu

Run it:
# echo 1024 > /proc/sys/dev/rtc/max-user-freq
$ make run-qemu
This will bring up the OpenMoko :) Use SPACE for AUX and ENTER for POWER.
Not quite the same as holding a Neo1973 in your hands I would guess, but this is the best we can do for now. Thanks!

== Building on Ubuntu Feisty ==

MokoMakefile requires more than 512 MB of RAM + Swap space (around 1GB?).

If you need swap, please '''check that its size under Feisty is not null'''!

[https://bugs.launchpad.net/ubuntu/+bug/105490 Bug #105490] describes the current issue and offers a workaround (23 Jul 07).

== Fails trying to build bluez-utils ==
on Gentoo Linux, it fails compiling bluez-utils (I've tried also "make clean-package-bluez-utils" before the following command)

do a "make build-package-libusb; make clean-package-bluez-utils" and it should continue (the bluez-utils .bb is missing the libusb dependency)

== openSUSE 10.1 and 10.2 workarounds ==

ltrace package fails to build with error:
<pre>
...
checking for pid_t... yes
checking for getopt... yes
checking for getopt_long... yes
checking gelf.h usability... no
checking gelf.h presence... no
checking for gelf.h... no
configure: error: ***** gelf.h not found *****
FATAL: oe_runconf failed
</pre>

'''FIX: '''
edit ''/home/moko/build/tmp/work/armv4t-linux/ltrace-0.4-r0/ltrace-0.4/configure.ac''
at line 44: remove the following block:
<pre>
for path in /usr/include/elfutils /usr/local/include/elfutils \
/usr/include/libelf /usr/local/include/libelf; do
if test -f ${path}/gelf.h; then
CPPFLAGS="$CPPFLAGS -I ${path}"
fi
done
</pre>
( it adds /usr/include/elfutils to path, which causes cross-compile badness error )

=== QEMU build fails to compile USB code ===
<pre>
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_control':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:103: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_data':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: error: storage size of 'bt' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:132: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: warning: unused variable `bt'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_device_open':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: error: storage size of 'ctrl' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:202: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: warning: unused variable `ctrl'
make[2]: *** [usb-linux.o] Error 1
</pre>

'''FIX: '''
edit ''/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c''
at line 29 add the following (before ''#include <linux/usbdevice_fs.h>'')
<pre>
#include <linux/compiler.h>
</pre>
hint: there is a copy of the file in ''/home/moko/build/tmp/work/i686-linux/qemu-native-0.9.0+cvs20070613-r5/qemu/usb-linux.c''

''see: http://osdir.com/ml/emulators.kvm.devel/2007-01/msg00101.html''

== Cannot satisfy fstests ==
<pre>
make openmoko-devel-image
...
| Collected errors:
| ERROR: Cannot satisfy the following dependencies for task-openmoko-debug:
| fstests
NOTE: Task failed: /no-backup/Moko/build/tmp/work/fic-gta01-linux/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.25036
NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
</pre>
Failed on debian etch 2007-07-20
Solution from mailing list post from hardskinone, report of an irc chat
<pre>
I got help in IRC channel. I do following steps
* remove fstest from oe/packages/tasks/task-openmoko.bb ,
* increase PR field by one
* make openmoko-devel-image
</pre>

== conflicting types for 'futimens' ==

if you encounter the following error:

| In file included from utimecmp.c:40:
| utimens.h:2: error: conflicting types for 'futimens'
| /usr/include/sys/stat.h:370: error: previous declaration of 'futimens' was here

a patch is needed because your glibc is too new. grab & enable the patch as follows

cd openembedded/packages/coreutils
mv coreutils_5.3.0.bb coreutils_5.3.0.orig
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils_5.3.0.bb
cd -
cd openembedded/packages/coreutils/coreutils-5.3.0
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils-5.3.0/futimens.patch
cd -

== Workaround for problems compiling mtd-utils ==

Change the line on <code>openembedded/packages/mtd/mtd-utils_1.0.0+git.bb</code> which reads:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=master \

to:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=a6fa706fe9e7696b4b2045edf9698c3bac07e3e3 \

which forces the recipe to use an older revision (the one which worked last time I built the image on my computer).

Be sure to remember to undo the change later, or else you will not get any new changes to that package. --[[User:CesarB|CesarB]] 04:48, 25 July 2007 (CEST)

Note: these patches should be updated - the lzo patch is included in the current version, so backing off to the previous version and repatching seems silly. I was able to make it through this part of the build by applying the remaining patches manually. --[[User:Mellon|Ted Lemon]] 15:44, 29 July 2007 (CDT)

== Monotone segfaulting on Ubuntu Feisty Fawn/PPC ==
If you are running Ubuntu Feisty Fawn on a PowerPC computer you will experience problems running monotone. To fix this issue you need to install monotone as well as the libboost packages from Gutsy. The easiest way to accomplish this is to add the gutsy repositories to your sources.list
and change the preferences to look like this:

Package: *
Pin: release a=feisty
Pin-Priority: 700

Package: *
Pin: release a=gutsy
Pin-Priority: -100

Package: libc6 libc6-dev tzdata util-linux libgcc1 libstdc++6 monotone
Pin: release a=gutsy
Pin-Priority: 800

Package: libboost-*
Pin: release a=gutsy
Pin-Priority: 800

After doing this install monotone in this way:
apt-get -t gutsy install monotone.
That should install monotone 0.35 with updated (and working) boost libraries.

== Fails on ncurses install in Fedora 7 with a "tic -x" message ==
Adjust the following command to your system, then run it:
export LD_LIBRARY_PATH=/home/moko/build/tmp/work/x86_64-linux/ncurses-native-5.4-r8/ncurses-5.4/lib
Then start make again and it should pick up where it left off.

You can get a list of potential paths to use with the following command from you main moko directory:
find . | grep libncurses

The basic problem is that it is linking against your main system libraries instead of the OpenEmbedded ones.

There's probably a cleaner way of handling this - please update this entry if you know it.

This has been fixed in Openembedded, see [http://bugs.openembedded.org/show_bug.cgi?id=2554 Openembedded Bug #2554] for further details.

== uboot-gta01 fails to build ==
Changes in the GIT of U-Boot make the OpenMoko patches unapplyable. For the use of Revision ''cc3023b9f95d7ac959a764471a65001062aecf41'' and everything will be fine for now.

== Perl fails to build ==
After following every bit of advice I can find to 'make clean' and nuke the perl build directories, every build comes up with:

| make[1]: Entering directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| make[1]: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop.
| make[1]: Leaving directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| FATAL: oe_runmake failed
NOTE: Task failed: /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/temp/log.do_compile.19531
NOTE: package perl-native-5.8.7-r3: task do_compile: failed

Solution turned out to be editing
/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7/makedepend.SH and at line 169 change the regexp to eat references to "<command.line>" to catch what was leaking through.

== Gettext fails to build ==
Gettext's build is broken unless you have emacs installed. Crazy though it seems. You will see an error like:

<pre>

| WARNING: Warnings can be ignored. :-)
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| else : ; fi
| mv: cannot move `elc-temp' to `elc-stamp': No such file or directory
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[5]: *** [elc-stamp] Error 1
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[4]: *** [po-mode.elc] Error 2
| make[4]: *** Waiting for unfinished jobs....
| make[4]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1'
| FATAL: oe_runmake failed

</pre>

The solution is simple - install emacs (example below for debian/ubuntu) and try again:

<pre>

sudo apt-get install emacs
make clean-package-gettext-native-0.14.1-r5
make openmoko-devel-image

</pre>

== Building OpenMoko with chroot ==

There may be hundreds of issues which may cause that OpenMoko fails to build on your system, so it might be more straightforward to just install a standardized build environment in which the openmoko build runs in chroot, independent of your distribution.

There is now a (not fully working) script which is able to set up a 32-bit openSUSE 10.3 build environment for building OpenMoko posted on distro-devel: [http://lists.openmoko.org/pipermail/distro-devel/2007-November/000076.html]

On gentoo and debian-like distribution, you can use debootstrap to quickly setup a base chroot.

== Fails compiling binutils-cross on Gentoo/AMD64 and openSUSE/x86_64 ==

make setup works fine, but when running make openmoko-devel-image it fails with the following:

<pre>
| make[4]: Entering directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[4]: Nothing to be done for `install'.
| make[4]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[3]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty'
| make[2]: Nothing to be done for `install-target'.
| make[2]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| make[1]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib/gcc-lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross: No such file or directory
| mv: cannot stat `build/tmp/cross/lib/libiberty.a': No such file or directory
NOTE: Task failed: build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/temp/log.do_stage.9730
NOTE: package binutils-cross-2.18-r0: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of openembedded/packages/binutils/binutils-cross_2.18.bb do_populate_staging failed
ERROR: Task 1641 (openembedded/packages/binutils/binutils-cross_2.18.bb, do_populate_staging) failed
NOTE: Tasks Summary: Attempted 107 tasks of which 107 didn't need to be rerun and 1 failed.
ERROR: 'openembedded/packages/binutils/binutils-cross_2.18.bb' failed
make: *** [openmoko-devel-image] Error 1
</pre>

The final reason why the build cannot continue is:
mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

=== The lib64 issue ===

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that may (or all?) AMD64 distributions do for their 64-bit binaries. On openSUSE-x86_64, the same happens. Debian/x86-64 seems to either not use lib64 or is somehow supported by the openmoko distribution.

On multilib/lib64 platforms like Gentoo/x86_64 and openSUSE-x86_64, the openmoko build runs into a final problem at the end of build: It tries to use fakeroot which uses LD_PRELOAD to fake a different root directory and in the final stages, after hours of compiling, fakeroot execution causes warning messages because on multilib/lib64 systems as they have two versions of many libraries, the 64-bit libraries are in /lib64, /usr/lib64 and oder lib64 paths, while the 32-bit libraries are in /lib, /usr/lib and other lib paths. Some tool on these lib64 distributions are adapted to install 64-bit libraries to lib64, but this seems to fail when cross-compiling.

At least on openSUSE-10.3 the missing libiberty.a was installed to build/tmp/cross/lib64/libiberty.a, which looks wrong, and it is if this libiberty.a file contains 32-bit arm objects. If it contains 64-bit x86_64 objects, it's fine, but openembedded/openmoko is not expecting it in a lib64 directory. I am not sure what is the case.

The lib64 fakeroot issue requires to change the openembedded build scripts, which is doable. But it's not very easy to find the correct script and patch it correctly. If you feel adventourus, go ahead and try to build openmoko on a lib64 distribution, but it's easyer to set up a complete 32-bit chroot environment and run a normal build in it.

After seeing this, I assumed that openmoko/openembedded was clearly not tested with lib64 build hosts and since that would mean that even if I'd fix that error, many others could follow, and as I was not interested to fix the lib64 bugs but rather wanted to see something running first, I decided to make openmoko/openembedded think that it was running on a normal 32-bit non-lib64 machine.

There are several ways to do that:
* You install an IA32-Linux somewhere and use that for building:
** Do a native install and dual-boot the IA32-linux (That's for dummies which do not know the other tricks)
** Install IA32-Linux in a virtual machine (Quite some setup and has some overhead too)
* you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience)
* Or you can install a 32-bit development system on the 64-bit host (suppored on openSUSE, should be possible with Gentoo/AMD64 too)

=== Building on SuSE Linux 10.3-AMD64 with -m32 (not finished) ===

Install the following packages for the 32-bit C/C++ compiler target option -m32 to work and to compile what is needed

gcc42-32bit gcc42libgcc42-32bit glibc-devel-32bit libstdc++-devel-32bit ncurses-devel-32bit zlib-devel-32bit (maybe also gtk2-devel-32bit)

The openSUSE 10.3-AMD64 has no libopenssl-devel-32bit, but you can install the 32-bit rpm from the i586 10.3 rpm tree:

libopenssl-devel

You should also make sure that gdbm-devel is not installed.
The multilib support in ld has an issue which surfaces when it is called from perl's Configure script to complile a test program with -Lgdbm. If gdbm-devel is installed, it finds /usr/lib64/libgdbm.so, but since it's not compatible with 32-bit, it skips it, but also does not search the specified -Lpath where the OpenEmbedded-built libgdbm.so is already installed. To work around this, uninstall /usr/lib64/libgdbm.so with:
rpm -e gdbm-devel

Note these need to be the 32-bit cpp33 and gcc33 rpms as the 64-bit gcc33 rpms for openSUSE do not support the 32-bit target.

To make the OpenMoko build think that its running on 32-bit i686, use linux32 (changes uname -m to i686 in the new shell):

linux32 bash

And set up gcc scripts which force the use of gcc-3.3 (it can only generate 32-bit assembly) for all compilation:

mkdir bin;cd bin
echo '/usr/bin/${0##*/}-3.3 -m32 "$@"' >gcc
echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld
echo '/usr/bin/${0##*/} --32 "$@"' >gas
sed -i '1i#!/bin/sh' gcc gas ld
chmod 755 gcc gas ld
ln -s gcc cc
ln -s gcc c++
ln -s gcc g++
ln -s gas as
echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32
cd -

Then set the path and test it:

source bin/.setup-gcc-m32
type gcc

== More package requirements ==

On my system (Kubuntu 6.10) build failed with message "ERROR: QEMU requires SDL or Cocoa for graphical output" because package <tt>libsdl-image1.2-dev</tt> was missing. Use <tt>apt-get install libsdl-image1.2-dev</tt> to install. Additionally I had to install packages <tt>cvs</tt> and <tt>diffstat</tt>. I was also asked to install Psyco JIT Compiler (package <tt>python-psyco</tt>) to increase performance. Nevertheless <tt>make flash-qemu-local</tt> took some hours, but now I finally can get an impression of the phone that I am looking for! -- [[User:Nichtich|Nichtich]] 00:26, 20 September 2007 (CEST)

== pango-directfb failed to build due to missing Glib 2.14.x ==

The latest(as of Sept. 25, 2007) build started to fail with the following error:

| checking for GLIB... no
| configure: error:
| *** Glib 2.14.0 or better is required. The latest version of
| *** Glib is always available from ftp://ftp.gtk.org/.
| FATAL: oe_runconf failed
NOTE: Task failed:
/media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\
pango-directfb-1.18.1-r0/temp/log.do_configure.19927
NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package pango-directfb-1.18.1: failed
ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\
pango-directfb_1.18.1.bb do_configure failed

The Glib included in the build tree seems to be only 2.12.12, so looks like something
is broken in term of dependency.

This had happened on both of Fedora 7 and Debian Etch. I am running the latest
MokoMakefile with OM-2007.2. The funny thing is that the build had worked only
couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile).
[[User:ttz|ttz]] Wed Sep 26 12:17:33 CDT 2007

pango-directfb had been removed from OE for now due to the report of it breaking builds like OpenMoko.

[[User:ttz|ttz]] Thu Oct 4 10:20:12 CDT 2007

== uicmoc4 failes to compile ==

This is solved by installing libz-dev

Or, look at [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=747 Bug #747]

== svn: REPORT request failed on '/repos/tasks/!svn/vcc/default' ==

osiris$ make update
...
Fetching external item into 'trunk/src/target/OM-2007.2/applications/openmoko-today2/libkoto'
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)
make: *** [update-openmoko] Error 1

osiris$ cd openmoko/trunk/src/target/OM-2007.2/applications/openmoko-today2//libkoto/
osiris$ svn up -r HEAD
svn: REPORT request failed on '/repos/tasks/!svn/vcc/default'
svn: REPORT of '/repos/tasks/!svn/vcc/default': 200 OK (http://svn.o-hand.com)

Anyone know about this one?
--[[User:Blackh|Blackh]] 00:11, 12 October 2007 (CEST)

== bootparam_prot.h fails to install in glibc-intermediate-2.5 package (Debian sid) ==

| install: cannot stat
`/home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc/bootparam_prot.h'
No such file or directory
NOTE: Task failed: /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/temp/log.do_stage.3940

For some reason, on Debian, the rpcgen command needs "-Y /usr/bin" added to the end of it or it won't work ("cannot find any C preprocessor (cpp)"). This can be fixed by hand...

cd /home/blackh/src/openmoko/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/
glibc-intermediate-2.5-r7/glibc-2.5/sunrpc/rpcsvc
for f in *.x ; do rpcgen -h $f -o ${f%%.x}.h -Y /usr/bin ; done

This command will generate the right files and you can resume the build with

make openmoko-devel-image

Here is a better fix - put this script, calling it rpcgen, somewhere in your PATH before /usr/bin:

#!/bin/sh
exec /usr/bin/rpcgen -Y /usr/bin "$@"

--[[User:Blackh|Blackh]] 05:17, 12 October 2007 (CEST)

Getting OpenMoko working on host with Xephyr

2007-11-29T07:42:56Z

Starox: /* What is Xephyr */

The goal of this page is to show you how to run an OpenMoko development image on your host x86 development machine in a chrooted environment.

== What is Xephyr ==
[http://projects.o-hand.com/xephyr Xephyr] is a modern X Server in a window which can be used to simulate small displays in a desktop development enviroment. It is maintained on the [http://projects.o-hand.com/Home OpenedHand] projects page. Xephyr is now part of xorg-server. Please note that even though it will render OpenMoko pixel for pixel, it will likely display almost 4 times larger than the actual device since portable devices tend to have smaller pixels than computer monitors.

=== Xephyr on your system ===

==== gentoo ====
To have it on your system, add ''kdrive'' flag in /etc/make.conf or on your x11-base/xorg-server use flags.

== Build an OpenMoko Image ==

First, you'll need to build an openmoko-devel-image. You'll need to edit your local.conf file during build process (before step 5).

You should use [[MokoMakefile|Building OpenMoko using the MokoMakefile]] to build an openmoko-devel-image for your host architecture (x86 in our case). Make sure you put the moko makefile in /home/moko/Makefile .

Prior to that, edit your build/conf/local.conf to make it look like this:

MACHINE = "x86"
DISTRO = "openmoko"
BUILD_ARCH = "i686"
INHERIT += " devshell"

Once you have built the image, you can start working toward running the image.

([[User:Flerchjj]]) I also had to add the following line to "build/conf/local.conf" to get "make openmoko-devel-image" to complete.
TARGET_FPU = ""

([[User:Enjahova]]) I had to remove all references to uboot from the makefile to get it to get "make openmoko-devel-image" to complete.

== Setup the image filesystem ==

Please see the included help script at the bottom of this article. It should make your life much easier.

The filesystem of the image can be found at /home/moko/build/tmp/rootfs . It is that image that we want to run in a chrooted environment.

We will copy that rootfs directory somewhere so that subsquent builds (using the MokoMakefile for instance) don't overwrite it.

Make sure you have root privileges:
su -

Copy the rootf into a directory called MokoBox. From now on, we will call the chrooted environment a MokoBox.

cp -r /home/moko/build/tmp/rootfs /home/moko/mokobox

make sure /dev and /proc of the host machine are visible from within mokobox

mount --bind /dev /home/moko/mokobox/dev
mount -t proc none /home/moko/mokobox/proc

Start/Move into the protected mokobox environment

chroot /home/moko/mokobox /bin/sh

=== In chroot'ed environment ===

set environment variables

DISPLAY=:1
LANG=C
HOME=/home/root
export DISPLAY LANG HOME

Create pango.modules file

pango-querymodules > /etc/pango/pango.modules

Create gdk-pixbuf.loaders file

gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders

Remove touch screen calibrator. Since touch screen hardware is not present, the touch screen calibration prevents X start-up on PC.

rm /etc/X11/Xsession.d/30xTs_Calibrate

== Starting the nested X server ==

=== Supplying fonts ===

You might need to install fonts supplied by OpenMoko to your host system. The easiest way to do is in Gnome is to go Preferences -> Font - > Details -> Go to font folder and then drag and drop TTF font files from build/tmp/rootfs/usr/share/fonts/ in Nautilus.
Using Xubuntu (no Gnome) I found copying the ttf folder into /usr/X11R6/lib/X11/fonts worked.

=== Launching Xephyr ===
In another terminal (not related to mokobox), start Xephyr

Xephyr :1 -ac -2button -host-cursor -screen 480x640

Add -dpi 140 or anything that fits you to get bigger fonts and better readability.

=== Start X Client ===
Now, back in chroo'ted environment, start X client:

eval $(dbus-launch)
/etc/X11/Xsession

You should see OpenMoko booting in the Xephyr window.

[[Image:Xephyr.png]]

== A sample script ==

'''Please do not use this script. It is simply wrong and will do harm to your host file system! The chroot has to be done earlier, otherwise the script modifies/deletes stuff in your host /etc directory.'''

The following script sets up the most of root fs environment automatically

<pre>
#!/bin/bash
#
# Set-up x86 OpenMoko root jail. This script must be run as root.
#
# Root jail is an environment, where the file system root has been
# changed to the OpenMoko root file system folder. Please don't
# use the build/rootfs, but make a copy of it, since build/rootfs
# gets overwritten each time you build openmoko-devel-image
#
# You need to set-up another X server (nested preferably) to
# act as a OpenMoko screen. Otherwise chrooted applications are executed
# as is on the host hardware and the kernel.
#
# See:
#
# http://wiki.openmoko.org/wiki/Getting_OpenMoko_working_on_host_with_Xephyr
#
#
# 2007 Mikko Ohtamaa - Red Innovation Ltd.
# <mikko@redinnovation.com>
#
# Do anything you wish with this script
#
#
#

# Setup required environment variables

# Xephyr must listen to this DISPLAY
DISPLAY=:1

# If we don't have locale, applications refuse to launch
LANG=C

# We are running as root in our chrooted environment

HOME=/home/root
export DISPLAY LANG HOME

# Update pango modules
pango-querymodules > /etc/pango/pango.modules

# Update icon images
gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders

# Mount /dev and /proc file systems
mount --bind /dev ./dev
mount -t proc none ./proc

# Remove touch screen calibration start up app
# It doesn't launch on x86 and prevents X booting
if [ -e /etc/X11/Xsession.d/30xTs_Calibrate ] ; then
rm /etc/X11/Xsession.d/30xTs_Calibrate
fi

# Use host name server information so that
# web browsing works
cp /etc/resolv.conf etc/resolv.conf

# Enter into chroot jail
chroot . /bin/sh

</pre>

== Improving Display Realism - Extending Xephyr with Xoo ==
[http://projects.o-hand.com/xoo/ Xoo] further extends [http://projects.o-hand.com/xephyr Xephyr] as to provide a poor mans device emulator. It is intended for embedded developers that want to simulate a target device (with an '''accurate''' display size, working hardware buttons, themed display, etc) on a desktop machine.

See [[Getting Openmoko working on host with Xoo]] for more information.

[[Category:Developer software]]

[[Category:Guides]]

{{Languages|Getting_OpenMoko_working_on_host_with_Xephyr}}

MokoMakefile

2007-11-23T23:23:46Z

Starox: /* Debian / Ubuntu */

MokoMakefile is a Makefile which saves lots of work when setting up an OpenMoko build environment.
By automating the setup process of a new OpenMoko build environment, it provides an environment which is configured the same for all the existing developers and should therefore be preferred over manual procedures or individual setup procedures.
It brings the same repeatability to build environment creation and maintenance as that which the BitBake scripts bring to [[OpenEmbedded]] ease and standardize the process of building OpenEmbedded.

Unlike the manual process described at [[Building OpenMoko from scratch]], MokoMakefile does not install anything into your system (it can and should be started as normal user).
MokoMakefile is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko.

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[OpenMoko2007.2#How_to_build|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

MokoMakefile also builds the QEMU-based neu1973 emulator as part of the build process and has make targets to install the OpenMoko images into it and run it. These commands can also be used without downloading and building the whole OpenMoko OpenEmbedded distribution. This part is described in [[Using QEMU with MokoMakefile]].

== Requirements for building OpenMoko ==
Independent on whether MokoMakefile or a manual process is used to setup an OpenMoko build environment, there are several requirements which must be fullfilled in order for the OpenMoko build to succeed:

* RAM: The build host needs to have at least 512MB of RAM, and about the same amount of swap. Some packages built by OpenEmbedded like busybox are built by compiling all source files into one binary which causes gcc to grow beyond 300MB of size and no part of this memory may be on swap for the compile to finish in predictable time. For busybox, this can be turned off, but turning this off means that busybox will not as well optimized by gcc.

* Disk space: You need about 12 GB of available disk space for the OpenMoko build to succeed (see below for a tip on how to reduce this).

* Time: The initial build takes at least 5 hours (on 2GHz core2duo without multiprocessor optimization) and may take several days on slower machines.

=== Required software ===
The version control system used by OpenEmbedded is [http://monotone.ca monotone], it is not downloaded and installed by MokoMakefile. If your distribution does not provide a package, you can download and install a static binary from http://monotone.ca

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://www.openembedded.org/wiki/OEandYourDistro but they may be outdated, incomplete and do not cover everything which OpenMoko needs to build.

A good guide is [[Building OpenMoko from scratch#Build host prerequisites|the section on build host prerequisites]] in [[Building OpenMoko from scratch]]

If you forgot anything which OE needs itself, OE will tell you shortly after you start building, but it does not check build dependices of OpenMoko, so you either have to install them before starting or install them after the build failed. OpenEmbedded will continue where it stopped when you restart the build afterwards.

==== Package requirements by distribution ====
Your distribution needs to provide these commands in order for OpenEmbedded to start building:
subversion texi2html texinfo help2man

OpenMoko needs the development packages (with header files, development libraries and tools) in order to finish building:
ncurses zlib (or libz) OpenSSL GTK++

Because there are bugs in the interaction of QEMU and GCC-4, you'll need a copy of gcc-3.x installed as well.

===== Debian / Ubuntu =====
apt-get install subversion monotone build-essential help2man
diffstat texi2html texinfo cvs gawk
apt-get install libncurses5-dev libz-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
apt-get install ca-certificates
# For OpenMoko 2007.2 using BitBake-1.8.8:
apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx netpbm dosfstools

===== SuSE =====
For building OpenMoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion diffstat texinfo help2man and [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_Factory/repodata/repoview/Development.Tools.group.html monotone]
For MokoMakefile to not fail on compiling qemu-user, you need to use gcc33:
wget download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/{cpp,gcc}33-3.3.3-41.8.i586.rpm
rpm -Uhv {cpp,gcc}33-3.3.3-41.8.i586.rpm

See also the [[Talk:MokoMakefile#Building_on_SuSE_Linux_10.3-AMD64|Talk page on Building on SuSE Linux 10.3-AMD64]]

10.1 and 10.2: same packages as 10.3, but install <code>openssl-devel</code> instead of libopenssl-devel. Use monotone for [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_10.2/repodata/repoview/Development.Tools.group.html 10.2] or [http://download.opensuse.org/repositories/devel:/tools:/scm/SUSE_Linux_10.1/repodata/repoview/Development.Tools.group.html 10.1]

==== For all distributions ====
As the QEMU-based neo1973 emulator is also built as part of the build process started by MokoMakefile, so you need gcc-3.3 and other packages for building QEMU installed. See [[Using QEMU with MokoMakefile#Build requirements|the build requirements section]] in [[Using QEMU with MokoMakefile]] for information on the required software.

== Building OpenMoko with MokoMakefile ==

1 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
2 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for the old version 2007.1 instead of the new
version edit the top of the Makefile. Edit the lines at the top to
look like this:
OPENMOKO_GENERATION = 2007.1
#OPENMOKO_GENERATION = 2007.2

{{note|For building 2007.2, MokoMakefile uses BitBake 1.8.8 which requires python-sqlite2 and sqlite-3.3 or later. Users of SUSE Linux 10.1 can update to [http://download.opensuse.org/pub/opensuse/distribution/10.2/repo/oss/suse/i586/sqlite-3.3.8-14.i586.rpm the version of openSUSE 10.2]}}

3 - Set up the environment:
make setup
4 - Start building. Before starting a lengthy make process, check the Tips section below for how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

==Updating the environment==
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To make sure that any recent changes to the build directory structure have been applied:
make setup

3 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

A quick way to rebuild a new image with the latest updates:
make update-makefile && make setup update openmoko-devel-image

==Build issues==
First, make sure that the problem is reproducible after running

make update-makefile && make setup && make update

then run

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

and finally

make openmoko-devel-image

If you can get the error to occur three times in a row after running that sequence of commands (including the update and setup steps) three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Known MokoMakefile errors ===
If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Fixes for distribution/environment-specific or isolated issues===

Work-arounds for temporary or isolated problems can be found and should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

==Tips==
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly. As of 10/16/07, this appears to be present in local.conf by default.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/''username''/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in ~/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

* If you encounter an error related with the qemu-native package and not compiling for the qemu, you can edit the build/conf/local.conf file and add ENABLE_BINARY_LOCALE_GENERATION = "0" line to avoid the error.

* To prevent building tons of locales, add a line like this to local.conf:
GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"

* To not build any binary locales at all, add this to local.conf:
ENABLE_BINARY_LOCALE_GENERATION = "0"

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building <code>openmoko-devel-image</code>, run <code>make build-package-package-index</code>.

==Developing with MokoMakefile==

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded. Also references to tmp/work/armv4t-linux should be replaced with tmp/work/fic-gta01-angstrom-linux-gnueabi}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

To make in-tree changes and have them built and used by qemu:

cd $OMDIR/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in $OMDIR/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd ../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
...make the changes...
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
cd $OMDIR/openmoko/
quilt new mycoolpackage.patch
mkdir trunk/oe/packages/mycoolpackage
quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
$OMDIR/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
quilt refresh
cd ..
make update openmoko-devel-image

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/Building_a_hello_world_application Hello World!] tutorial available too.

==Testimonials==
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

Talk:Host-based development with Xoo and Xephyr

2007-11-23T09:24:30Z

Starox:

In building for x86 using MokoMakefile, openmoko-panel-battery failed with:

openmoko-panel-battery.c:26:17: error: apm.h: No such file or directory
openmoko-panel-battery.c: In function 'timeout':

I resolved this by building apmd manually:
make build-package-apmd

--[[User:Haslup|Haslup]] 07:16, 28 April 2007 (CEST)

Xnest would refuse connections from the chroot-ed environment.
AUDIT: Sun Jul 29 17:57:58 2007: 6393 Xnest: client 1 rejected from IP 127.0.0.1

Solved this by starting Xnest with the following parameters:
Xnest :1 -ac -dpi 283 -geometry 480x640+86+295

--[[User:Scvalex|Scvalex]] 17:19, 29 July 2007 (CEST)

It'll fail with MokoMakefile because it builds also uboot (which is for arm ...)
Just setup your environnement for MokoMakefile and then :
source setup.env
cd build
bitbake openmoko-devel-image

--[[User:starox|starox]] 17:19, 29 July 2007 (CEST)

MokoMakefile

2007-11-15T22:46:09Z

Starox: /* Debian / Ubuntu */

MokoMakefile is a Makefile which saves lots of work when setting up an OpenMoko build environment.
By automating the setup process of a new OpenMoko build environment, it provides an environment which is configured the same for all the existing developers and should therefore be preferred over manual procedures or individual setup procedures.
It brings the same repeatability to build environment creation and maintenance as that which the BitBake scripts bring to [[OpenEmbedded]] ease and standardize the process of building OpenEmbedded.

Unlike the manual process described at [[Building OpenMoko from scratch]], MokoMakefile does not install anything into your system (it can and should be started as normal user).
MokoMakefile is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko.

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[OpenMoko2007.2#How_to_build|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

MokoMakefile also builds the QEMU-based neu1973 emulator as part of the build process and has make targets to install the OpenMoko images into it and run it. These commands can also be used without downloading and building the whole OpenMoko OpenEmbedded distribution. This part is described in [[Using QEMU with MokoMakefile]].

== Requirements for building OpenMoko ==
Independent on whether MokoMakefile or a manual process is used to setup an OpenMoko build environment, there are several requirements which must be fullfilled in order for the OpenMoko build to succeed:

* RAM: The build host needs to have at least 512MB of RAM, and about the same amount of swap. Some packages built by OpenEmbedded like busybox are built by compiling all source files into one binary which causes gcc to grow beyond 300MB of size and no part of this memory may be on swap for the compile to finish in predictable time. For busybox, this can be turned off, but turning this off means that busybox will not as well optimized by gcc.

* Disk space: You need about 12 GB of available disk space for the OpenMoko build to succeed (see below for a tip on how to reduce this).

* Time: The initial build takes at least 5 hours (on 2GHz core2duo without multiprocessor optimization) and may take several days on slower machines.

=== Required software ===
The version control system used by OpenEmbedded is [http://monotone.ca monotone], it is not downloaded and installed by MokoMakefile. If your distribution does not provide a package, you can download and install a static binary from http://monotone.ca

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://www.openembedded.org/wiki/OEandYourDistro but they may be outdated, incomplete and do not cover everything which OpenMoko needs to build.

A good guide is [[Building OpenMoko from scratch#Build host prerequisites|the section on build host prerequisites]] in [[Building OpenMoko from scratch]]

If you forgot anything which OE needs itself, OE will tell you shortly after you start building, but it does not check build dependices of OpenMoko, so you either have to install them before starting or install them after the build failed. OpenEmbedded will continue where it stopped when you restart the build afterwards.

==== Package requirements by distribution ====
Your distribution needs to provide these commands in order for OpenEmbedded to start building:
subversion texi2html texinfo help2man

OpenMoko needs the development packages (with header files, development libraries and tools) in order to finish building:
ncurses zlib (or libz) OpenSSL GTK++

Because there are bugs in the interaction of QEMU and GCC-4, you'll need a copy of gcc-3.x installed as well.

===== Debian / Ubuntu =====
apt-get install subversion monotone build-essential help2man
diffstat texi2html texinfo cvs gawk
apt-get install libncurses5-dev libz-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
apt-get install ca-certificates
# For OpenMoko 2007.2 using BitBake-1.8.8:
apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev lynx

===== SuSE =====
For building OpenMoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion texinfo help2man [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_Factory/repodata/repoview/Development.Tools.group.html monotone]
10.1 and 10.2: same packages as 10.3, but install <code>openssl-devel</code> instead of libopenssl-devel. Use monotone for [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_10.2/repodata/repoview/Development.Tools.group.html 10.2] or [http://download.opensuse.org/repositories/devel:/tools:/scm/SUSE_Linux_10.1/repodata/repoview/Development.Tools.group.html 10.1]

==== For all distributions ====
As the QEMU-based neo1973 emulator is also built as part of the build process started by MokoMakefile, so you need gcc-3.3 and other packages for building QEMU installed. See [[Using QEMU with MokoMakefile#Build requirements|the build requirements section]] in [[Using QEMU with MokoMakefile]] for information on the required software.

== Building OpenMoko with MokoMakefile ==

1 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
2 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for the old version 2007.1 instead of the new
version edit the top of the Makefile. Edit the lines at the top to
look like this:
OPENMOKO_GENERATION = 2007.1
#OPENMOKO_GENERATION = 2007.2

{{note|For building 2007.2, MokoMakefile uses BitBake 1.8.8 which requires python-sqlite2 and sqlite-3.3 or later. Users of SUSE Linux 10.1 can update to [http://download.opensuse.org/pub/opensuse/distribution/10.2/repo/oss/suse/i586/sqlite-3.3.8-14.i586.rpm the version of openSUSE 10.2]}}

3 - Set up the environment:
make setup
4 - Start building. Before starting a lengthy make process, check the Tips section below for how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

==Updating the environment==
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To make sure that any recent changes to the build directory structure have been applied:
make setup

3 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

A quick way to rebuild a new image with the latest updates:
make update-makefile && make setup update openmoko-devel-image

==Build issues==
First, make sure that the problem is reproducible after running

make update-makefile && make setup && make update

then run

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

and finally

make openmoko-devel-image

If you can get the error to occur three times in a row after running that sequence of commands (including the update and setup steps) three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Known MokoMakefile errors ===
If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Fixes for distribution/environment-specific or isolated issues===

Work-arounds for temporary or isolated problems can be found and should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

==Tips==
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly. As of 10/16/07, this appears to be present in local.conf by default.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/''username''/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in ~/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

* If you encounter an error related with the qemu-native package and not compiling for the qemu, you can edit the build/conf/local.conf file and add ENABLE_BINARY_LOCALE_GENERATION = "0" line to avoid the error.

* To prevent building tons of locales, add a line like this to local.conf:
GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"

* To not build any binary locales at all, add this to local.conf:
ENABLE_BINARY_LOCALE_GENERATION = "0"

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building <code>openmoko-devel-image</code>, run <code>make build-package-package-index</code>.

==Developing with MokoMakefile==

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded. Also references to tmp/work/armv4t-linux should be replaced with tmp/work/fic-gta01-angstrom-linux-gnueabi}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

To make in-tree changes and have them built and used by qemu:

cd $OMDIR/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in $OMDIR/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd ../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
...make the changes...
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
cd $OMDIR/openmoko/
quilt new mycoolpackage.patch
mkdir trunk/oe/packages/mycoolpackage
quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
$OMDIR/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
quilt refresh
cd ..
make update openmoko-devel-image

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/Building_a_hello_world_application Hello World!] tutorial available too.

==Testimonials==
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]

MokoMakefile

2007-11-15T22:25:22Z

Starox: /* Debian / Ubuntu */

MokoMakefile is a Makefile which saves lots of work when setting up an OpenMoko build environment.
By automating the setup process of a new OpenMoko build environment, it provides an environment which is configured the same for all the existing developers and should therefore be preferred over manual procedures or individual setup procedures.
It brings the same repeatability to build environment creation and maintenance as that which the BitBake scripts bring to [[OpenEmbedded]] ease and standardize the process of building OpenEmbedded.

Unlike the manual process described at [[Building OpenMoko from scratch]], MokoMakefile does not install anything into your system (it can and should be started as normal user).
MokoMakefile is a wrapper around all that to make it easy to set up and maintain a development environment that fully complies with the setup instructions published by OpenMoko.

MokoMakefile is developed by [[User:RodWhitby|Rod Whitby]] - it is not an official product of OpenMoko (although I would be happy for them to pick it up and use it internally). If there is any discrepancy between the [[OpenMoko2007.2#How_to_build|official OpenMoko build instructions]], and the operation of the MokoMakefile, then you should consider the official instructions to be correct.

The MokoMakefile is able to build either OM-2007.1 or OM-2007.2 images. The core team chooses the default, but you can select one or the other at the top of the Makefile.

MokoMakefile also builds the QEMU-based neu1973 emulator as part of the build process and has make targets to install the OpenMoko images into it and run it. These commands can also be used without downloading and building the whole OpenMoko OpenEmbedded distribution. This part is described in [[Using QEMU with MokoMakefile]].

== Requirements for building OpenMoko ==
Independent on whether MokoMakefile or a manual process is used to setup an OpenMoko build environment, there are several requirements which must be fullfilled in order for the OpenMoko build to succeed:

* RAM: The build host needs to have at least 512MB of RAM, and about the same amount of swap. Some packages built by OpenEmbedded like busybox are built by compiling all source files into one binary which causes gcc to grow beyond 300MB of size and no part of this memory may be on swap for the compile to finish in predictable time. For busybox, this can be turned off, but turning this off means that busybox will not as well optimized by gcc.

* Disk space: You need about 12 GB of available disk space for the OpenMoko build to succeed (see below for a tip on how to reduce this).

* Time: The initial build takes at least 5 hours (on 2GHz core2duo without multiprocessor optimization) and may take several days on slower machines.

=== Required software ===
The version control system used by OpenEmbedded is [http://monotone.ca monotone], it is not downloaded and installed by MokoMakefile. If your distribution does not provide a package, you can download and install a static binary from http://monotone.ca

Some distribution specific hints on preparing your build host for building OpenEmbedded are on http://www.openembedded.org/wiki/OEandYourDistro but they may be outdated, incomplete and do not cover everything which OpenMoko needs to build.

A good guide is [[Building OpenMoko from scratch#Build host prerequisites|the section on build host prerequisites]] in [[Building OpenMoko from scratch]]

If you forgot anything which OE needs itself, OE will tell you shortly after you start building, but it does not check build dependices of OpenMoko, so you either have to install them before starting or install them after the build failed. OpenEmbedded will continue where it stopped when you restart the build afterwards.

==== Package requirements by distribution ====
Your distribution needs to provide these commands in order for OpenEmbedded to start building:
subversion texi2html texinfo help2man

OpenMoko needs the development packages (with header files, development libraries and tools) in order to finish building:
ncurses zlib (or libz) OpenSSL GTK++

Because there are bugs in the interaction of QEMU and GCC-4, you'll need a copy of gcc-3.x installed as well.

===== Debian / Ubuntu =====
apt-get install subversion monotone build-essential help2man
diffstat texi2html texinfo cvs gawk
apt-get install libncurses5-dev libz-dev libssl-dev libgtk2.0-dev
# To prevent errors in host validation
apt-get install ca-certificates
# For OpenMoko 2007.2 using BitBake-1.8.8:
apt-get install python-pysqlite2 sqlite3 sqlite3-doc python-pysqlite2-dbg
# For building faster
apt-get install quilt python-psyco ccache
# For qemu, install a second compiler for bug avoidance; MokoMakefile knows to look for it.
apt-get install gcc-3.4 g++-3.4 libsdl1.2-dev

===== SuSE =====
For building OpenMoko on 10.3, you need
gcc-c++ ncurses-devel zlib-devel libopenssl-devel gtk2-devel subversion texinfo help2man [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_Factory/repodata/repoview/Development.Tools.group.html monotone]
10.1 and 10.2: same packages as 10.3, but install <code>openssl-devel</code> instead of libopenssl-devel. Use monotone for [http://download.opensuse.org/repositories/devel:/tools:/scm/openSUSE_10.2/repodata/repoview/Development.Tools.group.html 10.2] or [http://download.opensuse.org/repositories/devel:/tools:/scm/SUSE_Linux_10.1/repodata/repoview/Development.Tools.group.html 10.1]

==== For all distributions ====
As the QEMU-based neo1973 emulator is also built as part of the build process started by MokoMakefile, so you need gcc-3.3 and other packages for building QEMU installed. See [[Using QEMU with MokoMakefile#Build requirements|the build requirements section]] in [[Using QEMU with MokoMakefile]] for information on the required software.

== Building OpenMoko with MokoMakefile ==

1 - Create your $OMDIR directory (note that you can change ~/moko to any directory you like):
mkdir ~/moko ; cd ~/moko
2 - Grab MokoMakefile:
wget http://www.rwhitby.net/files/openmoko/Makefile

If that doesn't work, try

wget http://svn.nslu2-linux.org/svnroot/mokomakefile/trunk/Makefile

note: If you want to compile for the old version 2007.1 instead of the new
version edit the top of the Makefile. Edit the lines at the top to
look like this:
OPENMOKO_GENERATION = 2007.1
#OPENMOKO_GENERATION = 2007.2

{{note|For building 2007.2, MokoMakefile uses BitBake 1.8.8 which requires python-sqlite2 and sqlite-3.3 or later. Users of SUSE Linux 10.1 can update to [http://download.opensuse.org/pub/opensuse/distribution/10.2/repo/oss/suse/i586/sqlite-3.3.8-14.i586.rpm the version of openSUSE 10.2]}}

3 - Set up the environment:
make setup
4 - Start building. Before starting a lengthy make process, check the Tips section below for how to make Make multicore aware. You may want to modify the build/conf/local.conf file for your target (emulation/chroot) environment:
make openmoko-devel-image

This will set up the recommended directory structure as described in [[Building OpenMoko from scratch]], will download all the required software (from the right places with the right versions), and will immediately start building an image.

Once you have done this, you can choose to continue using the MokoMakefile to initiate your subsequent builds, or you can go into the build directory and run bitbake commands manually. The choice is yours.

==Updating the environment==
For easy maintenance of your build environment the following commands are available.

1 - To update the MokoMakefile to the latest version:
make update-makefile

2 - To make sure that any recent changes to the build directory structure have been applied:
make setup

3 - To update the OpenMoko repository checkout and the MokoMakefile patches to the latest version:
make update

A quick way to rebuild a new image with the latest updates:
make update-makefile && make setup update openmoko-devel-image

==Build issues==
First, make sure that the problem is reproducible after running

make update-makefile && make setup && make update

then run

make clean-package-<foo>

(where you replace <foo> with the name of the package which is failing)

and finally

make openmoko-devel-image

If you can get the error to occur three times in a row after running that sequence of commands (including the update and setup steps) three times, then feel free to report it to rwhitby in #openmoko on [http://wiki.openmoko.org/wiki/Development_resources#IRC IRC].

===Known MokoMakefile errors ===
If you experience the following after changing from OM-2007.1 to OM-2007.2:

Patch bitbake-1.6.6-om3.patch does not apply (enforce with -f)

then type "make clobber-patches" to fix it. There was a period of 24 hours when there was a bug in the MokoMakefile which causes this problem. Once the patches have been clobbered, they will re-download and the problem will not reoccur.

===Fixes for distribution/environment-specific or isolated issues===

Work-arounds for temporary or isolated problems can be found and should be added to the [[Talk:MokoMakefile|Discussion page]] which is associated with this page. As they are fixed, they will be removed from that page.

==Tips==
*You can reduce the amount of consumed disk space significantly by adding
INHERIT += "rm_work"
in your local.conf (e.g. ~/moko/build/conf/local.conf). This will remove the contents of each build/tmp/work/*/<package> directory after the corresponding package builds correctly. As of 10/16/07, this appears to be present in local.conf by default.

*If you an encounter an error with monotone similar to the following:
mtn: misuse: database /home/''username''/moko/OE.mtn is laid out according to an old schema
Then you need to upgrade OE.mtn Use the following command while in ~/moko:
# mtn --db OE.mtn db migrate

*If a certain package does not build due to corrupted download or some such try to remove the sources and rebuild it.
rm sources/<package>*
cd build
. ../setup-env
bitbake -crebuild <package>
after that your build might just work again.

*For people with multiple CPU's (or dual-core ones) this small patch might be useful to build things faster.
Edit the local.conf and add the following lines:
PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"

Change the PARALLEL_MAKE and BB_NUMBER_THREADS values to something that suits better if it chokes your machine.

*For amd64 host users you need the patch from http://bugs.openembedded.org/show_bug.cgi?id=1765 to build db3-native

* If you encounter an error related with the qemu-native package and not compiling for the qemu, you can edit the build/conf/local.conf file and add ENABLE_BINARY_LOCALE_GENERATION = "0" line to avoid the error.

* To prevent building tons of locales, add a line like this to local.conf:
GLIBC_GENERATE_LOCALES = "en_US.UTF-8 nl_NL.UTF-8"

* To not build any binary locales at all, add this to local.conf:
ENABLE_BINARY_LOCALE_GENERATION = "0"

* If you want to rebuild the package indexes (for instance, after compiling a new version of a package) without building <code>openmoko-devel-image</code>, run <code>make build-package-package-index</code>.

==Developing with MokoMakefile==

{{note|If using MokoMakefile with OM2007.2 then references to $OMDIR/openmoko should be replaced with $OMDIR/openembedded. Also references to tmp/work/armv4t-linux should be replaced with tmp/work/fic-gta01-angstrom-linux-gnueabi}}

For the following explanations $OMDIR is the directory where there Makefile puts all the stuff.

To make in-tree changes and have them built and used by qemu:

cd $OMDIR/openmoko
quilt new descriptive-patch-name.patch
quilt add trunk/src/name-of-file-to-change # do this for every file you are about to modify
...make the changes...
quilt refresh # this creates a file in $OMDIR/patches/openmoko-HEAD/ and updates the quilt series file there

Note: Do '''NOT''' use absolute paths as this confuses quilt and will get you a diff of the file against /dev/null!

To build the changes and have them used by qemu:

make build-qemu
make flash-qemu-local
make run-qemu

If you want to modify applications instead of the openmoko toolchain, this is what you have to do (example: openmoko-messages):

cd $OMDIR/build
. ../setup-env
bitbake -c unpack openmoko-messages
cd ../build/tmp/work/armv4t-linux/openmoko-messages-0.0.1+svnnow-r2_2276/openmoko-messages/
...make the changes...
cd -
bitbake openmoko-messages

Then continue with MokoMakefile usage.

If you want to add an application to your openmoko distribution, do this:
All file edits should be done using quilt as described above. That way a patch can easily be submitted to the openmoko project.
First, create a directory that will correspond to your package and edit a '''.bb''' file in there:
cd $OMDIR/openmoko/
quilt new mycoolpackage.patch
mkdir trunk/oe/packages/mycoolpackage
quilt add trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb
quilt edit trunk/oe/packages/mycoolpackage/mycoolpackage_1.bb

The file should have the following content:
DESCRIPTION = "This is a cool package"
SECTION = "username/mycoolpackage"
PV = "1"

inherit autotools

SRC_URI = "http://www.example.com/download/mycoolpackage-1.tar.gz"

Explanation:
* DESCRIPTION - Just a short text explaining the package
* SECTION - I have no clue, but I'll use username/mycoolpackage for now
* PV - Package Version
* inherit autotools - The package can be compiled by './configure && make && make install' so we tell MokoMakefile to do it this way.
* SRC_URI = ... - This is the download location of the package source. It's imperative that the tar.gz contains a directory called '''packagename-packageversion''' (in this case: mycoolpackage-1) so that MokoMakefile can find it automatically or the build will fail.

This is not all. We also need to tell MokoMakfile that it needs to build and include the package in the image. To do this, do
$OMDIR/openmoko# quilt edit trunk/oe/packages/tasks/task-openmoko.bb
Here, increase the value '''PR''' by one and add '''mycoolpackage \''' (with the backslash!) just before the line reading '''# update-alternatives \'''.

Now run
quilt refresh
cd ..
make update openmoko-devel-image

And if everything's alright you should now have an OpenMoko image to flash to your phone or run in qemu as described above.

=== Hello World application ===

There is a [http://wiki.openmoko.org/wiki/Building_a_hello_world_application Hello World!] tutorial available too.

==Testimonials==
MokoMakefile is recommended by 4 out of 4 new developers on #openmoko, with testimonials such as "For some reason last night I couldn't get my manual install of everything to work (bb complained about my bbpath I think) ... but with your makefile, it works great!", "MokoMakefile rocks!", and "Wow this build system is nice - it just seems more polished than my gumstix toolchain buildroot system".

Project page:
http://mokomakefile.projects.openmoko.org/

{{Languages|MokoMakefile}}

[[Category:Developer]]
[[Category:Guides]]