KERNEL LINUX Hugo Descoubes – Janvier 2014 Embedded Linux

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 2 – copyleft KERNEL LINUX Le kernel Linux est un noyau monolithique modulaire sous licence GNU GPL v2 développé sur un modèle collaboratif décentralisé via internet (sources librement accessibles sur Linus Torvalds reste en 2013 le principal superviseur des dernières releases du kernel, aussi nommées ‘’vanilla’’ ou ‘’mainline’’. Observons le roadmap du kernel :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 3 – copyleft KERNEL LINUX Comme tout kernel, Linux propose des services bas niveaux tel qu’un ordonnanceur, la gestion de systèmes de fichiers, des pilotes de périphériques, des mécanismes de protection mémoire … Observons la représentation fonctionnelle du kernel Linux :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 4 – copyleft KERNEL LINUX Observons maintenant le système de fichier du kernel : …

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 5 – copyleft KERNEL LINUX /usr/src/linux-headers- / Etudions succinctement l’arborescence du système de fichiers du kernel (rq, sources accessibles côté host dans /usr/src/linux-headers- / ) : arch/ arch/ (architecture) : parties spécifiques aux architectures CPU et plateformes supportées ainsi que certains services propres aux cœurs (core DMA, cache, core timer, vecteurs d’interruptions, board support, device tree …). Il s’agit du second plus gros répertoire de l’arborescence, observons les architectures supportées en 2013 : arch/ /boot/ arch/ /boot/ contient les premiers fichiers (assembleur) d’amorçage du kernel.

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 6 – copyleft KERNEL LINUX drivers/ drivers/ : pilotes de périphériques, il s’agit du répertoire le plus gros de l’arborescence (GPIO, I2C, CAN, USB, SPI … multiplateformes). Rappelons que le kernel Linux reste un noyau monolithique, tout service matériel supporté par la main line doit pouvoir être ajouté à la compilation du noyau (monolithic driver, buildin) fs/ fs/ (file system): systèmes de fichiers réels et virtuels supportés (ext2, ext4, FAT, NTFS …) include/ include/ : principaux fichiers d’en-tête du noyau (hors headers ayant une portée locale) init/ init/ : fichiers non-architecture dépendant d’amorçage et d’initialisation du système (main.c, initramfs.c …)

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 7 – copyleft KERNEL LINUX ipc/ ipc/ (inter processes communication) : mécanismes de communication inter-processus (mémoire partagée, message queue, sémaphores …) kernel/ kernel/ : cœur du noyau (scheduler, signaux UNIX …) lib/ lib/ (libraries): petite bibliothèque C interne au kernel (algorithmes de décompression, manipulation de string ‘’strcmp, strlen …’’ …) mm/ mm/ (memory managment) : mécanismes de gestion et protection mémoire (segmentation, pagination, swap …) net/ net/ (network) : interfaces non-architecture dépendant et protocoles réseaux (Ethernet, IPv4, IPv6, CAN …)

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 8 – copyleft KERNEL LINUX Documentation/ Documentation/ : documentation propre au kernel et aux sous- services proposés, notamment les drivers. scripts/ scripts/ : scripts pour la configuration et la compilation du kernel. firmware/ firmware/ : binaires précompilés en mode texte hexadécimal. Inclusion de codes fermés propriétaires, répertoire sujet à controverse vis-à-vis de la licence GPLv2 du kernel. tools/ tools/ (utilitaires) : utilitaires de prototypage et d’analyse du kernel et de l’architecture cible (profilage, trace, consommation, échauffement thermique …)

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 9 – copyleft KERNEL LINUX Afin d’assurer un bonne interopérabilité, maintenabilité et portabilité, le kernel Linux est découpé en couches proposant plusieurs niveaux d’abstraction, notamment au regard du matériel. Observons le kernel map du noyau :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 10 – copyleft KERNEL LINUX Observons la phase de boot du noyau sur architecture mono-cœur ARM pour un kernel compressé : Image decompression Architecture dependent arch/arm/boot/compressed/head.S After kernel loading U-Boot jump to ‘’start’’ label Boot parameters passed by U-Boot in CPU registers : r1 (CPU architecture ID or don’t care if DTB) r2 (ATAGS parameters pointer or Device Tree Blob address ATAG_DEVTREE) Initialization of main memory, cache and MMU Architecture dependent arch/arm/kernel/head.S start_kernel, initialization of all kernel components Architecture independent init/main.c Rq : Rq : compatible mode if kernel option CONFIG_ARM_ATAG_DTB_COMPAT activated. Traditional ATAGS reading and update them DT.

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 11 – copyleft KERNEL LINUX init/main.c Le fichier init/main.c est donc le premier point d’entrée architecture agnostique du kernel. Il assure l’initialisation de tous les composants logiciels et matériels du noyau :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 12 – copyleft KERNEL LINUX Attention, ce qui suit n’est pas un cours sur git, cette partie présente juste succinctement le projet ainsi que ses forts liens avec le kernel Linux ! Avant de présenter le projet Git, rappelons le rôle des outils de gestion de version. Les outils de gestion de version ou outils de versionning permettent de maintenir l’ensemble des versions d’un ou plusieurs fichiers. Ces outils sont très rencontrés dans le monde de l’édition logicielle. Principaux acteurs dans l’embarqué en 2013 : UBM, EETimes Embedded Market 2013

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 13 – copyleft KERNEL LINUX Git Git est un outil simple et puissant de gestion de version décentralisé. Le projet a été créé en 2005 par Linus Torvalds et pensé pour le Kernel Linux (publié sous licence GPLv2). Contrairement à la plupart des autres outils de versionning, Git ne repose pas sur un serveur centralisé (cf. comptes sur dépôts SVN ou CVS). De plus, contrairement à ses principaux concurrents qui archives les différences entre fichiers, Git sauvegarde les deux versions d’un fichier sur le disque en cas de modification (indexation d’après un checksum des fichiers calculé via fonction de hachage SHA-1)

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 14 – copyleft KERNEL LINUX Observons rapidement le vocabulaire caché derrière les outils de versionning : 0.1 tag Master Trunk Branch DiscontinuedBranch Branch Merge tag Branch Merge Commits

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 15 – copyleft KERNEL LINUX Git travail avec deux structures de données, une base d’objets et un cache de répertoires. Il existe 4 types d’objets : blob Objet blob (Binary Large OBject) : représente le contenu d’un fichier tree Objet tree : liste et informations concernant les objets blobs commit Objet commit (sens ‘’confirmer’’) : contient un message de log, un objet tree et pointe vers un ou plusieurs objets commit parents tag Objet tag (étiquette) : utiliser pour marquer certains commit (par exemple les numéros de version) git init git clone git add git branch git merge git commit Observons une liste non exhaustive de commandes Git : git init (création nouveau dépôt), git clone (clone dépôt distant), git add (ajout nouveaux objets blobs), git branch (création nouvelle branche), git merge (fusionne plusieurs branches), git commit

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 16 – copyleft KERNEL LINUX gitkgitwebgiggleJGit/EGitgit-gui Il est également possible d’utiliser des interfaces graphiques afin de parcourir des projets Git, ceci peut faciliter le parcours de l’arbre et le suivi d’un projet. Prenons quelques exemples d’interfaces : gitk, gitweb, giggle, JGit/EGit, git-gui … Interface gitk Identifiant SHA-1 unique du commit courant

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 17 – copyleft KERNEL LINUX githubgitorious Afin de facilité le travail collaboratif, de nombreux projets sont accessibles depuis des dépôts distants. Notamment dans le monde de Git, ces services web d’hébergement sont aussi bien des plateformes de gestion de développement de logiciels que des réseaux sociaux. Prenons l’exemple des deux plus célèbres autour du projet Git : github et gitorious

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 18 – copyleft KERNEL LINUX.config Avant de découvrir la procédure de compilation du kernel, étudions les principales méthodes de configuration de celui-ci. Cette configuration consiste à éditer le fichier.config présent à la racine d’un projet (le kernel Linux dans notre cas). Rappelons que le kernel Linux est un noyau monolithique modulaire. Durant la configuration du kernel, trois solutions s’offrent à nous : Exclusion du service Exclusion du service (service non présent dans le fichier de configuration ou marqué comme ‘’is not set’’) Service monolithique Service monolithique (inclus dans le kernel à la compilation et marqué ‘’y’’) Service modulaire Service modulaire (service pouvant être rajouté depuis le user space et marqué comme ‘’m’’)

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 19 – copyleft KERNEL LINUX /boot/config- Première solution, éditer manuellement ce fichier. Cette solution peut être dangereuse car elle ne tient pas compte des dépendances entre services kernel (rq, configuration noyau accessible côté host dans /boot/config- ) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 20 – copyleft KERNEL LINUX Makefile Ce fichier de configuration permet l’inclusion de directives de compilation présents dans les différents Makefile du projet. Observons le Makefile propre à l’ajout de drivers et services CAN au kernel (drivers/net/can/Makefile) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 21 – copyleft KERNEL LINUX Kconfig make config make menuconfig make xconfigmake gconfig Il est également possible d’utiliser une interface graphique avec gestion des dépendances pour la génération du fichier de configuration. Il s’agit d’une interface simple associée aux fichiers Kconfig présents dans chaque répertoire de l’arborescence. Plusieurs interfaces existent : make config (interface shell, navigation difficile), make menuconfig (interface ncurses cf. ci-dessous, la plus utilisée pour sa simplicité et sa vitesse de chargement), make xconfig, make gconfig (interface GTK+) …

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 22 – copyleft KERNEL LINUX menuconfig Observons les principaux symboles et caractères permettant la compréhension et la manipulation du menuconfig : : aucune dépendance : dépendance nécessaire afin d’être compilé monolitiquement [ ] [ ] : dépendance nécessaire afin d’être compilé monolitiquement ou non compilé { } { } : dépendance nécessaire afin d’être compilé monolitiquement ou être un module ---> ---> : appuyer sur ENTER afin d’étendre la branche ymn?/ Caractères : y (build-in), m (module), n (exclusion), ? (aide), / (recherche paramètres de configuration) …

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 23 – copyleft KERNEL LINUX Nous allons maintenant nous fixer un cahier des charges. Le SoC AM335x de la famille Sitara présent sur la BBB embarque deux contrôleurs CAN (DCAN0 et DCAN1). Hors, aucune des distributions présentes sur internet et aucune des configurations du kernel pour la BBB n’incluent nativement de services d’interface :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 24 – copyleft KERNEL LINUX Comme pour beaucoup de projets, commençons par une recherche internet et intéressons-nous notamment aux forums et wikis du fondeur (lire attentivement le wiki de TI) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 25 – copyleft KERNEL LINUX arch/ /configs/ Nous allons maintenant appliquer un fichier de configuration pour la BBB puis inclure driver et services CAN associés à notre architecture. Pour information, de nombreuses configurations par défaut pour des processeurs ou plateformes du marché se situent dans arch/ /configs/ :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 26 – copyleft KERNEL LINUX make ARCH=arm menuconfig Configuration du kernel afin d’inclure les drivers DCAN et services d’interface associés (make ARCH=arm menuconfig) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 27 – copyleft KERNEL LINUX Observons les liens en entre interface menuconfig, fichiers Kconfig, Makefile et sources : drivers/net/can/c_can/Kconfig drivers/net/can/c_can/Makefile

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 28 – copyleft KERNEL LINUX Sauvegarder la configuration générée, lancer la compilation du kernel (option -j ou jobs dépend du nombre de cœurs physiques ou logiques de la machine host) et du device tree. Récupérer ensuite les binaires de sortie :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 29 – copyleft KERNEL LINUX Observons le modèle en couches entre interfaces matérielles et couches applicatives présentes en user space : Application Layer ip, cansend, candump … Socket CAN interface Networking interface DCAN Core Transceiver User Space Kernel Space Hardware drivers/net/can/c_can/drivers/net/can/ Hardware dependent net/can/Documentation/networking/can.txt Hardware independent net/ DCAN driver OthersCAN drivers ??

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 30 – copyleft KERNEL LINUX dmesg Copier la nouvelle image du kernel et du device tree (pas obligatoire) sur la SDcard puis booter le système. Vérifier la bonne configuration des services CAN via la commande dmesg (‘’display message’’ affiche la mémoire tampon des messages kernel) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 31 – copyleft KERNEL LINUX device tree Néanmoins, même si nous pouvons vérifier que les drivers CAN et services kernel associés sont bien inclus, le périphérique matériel n’est pas reconnu du système. En effet, sous Linux, les contrôleurs CAN sont reconnus en tant que périphériques réseaux, hors nous pouvons constater que le système ne reconnais pas le device. Nous allons devoir nous intéresser à la notion de device tree !

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 32 – copyleft KERNEL LINUX Intéressons-nous au processus de compilation et de copie en user space des modules kernel. Connecter physiquement la SDcard au host et s’assurer du nom et de l’emplacement exact du point de montage : A ce stade, les modules ont été copiés en user space, ils pourront être chargés dynamiquement par la suite après la phase de démarrage du kernel. Penser également à installer les firmwares en user space (format HEX Intel) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 33 – copyleft KERNEL LINUX phases de test et de prototypage Néanmoins, même si nous constaterons que les services kernel CAN sont stables et opérationnels, il peu être plus aisé, durant des phases de test et de prototypage, de développer des modules. Possibilité de rajouter ou retirer à chaud en user space le module avec insertion de code de test et d’instrumentation logicielle. Hardware Application Layer UserSpace KernelSpace Drivers network network scheduler scheduler ipc ipc file system file system Mem. Manag. Module Module(service)

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 34 – copyleft KERNEL LINUX Concernant le modèle de développement de drivers (char, block, network) et l’insertion de modules depuis le user space, vous aurez un enseignement dédié au développement de drivers réalisé par un ingénieur NXP sur le sujet :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 35 – copyleft KERNEL LINUX board file device tree Afin de décrire l’architecture de la plateforme matérielle cible au kernel, deux solutions s’offrent à nous : board file ou device tree (très rencontré sur architecture PowerPC et se propage de plus en plus en 2013 sur ARM), sachant que la première tend à tomber dans l’obsolescence. descripteurs d’architecture matérielle Dans les deux cas, ces fichiers sont des descripteurs d’architecture matérielle (nombre de CPU’s, énumération des périphériques de communication, plages d’adresses mémoire des registres de configuration des périphériques …). Rappelons que sur un processeur numérique à architecture CPU typique les périphériques internes se partagent en général les broches d’I/O, ces fichiers de description permettent notamment de fixer ce type de conflit.

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 36 – copyleft KERNEL LINUX board file arch/ / arch/arm/mach-omap2/board- omap3beagle.c Les fichiers board file sont des fichiers au format C classique (arch/ /). Néanmoins, l’arrivée en force depuis plus de dix ans de Linux dans l’embarqué a permis de remettre en cause ce type de solution. Observons le contenu partiel de l’un de ces fichiers (arch/arm/mach-omap2/board- omap3beagle.c) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 37 – copyleft KERNEL LINUX Observons les principaux inconvénients et avantages de cette solution (thème sujet à de nombreux débats sur internet) : Explosion du nombre d’architecture CPU et board supportés Explosion du nombre d’architecture CPU et board supportés (surcharge du répertoire arch/ et maintenabilité complexe, aspect essentiel au regard de Linus T.). Pour anecdote, voici un petit échange courtois sur le sujet en ligne avec Linus T. : recompilation complète du kernel Rajouter le support matériel d’une interface nécessite la recompilation complète du kernel Edition en C Edition en C (compétences déjà présentes) Temps de boot plus rapide Temps de boot plus rapide (aucun parsage)

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 38 – copyleft KERNEL LINUX device tree Documentation/devicetree/usage-model.txt devicetree.org L’idée générale du device tree est d’obtenir à terme un kernel indépendant de l’architecture cible et de passer celle-ci en argument au noyau à l’exécution (portabilité et interopérabilité). arch/arm/boot/dtbs/ Les fichiers device tree sont à la fois des structures de données et un langage permettant la description d’architectures matérielles (nécessite un compilateur dédié, dtc). Nous parlerons de représentation Device Tree ou représentation Flatenned Device Tree (Documentation/devicetree/usage-model.txt ou devicetree.org). L’idée générale du device tree est d’obtenir à terme un kernel indépendant de l’architecture cible et de passer celle-ci en argument au noyau à l’exécution (portabilité et interopérabilité). Observons le contenu partiel du device tree pour la BBB (arch/arm/boot/dtbs/) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 39 – copyleft KERNEL LINUX Documentation/devicetree/bindings/ arch/arm/boot/dts/ Un DT ou FDT est donc une structure de donnée en mode texte comportant une architecture en arbre dont les champs et propriétés (architecture dépendants) sont documentés dans Documentation/devicetree/bindings/. Pour architecture ARM, tous les DT se situent dans arch/arm/boot/dts/. Nous distinguerons les fichiers sources des fichiers de sortie :.dts.dts (device tree source) : contient en général la description de la board cible.dtsi.dtsi (device tree source include) : contient en général la description du processeur ou SoC cible.dtb.dtb (device tree blob ou binary large object) : binaire de sortie après compilation via le device tree compiler (dtc).dtbo.dtbo (dtb object) : DT précompilé chargeable dynamiquement en user space, à rapprocher de la notion de firmware

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 40 – copyleft KERNEL LINUX device tree Comme son nom l’indique, le principe du device tree consiste à représenter sous forme d’un arbre l’architecture matérielle du SoC et de la board cible. Attention, il s’agit bien d’un langage de description (cf. VHDL ou Verilog) contrairement au C qui est un langage de programmation (exécution séquentielle). Prenons un exemple : Board Board (.dts) … / SoC / SoC (.dtsi) CPU CPU1CPU2 memory buses pin ctrl BUS1BUS2 CAN…I2C ETH…USB Additionalproperties

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 41 – copyleft KERNEL LINUX Observons la structure générique d’un DTS ou DTSI : Nœud racine (de l’arbre) Nœud 0 Propriétés du nœud 0 Valeur associée à la propriété. String terminée par le caractère NULL Label 4 Cellules de 32 bits : <délimiteur> 4 Cellules Binaires : [délimiteur] Liste de chaîne de caractères

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 42 – copyleft KERNEL LINUX arch/arm/boot/dts/am33xx.dtsi Analysons le nœud associé à la description du module DCAN1 du SoC AM335x (cf. arch/arm/boot/dts/am33xx.dtsi) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 43 – copyleft KERNEL LINUX Documentation/devicetree/bindings/net/can/c_can.txt Maintenant, afin de rajouter le support matériel du contrôleur CAN par notre SoC, hors de question de réinventer la poudre. Etudions la documentation fournie par le kernel (cf. Documentation/devicetree/bindings/net/can/c_can.txt) : cf. arch/arm/boot/dts/am33xx.dtsi Activation du module, à faire !

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 44 – copyleft KERNEL LINUX Faisons le lien avec la datasheet du SoC (cf. spruh73i.pdf, Memory Map) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 45 – copyleft KERNEL LINUX Faisons le lien avec la datasheet du SoC (cf. spruh73i.pdf, Interrupts) :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 46 – copyleft KERNEL LINUX Comme pour la majorité des SoC du marché, les périphériques internes se partagent en général les broches d’I/O (stratégie interne de multiplexage des broches ou pinmux) : Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt Beagle Bone Black : Beagle Bone Black : AM335x Texas Instruments : AM335x Texas Instruments :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 47 – copyleft KERNEL LINUX Observons le partage de broches sur SoC AM335x (boîtier ZCZ), périphérique GPMC (General Purpose Memory Controller):

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 48 – copyleft KERNEL LINUX Etudions les modifications à apporter au DTS associé à notre board. Bien s’assurer des conflits éventuels entre broches du package ( : Ajout ou modification de propriétés associées à un nœud associées à un nœud

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 49 – copyleft KERNEL LINUX Observons le travail d’inclusion (pre-processing) réalisé par le dtc avant compilation : am33xx.dtsi (SoC dependent) am335x-boneblack.dts (board dependent) + = Compiled by dtc

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 50 – copyleft KERNEL LINUX arch/arm/boot/dts/am335x- boneblack.dts am335x-boneblack.dtb Modifier le fichier arch/arm/boot/dts/am335x- boneblack.dts, le compiler puis remplacer sur la MMC/SDcard le binaire am335x-boneblack.dtb existant avec le nouveau :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 51 – copyleft KERNEL LINUX S’assurer côté BBB que le périphérique est bien reconnu par le système. A ce stade d’avancement, il ne reste plus qu’à s’assurer des services et packages nécessaires en user space afin d’utiliser notre contrôleur. Les premiers tests pourront alors débuter.

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 52 – copyleft KERNEL LINUX patch kernel ~/elinux/work/kernel/patch/ ~/elinux/work/kernel/kernel Maintenant, voici un dernier exercice autour de la découverte du noyau. Vous allez développer votre premier patch kernel. Créer un patch à lancer depuis le répertoire ~/elinux/work/kernel/patch/ permettant de patcher le fichier ~/elinux/work/kernel/kernel /kernel/arch/arm/boot/dts/am335x-boneblack.dts diff /kernel/arch/arm/boot/dts/am335x-boneblack.dts initialement présent dans le système de fichiers du noyau (appliquer les modifications précédemment présentées). Pour ce faire, regarder sur internet comment créer un patch avec la commande diff !

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 53 – copyleft KERNEL LINUX Nous pouvons dés à présent commencer à développer des logiciels applicatifs communicant avec l’interface kernel socketCAN. Application Layer Homemade software with socketCAN interface, ip (iproute2), can-utils (cansend, candump …) Socket CAN interface Networking interface DCAN Core Transceiver User Space Kernel Space Hardware DCAN Driver

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 54 – copyleft KERNEL LINUX Afin de travailler avec l’interface socketCAN depuis l’espace utilisateur vous pouvez maintenant avoir accès à différentes ressources en ligne ou incluses dans le kernel : Documentation kernel : Documentation kernel : Documentation/networking/can.txt ( Wikipedia : Wikipedia : Projet Git socketCAN : Projet Git socketCAN : Projet Git can-utils : Projet Git can-utils : …

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 55 – copyleft KERNEL LINUX /usr/src/ Prenons un code de test trouvé sur internet (wikipedia socketCAN, Vous constaterez que pour compiler ce fichier depuis le user space, l’environnement de compilation doit forcément avoir accès aux headers kernel (présents en user space dans /usr/src/ ):

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 56 – copyleft KERNEL LINUX cantest.c ~/elinux/work/misc/can/ /home/debian/ Editer un fichier source C cantest.c en adaptant le code à votre application (se placer dans ~/elinux/work/misc/can/). Cross- compiler le fichier source et le porter en user sur la board dans /home/debian/ : Côté BBB, configurer le débit de la communication et activer le module (étapes obligatoires). Lancer ensuite l’exécutable :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 57 – copyleft KERNEL LINUX can- utils A titre indicatif, en ce qui concerne le CAN, le package can- utils ( propose une API simple mais néanmoins complète de communication avec l’interface kernel socketCAN. Pour vos futurs projets, toujours essayer de s’approprier l’existant en optimisant au maximum votre temps de développement en le réutilisant et le réadaptant :

Architecture – git – Configuration – Driver monolithique – module – device tree – user space 58 – copyleft KERNEL LINUX now, it’s coffee time ! La preuve en image … now, it’s coffee time ! =

Merci de votre attention !