Authentification sur 9grid.fr

À partir de Plan 9 ou 9vx :

echo 'auth=andromeda.9grid.fr authdom=9grid.fr' >> /lib/ndb/local
auth/factotum
import andromeda.9grid.fr / /n/andromeda
cpu -h andromeda.9grid.fr

À partir de Inferno :

echo 'auth=andromeda.9grid.fr authdom=9grid.fr' >> /lib/ndb/local
ndb/cs
auth/factotum
auth/feedkey
mount -ac {mntgen} /n
import andromeda.9grid.fr / /n/andromeda.9grid.fr

À partir de Drawterm :

drawterm -a andromeda.9grid.fr -c andromeda.9grid.fr -u [user]

À partir de plan9port, v9fs et 9mount ou 9pfuse ou 9import :

echo 'auth=andromeda.9grid.fr authdom=9grid.fr' >> $PLAN9/ndb/local
factotum -n
srv -a andromeda.9grid.fr
9mount -i unix\!`namespace`/andromeda.9grid.fr /n/andromeda
9pfuse `namespace`/andromeda.9grid.fr /n/andromeda

À partir de 9import :

echo 'auth=andromeda.9grid.fr authdom=9grid.fr' >> $PLAN9/ndb/local
factotum -n
9import andromeda.9grid.fr /n/andromeda

Listen

Ceci est une brêve description des principaux services réseaux utiles à la communication entre différentes machines sous Plan 9.

  • /rc/bin/service
    • tcp17007 : exportfs sur TCP avec pré-authentification via authsrv et chiffrement
    • il17007 : exportfs sur IL avec pré-authentification via authsrv et chiffrement
    • tcp17010 : cpu sur TCP
  • /rc/bin/service.auth
    • il566 : authsrv sur IL (authentification)
    • tcp567 : authsrv sur TCP (authentification)
  • fossil/conf /dev/sdC0/fossil
    • listen tcp!*!564 : fossil sur TCP avec authentification via Tauth et sans chiffrement
    • listen il!*!17008 : fossil sur IL avec authentification via Tauth et sans chiffrement

Le protocole IL n'est aujourd'hui plus disponible dans la distribution de Bell Labs, puisqu'il a été retiré en faveur de TCP. Cependant, des distributions alternatives comme 9atom d'Erik Quanstrom l'intégrent toujours.

Notez qu'il17010 n'a jamais existé. Cependant, il existait il17013, l'équivalent de tcp17013 du temps de l'ancien serveur cpu.

Systèmes de fichiers

De part de l'interêt que ses créateurs ont pour les systèmes de fichiers, Plan 9 dispose de multiples systèmes de fichiers différents, tous se différenciant par leurs propres caractéristiques.

  • fs(4), « The Plan 9 File Server » ou « Ken's File Server »

    C'est l'ancien système de fichiers d'archivage principal de Plan 9. Il dispose de son propre noyau, dérivé d'un ancien noyau de Plan 9 et nécessite ainsi une machine dédiée. Un disque dur est utilisé en tant que cache de lecture et d'écriture vers un jukebox de disques magnéto-optiques WORM. Il a initialement été développé par Sean Quinlan et Ken Thompson au début des années 90. Geoff Collyer l'a mis à jour en 64-bit en 2004 et a été distribué à partir du 17 février 2006. Il a finalement été retiré conjointement avec IL par Geoff Collyer le 30 août 2007. Il est depuis toujours maintenu par Erik Quanstrom et disponible dans son répertoire contrib et au sein de sa distribution 9atom. Le jukebox est aujourd'hui souvent remplacé par un disque dur ou un LUN AoE.

  • cwfs(4) ou « Cached–WORM File Server »

    C'est une implémentation de fs conçue pour tourner en espace utilisateur, et non sur un noyau séparé. Il a été développé par Geoff Collyer dans le but d'accéder au contenu des anciens serveurs de fichiers avec un noyau récent. L'unique nouveauté est l'ajout du support d'un nouveau format de cache, beaucoup plus performant. Il a été distribué à partir du 25 mars 2007.

  • kfs(4) ou « Disk File System »

    C'est un ancien système de fichiers local tournant en espace utilisateur. Il a été conçu pour les terminaux Plan 9 disposant d'un disque dur. C'est un dérivé du cache de fs qui ne dispose pas de la fonction d'archivage. Il est trés similaire à la partition « other » de fs.

  • venti(6) ou « Archival Storage Server »

    C'est le successeur de fs. C'est un système de fichiers d'archivage compressé tournant en espace utilisateur. Les groupes de fichiers sont identifiés par des bloc en écriture seule. Chaque bloc est identifié par une emprunte SHA-1, ainsi deux blocs identiques ne seront présents physiquement qu'une seule fois sur le disque. Il a été initialement développé par Sean Quinlan et Sean Dorward en 2001. Venti fut distribué à partir de la quatrième édition de Plan 9, annoncée le 27 avril 2002. Russ Cox, Sean Rhea et Alex Pesterev ont ensuite travaillé sur l'amélioration des performances au sein du projet « Foundation ». Ils ont notamment travaillé sur les caches et ajouté un filtre de Bloom. Leurs changements furent intégrés à Venti le 5 septembre 2007.

  • fossil(4) ou « The Fourth Edition File Server »

    C'est le nouveau système de fichiers principal de Plan 9. Il tourne en espace utilisateur. Il a été conçu comme un buffer d'écriture qui peut éventuellement être archivé vers un serveur venti. En plus de ça, il a la possibilité d'effectuer des snapshot éphémères. Il a été développé par Sean Quinlan, Jim McKie et Russ Cox. Il a été anoncé le 8 janvier 2003

  • cfs(4) ou « Cache File System »

    C'est un système de fichiers tournant en espace utilisateur qui sert de tampon entre des fichiers distants et un disque local.

  • paqfs(4)

    C'est un système de fichiers en lecture-seule, compressé et destiné aux mémoires flash.

  • flashfs(4)

    C'est un système de fichiers journalisé et destiné aux mémoires flash.

