{"id":5473,"date":"2019-02-01T08:00:22","date_gmt":"2019-02-01T07:00:22","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=5473"},"modified":"2019-02-01T09:15:57","modified_gmt":"2019-02-01T08:15:57","slug":"un-raspberry-pi-en-production","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2019\/02\/01\/un-raspberry-pi-en-production\/","title":{"rendered":"Un Raspberry Pi en production ?"},"content":{"rendered":"\n

(ou \u00ab\u00a0Jouons avec un Compute Module 3+, Raspbian, Buildroot et Yocto<\/em>\u00ab\u00a0)<\/h3>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/a><\/figure><\/div>\n\n\n\n

Je r\u00e9alise des prestations de conseil et de formation aupr\u00e8s d’entreprises qui souhaitent utiliser Linux pour produire un syst\u00e8me embarqu\u00e9. La plupart de ces projets commencent par un prototype sur Raspberry Pi<\/strong>.<\/p>\n\n\n\n

Lorsqu’elles me consultent sur le choix d’une plate-forme pour l’industrialisation de leur produit, je leur conseille de laisser de c\u00f4t\u00e9 le Raspberry Pi et de se tourner vers une carte plus adapt\u00e9e \u00e0 la production en s\u00e9rie.<\/p>\n\n\n\n

Mais cette r\u00e9ponse pourrait bien \u00e9voluer…<\/p>\n\n\n\n\n\n\n\n

System-On-Chip<\/em>, Single-Board-Computer<\/em> et System-On-Module<\/em><\/h2>\n\n\n\n

Pour commencer, quelques rappels sur le vocabulaire des syst\u00e8mes embarqu\u00e9s ; la plupart d’entre-eux sont construits autour d’un System-On-Chip<\/strong><\/em> (S.O.C.) c’est-\u00e0-dire une \u00ab\u00a0puce\u00a0\u00bb comprenant un processeur, des circuits \u00e9lectroniques (diviseurs d’horloge, logique de reset<\/em>, etc.), des contr\u00f4leurs d’entr\u00e9es-sorties, de la m\u00e9moire… Le S.O.C. utilis\u00e9 par le Raspberry Pi (3B+) est le BCM2837B0 de Broadcom.<\/p>\n\n\n\n

Le Raspberry Pi associe ce S.O.C. avec un peu de m\u00e9moire, un contr\u00f4leur USB\/Ethernet et ajoute des fonctions \u00e9lectroniques (alimentation, amplification des signaux, etc.). Il suffit d’ajouter une carte micro-SD contenant le syst\u00e8me d’exploitation et d’alimenter le Raspberry Pi pour qu’il soit op\u00e9rationnel. On lui connecte, au choix, un \u00e9cran, un clavier, un c\u00e2ble Ethernet, des p\u00e9riph\u00e9riques s\u00e9rie, SPI, i\u00b2c, etc. C’est ce que l’on nomme un Single-Board-Computer<\/strong><\/em> (S.B.C.)<\/p>\n\n\n\n

Un S.B.C. est tr\u00e8s adapt\u00e9 pour le prototypage, les projets personnels (media center<\/em>, retro-gaming<\/em>, station m\u00e9t\u00e9o, serveur domotique…) ou la production de mini-s\u00e9ries de quelques exemplaires. D\u00e8s que l’on souhaite d\u00e9passer quelques dizaines d’unit\u00e9s \u00e0 produire, l’utilisation d’un S.B.C. devient peu souhaitable.<\/p>\n\n\n\n

Il est tr\u00e8s rare qu’un produit ne n\u00e9cessite pas d’autres composants \u00e9lectroniques externes (capteurs, actionneurs, leds, boutons, interrupteurs, etc.). Il faut alors d\u00e9velopper une carte \u00e9lectronique d\u00e9di\u00e9e pour supporter ces \u00e9l\u00e9ments sp\u00e9cifiques au projet. Cette carte \u00ab\u00a0m\u00e9tier\u00a0\u00bb et le S.B.C. doivent \u00eatre reli\u00e9s par l’interm\u00e9diaire de c\u00e2bles, de connecteurs, et probablement solidaris\u00e9s physiquement par le biais d’entretoises, de boulons, etc. Tout ceci ajoute de la complexit\u00e9 dans la production et des points de dysfonctionnements potentiels du syst\u00e8me.<\/p>\n\n\n\n

L’id\u00e9al est de regrouper toute l’\u00e9lectronique m\u00e9tier sur une seule carte qui inclue \u00e9galement le S.O.C. Toutefois ceci n\u00e9cessite un investissement en d\u00e9veloppement \u00e9lectronique cons\u00e9quent, que l’on ne consid\u00e8re en g\u00e9n\u00e9ral pas rentable en de\u00e7\u00e0 de plusieurs milliers d’unit\u00e9s \u00e0 produire.<\/p>\n\n\n\n

La solution consiste \u00e0 utiliser un System-On-Module<\/strong><\/em> (S.O.M.) c’est \u00e0 dire une petite carte contenant toute l’\u00e9lectronique complexe du S.B.C. avec un seul connecteur sp\u00e9cifique, par exemple une rang\u00e9e de mini broches \u00e0 la mani\u00e8re des barrettes de m\u00e9moires SO-DIMM<\/em>. Il suffit alors d’ajouter sur la carte m\u00e9tier un support d’insertion accueillant le S.O.M. pour qu’il puisse communiquer avec les p\u00e9riph\u00e9riques. L’int\u00e9gration d’un S.O.M. dans la conception d’une carte \u00e9lectronique m\u00e9tier est une op\u00e9ration relativement simple pour un bureau d’\u00e9tude, l’interface \u00e9lectronique et logique \u00e9tant bien document\u00e9e par le fournisseur de module.<\/p>\n\n\n\n

Pour les projets de mes clients, j’ai eu \u00e0 utiliser plusieurs modules \u00e0 vocation industrielle, je citerais par exemple les OposSOM d’Armadeus<\/a>, les Phycore de Phytec<\/a> ou les A20-SOM d’Olimex<\/a>.<\/p>\n\n\n\n

Mais le Raspberry Pi dans tout \u00e7a ?<\/p>\n\n\n\n

Raspberry Pi Compute Module<\/h2>\n\n\n\n

La Raspberry Pi Fundation<\/a><\/em> avait compris depuis longtemps l’int\u00e9r\u00eat pour le d\u00e9veloppeur d’un produit industriel de disposer d’un module regroupant toutes les fonctionnalit\u00e9s du Raspberry Pi, sur lequel il puisse faire fonctionner l’application prototyp\u00e9e et mise au point sur un S.B.C. classique. Elle a propos\u00e9 le mod\u00e8le Raspberry Pi Compute Module CM1<\/em> qui dans un premier temps \u00e9tait \u00e9quivalent au Raspberry Pi 1 B+, puis le CM3 \u00e9quivalent au Raspberry Pi 3. Toutefois la disponibilit\u00e9 de ces modules laissait \u00e0 d\u00e9sirer et la p\u00e9rennit\u00e9 de leur production n’\u00e9tait pas garantie.<\/p>\n\n\n\n

Le nouveau Raspberry Pi Compute Module 3+<\/em> disponible depuis le 29 janvier 2019 franchit une \u00e9tape en garantissant une disponibilit\u00e9 du module jusqu’au d\u00e9but 2026.<\/p>\n\n\n\n

\"\"
Raspberry Pi Compute Module 3<\/figcaption><\/figure><\/div>\n\n\n\n

Il est \u00e9galement disponible en plusieurs versions suivant la taille de la m\u00e9moire eMMC<\/em> d\u00e9sir\u00e9e. En effet, il est difficilement envisageable dans un produit industriel que tout le logiciel du syst\u00e8me soit install\u00e9 sur une simple carte micro-SD, avec tous les risques que cela comporte : extraction involontaire, mauvais contacts par vibrations, duplication et reverse ingeniering<\/em> du code applicatif (piratage), etc. Le Raspberry Pi Compute Module<\/em> contient donc une m\u00e9moire flash eMMC<\/em> que l’on programme avec l’O.S. d\u00e9sir\u00e9 (une distribution Raspbian<\/a> par exemple, ou une image personnalis\u00e9e obtenue avec Yocto<\/a> ou Buildroot<\/a>).<\/p>\n\n\n\n

Pour programmer le module, il est n\u00e9cessaire de disposer d’un petit kit de d\u00e9veloppement d\u00e9di\u00e9, qui permet d’ins\u00e9rer le S.O.M. et de disposer de la connectique \u00e9quivalente au S.B.C. initial. Cette carte s’appelle un Compute Module I\/O Board<\/em> (CMIO board<\/em>). Il en existe deux versions, la premi\u00e8re v.1.2 date de 2014 environ, lors de la sortie du premier Compute Module, la seconde v.3 date de 2017. La documentation indique que la CMIO board v1.2 ne fonctionne pas avec le CM3+, pourtant c’est celle que j’ai utilis\u00e9e avec succ\u00e8s. Il est possible que certaines fonctionnalit\u00e9s ne soient pas support\u00e9es, mais pour la programmation de base, pas de souci.<\/p>\n\n\n\n

\"\"
Kit de d\u00e9veloppement CMIO board v.1.2<\/em> & Raspberry Pi CM3<\/figcaption><\/figure><\/div>\n\n\n\n

Raspbian sur CM3+<\/h2>\n\n\n\n

Le premi\u00e8re exp\u00e9rience \u00e0 tenter est de flasher une distribution Raspbian<\/a> standard dans la m\u00e9moire eMMC du Compute Module 3+. Pour cela, il existe un tutoriel<\/a> tr\u00e8s bien fait sur le site de la Raspberry Pi Fundation<\/em>, aussi vais-je simplement lister les op\u00e9rations que je r\u00e9alise sans trop les d\u00e9tailler. Je d\u00e9crirai plus pr\u00e9cis\u00e9ment l’utilisation de Buildroot et Yocto.<\/p>\n\n\n\n

J’ai t\u00e9l\u00e9charg\u00e9 sur mon PC l’image 2018-11-13 de Raspbian. Sur ce m\u00eame PC, je compile l’utilitaire usbboot<\/code> qui nous servira \u00e0 pr\u00e9parer le CM3+ \u00e0 l’installation de l’image. Pour cela je dois d’abord installer une version de d\u00e9veloppement de la biblioth\u00e8que libusb<\/code>.<\/p>\n\n\n\n

[~]$ sudo  apt  install  -y  libusb-1.0.0-dev<\/strong>
[~]$ git  clone  --depth=1  https:\/\/github.com\/raspberrypi\/usbboot<\/strong>
[~]$ cd usbboot<\/strong>
[usbboot]$ make<\/strong><\/pre>\n\n\n\n
Une fois la compilation achev\u00e9e, je regarde la liste des partitions pr\u00e9sentes sur ce PC, avant de lancer l’utilitaire de programmation du module.<\/p>\n\n\n\n
[usbboot]$ lsblk<\/strong>
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
 loop0    7:0    0 140,7M  1 loop \/snap\/gnome-3-26-1604\/74
 [...]
 sda      8:0    0   1,8T  0 disk
 \u251c\u2500sda1   8:1    0   1,8T  0 part \/
 \u251c\u2500sda2   8:2    0     1K  0 part
 \u2514\u2500sda5   8:5    0     3G  0 part [SWAP]
 sr0     11:0    1  1024M  0 rom
[usbboot]$ sudo  .\/rpiboo<\/strong>t
 Waiting for BCM2835\/6\/7<\/pre>\n\n\n\n
J’ai ins\u00e9r\u00e9 le module CM3+ dans la carte CMIO. Je connecte son port \u00ab\u00a0USB Slave<\/em>\u00a0\u00bb \u00e0 un port USB de mon PC. Le jumper J4 \u00ab\u00a0USB Slave Boot<\/em>\u00a0\u00bb est sur la position \u00ab\u00a0Enable<\/em>\u00ab\u00a0.<\/p>\n\n\n\n
\"\"
Programmation du CM3+<\/em> avec la CMIO board v.1.2<\/em><\/figcaption><\/figure><\/div>\n\n\n\n
 Je branche l’alimentation de la CMIO boar<\/em>d. L’utilitaire rpiboot<\/code> la d\u00e9tecte…<\/p>\n\n\n\n
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835\/6\/7
Second stage boot server
File read: start.elf
Second stage boot server done
[usbboot]$<\/pre>\n\n\n\n
Je v\u00e9rifie \u00e0 nouveau la liste des partitions, un nouveau p\u00e9riph\u00e9rique bloc est pr\u00e9sent, qui repr\u00e9sente la m\u00e9moire eMMC<\/em> du module CM3+.<\/p>\n\n\n\n
[usbboot]$ lsblk<\/strong>
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
 loop0    7:0    0 140,7M  1 loop \/snap\/gnome-3-26-1604\/74
 [...]
 sda      8:0    0   1,8T  0 disk
 \u251c\u2500sda1   8:1    0   1,8T  0 part \/
 \u251c\u2500sda2   8:2    0     1K  0 part
 \u2514\u2500sda5   8:5    0     3G  0 part [SWAP]
 sdb      8:16   1   3,7G  0 disk<\/strong>
 sr0     11:0    1  1024M  0 rom<\/pre>\n\n\n\n
On peut alors copier directement l’image de la distribution sur ce p\u00e9riph\u00e9rique.<\/p>\n\n\n\n
[usbboot]$ sudo  cp  ..\/2018-11-13-raspbian-stretch.img  \/dev\/sdb<\/strong><\/pre>\n\n\n\n
La copie dure plusieurs minutes. Vous pouvez \u00e9galement utiliser la commande dd<\/code> dont la syntaxe est l\u00e9g\u00e8rement plus compliqu\u00e9e, mais qui sera un peu plus rapide. Une fois la copie termin\u00e9e, je d\u00e9branche le c\u00e2ble USB qui reliait la CMIO board<\/em> \u00e0 mon PC et je le rebranche. Deux nouvelles partitions format\u00e9es apparaissent et sont automatiquement mont\u00e9es.<\/p>\n\n\n\n
[usbboot]$ lsblk<\/strong>
 NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
 loop0    7:0    0 140,7M  1 loop \/snap\/gnome-3-26-1604\/74
 [...]
 sda      8:0    0   1,8T  0 disk
 \u251c\u2500sda1   8:1    0   1,8T  0 part \/
 \u251c\u2500sda2   8:2    0     1K  0 part
 \u2514\u2500sda5   8:5    0     3G  0 part [SWAP]
 sdb      8:16   1   7,3G  0 disk
 \u251c\u2500sdb1   8:17   1  43,9M  0 part \/media\/cpb\/boot
 \u2514\u2500sdb2   8:18   1   3,1G  0 part \/media\/cpb\/rootfs
<\/strong> sr0     11:0    1  1024M  0 rom<\/pre>\n\n\n\n
Comme je souhaite utiliser le port s\u00e9rie pour me connecter sur mon Compute Module, j’\u00e9dite le fichier \/media\/cpb\/boot\/config.txt<\/code> pour y ajouter cette ligne :<\/p>\n\n\n\n
enable_uart=1<\/pre>\n\n\n\n
Je d\u00e9monte consciencieusement les deux partitions et je fais d\u00e9marrer la CMIO board<\/em> apr\u00e8s avoir plac\u00e9 le cavalier \u00ab\u00a0USB Slave Boot<\/em>\u00a0\u00bb en position \u00ab\u00a0Disable\u00a0\u00bb<\/em>. <\/p>\n\n\n\n
\"\"
Boot normal du module CM3+<\/em><\/figcaption><\/figure>\n\n\n\n
Voici quelques traces de ma connexion sur le port s\u00e9rie.<\/p>\n\n\n\n
Raspbian GNU\/Linux 9 raspberrypi ttyAMA0
 raspberrypi login: pi<\/strong>
 Password: (raspberry)<\/strong>
 Last login: Tue Nov 13 14:13:35 GMT 2018 on ttyAMA0
 Linux raspberrypi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l
 [...]
pi@raspberrypi:~$ cat  \/sys\/firmware\/devicetree\/base\/model<\/strong>
 Raspberry Pi Compute Module 3 Plus Rev 1.<\/pre>\n\n\n\n
Le mod\u00e8le est bien reconnu, v\u00e9rifions son processeur et sa m\u00e9moire RAM (1 Go).<\/p>\n\n\n\n
pi@raspberrypi:~$ lscpu<\/strong>
 Architecture:          armv7l
 Byte Order:            Little Endian
 CPU(s):                4
 On-line CPU(s) list:   0-3
 Thread(s) per core:    1
 Core(s) per socket:    4
 Socket(s):             1
 Model:                 4
 Model name:            ARMv7 Processor rev 4 (v7l)
 CPU max MHz:           1200.0000
 CPU min MHz:           600.0000
 BogoMIPS:              38.40
 Flags:                 half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
pi@raspberrypi:~$ free<\/strong>
               total        used        free      shared  buff\/cache   available
 Mem:         949452<\/strong>       69364      730168       14012      149920      816484
 Swap:        102396           0      102396<\/pre>\n\n\n\n
Le mod\u00e8le que j’ai choisi est celui avec 8 Go de m\u00e9moire eMMC, je peux le v\u00e9rifier \u00e9galement.<\/p>\n\n\n\n
pi@raspberrypi:~$ df<\/strong>
 Filesystem     1K-blocks    Used Available Use% Mounted on
 \/dev\/root        7400936<\/strong> 2657104   4382080  38% \/
 devtmpfs          470116       0    470116   0% \/dev
 tmpfs             474724       0    474724   0% \/dev\/shm
 tmpfs             474724   12216    462508   3% \/run
 tmpfs               5120       4      5116   1% \/run\/lock
 tmpfs             474724       0    474724   0% \/sys\/fs\/cgroup
 \/dev\/mmcblk0p1     44220   22540     21681  51% \/boot
 tmpfs              94944       0     94944   0% \/run\/user\/1000
<\/pre>\n\n\n\n
J’avais par ailleurs connect\u00e9 un petit \u00e9cran sur le port HDMI de la CMIO board<\/em>, on peut voir que l’IHM de la distribution Raspbian fonctionne parfaitement.<\/p>\n\n\n\n
\"\"
Raspbian 2018.11<\/em> sur CM3+<\/em><\/figcaption><\/figure>\n\n\n\n
La distribution Raspbian est donc bien support\u00e9e par ce nouveau module. Toutefois, pour les syst\u00e8mes embarqu\u00e9s industriels, on utilise rarement de distribution compl\u00e8te, on pr\u00e9f\u00e8re construire une image personnalis\u00e9e ne contenant que le strict n\u00e9cessaire. Pour cela on utilise un build system<\/em> comme Buildroot ou Yocto. Commen\u00e7ons par tester notre module avec Buildroot.<\/p>\n\n\n\n
Raspberry Pi CM3+ et Buildroot<\/h2>\n\n\n\n
J’ai d\u00e9j\u00e0 d\u00e9crit la production compl\u00e8te d’un syst\u00e8me embarqu\u00e9 avec Buildroot dans cet article<\/a>. Nous ne verrons ici que les op\u00e9rations de base pour s’assurer du fonctionnement minimal.<\/p>\n\n\n\n
Je t\u00e9l\u00e9charge la derni\u00e8re version stable de Buildroot, j’extrais les sources, je pr\u00e9pare une configuration pour l’ensemble des mod\u00e8les compatibles avec le Raspberry Pi 3, et je lance la compilation.<\/p>\n\n\n\n
[~]$ wget  https:\/\/buildroot.org\/downloads\/buildroot-2018.11.2.tar.bz2<\/strong>
[~]$ tar  xf  buildroot-2018.11.2.tar.bz2<\/strong>
[~]$ cd  buildroot-2018.11.2\/<\/strong>
[buildroot-2018.11.2]$ make  raspberrypi3_defconfig<\/strong>
[buildroot-2018.11.2]$ make<\/strong><\/pre>\n\n\n\n
La compilation initiale prend une demi-heure environ. Ensuite je replace le cavalier \u00ab\u00a0USB Slave Boot<\/em>\u00a0\u00bb de la CMIO board<\/em> sur \u00ab\u00a0Enable<\/em>\u00a0\u00bb et je red\u00e9marre la carte, en lan\u00e7ant sur mon PC :<\/p>\n\n\n\n
[buildroot-2018.11.2]$ cd  ..\/usbboot\/<\/strong>
[usbboot]$ sudo  .\/rpiboot<\/strong>
Waiting for BCM2835\/6\/7
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835\/6\/7
Second stage boot server
File read: start.elf
Second stage boot server done

[usbboot]$ umount  \/media\/cpb\/*<\/strong>
[usbboot]$ sudo  cp  ..\/buildroot-2018.11.2\/output\/images\/sdcard.img  \/dev\/sdb<\/strong><\/pre>\n\n\n\n
Apr\u00e8s copie et re-positionnement du cavalier sur \u00ab\u00a0Disable<\/em>\u00ab\u00a0, j’observe les traces de boot<\/em> suivantes :<\/p>\n\n\n\n
[    0.000000] Booting Linux on physical CPU 0x0                                                                
[    0.000000] Linux version 4.14.74-v7 (cpb@why-cpb) (gcc version 7.3.0 (Buildroot 2018.11.2)) #1 SMP Thu Jan 31 08:10:44 CET 2019
[    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[...]
[    2.089583] devtmpfs: mounted
[    2.097822] Freeing unused kernel memory: 1024K
[    2.186441] EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
Starting logging: OK
Initializing random number generator\u2026
[    2.261917] random: dd: uninitialized urandom read (512 bytes read)
done.
Starting network:
[    2.447091] NET: Registered protocol family 10
[    2.455052] Segment Routing with IPv6
Waiting for interface eth0 to appear\u2026\u2026\u2026\u2026\u2026 timeout!
run-parts: \/etc\/network\/if-pre-up.d\/wait_iface: exit status 1
FAIL
Welcome to Buildroot
buildroot login: <\/pre>\n\n\n\n
L’erreur en fin de boot<\/em> est normale, le Compute Module<\/em> n’a pas d’interface Ethernet (sur le Raspberry Pi classique, cette interface est fournie par un convertisseur USB \/ Ethernet LAN9512), le script de configuration par DHCP<\/em> \u00e9choue donc au bout de quelques secondes. Ceci ne nous emp\u00eache pas de nous connecter et de passer quelques commandes.<\/p>\n\n\n\n
Welcome to Buildroot
buildroot login: root<\/strong>
# uname  -a<\/strong>
Linux buildroot 4.14.74-v7 #1 SMP Thu Jan 31 08:10:44 CET 2019 armv7l GNU\/Linux
# cat  \/sys\/firmware\/devicetree\/base\/model<\/strong>
Raspberry Pi Compute Module 3 Plus Rev 1.0<\/pre>\n\n\n\n
Notre Compute Module<\/em> est bien reconnu et utilisable avec la derni\u00e8re version stable de Buildroot. Comme j’en avais parl\u00e9 dans cet article<\/a>, il est possible de configurer \u00e0 loisir la composition du syst\u00e8me et de le rendre tr\u00e8s robuste.<\/p>\n\n\n\n
Raspberry Pi CM3+ et Yocto Project<\/h2>\n\n\n\n
Le projet Yocto<\/em>, \u00e0 l’instar de son confr\u00e8re Buildroot<\/em>, permet de construire une image personnalis\u00e9e pour un syst\u00e8me embarqu\u00e9 en le limitant au strict n\u00e9cessaire. Nous allons l’utiliser pour produire une image pour le Raspberry Pi Compute Module 3+.<\/p>\n\n\n\n
Tout d’abord t\u00e9l\u00e9chargeons la derni\u00e8re version de Yocto. D\u00e9but 2019, il s’agit de la branche \u00ab\u00a0Thud\u00a0\u00bb.<\/p>\n\n\n\n
[~]$ mkdir  CM3lab<\/strong>
[~]$ cd  CM3lab<\/strong>
[CM3lab]$ git  clone git:\/\/git.yoctoproject.org\/poky.git  -b  thud<\/strong><\/pre>\n\n\n\n
T\u00e9l\u00e9chargeons \u00e9galement le layer<\/em> pour Raspberry Pi, il s’agit d’un r\u00e9pertoire pr\u00e9fix\u00e9 par meta<\/code> contenant les recipes<\/em> – les recettes n\u00e9cessaires pour g\u00e9n\u00e9rer les composants du syst\u00e8me – d\u00e9di\u00e9es \u00e0 cette plateforme.<\/p>\n\n\n\n
[CM3lab]$ git  clone git:\/\/git.yoctoproject.org\/meta-raspberrypi  -b  thud<\/strong><\/pre>\n\n\n\n
Appelons le script oe-build-env<\/code> pour cr\u00e9er un r\u00e9pertoire de travail et pr\u00e9parons la configuration de la compilation.<\/p>\n\n\n\n
[CM3lab]$ source  poky\/oe-init-build-env  build-cm3+<\/strong>
[build-cm3+]$<\/pre>\n\n\n\n
On remarque que le script nous a plac\u00e9 dans le r\u00e9pertoire de travail nouvellement cr\u00e9\u00e9. Ajoutons le layer<\/em> du Raspberry Pi pour notre compilation.<\/p>\n\n\n\n
[build-cm3+] $ bitbake-layers   add-layer   ..\/meta-raspberrypi<\/strong><\/pre>\n\n\n\n
\u00c9ditons le fichier de configuration de Yocto, et modifions le type de machine ainsi :<\/p>\n\n\n\n
[build-cm3+]$ nano  conf\/local.conf<\/strong>
    [...]
    MACHINE = \"raspberrypi-cm3\"
    [...]
<\/pre>\n\n\n\n
Nous pouvons maintenant lancer la compilation…<\/p>\n\n\n\n
[build-cm3+]$ bitbake  rpi-basic-image<\/strong><\/pre>\n\n\n\n
La dur\u00e9e de compilation varie sensiblement en fonction de la puissance processeur disponible et du d\u00e9bit de la connexion Internet, mais elle est de l’ordre de deux heures environ.<\/p>\n\n\n\n
Le fichier \u00e0 copier sur la partition eMMC (\u00e0 partir du r\u00e9pertoire courant) est le suivant :<\/p>\n\n\n\n
tmp\/deploy\/images\/raspberrypi-cm3\/rpi-basic-image-raspberrypi-cm3.rpi-sdimg
<\/pre>\n\n\n\n
Si on veut utiliser la connexion par port s\u00e9rie, il faut ajouter deux op\u00e9rations. Une fois le fichier copi\u00e9, il faut d\u00e9connecter puis reconnecter le c\u00e2ble USB Slave<\/em> afin de voir appara\u00eetre sur le PC les deux partitions. On \u00e9dite le fichier config.txt<\/code> se trouvant sur la premi\u00e8re pour, comme avec la distribution Raspbian, ajouter la ligne suivante.<\/p>\n\n\n\n
enable_uart=1<\/pre>\n\n\n\n
En outre, il faut \u00e9diter le fichier \/etc\/inittab<\/code> se trouvant sur la seconde partition et remplacer la ligne<\/p>\n\n\n\n
S0:12345:respawn:\/bin\/start_getty 115200 ttyS0<\/strong> vt102<\/pre>\n\n\n\n
par<\/p>\n\n\n\n
S0:12345:respawn:\/bin\/start_getty 115200 ttyAMA0<\/strong> vt102<\/pre>\n\n\n\n
Comme avec les images pr\u00e9c\u00e9dentes, nous pouvons v\u00e9rifier le boot<\/em> du syst\u00e8me :<\/p>\n\n\n\n
Poky (Yocto Project Reference Distro) 2.6.1 raspberrypi-cm3 \/dev\/ttyAMA0
 raspberrypi-cm3 login: root<\/strong>
 root@raspberrypi-cm3:~# uname  -a<\/strong>
 Linux raspberrypi-cm3 4.14.87 #1 SMP Thu Jan 31 09:49:20 UTC 2019 armv7l GNU\/Linux
 root@raspberrypi-cm3:~# cat \/sys\/firmware\/devicetree\/base\/model<\/strong> 
 Raspberry Pi Compute Module 3 Plus Rev 1.0
<\/pre>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Nous voyons que le nouveau Raspberry Pi Compute Module 3+<\/em> fonctionne avec la m\u00eame configuration que le CM3 pr\u00e9c\u00e9dent, tant avec une distribution compl\u00e8te comme Raspbian<\/em>, qu’avec des images minimales et customis\u00e9es produites par Buildroot<\/em> ou Yocto<\/em>. La gamme de choix \u00e9tendue en ce qui concerne la m\u00e9moire eMMC, la disponibilit\u00e9 prolong\u00e9e sur six ans, et le prix raisonnable en font une solution int\u00e9ressante pour industrialiser un produit prototyp\u00e9 sur le Raspberry Pi classique.<\/p>\n\n\n\n
Pour pouvoir ensuite utiliser le module ainsi programm\u00e9 sur une carte m\u00e9tier, on trouvera la documentation de r\u00e9f\u00e9rence<\/a> sur le site de la Raspberry Pi Fundation<\/em>, mais aussi des sites ind\u00e9pendants comme ce projet Instructables de Manolis Agkopplan<\/a> (merci \u00e0 Fran\u00e7ois Mocq pour le lien).<\/p>","protected":false},"excerpt":{"rendered":"
(ou « Jouons avec un Compute Module 3+, Raspbian, Buildroot et Yocto« ) Je réalise des prestations de conseil et de formation auprès d’entreprises qui souhaitent utiliser Linux pour produire un système embarqué. La plupart de ces projets commencent par un prototype sur Raspberry Pi. Lorsqu’elles me consultent sur le choix d’une plate-forme pour l’industrialisation de leur […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,8,10,11],"tags":[],"class_list":["post-5473","post","type-post","status-publish","format-standard","hentry","category-embarque","category-linux-2","category-microprocesseur","category-raspberry-pi"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/5473","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=5473"}],"version-history":[{"count":49,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/5473\/revisions"}],"predecessor-version":[{"id":5570,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/5473\/revisions\/5570"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=5473"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=5473"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=5473"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Dans le cas du Raspberry Pi, on peut d\u00e9velopper une carte venant se brancher sur le connecteur d’entr\u00e9e-sortie \u00e0 la mani\u00e8re des hats<\/em> propos\u00e9s pour cette carte (par exemple le P.O.E. hat<\/a><\/em> ou le Pi TV hat<\/a><\/em>) mais ce n’est pas toujours possible pour des raisons pratiques. Pour un projet r\u00e9cent, mon client \u00e9tait limit\u00e9 \u00e0 une \u00e9lectronique ne d\u00e9passant pas 17 mm d’\u00e9paisseur, soit \u00e0 peine plus que les connecteurs USB\/Ethernet. Impossible donc de se brancher sur le connecteur d’extension sauf en soudant directement sur les broches \u00e0 mi-hauteur. Autrement dit, parfaitement r\u00e9alisable pour un prototype mais totalement irr\u00e9aliste pour une production en nombre.<\/p>\n\n\n\n