Outils pour utilisateurs

Outils du site


tuto_a20-olinuxino-micro_bidouillages_autour_de_la_a20-linuxino

====== Bidouillages autour de la A20-LinuXino ====== ---- ===== Introduction ===== Article en cours de redaction. Bonne lecture ! ---- ===== Mise a l'heure ===== Nous avons vu dans le tutoriel précédent que le package //ntpdate// etait installé. Il suffit donc a présent de mettre effectivement a l'heure notre carte. Cela peut se faire à la main simplement par l'appel de //ntpdate// : <code bash> $ sudo ntpdate ntp.ubuntu.com </code> Une mise a l'heure journaliere peu etre programmé en créant un script qui sera appellé une fois par jour par le ///etc/cron.daily// car une horloge derive toujours un petit peu (drift). <code bash> $ sudo su - $ echo "#!/bin/sh" > /etc/cron.daily/ntpdate $ echo "ntpdate ntp.ubuntu.com" >> /etc/cron.daily/ntpdate $ chmod 755 /etc/cron.daily/ntpdate $ exit </code> Dans le doute de la presence ou pas d'une RTC sur la carte, et pour qu'elle soit mise a l'heure a chaque demarrage il suffit d'appeller le ///etc/cron.daily/ntpdate// depuis le ///etc/rc.local//. <file bash /etc/rc.local> #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. # Generate the SSH keys if non-existent test -f /etc/ssh/ssh_host_dsa_key || dpkg-reconfigure openssh-server /etc/cron.daily/ntpdate exit 0 </file> Et afin de completer le tableau, si on regarde bien la sortie de la commande date, on remarque que nous avons deux heures de retard par rapport a l'heure qu'il est dans notre beau pays, qu'est la France. <code bash> % date Sat Jul 19 17:37:39 UTC 2014 </code> D'apres //date//, nous sommes en heure UTC (Universal Time Clock). Changeons tout ca ! <code bash> $ sudo rm -rf /etc/localtime </code> Bah ouais rm, carrement. Z'inquietez pas, on va retablir les choses : <code bash> $ sudo ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime $ ls -al /etc/timezone lrwxrwxrwx 1 root root 32 Jul 19 17:51 /etc/localtime -> /usr/share/zoneinfo/Europe/Paris $ date Sat Jul 19 20:19:33 CEST 2014 </code> une autre moyen de faire est via le //dpkg-reconfigure// : <code bash> $ sudo dpkg-reconfigure tzadata </code> Puis selectionner la //timezone// desirée (Europe/Paris). Et voila, un systeme a l'heure francaise. Alors oui, forcement vous allez me dire, mais ca n'a rien a voir avec une carte A20-OLinuXino ou meme une Raspbery Pi ; c'est de l'administration/configuration systeme. Bah oui, mais quand on installe une Debian ou une Ubuntu, on selectionne juste Paris, sans se douter de ce qui est fait derriere. bah le voila le mecanisme d'horloge ;-) Tout ceci peut faire, et fera, partie des customisations apportées lors de la génération de l'image (cf tutoriel "[[http://fablab-robert-houdin.org/wiki/doku.php?id=tuto_a20-olinuxino-micro_generation_d_un_rootfs_ubuntu_14.04_minimal_a_l_aide_de_live-build|[TUTO] [A20-OLinuXino-MICRO] Generation d'un "rootfs" Ubuntu 14.04 Minimal à l'aide de live-build]]"). ---- ===== Jouons avec les GPIOs ===== Comme indiqué [[https://www.olimex.com/wiki/A20-OLinuXino-MICRO#GPIO_under_Linux|ici]], il convient avant toute chose de réaliser un //export// des GPIOs. Ca a l'air d'etre une operation visant a dire au noyau, que l'on souhaite pouvoir acceder aux GPIOs. Il est possible d'//exporter// une GPIO bien specifique : <code bash> # echo XX > /sys/class/gpio/export </code> Apres un reboot, aucune GPIOn'est exportée : <code bash> $ sudo su - % cd /sys/class/gpio % ll total 0 --w------- 1 root root 4096 Jul 20 10:21 export lrwxrwxrwx 1 root root 0 Jul 20 10:21 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1/ --w------- 1 root root 4096 Jul 20 10:21 unexport </code> Dans notre cas, on va toutes les exporter ; il semble y en avoir 76 en tout. <code> % for i in `seq 1 1 76`; do echo $i > /sys/class/gpio/export; done </code> Il va de soit que si l'on souhaite que les GPIOs soient exportées dès le demarrage de la carte, il convient d'ajouter la ligne precedente dans le ///etc/rc.local//. La LED verte presente sur la carte et labelisée LED1 sur le silkscreen est branchée sur la broche C6 du SoC. Il s'agit de la broche 2 du port H (PH2). Au demarrage, le noyau l'alume pour dire qu'il tourne. Nous pouvons cependant jouer avec : <code bash> % cd /sys/class/gpio/gpio47_ph2 % echo out > direction % echo 0 > value % echo 1 > value </code> Bien sur, on peut aller plus loin. et on le fera, notamment en Python et en C ; surement dans un prochain tuto ;-) ---- ===== Console série ===== J'ai été longtemps sans pouvoir savoir si ma carte tournait ou pas. La seule indication que j'avais etait savoir si la LED verte est allumée "vert fixe" alors c'est OK ; si c'est "vert clignotant", il y a un probleme. Par defaut, le noyau est configuré pour envoyer ses traces vers le port serie par defaut (///dev/ttyS0//). On part alors de "console série". C'est assez employé sur les serveurs, ou il n'y a pas d'ecran. Et meme parfois sur un pool de serveurs, avec des multiplexeurs de connexion serie... C'est un moyen de garder un oeil sur le serveur et de s'y logger si besoin. J'ai donc fait l'acquisition d'un convertisseur USB-serie. J'en avais deja un, bien sur, comme tout bon bidouilleur qui se respecte ; le probleme c'est qu'il convertit en signaux un peu trop poilus pour la carte A20-OLinuXino qui s'attend a du RS232, certes, mais en signaux 0-3.3V. Des convertisseurs, il y en a plein et a tous les prix. Parmis le choix, il faut faire le tri. Celui pour lequel j'ai opté est fait par [[https://www.sparkfun.com/|Sparkfun]] : [[https://www.sparkfun.com/products/9716|FTDI Basic Breakout - 5V ]] ; je l'ai pris sur [[http://www.evola.fr/|evola]] : [[http://www.evola.fr/convertisseur-usb-uart-ftdi-p-174.html]]. La chose principale à laquelle il faut faire attention, c'est au chip autour duquel le convertisseur est batit. A ma connaissance, il y en a deux qui valent le coup : le FTDI FT232RL, et le CP2102. Ces deux chips sont bien supportés et reconnus par Linux. L'autre point auquel il faut porter attention, est le niveau des signaux en sortie. Pour ma part, j'ai pris 5V. Cependant, il est precisé qu'il y a une piste a couper et un jumper à souder pour le passer en 3.3V. Chose que je me suis empressé de faire. Il ne restait plus qu'à connecter le tout, GND sur GND, Tx sur Rx et Rx sur Tx. Un petit coup de screen pour voir les messages du moyau : <code bash> $ screen /dev/ttyUSB0 115200 </code> Et le tour est joué. Je suis a présent en mesure de voir la sortie des messages du noyau. Tout ca c'est bien joli... Sauf que l'autre fois, alors que je mettais au point l'image //rootfs// Ubuntu (cf précédent tuto), j'avais oublié de mettre le demarrage de l'interface eth0 en automatique. Je me retrouvais pantois devant ma console serie car impossible de se logger dessus. Beh oui ma bonne dame ! C'est pas parceque on voit tout plein de message qu'on peut en envoyer ; en fait si, on peut en envoyer. Mais si personne n'ecoute, ca sert a rien. Pour pouvoir se logger, il faut donc mettre a l'ecoute un gestionnaire de session. c'est quelque chose qui est réalisé par le script ///etc/init/ttyS0.conf// : <file bash /etc/init/ttyS0.conf> # ttyS0 - getty # # This service maintains a getty on ttyS0 from the point the system is # started until it is shut down again. start on stopped rc or RUNLEVEL=[12345] stop on runlevel [!12345] respawn exec /sbin/getty -L 115200 ttyS0 vt102 </file> Il sera exécuté au demarrage et permettra de se logger sur le systeme via la console serie. ---- ===== Remarques, Propositions d'améliorations, Questions ===== Vous pouvez poster vos remarques, propositions d’amélioration, et questions sur le forum, dans la discussion prévue a cet effet : [[http://fablab-robert-houdin.org/fablab/phpBB-3.0.11-fr/phpBB3/viewtopic.php?f=5&t=46]] ----

tuto_a20-olinuxino-micro_bidouillages_autour_de_la_a20-linuxino.txt · Dernière modification: 2014/07/20 20:44 par spelle