Bien qu'il ait été retiré de la distribution Plan 9 de Bell Labs, le système de fichiers fs est toujours utilisé par quelques personnes. L'absence de compression diminue la sensibilité aux temps d'accès disque et le fait qu'il tourne en espace noyau réduit les changements de contexte, ce qui le rend plus performant que son successeur venti, bien que d'avantage consommateur en espace disque. De plus, fs est considéré plus mature puisqu'il a pu prouver sa robustesse pendant plus de 15 ans d'utilisation chez Bell Labs et ailleurs.

Plan 9 sur iPAQ

Le port de Plan 9 sur Compaq iPAQ H3600 par David Presotto et Sape Mullender a été annoncé le 13 novembre 2000. Il est aujourd'hui toujours possible de faire fonctionner la version actuelle de Plan 9 dessus.

Tout d'abord, il existe actuellement trois documentations d'installation qui diffèrent légèrement :

Je vous recommande la lecture de ces documentations, parce qu'elles sont plus complètes que celle présentée ici. Mon but ici est avant tout de vous faire partager mon expérience.

Pour installer Plan 9 sur iPAQ, vous devez disposer du matériel suivant :

  • un iPAQ H3630 ou H3650, bien que d'autres modèles de la série H3600 puissent fonctionner,
  • son câble série, sachant qu'il n'est pas possible d'utiliser le câble USB pour installer un système d'exploitation dessus.

Si vous souhaitez disposer du réseau, il faudra en outre disposer du matériel suivant :

  • un adaptateur de cartes PCMCIA simple, sachant que le modèle double n'est pas supporté,
  • une carte Wi-Fi PCMCIA de type WaveLAN telle que « Lucent Technologies WaveLAN/IEEE 802.11 » ou « ORiNOCO Classic Gold ».

Une liste des cartes WaveLAN est disponible dans le manuel de wi(4) de FreeBSD.

Les iPAQ H3600 étaient à l'origine commercialisés sous PocketPC 2000, mais il est possible d'en trouver sous PocketPC 2002 aujourd'hui.

La première étape de l'installation consistera à remplacer le chargeur de démarrage initial par le chargeur de démarrage pour Linux.

Pour se faire, nous allons télécharger les programmes suivants :

  • BootBlaster_1.18.exe (MD5), qui permet de sauvegarder ou installer le chargeur de démarrage,
  • bootldr-0000-2.14.8 (MD5), le chargeur de démarrage de Linux, en version 2.14.8, sachant que les versions suivantes sont déconseillées, puisqu'elles posent un problème avec la mise en veille sous Plan 9.

Microsoft fournit un logiciel qui permet de synchroniser les données de l'iPAQ avec celle de votre ordinateur. Nous l'utiliserons pour copier les deux fichiers précédents sur l'iPAQ. Sous Windows 2000 et XP, ce logiciel s'appelle ActiveSync, sous Windows Vista et Windows 7, il s'appelle Windows Mobile Device Center.

D'abord, sous Windows, renommez le fichier bootldr-0000-2.14.8 en bootldr-0000-2.14.8.bin. Il est important de renommer le fichier sous Windows, parce qu'il est difficile de le faire sur PocketPC et que Bootblaster nécessite que le nom du fichier finisse par .bin.

