Another world ‽ - seb35’s blog - Mot-clé - Debian2024-02-11T02:34:29+01:00urn:md5:70dee6f1fc053a5e3374878073ac9f13DotclearInstallation de Debian 7 sur DreamPlugurn:md5:98ffaa1e6a35a8e8e75ef58eda14e4be2014-03-06T03:22:00+01:002014-03-10T20:50:56+01:00Seb35GNU/LinuxbugDebianDreamPlug <p>Depuis trois jours, j’installe <a href="https://www.debian.org/News/2013/20130504.fr.html" hreflang="fr">Debian 7</a> sur un <a href="https://en.wikipedia.org/wiki/DreamPlug" hreflang="en">DreamPlug</a>. Il avait auparavant le Debian 6 d’usine fourni par Marvell, mais cela commençait à devenir vieux : sécurité de moins en moins assurée, noyau Linux 2.6, évolution des versions des logiciels, etc. À partir de Debian 7, Debian <a href="http://www.cyrius.com/debian/kirkwood/sheevaplug/" hreflang="en">prend en charge directement les DreamPlugs</a>, ou disons la famille des GuruPlugs. J’ai donc tenté la mise à jour qui n’a pas été de tout repos. Je retrace ci-après les grandes étapes et surtout les problèmes que j’ai rencontrés.</p>
<p>Ce qui suit s’applique au passage du Debian 6 customisé Marvell au Debian 7 naturel en passant par l’installeur Debian naturel, et en écrasant tout le système préexistant. Il est peut-être possible de faire une mise à jour simple avec <code>apt-get dist-upgrade</code>, mais il y aurait peut-être des problèmes du fait qu’il faudrait probablement mettre à jour en même temps U-Boot, le bootloader, en 2012.04 et Debian (j’ai eu des problèmes de par le passé à vouloir mettre à jour U-Boot en gardant Debian 6). Cet article tente de donner (presque) toutes les commandes qui ont été nécessaires à cette installation de Debian 7 sur DreamPlug.</p>
<h3>Préparation</h3>
<p>Je supposerai dans la suite que vous disposez, outre le DreamPlug, d’un autre ordinateur sous GNU/Linux relié au DreamPlug au moyen d’une connexion <abbr lang="en" title="Universal Asynchronous Receiver Transmitter">UART</abbr>/<abbr lang="en" title="Joint Test Action Group">JTAG</abbr> ↔ <abbr lang="en" title="Universal Serial Bus">USB</abbr> (vendue avec le DreamPlug ou à l’unité). Sur cet ordinateur, vous pouvez utiliser l’utilitaire <code>minicom</code> (fourni dans un paquet Debian et probablement disponible ailleurs aussi). Si vous avez un autre plug computer que le DreamPlug, ne suivez pas directement ces instructions et reportez-vous à ces <a href="http://www.cyrius.com/debian/kirkwood/sheevaplug/" hreflang="en">autres documents</a>. Bien sûr, il va sans dire mais ça va mieux en le disant qu’il est très souhaitable de faire une sauvegarde des données existantes du DreamPlug avant l’installation de Debian 7.</p>
<p>Martin Michlmayr a écrit <a href="http://www.cyrius.com/debian/kirkwood/sheevaplug/" hreflang="en">plusieurs documents sur les plugs computers</a>, dont les DreamPlugs qui nous intéressent, et en particulier un guide de <a href="http://www.cyrius.com/debian/kirkwood/sheevaplug/install/" hreflang="en">mise à jour vers Debian 7</a>. La première étape importante est de <a href="http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/" hreflang="en">mettre à jour Das U-Boot</a>, le bootloader des DreamPlugs, vers la version 2011.12-3 ou plus récente. Pour ma part, j’ai utilisé la version <a href="https://packages.debian.org/wheezy/u-boot" hreflang="en">2012.04.01-2 de Debian 7</a> en téléchargeant ce paquet et en utilisant la version spécialement compilée pour le DreamPlug (copier le bon fichier <var>u-book.kwb</var> sur une partition accessible à U-Boot, par exemple sur une carte <abbr lang="en" title="Secure Digital">SD</abbr> ou une clé <abbr lang="en" title="Universal Serial Bus">USB</abbr> formatée en ext2, ext3 ou <abbr lang="en" title="File Allocation Table">FAT</abbr>32 -- de mémoire l’ext4 n’est pas lu par les vieilles versions de U-Boot antérieures à 2010).</p>
<p>Avant de se lancer dans cette mise à jour de U-Boot, j’ai également mis sur une partition accessible à U-Boot l’installeur de Debian 7 récupéré <a href="https://packages.debian.org/wheezy/debian-installer-7.0-netboot-armel" hreflang="en">dans l’archive Debian</a> (copier les <var>uImage</var> et <var>uInitrd</var> spécifiques au DreamPlug ; leur donner des noms spécifiques plutôt que d’écraser les fichiers existants, par exemple <var>uImageD7</var> et <var>uInitrdD7</var>). Noter qu’une bonne pratique est de vérifier les sommes de contrôle des paquets téléchargés lorsque c’est possible pour prévenir toute corruption des paquets ; pour Debian, les sommes <abbr lang="en" title="Message Digest 5">MD5</abbr>, <abbr lang="en" title="Secure Hash Algorithm">SHA</abbr>-1 et <abbr lang="en" title="Secure Hash Algorithm">SHA</abbr>-256 sont indiquées sur la page de téléchargement et peuvent être vérifiées avec <code>md5sum</code>, <code>sha1sum</code> et <code>sha256sum</code>.</p>
<h3>Mise à jour de U-Boot</h3>
<p>Une fois le DreamPlug redémarré et observé au travers de la connexion série <abbr lang="en" title="Universal Asynchronous Receiver Transmitter">UART</abbr>/<abbr lang="en" title="Joint Test Action Group">JTAG</abbr>, il faut arrêter le lancement du système en appuyant sur une touche (par défaut on a trois secondes pour ce faire). Ensuite peuvent être affichées les variables d’environnement U-Boot pour vérification :<br />
<code>Marvell>> print</code><br />
ou<br />
<code>Marvell>> printenv</code></p>
<p>La variable d’environnement la plus importante est <var>bootcmd</var> qui est celle qui sera exécutée lors des lancements automatiques, et <var>bootargs</var> est également importante puisqu’elle contient les arguments qui seront passés au noyau Linux. Il est possible d’exécuter du code inscrit dans d’autres variables d’environnement U-Boot en appellant <code>run NOM-VARIABLE</code> ; cela permet de décomposer les instructions de démarrage en plusieurs sous-sections.</p>
<p>Pour lancer la mise à jour de U-Boot, il faut commencer par lancer le sous-système <abbr lang="en" title="Universal Serial Bus">USB</abbr> de U-Boot :<br />
<code>Marvell>> usb start</code><br />
puis chercher la partition sur laquelle vous avez mis les fichiers <var>u-boot.kwb</var> et les <var>uImageD7</var>/<var>uInitrdD7</var> de l’installeur Debian. Si vous ne savez pas, vous pouvez essayer successivement les numéros de 0 à 5 (?) dans les commandes suivantes jusqu’à trouver les fichiers :<br />
<code>Marvell>> ext2ls usb 0</code><br />
(Si la partition est en ext2 ou ext3 ; si la partition est en <abbr lang="en" title="File Allocation Table">FAT</abbr>32, ce sera <code>fatls</code> et <code>fatload</code> dans la suite.)</p>
<p>Pour mettre à jour U-Boot, il faut exécuter la séquence qui suit. Bien sûr, le <code>usb NUMÉRO</code> est issu de l’étape précédente. Attention, en cas d’interruption au milieu, il est possible que le DreamPlug ne redémarre pas, assurez-vous qu’il n’y a pas d’orage, que le courant ne sera pas coupé, etc.<br />
<code>Marvell>> ext2load usb NUMÉRO 0x0800000 u-boot.kwb<br />
Marvell>> sf probe 0<br />
Marvell>> sf erase 0x0 0x60000<br />
Marvell>> sf write 0x0800000 0x0 0x60000</code></p>
<p>Enfin, redémarrez le DreamPlug et arrêtez à nouveau le démarrage.<br />
<code>Marvell>> reset</code></p>
<h3>Installation de Debian 7</h3>
<p>Si vous avez bien mis les deux fichiers d’installation de Debian 7 <var>uImageD7</var> et <var>uInitrdD7</var> sur une partition accessible à U-Boot, chargez ces deux fichiers en mémoire (sinon il est encore temps de les mettre sur une clé <abbr lang="en" title="Universal Serial Bus">USB</abbr> à partir d’un autre ordinateur).<br />
<code>Marvell>> usb start<br />
Marvell>> ext2load usb NUMÉRO 0x00800000 uImageD7<br />
Marvell>> ext2load usb NUMÉRO 0x01100000 uInitrdD7<br />
Marvell>> setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most<br />
Marvell>> bootm 0x00800000 0x01100000</code></p>
<p>Ensuite, l’installeur Debian va se lancer, vous poser des questions pendant un petit quart d’heure et prendra ensuite quelques heures pour installer le système Debian 7. Je n’ai pas eu de problèmes lors de cette étape mis à part un avertissement à la fin de l’installation prévenant que le bootloader ne pouvait pas être mis à jour, mais cela peut être ignoré puisqu’on a fait la mise à jour à l’étape précédente. J’ai ensuite redémarré le système, ce qui n’était peut-être pas la meilleure idée : s’il est proposé de lancer directement le système à la suite, sautez sur l’occasion et passez au dernier titre ci-après pour compiler un noyau « sans NAND_ORION » – j’expliquerai ce que c’est.</p>
<h3>Problème d’identification de la machine par Linux : machid</h3>
<p>Normalement, l’installeur Debian a déposé dans le dossier <var>/boot</var> du système le noyau (3.2.0-4-kirkwood pour moi) et le système Debian 7 devrait normalement se charger avec la séquence suivante de U-Boot :<br />
<code>Marvell>> usb start<br />
Marvell>> ext2load usb NUMÉRO 0x00800000 uImage<br />
Marvell>> ext2load usb NUMÉRO 0x01100000 uInitrd<br />
Marvell>> setenv bootargs 'console=ttyS0,115200 rw root=/dev/sda1 rootdelay=10 panic=10'<br />
Marvell>> bootm 0x00800000 0x01100000</code><br />
Notez que le <var>/dev/sda1</var> est peut-être à remplacer si votre système racine a été installé sur une autre partition, et que les <var>uImage</var> et <var>uInitrd</var> ont peut-être d’autres noms.<br />
Notez aussi que vous pouvez automatiser le processus de lancement en fixant une fois pour toutes la variable d’environnement <var>bootargs</var> et surtout <var>bootcmd</var>, cette dernière avec :<br />
<code>Marvell>> setenv bootargs 'printenv; usb start; ext2load usb NUMÉRO 0x00800000 uImage; ext2load usb NUMÉRO 0x01100000 uInitrd; bootm 0x00800000 0x01100000'<br />
Marvell>> saveenv</code></p>
<p>En lançant ce noyau Linux Debian 7, celui-ci (le noyau Linux) répond dès le début qu’il ne reconnait pas le matériel :
</p>
<pre style="border:solid black 1px; padding:5px; display:inline-block; margin-left:5px;">Error: unrecognized/unsupported machine ID (r1 = 0x00000dde).
Available machine support:
ID (hex) NAME
00000690 Marvell DB-88F6281-BP Development Board
00000691 Marvell RD-88F6192-NAS Development Board
00000692 Marvell RD-88F6281 Reference Board
0000078c Marvell 88F6281 GTW GE Board
00000a76 Marvell eSATA SheevaPlug Reference Board
00000831 Marvell SheevaPlug Reference Board
00000a63 Marvell GuruPlug Reference Board
[...]
00000b1e HP t5325 Thin Client
ffffffff Marvell Kirkwood (Flattened Device Tree)
Please check your kernel config and/or bootloader.
</pre>
<p>Puisque j’ai recherché les causes de ceci, je vais vous en faire profiter :-) Linux s’attend à reçevoir une indication sur le type de matériel sur lequel il se trouve ; dans le cas des processeurs ARM, ces numéros sont référencés dans le fichier <a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/tools/mach-types" hreflang="en">arch/arm/tools/mach-types</a> du noyau Linux. Dans notre cas, le DreamPlug a le numéro hexadécimal 0xdde (=3550) (ne cherchez pas dans la liste de Linux, il n’y est pas :/ il est sur le <a href="http://www.arm.linux.org.uk/developer/machines/list.php?id=3550" hreflang="en">site officiel de ARM</a>). La version U-Boot de Debian indique donc le bon identifiant de matériel, mais Linux ne le connait pas.</p>
<p>L’ancienne version de U-Boot (Marvell customisée) donnait à Linux l’identifiant hexadécimal 0xa63 (=2659), le GuruPlug étant très proche du DreamPlug. C’est donc ce que nous allons faire. Pour cela, il faut configurer la variable d’environnement U-Boot <var>machid</var> à 0xa63 :<br />
<code>Marvell>> setenv machid a63<br />
Marvell>> saveenv</code><br />
Sur les forums, il est évoqué aussi la variable arcNumber mais il semble que cela était pour les (très) vieilles versions de U-Boot (d’ailleurs arcNumber n’apparaît pas dans les sources de U-Boot, contrairement à machid). L’option Flattened Device Tree est censée être une unification des configurations matérielles pour le futur, mais elle n’a pas fonctionné pour moi (le noyau ne se lance pas) et l’expérience est identique pour <a href="http://www.madore.org/~david/linux/dreamplug.html" hreflang="en">David Madore</a> (que je remercie vraiment au passage car c’est lui qui m’a débloqué grâce à cette page dans les deux gros problèmes que j’ai rencontrés, avec quelques autres recherches sur le Web pour les instructions précises).</p>
<p>Une fois ces commandes exécutées, le démarrage de Linux se lance bien. Du moins dans mon cas pendant les 15 secondes suivantes.</p>
<h3>Arrêt du chargement du noyau lors de l’initialisation du NAND Orion, inexistant sur DreamPlug</h3>
<p>Le chargement du noyau Debian (3.2.0-4-kirkwood) s’arrêtait systématiquement après "console [ttyS0] enabled" dans la fonction "nand_read_byte". Plus exactement, c’est le watchdog qui retourne ce message toutes les 22 secondes. Pour être plus précis, c’est avec la fonction "orion_nand_probe" que les problèmes se posent. Voici mon log d’erreur exact :
</p>
<pre style="border:solid black 1px; padding:5px; display:inline-block; margin-left:5px;">[ 11.167148] console [ttyS0] enabled
[ 38.208674] BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
[ 38.214621] Modules linked in:
[ 38.217690]
[ 38.219183] Pid: 1, comm: swapper
[ 38.223641] CPU: 0 Not tainted (3.2.0-4-kirkwood #1 Debian 3.2.54-2)
[ 38.230380] PC is at nand_read_byte+0xc/0x10
[ 38.234673] LR is at nand_command+0x184/0x1c4
[ 38.239051] pc : [<c0207e6c>] lr : [<c020ace0>] psr: 60000013
[ 38.239056] sp : df82be80 ip : c020ab5c fp : 00000000
[ 38.250593] r10: 00000000 r9 : 00000000 r8 : ffffffff
[ 38.255844] r7 : ffffffff r6 : df8c4800 r5 : 000000ff r4 : df8c4a20
[ 38.262400] r3 : e08aa000 r2 : 00000081 r1 : ffffffff r0 : 00000000
[ 38.268958] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 38.276300] Control: 0005397f Table: 00004000 DAC: 00000017
[ 38.282093] [<c00137c4>] (unwind_backtrace+0x0/0xe0) from [<c0065068>] (watchdog_timer_fn+0xe0/0x134)
[ 38.291361] [<c0065068>] (watchdog_timer_fn+0xe0/0x134) from [<c0043c94>] (__run_hrtimer+0x118/0x1ec)
[ 38.300628] [<c0043c94>] (__run_hrtimer+0x118/0x1ec) from [<c00444bc>] (hrtimer_interrupt+0xf4/0x23c)
[ 38.309903] [<c00444bc>] (hrtimer_interrupt+0xf4/0x23c) from [<c001a3a8>] (orion_timer_interrupt+0x20/0x30)
[ 38.319701] [<c001a3a8>] (orion_timer_interrupt+0x20/0x30) from [<c0065958>] (handle_irq_event_percpu+0x7c/0x23c)
[ 38.330015] [<c0065958>] (handle_irq_event_percpu+0x7c/0x23c) from [<c0065b40>] (handle_irq_event+0x28/0x38)
[ 38.339895] [<c0065b40>] (handle_irq_event+0x28/0x38) from [<c0067d04>] (handle_level_irq+0xac/0xbc)
[ 38.349077] [<c0067d04>] (handle_level_irq+0xac/0xbc) from [<c0065328>] (generic_handle_irq+0x28/0x44)
[ 38.358438] [<c0065328>] (generic_handle_irq+0x28/0x44) from [<c000ee14>] (handle_IRQ+0x60/0x84)
[ 38.367266] [<c000ee14>] (handle_IRQ+0x60/0x84) from [<c000db34>] (__irq_svc+0x34/0x78)
[ 38.375314] [<c000db34>] (__irq_svc+0x34/0x78) from [<c0207e6c>] (nand_read_byte+0xc/0x10)
[ 38.383627] [<c0207e6c>] (nand_read_byte+0xc/0x10) from [<c020ace0>] (nand_command+0x184/0x1c4)
[ 38.392372] [<c020ace0>] (nand_command+0x184/0x1c4) from [<c020a150>] (nand_scan_ident+0x16c/0xa94)
[ 38.401466] [<c020a150>] (nand_scan_ident+0x16c/0xa94) from [<c020be9c>] (nand_scan+0x48/0x68)
[ 38.410128] [<c020be9c>] (nand_scan+0x48/0x68) from [<c040048c>] (orion_nand_probe+0x120/0x1b0)
[ 38.418876] [<c040048c>] (orion_nand_probe+0x120/0x1b0) from [<c01ef9e0>] (platform_drv_probe+0x14/0x18)
[ 38.428403] [<c01ef9e0>] (platform_drv_probe+0x14/0x18) from [<c01eeb10>] (driver_probe_device+0xd4/0x198)
[ 38.438107] [<c01eeb10>] (driver_probe_device+0xd4/0x198) from [<c01eec34>] (__driver_attach+0x60/0x84)
[ 38.447550] [<c01eec34>] (__driver_attach+0x60/0x84) from [<c01ed798>] (bus_for_each_dev+0x50/0x84)
[ 38.456645] [<c01ed798>] (bus_for_each_dev+0x50/0x84) from [<c01ee40c>] (bus_add_driver+0x9c/0x218)
[ 38.465740] [<c01ee40c>] (bus_add_driver+0x9c/0x218) from [<c01eeedc>] (driver_register+0xa0/0x12c)
[ 38.474836] [<c01eeedc>] (driver_register+0xa0/0x12c) from [<c01efbb4>] (platform_driver_probe+0x18/0x68)
[ 38.484454] [<c01efbb4>] (platform_driver_probe+0x18/0x68) from [<c00085a4>] (do_one_initcall+0x90/0x168)
[ 38.494079] [<c00085a4>] (do_one_initcall+0x90/0x168) from [<c03e882c>] (kernel_init+0xbc/0x164)
[ 38.502917] [<c03e882c>] (kernel_init+0xbc/0x164) from [<c000ee98>] (kernel_thread_exit+0x0/0x8)
</pre>
<p>Après recherches, et en particulier la page de <a href="http://www.madore.org/~david/linux/dreamplug.html" hreflang="en">David Madore</a>, une <a href="http://forums.fedoraforum.org/showthread.php?t=284430" hreflang="en">page de forum de Fedora 17</a> et la discussion liée <a href="https://lists.fedoraproject.org/pipermail/arm/2012-October/004139.html" hreflang="en">sur la liste ARM de Fedora</a> et probablement <a href="https://wiki.debian.org/DreamPlugTesting" hreflang="en">ici aussi</a>, il apparaît que le DreamPlug n’a pas le périphérique NAND Orion (contrairement à d’autres plug computers de la famille GuruPlug) mais le noyau essaye quand même de lire ce périphérique. Plus précisément, ce périphérique est géré par le module <var>orion_nand</var> du noyau. La solution évoquée pour Fedora et qui fonctionnait était de blacklister ce module. Pour Debian 7, cela ne fonctionnait pas d’après mes tests, d’autant que le module <var>orion_nand</var> chez Debian est un module intégré (built-in), impossible à désactiver donc. Pour Debian, ce problème correspond au <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717470" hreflang="en">bug 717470</a>, rapporté pour les noyaux à partir de 3.9.x, et j’ai rencontré le problème également avec le noyau 2.6.x de Debian 7.</p>
<p>D’après <a href="http://www.madore.org/~david/linux/dreamplug.html" hreflang="en">David Madore</a>, il faut compiler un noyau sans la directive de compilation <var>CONFIG_MTD_NAND_ORION</var>, et il apparaît que cela fonctionne effectivement pour le noyau Linux 3.2.x de Debian 7. Je détaille ci-après le mode opératoire pour compiler ce noyau fonctionnel sur DreamPlug. Je me suis permis de ne pas changer le nom du noyau (pas de « +nonand » ajouté au nom du noyau) étant donné que ce noyau est presque pareil que celui de Debian 7 à une directive de compilation (et donc réutiliser tous les autres modules) près et surtout que ça ne voulait pas compiler lorsque je changeai <var>abi.abiname</var> dans <var>debian/config/defines</var> (exception Python lors de l’exécution de <code>make -f debian/rules source</code>). À part ça, j’ai suivi <a href="https://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage" hreflang="en">HowToRebuildAnOfficialDebianKernelPackage</a> sur le wiki Debian. (note : c’est la première fois que je compilai un noyau, il y a sûrement matière à mieux compiler ce noyau-ci.)</p>
<p>Pour éviter d’avoir à faire du cross-build depuis une autre architecture, le plus simple (qui a fonctionné pour moi) est de charger le système Debian 7 avec le noyau 2.6 de Marvell (<a href="https://code.google.com/p/dreamplug/downloads/list">téléchargeable ici</a>). Redémarrer le DreamPlug et exécuter dans U-Boot :<br />
<code>Marvell>> usb start; ext2load usb NUMÉRO 0x00800000 uImage_dreamplug_v10_Aug-28-2012; bootm 0x00800000</code></p>
<p>Une fois connecté en root à Debian, exécutez :<br />
<code>$ apt-get install fakeroot build-essential devscripts quilt u-boot-tools<br />
$ apt-get build-dep linux<br />
$ apt-get source linux<br />
$ cd linux-*<br />
$ make -f debian/rules source<br />
$ fakeroot make -f debian/rules.gen setup_armel_none_kirkwood<br />
$ cd debian/build/build_armel_none_kirkwood<br />
$ make menuconfig</code><br />
Dans le menu de configuration du noyau qui apparaît, allez dans <span lang="en">"Device Drivers" > "Memory Technology Device (MTD) support" > "NAND Device Support" > "NAND Flash support for Marvell Orion SoC"</span> et désactivez cette dernière option.<br />
<code>$ cd ../../..<br />
$ fakeroot make -f debian/rules.gen binary-arch_armel_none_kirkwood binary-indep DEBIAN_KERNEL_JOBS=1</code><br />
Après quelques heures (et j’ai arrêté lors de la compilation des pages de manuel vu qu’elles étaient déjà présentes, et ça m’a pris entre 1 et 2 Gio), le noyau devient disponible dans le répertoire <var>debian/linux-image-3.2.0-4-kirkwood/boot</var> (les fichiers <var>vmlinuz-3.2.0-4-kirkwood</var>, <var>System.map-3.2.0-4-kirkwood</var> et <var>config-3.2.0-4-kirkwood</var>).<br />
<code>$ cd debian/linux-image-3.2.0-4-kirkwood</code></p>
<p>À partir de là, il faut créer le fichier initrd.img pour la version 3.2.0-4-kirkwood si vous ne l’avez pas déjà.<br />
<code>$ update-initramfs -u -k 3.2.0-4-kirkwood</code></p>
<p>Et enfin transformer les fichiers vmlinuz et initrd.img au format de fichier de U-Boot :<br />
<code>$ mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "Linux kernel 3.2.0-4-kirkwood" -d vmlinuz-3.2.0-4-kirkwood /boot/uImage-3.2.0-4+nonand-kirkwood<br />
$ mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000 -n "Linux ramdisk 3.2.0-4-kirkwood" -d /boot/initrd.img-3.2.0-4-kirkwood /boot/uInitrd-3.2.0-4+nonand-kirkwood</code></p>
<p>Maintenant, pour charger ces noyau et ramdisk, il peut être pratique d’utiliser des liens symboliques pour les fichiers <var>/boot/uImage</var> et <var>/boot/uInitrd</var> (dans l’étape précédente, on a demandé à U-Boot de charger ces fichiers spécifiquement) (ça ne marche pas pour les partitions <abbr lang="en" title="File Allocation Table">FAT</abbr>32, il renommer explicitement les fichiers).<br />
<code>$ cd /boot<br />
$ mv uImage uImage.old<br />
$ mv uInitrd uInitrd.old<br />
$ ln -s uImage-3.2.0-4+nonand-kirkwood uImage<br />
$ ln -s uInitrd-3.2.0-4+nonand-kirkwood uInitrd</code></p>
<p>Maintenant, redémarrez le DreamPlug. Le système Debian 7 avec le noyau 3.2.x devrait se charger correctement (ça a été mon cas du moins). En cas de mise à jour du noyau, il faudrait également recompiler un noyau sans la directive de compilation <var>CONFIG_MTD_NAND_ORION</var>.</p>
<p>Je vais évoquer cette solution dans le <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717470" hreflang="en">bug 717470</a>, mais je ne suis pas sûr de la résolution propre à effectuer, et cela rejoint les interrogations sur la liste de Fedora : comment faire en sorte de charger ce module <var>orion_nand</var> pour certains plug computers mais pas pour les DreamPlugs ? Il pourrait être utilisé la variable d’environnement <var>machid</var> donnée par U-Boot (0xdde = DreamPlug) mais Linux ne reconnait pas cette valeur et oblige donc à utiliser encore 0xa63 (= GuruPlug), ou alors utiliser 0xffffffff (= Marvell Kirkwood (Flattened Device Tree)) mais cela n’était pas encore fonctionnel. Si vous avez des idées ou plus d’expérience que moi, n’hésitez pas à compléter sur ce bug.</p>//blog.seb35.fr/post/2014/03/Installation-de-Debian-7-sur-DreamPlug#comment-form//blog.seb35.fr/feed/atom/comments/6