Tag Archives: Cubieboard2

Noyau Linux 4.0 (4.1 le 25 juin) sur Allwinner A20/Cubieboard2

Grâce aux travaux de développement électronique et logiciel, aux efforts de la communauté Linux-sunxi pour l’amélioration et l’intégration des pilotes dans le tronc principal des sources de Linux et au travail d’intégration des communauté ArchLinux et ArchLinuxARM, la Cubieboard2 (basée sur le SoC AllWinner A20) avec la distribution ArchlinuxARM utilise depuis cette nuit le noyau 4.0 par défaut. Auparavant, elle utilisait une branche 3.x du noyau en retard par rapport aux avancées de la branche principale.

* Linux XXX 4.0.5-2-ARCH #1 SMP Fri Jun 12 20:03:44 MDT 2015 armv7l GNU/Linux

Grâce à cela :
* Une grande partie des flash NAND peuvent être utilisée pour le système.
* La gestion de la fréquence CPU dynamique est bien gérée maintenant.
* La plupart des pilotes sont intégrées et à priori très stable.

Mise à jour du 25 juin, 11 jours après le 4.0 : Mise à jour vers noyau linux 4.1 effectuée ce soir
* Linux XXX 4.1.0-1-ARCH #1 SMP Tue Jun 23 23:24:14 MDT 2015 armv7l GNU/Linux

Archlinux ARM sur Cubieboard2

La distribution ArchlinuxARM est une distribution pour ARM dérivé de l’excellent Archilinux, elle même dérivée de je ne sais plus quoi. Elle a été conçu pour s’adapter avec une relativement bonne précision au matériel utilisé. (dans le cas d’ARM un noyau/firmware par carte et 3 versions des paquets pour ARMv5, ARMv6h (h pour hardfloat) et ARMv7h (hardfloat). Ce qui en fait, à ma connaissance, la seule distribution aussi bien adaptée. Pour une installation rapide pour un ordinateur de bureau, la démarche est un peu plus fastidieuse, à moins d’y apporter ces propres scripts, où d’utiliser, des distributions facilitant l’installation, comme Antergos sur plate-forme x86.

Entre le début de la rédaction de cet article (le 17 juin) et aujourd’hui, j’ai beaucoup progressé sur la compréhension du fonctionnement de la NAND. J’ai donc :

  • Réussi à créer une NAND qui fonctionne à partir d’Archlinux ARM, en bidouillant avec plusieurs images.
  • Découvert qu’Archlinux est réellement une distribution géniale, d’autant plus en version ARM, je publierais probablement prochainement une image SD pour l’installer automatiquement sur la NAND, avec le noyau 3.4.90, très stable et 3 Go de libre sur la NAND :). (je vais essayer de tenter un noyau 3.16 prochainement)

Continue reading

Image NAND stable de Debian pour Cubieboard2

Lors de mes premiers tests systèmes de la Cubieboard2 aux alentours d’octobre 2014, l’accès à la mémoire flash NAND intégrée ne fonctionnait pas avec le noyau et pilote à sources ouvertes. C’est corrigé depuis au moins la version 3.4.79 du noyau adapté par la communauté Linux-Sunxi. D’avantage d’optimisation importantes vont apparaître durant cet été (utilisation des DMA pour les transferts entres composants, utilisation de l’unité crypto/CRC pour le chiffrement, etc…).

Après avoir testé différentes images NAND, Cubian, lubuntu-desktop, etc… j’ai enfin trouvé l’image NAND d’un système stable, appelée Debieez cb2, basé sur Debian Wheezy (8.5, la dernière stable).
Continue reading

Méthodes de contrôle à distance d’une SBC (exemple avec la Cubieboard)

* Port série
* SSH
* SSH + X11
* XDMCP
* Protocole X
Port série/UART/RS232

Si il n’y a pas de réseau, dans la séquence U-boot, ou pour d’autres raisons. Connecté via (remplacer le x par le numéro correspondant) :
* Un câble série entre l’ordinateur de contrôle et la carte contrôlée (CubieBoard ici) et utiliser le port /dev/ttySx.
* Un câble/adaptateur USB<=> série standard (comme compatible PL2303, CH340, FT2232C…) et utiliser le port /dev/ttyUSBx.

Branchement du port série sur la Cubieboard

Branchement du port série sur la Cubieboard

Voir aussi cet article, section Premiers tests de démarrage

Quelques commandes possibles (en terminal) pour se connecter en série. Les arguments des exemples sont avec câble USB-série (/dev/ttyUSB0), pour un câble série utiliser à la place /dev/ttyS0 (ou 1 pour le second, etc)