Avec l'aide de votre outil de synchronisation, placez les deux fichiers précédents sur l'iPAQ. Ensuite, sur l'iPAQ, exécutez BootBlaster_1.18.exe pour sauvegarder le chargeur de démarrage actuel ainsi que le système d'exploitation PocketPC.

Désormais, nous allons passer à la seule étape risquée du processus. Assurez vous que votre iPAQ est bien chargé, que l'alimentation est branchée et n'éteignez pas votre iPAQ durant cette étape. Avec l'aide de BootBlaster_1.18.exe, installez le fichier bootldr-0000-2.14.8.bin en tant que chargeur de démarrage.

À présent, votre iPAQ dispose du chargeur de démarrage de Linux. Redémarrez votre iPAQ en pressant le bouton « reset » avec le stylet.

La distribution de Plan 9 n'inclut pas les binaires ARM. Il faudra donc compiler le compilateur ARM puis compiler le système, et enfin le noyau :

for(i in /sys/src/cmd/5?) @{cd $i && mk install && mk clean}
cd /sys/src && objtype=arm {mk install && mk clean}
cd /sys/src/boot/bitsy && objtype=arm {mk install && mk clean}

Deux fichiers seront à charger sur l'iPAQ :

  • le noyau 9bitsy, qui se loge dans la partition kernel,
  • le système paqdisk, qui se loge dans la partition ramdisk.

Contrairement à ce qui est écrit dans plusieurs documentations, la partition ramdisk ne fait pas 6 Mo, mais bien 4 Mo. Le fichier paqdisk doit donc être de taille inférieure 4 Mo.

Le fichier /sys/lib/sysconfig/proto/armpaqproto décrit la liste des fichiers qui seront inclus dans le paqdisk.

Par défaut, le paqdisk est trop gros. Vous devez donc éditer le fichier /sys/lib/sysconfig/proto/armpaqproto pour y supprimer les applications qui vous semble inutile et éventuellement en rajouter d'autres, s'il vous reste de la place.

Dans le fichier /sys/src/9/bitsy/paqfiles/cpurc vous pouvez éventuellement modifier le clavier. Par défaut, le clavier est un peu petit puisqu'il contient winwatch ainsi que le système de reconnaissance d'écriture.

Maintenant, compilons le paqdisk, ainsi que 9bitsy :

cd /sys/src/9/bitsy && mk && mk paqdisk

Connectez l'iPAQ au port RS-232 de votre ordinateur. Désormais, nous allons lancer la console série depuis Plan 9 vers l'iPAQ pour y créer les partitions, puis installer 9bitsy, ainsi que paqdisk :

con -b 115200 /dev/eia0
boot>
boot> partition reset
boot> partition define bootldr 0x000000 0x040000 2
boot> partition define params 0x040000 0x040000 0
boot> partition define kernel 0x080000 0x0c0000 0
boot> partition define user 0x140000 0x0c0000 0
boot> partition define ramdisk 0x200000 0x600000 0
boot> partition define fs 0x800000 0x800000 0
boot> params save
boot> load kernel
[ Appuyez sur « Ctrl-\ » ]
>>> !xms /sys/src/9/bitsy/9bitsy
boot> load ramdisk
[ Appuyez sur « Ctrl-\ » ]
>>> !xms /sys/src/9/bitsy/paqdisk
>>> boot

À présent, Plan 9 devrait démarrer.

Plan 9 sur SheevaPlug

Le SheevaPlug est une machine idéale pour réaliser un petit cpu server sous Plan 9. Heuresement pour nous, un port a été effectué par Geoff Collyer.

Dans notre exemple, nous considérerons les machines suivantes :

  • un file server, nommé « tellurium»,
  • un SheevaPlug, nommé « iodine », d'adresse IP 192.168.2.30 et d'adresse MAC 00:50:43:01:6E:2C.

On s'assurera que fossil écoute sur le port 564. Si ce n'est pas le cas, effectuez l'opération suivante :

fossil/conf /dev/sdC0/fossil >fossil.conf
cat >> fossil.conf << EOF
listen tcp!*!564
EOF
fossil/conf -w /dev/sdC0/fossil fossil.conf

Dans le fichier /lib/ndb/local, on ajoute :

ip=192.168.2.30 sys=iodine ether=005043016e2c
    bootf=/arm/9plug
    auth=tellurium
    fs=tellurium
    gw=192.168.2.1
    dns=192.168.2.1

On utilise l'example du plan9.ini pour SheevaPlug :

cp /cfg/pxe/example–kw /cfg/pxe/005043016e2c

On copie la NVRAM du auth server vers les sources du SheevaPlug :

