Un article dans lequel je vais essayer de décrire/documenter comment j'ai installé une debian à côté de l'OS de démo sur la carte sama5d35 gagnée au Fosdem 2013 (merci encore ! )
L'idée était de ne pas écraser le système de démo et d'essayer d'utiliser le système le plus "normal" possible. C'est à dire le moins de patch noyau et une debian ARM.
Je me suis inspiré de ce [wiki](http://www.eewiki.net/display/linuxonarm/SAMA5D3) pour gcc et u-boot. J'ai aussi pris les patch u-boot en suivant les liens donnés sur le wiki.
Une fois le compilateur installé, on exporte la variable `CC` qui contient le chemin et le préfix de l'architecture et en informant make que l'on utilise un autre compilateur :
Une fois tous les éléments compilés, il faut copier les fichiers dans `/boot`.
Vu que pour l'instant, je n'ai pas réussi à compiler de noyau mainline fonctionnel, je copie les fichiers à côté de ceux du 3.6.9-at91 qui fonctionnent.
Attention, le deuxième slot, celui pour µSD, n'est pas parcouru au démarrage, contrairement à ce qui est listé dans le diagramme de la [datasheet](Atmel_11121_32-bit-Cortex-A5-Microcontroller_SAMA5D3_Datasheet.pdf).
Par contre, dans la [documentation utilisateur](Atmel_11180_32-bit-Cortex-A5-Microcontroller_SAMA5D3-Series-EK_User-Guide.pdf) la description du processus d'amorçage ne mentionne que le premier slot, celui pour carte SD.
Ça m'a pris une bonne semaine pour m'apercevoir de ça... Je pensais que mes compilations étaient mauvaises et/ou que j'allais absolument devoir flasher la mémoire NAND de la carte avec SAM-BA.
Mais finalement, avec u-boot contenu dans un fichier `u-boot.bin` et un noyau sur une partition FAT(16 ou 32) de la carte SD, on peut démarrer son propre système sans avoir à flasher le système de démo de la carte.
bootcmd=if mmc rescan; then echo SD/MMC found on device;if run loadbootenv; then echo Loaded environment from ${bootenv};run importbootenv;fi;if run loadzimage; then run loaddtb;run mmcboot;fi;fi;
On voit donc que la plupart des noms de fichiers sont paramétrables, on peut donc assez facilement avoir une configuration avec un noyau stable et un autre de test.
- debian wheezy armhf installée avec `debootstrap --arch=armhf`, puis en ajoutant `--stage2`une fois la carte sd montée depuis le système ARM existant dans la NAND
TODO: retrouver les commande initiales pour lancer debootstrap
J'utilise la carte comme routeur pour ma connexion internet.
Je l'utilise aussi pour quelques autres services liés au réseau : serveur DHCP, Annonces RA, serveur DNS (comme serveur faisant autorité ainsi que comme resolver/cache pour le lan), pare-feu et serveur NTP pour le lan.
Le système semble parfaitement stable et n'a pour l'instant jamais planté ni affiché de message d'erreur particulier dans les logs kernel.
J'ai du mal à utiliser toute ma connexion avec la carte, parce que le trafic réseau provoque énormément d'IRQ et celà occupe tout le processeur. J'essaie d'investiguer pour savoir si on ne pourrait pas faire mieux avec les noyaux plus récents.
Sur le dernier test, en HTTP, on remarque qu'il semble y avoir autant d'interruptions que de paquets reçus/envoyés. Le mécanisme NAPI qui permet de stocker les interruptions pour passer plusieurs paquets d'un seul coup au noyau ne semble pas activé/disponible. Ce qui serai plutôt une bonne nouvelle et permettrai d'augmenter les performances à l'avenir.