Paquet              commande
busybox             busybox microcom -t 5000 -s 115200 /dev/ttyUSB0
minicom             minicom -D /dev/ttyUSB0 
gtkterm-git (AUR)   gtkterm -s 115200 -p /dev/ttyUSB0
python-pyserial     python -m serial.tools.miniterm /dev/ttyUSB0 115200
screen              screen /dev/ttyUSB0 115200
tinyserial          com /dev/ttyUSB0 115200
picocom             picocom --baud 115200 /dev/ttyUSB0

Il est possible de changer les paramètre d’un ttyS/ttyUSB à l’aide de la commande stty (voir man stty)

stty -F /dev/ttyUSB0 cs8

Les commandes suivantes ont une interface graphique, ici nom du paquet Arch Linux (AUR)
* gtkterm-git (AUR)
* easyterm (AUR)

SSH

ssh utilisateur@cubieboard

SSH + affichage d’application X via tunnel SSH

Il faut d’abord vérifier que le transfert X11 via SSH est autorisé. Pour cela, il faut vérifier que dans /etc/ssh/sshd_config, vous avez bien :

X11Forward yes

Si ça n’était pas le cas, il faut relancer le service SSH après modification, puis:

ssh -X utilisateur@cubieboard

Si cette erreur apparaît

Xlib:  extension "RANDR" missing on display "localhost:10.0".

Se déconnecter et réessayer avec :

ssh -Y utilisateur@cubieboard

Si cette erreur apparaît

X11 forwarding request failed on channel 0

Assurez-vous que le paquet xorg-xauth est bin installé sur le serveur distant

sudo pacman -S xorg-xauth

Avec cette méthode, concernant les applications 3D :
* Si OpenGL ou OpenGL ES purement logiciel, cela passera (mais lentement).
* Si OpenGL ES accéléré, ça ne marche pas.
Une solution de contournement, utliser LLVMpipe (la plus rapide des implémentations logicielles), Il y aura OpenGL complet mais dont le rendu ne sera fait que par le CPU/SIMD :

LIBGL_ALWAYS_SOFTWARE=1 $application

ou bien

export LIBGL_ALWAYS_SOFTWARE=1
$application

XDMCP

Avec cette méthode à propos des applications 3D :
* OpenGL logiciel ou OpenGL ES (logiciel ou avec accélération matérielle), ne fonctionne pas du tout, du moins en cas de mélange x86 <-> ARM. Il est toujours possible d’utiliser LLVMpipe

Attention XDMCP va écouter sur le port 177 en TCP, penser à le protéger sur un poste nomade ou qui n’est pas derrière un parre-feu

Vous pouvez le protéger comme suit (il faut être root ou le faire en sudo), si vous n’avez pas encore de règle. On définit d’abord l’adresse IP du seul host à autoriser dans la variable HOST_A_AUTORISER (j’ai donné 192.168.0.2 pour l’exemple, il faut le remplacer). Il peut être nécessaire d’autoriser la sortie si vous avec un DROP par défaut (ce que je conseillerais plutôt)

HOST_A_AUTORISER=192.168.0.2
iptables -I INPUT -p tcp --dport 177 -m comment --comment "interdit tout XDMCP" -j DROP
iptables -I INPUT -p tcp --dport 177 -s ${HOST_A_AUTORISER} -m comment --comment "autorise host toto XDMCP" -j ACCEPT

Sur la Cubieboard, ajouter dans /etc/lightdm/lightdm.conf

[XDMCPServer]
enabled=true

puis redémarrer lightdm comme suit :

service lightdm restart

Sur le poste de contrôle :
* Installer le paquet xnest si nécessaire, puis

Xnest :1 -query cubieboard

VNC

Sur la cubieboard. Installer un serveur VNC, par exemple tightvncserver (vnc4server exigera un mot de passe) :

apt-get install tightvncserver

Ajouter dans /etc/lightdm/lightdm.conf :

[VNCServer]
enabled=true

Attention XDMCP va écouter sur le port 177 en TCP, penser à le protéger sur un poste nomade ou qui n’est pas derrière un parre-feu

Vous pouvez le protéger comme suit (il faut être root ou le faire en sudo), si vous n’avez pas encore de règle. On définit d’abord l’adresse IP du seul host à autoriser dans la variable HOST_A_AUTORISER (j’ai donné 192.168.0.2 pour l’exemple, il faut le remplacer). Il peut être nécessaire d’autoriser la sortie si vous avec un DROP par défaut (ce que je conseillerais plutôt)