dd -if /dev/sdC0/nvram -of /sys/src/9/kw/nvram

Si l'on n'effectue pas l'opération précédente, il vous sera demandé d'entrer les informations à chaque démarrage du SheevaPlug.

On lance la compilation du compilateur ARM, puis du système et enfin du noyau :

for(i in /sys/src/cmd/5?) @{cd $i && mk install && mk clean}
cd /sys/src && objtype=arm {mk install && mk clean}
cd /sys/src/9/kw && mk CONF'='plug install && mk clean

Afin d'effectuer la configuration préliminaire de Das U-Boot, on connecte le port mini-USB du SheevaPlug au port USB d'un terminal Plan 9, puis on branche le SheevaPlug. Enfin, on utilise usb/uart afin d'accéder à l'UART sur USB.

usb/serial

Vous devriez obtenir un affichage ressemblant à ce qui suit.

usb/serial: startdevs: opening #0 /dev/usb/ep4.0
eiaU4

Suite à quoi, vous pouvez utiliser le périphérique créé de la même manière qu'un véritable port série.

con -b 115200 /dev/eiaU4/eiaU
Marvell>> resetenv
Marvell>> reset
Marvell>> setenv bootdelay 2
Marvell>> setenv bootcmd 'bootp; bootp; tftp 0x1000 /cfg/pxe/005043016e2c;
          bootp; tftp 0x800000; go 0x800000'
Marvell>> setenv ethaddr 00:50:43:01:6e:2c
Marvell>> saveenv

On n'oubliera pas de spécifier l'adresse MAC telle qu'elle est inscrite sur le SheevaPlug, car la commande resetenv regénère systématiquement une adresse différente.

Désormais, à chaque mise sous tension, votre SheevaPlug démarrera automatiquement à partir de votre auth server.

Démarrage de Plan 9 en PXE

Plan 9 from Bell Labs est un système d'exploitation distribué. Les terminaux ne disposent généralement pas de disque dur et démarrent en réseau à partir d'un file server. Sur les PC, on utilise actuellement la technologie PXE pour démarrer en réseau.

Nous allons configurer notre file server, dans le but de permettre à notre terminal de démarrer en PXE.

Évidemment, il est nécessaire de disposer au préalable d'un cpu server fonctionnel.

Dans notre exemple, nous considérerons les machines suivantes :

  • un file server, nommé « fluorine », d'adresse IP 192.168.0.9,
  • un terminal, nommé « carbon », d'adresse IP 192.168.0.6 et d'adresse MAC 00:04:AC:EE:E7:E3.

L'ensemble de la configuration s'effectue sur le cpu server.

Nous créons le fichier /cfg/pxe/0004aceee7e3 :

bootfile=ether0!/386/9pcf
bootargs=tcp
nobootprompt=tcp
mouseport=ps2intellimouse
vgasize=1280x1024x32
monitor=xga

Ce fichier est l'équivalent de /n/9fat/plan9.ini pour les machines démarrant en réseau. Pour chaque terminal, vous devrez créer un fichier comme celui-ci et dont le nom correspondra à son adresse MAC.

Nous complétons le fichier /lib/ndb/local comme ceci :

ip=192.168.0.6 sys=carbon ether=0004aceee7e3
    bootf=/386/9pxeload
    auth=fluorine
    fs=fluorine
    ipgw=192.168.0.1
    dns=192.168.0.1

C'est le fichier de configuration du serveur DHCP. Ici nous précisons que le système d'adresse MAC 00:04:AC:EE:E7:E3 aura pour pour adresse IP 192.168.0.6 et pour nom « carbon ».

Le fichier /386/9pxeload est le programme de démarrage en PXE. Si vous ne l'avez pas, compilez le puis installez le :

cd /sys/src/boot/pc
mk install TARG'='9pxeload
mk clean

Évidemment, il ne faudra pas oublier de configurer le BIOS du terminal afin de définir PXE comme mode de démarrage par défaut.

Ceci fait, il ne nous reste plus qu'a démarrer le terminal.

Construction d'une image d'installation

Il est parfois utile de construire une image ISO personnalisée du média d'installation de Plan 9. Cette procédure n'est pas documentée, mais tous les scripts qui servent à la construction automatisée des images ISO distribuées par Bell Labs sont fourni dans la distribution.

Nous allons simuler un environnement similaire à celui de chez Bell Labs, afin d'avoir à effectuer le moins possible de modifications dans les scripts de construction de l'image ISO. Nous choisissons d'utiliser le répertoire /usr/setup à cet effet.

