Booting from SD/fr

From Openmoko

Revision as of 19:12, 25 September 2008 by Pierrebrua (Talk | contribs)

Jump to: navigation, search

Contents

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 #1802 et le 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 et 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 "extload" 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:<p> 0x32000000 <filepath>
ext2load mmc 1:<p> 0x32000000 <filepath>

où <p> 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, sont touchés par le bug #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 [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 CD

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 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 sur, 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 8Mbit pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

  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.

Should probably need to change type of first partition to FAT 16 too ?

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

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

Annexes

Démarrage à partir de la SDHC

Démarrage automatique à partir de la SDHC

Désactivation du montage automatique de udev

Remarques sur les paramètres noyau

loglevel

Personal tools

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 #1802 et le 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 et 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 "extload" 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:<p> 0x32000000 <filepath>
ext2load mmc 1:<p> 0x32000000 <filepath>

où <p> 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, sont touchés par le bug #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 [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 CD

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 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 sur, 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 8Mbit pour notre noyau et une autre pour le système de fichiers racine (rootfs) avec la place restante sur la carte.

  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.

Should probably need to change type of first partition to FAT 16 too ?

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

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

Annexes

Démarrage à partir de la SDHC

Démarrage automatique à partir de la SDHC

Désactivation du montage automatique de udev

Remarques sur les paramètres noyau

loglevel