HOST_A_AUTORISER=192.168.0.2
iptables -I INPUT -p tcp --dport 5900 -m comment --comment "interdit tout VNC" -j DROP
iptables -I INPUT -p tcp --dport 5900 -s ${HOST_A_AUTORISER} -m comment --comment "autorise host toto VNC" -j ACCEPT

puis redémarrer lightdm comme suit :

service lightdm restart

Sur le poste de contrôle :
* Installer le paquet xvncviewer si nécessaire, puis

xvncviewer cubieboard

Protocole X

Il est également possible de lancer une application à distance via le protocol X, c’est un peu comme le tunnel X11 SSH mais en plus direct, sur un test glxgears LLVMpipe on passe de 17fps en tunnel SSH à 20fps en direct. C’est une des méthodes les plus complexes à mettre en place. Il ne faut l’utiliser que si le poste est protégé par un routeur en mode NAT avec un par feu limitant les adresses IP autorisées, sur un réseau local, ou éventuellement au travers d’un tunnel encrypté du genre VPN, mais avec bon chiffrement, car peut être très dangereux.

Par défaut, le protocole tcp X est désactivé sur le serveur X des distributions récentes. Pour l’activer, il faut modifier la ligne de /etc/X11/xinit/xserverrc en retirant la directive -nolisten tcp, à faire sur le serveur X (donc le poste client qui affichera l’application). Cela donnera quelque chose comme ça (attention, cela ne marche pas avec systemd) :

#!/bin/sh
#exec /usr/bin/X -nolisten tcp "$@"
exec /usr/bin/X "$@"

Attention XDMCP va écouter sur le port 6000 en TCP, penser à le protéger sur un poste nomade ou qui n’est pas derrière un parre-feu

Vous pouvez le protéger comme suit (il faut être root ou le faire en sudo), si vous n’avez pas encore de règle. On définit d’abord l’adresse IP du seul host à autoriser dans la variable HOST_A_AUTORISER (j’ai donné 192.168.0.2 pour l’exemple, il faut le remplacer). Il peut être nécessaire d’autoriser la sortie si vous avec un DROP par défaut (ce que je conseillerais plutôt)

HOST_A_AUTORISER=192.168.0.2
iptables -I INPUT -p tcp --dport 6000 -m comment --comment "interdit tout X11" -j DROP
iptables -I INPUT -p tcp --dport 6000 -s ${HOST_A_AUTORISER} -m comment --comment "autorise host toto X11" -j accept

Il faut ensuite relancer le serveur X.

Puis sur le poste client contenant le serveur X, il faut autoriser le serveur d’application à accéder à X :

xhost + $serveur_application

Et ajouter les règles d’autorisation de pare-feu. Par exemple, sur un poste utilisant le noyau Linux (interface locale est typiquement eth1 ou autre à déterminer :

iptables -I INPUT -s $serveur_application -d $serveur_X -i $interface_locale -p tcp -m tcp --dport 6000 -j ACCEPT -m comment --comment --comment "connexions X"
iptables -I OUTPUT -d $serveur_application -s $serveur_X -o $interface_locale -p tcp -m tcp --sport 6000 -j ACCEPT -m comment --comment "connexions X"

Sur le serveur d’application c’est le contraire :

iptables -I OUTPUT -s $serveur_application -d $serveur_X -o $interface_locale -p tcp -m tcp --dport 6000 -j ACCEPT -m comment --comment "connexions X"
iptables -I INPUT -d $serveur_application -s $serveur_X -i $interface_locale -p tcp -m tcp --sport 6000 --dport 1024: -j ACCEPT -m comment --comment "connexions X"

Sur le serveur d’application, il faut alors définir le client. Typiquement, sous bash :

export DISPLAY $serveur_X:0

Pour des raisons de sécurité et séparation des interfaces il est possible de l’afficher sur une session X différente de celle utiliser pour les travaux locaux (il faut dans ce cas tout préparer) :

export DISPLAY $serveur_X:1

Tester avec une commande de base xterm, xclock ou autre. Si ça fonctionne bien, cela devrait fonctionner avec n’importe quelle application.

Installer ubuntu-13.10 beta ARM sur Cubieboard2 depuis une autre système ARM Cubie :)

Travail en cours : Il y aura au boot des problèmes pour le dhcp automatique et l’horloge tant que le paquet de distribution *-desktop ne sera pas installé, j’ai encore besoin de trouver les paquets nécessaires à résoudre cela sans installer un bureau complet

Ubuntu 13.10 Saucy sur Cubieboard2

Ubuntu 13.10 Saucy sur Cubieboard2

Dans mon cas, je pars du système avec u-boot et noyau précédemment installés, ce qui facilite les chose.
Continue reading