mkdir /usr/setup
mkdir /usr/setup/dist
mkdir /usr/setup/other
mkdir /usr/setup/other/dist
mkdir /usr/setup/sources
mkdir /usr/setup/sources/plan9
mkdir /sys/lib/dist/web.protect

On compile, puis on installe les utilitaires servant à la fabrication du bzroot :

cd /sys/lib/dist/cmd
mk install
mk clean
cd /sys/lib/dist/cmd/multi
mk
mk install
mk scripts
mk clean

On remplace le contenu du fichier /sys/lib/dist/setup par ce qui suit :

#!/bin/rc
# setup - prep for the mkfile
bind /usr/setup/sources /n/sources
bind /usr/setup/other /n/other
bind /usr/setup/dist /n/dist

On télécharge, puis on extrait l'image ISO de Plan 9 afin de l'utiliser comme base pour la création de notre système personnalisé :

hget https://9p.io/plan9/download/plan9.iso.bz2 | bunzip2 > plan9.iso
9660srv -f plan9.iso
mount /srv/9660 /n/plan9
cd /n
tar cf /usr/setup/sources/plan9.tar plan9
cd /usr/setup/sources
tar xf plan9.tar

Désormais, vous pouvez modifier le système présent dans le répertoire /usr/setup/sources/plan9 à votre convenance. N'oubliez pas que les noyaux pcflop et pccd utilisés pour le démarrage de l'ISO sont construits à partir du noyau de votre système.

Une fois que tout est prêt, il ne vous reste plus qu'à lancer le processus de création de l'image ISO.

cd /sys/lib/dist
mk

Après quelques minutes, l'image ISO sera disponible dans le fichier /usr/setup/other/dist/plan9.iso.

Installation en réseau

Il n'est pas toujours pratique d'installer Plan 9 partir du cédérom d'installation, notamment parce que certaines machines ne disposent pas de lecteur. Évidemment, il est possible d'installer Plan 9 réseau, mais cette procédure n'est, là encore, pas documentée.

Les scripts d'installation fournis semblent sauter l'étape de téléchargement de l'ISO pendant l'installation. Nous allons donc effectuer quelques légères modifications sur ceux-ci.

Dans le fichier /sys/lib/dist/pc/inst/download, on remplace la ligne prereq par ce qui suit :

# prereq: mountfs confignet

Dans le fichier /sys/lib/dist/pc/inst/mountdist, on remplace la ligne prereq par ce qui suit :

# prereq: mountfs configdist download

Dans le fichier /sys/lib/dist/pc/inst/main, on redéfinit la liste des tâches dans l'ordre suivant :

confignet\
download\
mountdist\
fmtventi\

On compile, puis on installe les utilitaires servant à la fabrication du bzroot :

cd /sys/lib/dist/cmd
mk install
mk clean
cd /sys/lib/dist/cmd/multi
mk
mk install
mk scripts
mk clean

On compile, puis on installe le noyau pccflop servant à l'installation :

cd /sys/lib/dist/pc
mk
cp /sys/src/9/pc/9pcflop.gz /386

Ensuite, on modifie les fichiers /lib/ndb/local et /cfg/pxe/<mac> de la même manière qu'une machine démarrant en réseau de manière classique, à la différences que le fichier /cfg/pxe/<mac> devra contenir les lignes suivantes :

bootfile=ether0!/386/9pcflop.gz
nobootprompt=local!/boot/bzroot
installurl=https://9p.io/plan9

La ligne installurl est l'URL HTTP à partie de laquelle sera téléchargée l'image ISO de Plan 9. Cela peut être n'importe quel serveur aussi bien à l'intérieur qu'à l'extérieur de votre réseau local.

Enfin, il suffit de démarrer la machine. L'installation se déroulera de la même manière qu'à partir d'un cédérom, à la différence qu'il faudra spécifier « Distribution is from net » lors de l'étape configdist.

Miroir des disques durs

Le driver fs(3) fut publié le 30 décembre 2002. Il permet entre autres d'effectuer une écriture simultanée sur deux disques durs, d'une façon similaire à RAID1.

Ici, nous prennons l'exemple d'un file server disposant de deux disques durs « sdE0 » et « sdE1 » et utilisant les systèmes de fichiers fossil+venti. La configuration est très similaire dans le cas ou votre file server ne dispose que du système de fichiers fossil. Évidemment, les deux disques durs devront être de taille identique.

On crée le fichier /cfg/fs.conf :

fsdev:
mirror arenas /dev/sdE0/arenas /dev/sdE1/arenas
mirror fossil /dev/sdE0/fossil /dev/sdE1/fossil
mirror isect /dev/sdE0/isect /dev/sdE1/isect

On considère que l'on utilise le noyau pccpuf, ce qui est le cas le plus fréquent sur un file server, mais la démarche reste applicable à n'importe quel noyau.

Dans le fichier /sys/src/9/pc/pccpuf on décommente :

#/386/bin/disk/kfs

Puis on ajoute :

/cfg/fs.conf

On recompile le noyau :

cd /sys/src/9/pc
mk clean
mk CONF'='pccpuf install
mk clean

On monte la partition 9fat, puis on y installe le noyau :

9fat:
cp /386/9pccpuf /n/9fat

Dans le fichier /n/9fat/plan9.ini, on ajoute :

fsconfig=/boot/fs.conf

Puis on remplace #S/sdE0/arenas par #k/fs/arenas.

On extrait la configuration de fossil :

fossil/conf /dev/sdE0/fossil >fossil.conf

Dans le fichier fossil.conf, on remplace « sdE0 » par « fs ».

On réécrit la configuration de fossil :

fossil/conf -w /dev/sdE0/fossil fossil.conf

On extrait la configuration de venti :

venti/conf /dev/sdE0/arenas >venti.conf

Dans le fichier venti.conf, on remplace « sdE0 » par « fs ».

On réécrit la configuration de venti.

venti/conf -w /dev/sdE0/arenas venti.conf

On éteint la machine, puis on boot sur un CD-ROM de Plan 9 pour recopier l'ensemble du disque sdE0 sur le disque sdE1. Cette étape peut être assez longue en fonction de la taille et la vitesse de vos disques durs.

dd -if /dev/sdE0/data -of /dev/sdE1/data

Enfin, il suffit de démarrer la machine normalement. L'écriture s'effectue de façon séquentielle, d'abord sur le premier disque, ensuite sur le second disque. La lecture s'effectue uniquement à partir du premier disque.

Inferno sur le Neo FreeRunner

Introduction

Le Neo FreeRunnner est un téléphone portable libre, dont le système d'exploitation officiel est une distribution Linux appelée OpenMoko. De nombreuses autres distributions sont également disponibles.

Outre le fait qu'il s'agisse d'un bon téléphone, le Neo FreeRunner fait également office d'un bon ordinateur de poche, mais surtout d'une excellente plateforme de développement. Tout comme l'iPAQ H3650, il peut être très intéressant d'y installer Inferno.

Mashara Binovich a auparavant réussit à faire fonctionner Inferno sur OpenMoko. Son code est disponible au sein du projet inferno-openmoko. Cependant cette dernière a également effectuée de nombreuses autres modifications, se séparant ainsi complètement de la branche officielle de développement d'Inferno (inferno-os).

J'ai ici tenté d'expliquer comment faire fonctionne la version officielle actuelle d'Inferno sur OpenMoko, le plus simplement possible, tout en effectuant le minimum de modifications et en réutilisant le travail déjà effectué. La procédure décrite ici se déroule sous Linux.

Variables d'environnement

Par la suite, on considérera les variables d'environnement suivantes :

INFERNO=/usr/local/inferno
OMINFERNO=/usr/inferno
OM=/root/openmoko

$INFERNO représente le répertoire où est installé Inferno pour votre système hôte, $OMINFERNO le répertoire ou sera installé Inferno pour OpenMoko et $OM le répertoire de travail pour la préparation de la distribution OpenMoko.

Pré-requis

Avant toute chose, il est nécessaire que vous ayé déjà installé Inferno pour votre système, et ajouté le répertoire Linux/386/bin dans votre PATH, afin d'avoir accès aux commandes telles que limbo.

Utilitaires

On commence par installer les outils de base :

  • dfu-util permet de flasher la mémoire NAND du Neo FreeRunner à partir des images présentes sur votre ordinateur, par l'intermédiaire du câble USB,
  • mkfs.jffs2 permet de formater une partition en JFFS2, le système de fichiers utilisé par la distribution OpenMoko.

L'utilitaire mkfs.jffs2 est généralement fournit dans les distributions Linux au sein du paquet mtd-utils.

yum install mtd-utils

L'utilitaire dfu-util est propre au projet OpenMoko. Il est présent dans plusieurs distributions Linux, mais n'étant pas forcément très à jour, il est plutôt conseillé de récupérer la dernière version à partir du dépôt Subversion. Sa compilation dépend des paquets libusb-devel, glibc-static et libusb-static qu'il vous faudra préalablement installer avec le gestionnaire de paquet de votre distribution.

svn co https://svn.openmoko.org/trunk/src/host/dfu-util/
cd dfu-util
./autogen.sh
./configure
make
make install
cd ..
rm -rf dfu-util

Environnement de compilation croisé

Ensuite, nous aurons besoin d'un environnement de compilation croisée pour compiler Inferno pour l'architecture ARM. Si vous utilisez un système x86, le projet OpenMoko fournit un environnement de compilation ARM920T prêt-à-l'emploi.

cd /
wget http://downloads.openmoko.org/developer/toolchains/
openmoko-i686-20090323-armv4t-linux-gnueabi-toolchain-openmoko.tar.bz2
tar jxf openmoko-i686-20090323-armv4t-linux-gnueabi-toolchain-openmoko.tar.bz2
rm openmoko-i686-20090323-armv4t-linux-gnueabi-toolchain-openmoko.tar.bz2
. /usr/local/openmoko/arm/environment-setup
opkg-target update
opkg-target install libx11-dev libxext-dev
ln -s /usr/local/openmoko/arm/bin/arm-angstrom-linux-gnueabi-gcc /usr/local/bin/arm-gcc

Installation d'Inferno

Nous allons maintenant télécharger la version de développement d'Inferno à partir du dépôt Mercurial.

hg clone https://inferno-os.googlecode.com/hg/ $OMINFERNO

On supprime les fichiers de Mercurial, ce qui permettra d'économiser de la place sur la mémoire Flash du Neo FreeRunner.

find $OMINFERNO -name .hg -exec rm -rf {} \;

Suite à la migration du projet Inferno de Subversion vers Mercurial, certains répertoires sont manquants. Nous allons donc les créer.

mkdir $OMINFERNO/Linux/arm/lib
mkdir $OMINFERNO/Linux/arm/bin

Sous OpenMoko, les applications sont exécutés en tant que root, donc nous allons ajouter son répertoire personnel dans Inferno.

cp -r $OMINFERNO/usr/inferno $OMINFERNO/usr/root

Certaines polices ne sont pas distribuées autrement que dans la version commerciale d'Inferno. On ira donc les récupérer sur le site de Vita Nuova.

wget http://www.vitanuova.com/dist/4e/inferno-20090730.tgz
tar xzf inferno-20090730.tgz
mv inferno/fonts/lucida $OMINFERNO/fonts
mv inferno/fonts/lucidasans $OMINFERNO/fonts
mv inferno/fonts/lucm $OMINFERNO/fonts
mv inferno/fonts/pelm $OMINFERNO/fonts
rm -rf inferno inferno-20090730.tgz

Éditez le fichier $OMINFERNO/mkconfig, en changeant les variables ROOT, SYSHOST et OBJTYPE comme ci-dessous :

ROOT=/usr/inferno
SYSHOST=Linux
OBJTYPE=arm

Modification d'Inferno

Le clavier virtuel est un élément indispensable sur un ordinateur ne disposant pas de clavier physique. Le clavier par défaut étant un trop petit pour l'écran du Neo FreeRunner, nous allons ici le configurer pour qu'il prenne toute la largeur de l'écran (480 pixels).

Éditez le fichier $OMINFERNO/appl/wm/keyboard.b, en remplaçant la ligne :

KEYSIZE: con 13;

Par la ligne :

KEYSIZE: con 31;

Le clavier virtuel étant absent du menu de lancement des applications, il faudra l'ajouter.

Éditez le fichier $OMINFERNO/lib/wmsetup et ajoutez la ligne suivante dans le menu que vous désirez.

menu Keyboard {wmrun wm/keyboard}

Parmi de nombreuses autres choses, le projet inferno-openmoko a effectué un excellent travail de modification d'Inferno pour que ce dernier s'exécute correctement sur le Neo FreeRunner. Plutôt que de livrer mon propre code, je vous conseille de réutiliser leur travail, qui est déjà disponible en ligne, en remplaçant ces deux fichiers par les leurs. Je vous laisse soin de comparer le code pour comprendre leurs modifications.

SVN=http://inferno-openmoko.googlecode.com/svn-history/r5/trunk
curl $SVN/emu/Linux/asm-arm.S > $OMINFERNO/emu/Linux/asm-arm.S
curl $SVN/emu/port/win-x11a.c > $OMINFERNO/emu/port/win-x11a.c

Compilation d'Inferno

Désormais, vous pouvez lancer la compilation d'Inferno, qui durera plusieurs minutes.

cd $OMINFERNO
mk nuke
mk install
mk clean

Intégration d'Inferno dans OpenMoko

Maintenant, vous pouvez télécharger la distribution OpenMoko :

  • fso-paroli-image est la distribution d'OpenMoko contenant l'environnement graphique,
  • u-boot est le chargeur de démarrage du Neo FreeRunner,
  • uImage est le noyau Linux d'OpenMoko,
  • Om2008.9.splash.gz est l'image affichée au démarrage du Neo FreeRunner.
mkdir $OM
cd $OM
OMFTP=ftp://downloads.openmoko.org/distro
wget $OMFTP/unstable/NeoFreerunner/fso-paroli-image-om-gta02.jffs2
wget --glob=on $OMFTP/unstable/NeoFreerunner/u-boot-gta02v5-1.3.1+*.bin
wget --glob=on $OMFTP/unstable/NeoFreerunner/uImage-2.6.28-stable+*.bin
wget $OMFTP/releases/Om2008.9/Om2008.9.splash.gz

L'utilitaire Mntjffs.sh permet de monter les images au format JFFS2 dans votre arborescence.

wget http://wiki.openmoko.org/images/8/82/Mntjffs.sh
chmod +x Mntjffs.sh

Nous allons maintenant extraire l'image d'OpenMoko, afin d'y intégrer Inferno

mkdir $OM/ro
$OM/Mntjffs.sh $OM/fso-paroli-image-om-gta02.jffs2 $OM/ro
cp -r $OM/ro $OM/rw
umount $OM/ro
rmmod block2mtd jffs2 mtdblock
rm -rf $OM/fso-paroli-image-om-gta02.jffs2 $OM/ro
cp -r $OMINFERNO $OM/rw/usr/inferno

Nous modifions le script x-window-manager d'OpenMoko, afin qu'Inferno soit lancé au démarrage de X, à la place d'Enlightenment.

rm $OM/rw/usr/bin/x-window-manager
ln -s /usr/bin/inferno_start $OM/rw/usr/bin/x-window-manager

Créez le fichier $OM/rw/usr/bin/inferno_start comme ci-dessous :

#!/bin/sh
/usr/inferno/Linux/arm/bin/emu -g 480x640 -r /usr/inferno wm/wm

Création de l'image d'OpenMoko

Maintenant, nous pouvons créer l'image rootfs.jffs2 à partir du répertoire $OM/rw.

mkfs.jffs2 --pad=0x700000 -o $OM/rootfs.jffs2 -e 0x20000 \
--pagesize=0x100 -n -d $OM/rw

Installation d'OpenMoko sur le Neo FreeRunner

Maintenant, branchez votre Neo FreeRunner à votre ordinateur à l'aide du câble USB, puis démarrer sur la mémoire NOR en appuyant sur le bouton « Aux », que vous maintenez enfoncé tout en appuyant sur le bouton « Power ». Vous avez désormais 30 secondes pour commencer à flasher, avant que le Neo FreeRunner ne s'éteigne.

dfu-util -a rootfs -R -D $OM/rootfs.jffs2
dfu-util -a u-boot -R -D $OM/u-boot-gta02v5-1.3.1+*.bin
dfu-util -a kernel -R -D $OM/uImage-2.6.28-stable+*.bin
dfu-util -a splash -R -D $OM/Om2008.9.splash.gz

Désormais, vous pouvez éteindre votre Neo FreeRunner, puis le démarrer normalement. Le premier démarrage d'OpenMoko peut prendre plusieurs minutes. Inferno se lancera au démarrage à la place de l'environnement graphique habituel.

Inferno en Framebuffer

Sous Linux, le Framebuffer (fbdev) permet un affichage graphique natif, sans avoir recours à l'environnement X11. Inferno ne permet pas directement d'exploiter cette fonctionnalité, mais Alexander Sychev a créé un patch qui permet de lancer Inferno directement dans le Framebuffer.

On commence par télécharger l'archive inferno-fb.tar.bz2 distribuée par Alexander Sychev le 14 Août 2006 sur la liste de diffusion d'Inferno.

tar jxf inferno-fb.tar.bz2
cp -r inferno-fb/emu/Linux-fb /usr/local/inferno/emu
cp inferno-fb/emu/port/devpointer.c /usr/local/inferno/emu/port

Dans le fichier /usr/local/inferno/emu/Linux-fb/emu-fb-386, on ajoute la ligne devtab.

cd /usr/local/inferno/emu/Linux-fb
mk install

On utilisera la commande emu-fb-386 à la place de emu pour lancer Inferno dans le Framebuffer.

Par exemple, pour lancer Acme :

emu-fb-386 -r/usr/local/inferno -g1024x600 -S /dis/acme/acme.dis

Philips IS2630

Pour lancer un terminal sous Inferno, tapez sur le pavé numérique :

##314159265359**

La fenêtre suivante s'affichera :

You have four choices:
1) Choose OutOfBox and reset.
2) Bring up an Inferno Shell.
3) Read Config Data from Flash.
4) Back to normal.

Appuyez sur le bouton « Shell » pour lancer un terminal.