module noyau ajouté via buildroot introuvable

a marqué ce sujet comme résolu.

Bonjour, J’essaye depuis plusieurs jours d’ajouter un module à une distribution linux mais je n’y arrive pas. J’essaye de rajouter ce programme de gestion d’une matrice led à ma distribution: https://github.com/hzeller/rpi-rgb-l…g1pakR972OzFos

Pour cela, j’ai suivi ce tutoriel: https://www.blaess.fr/christophe/201…ans-buildroot/

La seule modification que j’ai fait ce trouve dans mon fichier .mk que voici: Code :

################################################################################
#
# led-module
#
################################################################################
 
LED_VERSION     = 1.0.0
LED_SOURCE = led-$(LED_VERSION).tar.gz
LED_SITE        = git://github.com/cpb-/rotation-sensor-module.git
LED_SITE_METHOD = git
LED_DEPENDENCIES = linux
 
define ROTATION_SENSOR_MODULE_BUILD_CMDS
    $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KERNELDIR=$(LINUX_DIR)
endef
 
define ROTATION_SENSOR_MODULE_INSTALL_TARGET_CMDS
    $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KERNELDIR=$(LINUX_DIR) modules_install
endef
 
$(eval $(generic-package))

Afin de ne pas avoir besoin de télécharger quoi que ce soit, j’ai ajouté dans le répertoire dl un dossier led contenant un fichier compressé tar.gz renommé led contenant la totalité du projet git présenté plus haut dont le Makefile.

Ensuite, lorsque je lance la commande make dans mon dossie buildroot, tout se passe bien mais ensuite, lorsque j’essaye de trouver mon nouveau module sur ma distribution en lançant la commande modprobe led je ne trouve rien. Je pense que cela n’est pas le bon nom du module alors j’en ai testé plusieurs autres comme rgbmatrix qui semble être le nom donné dans le makefile mais encore une fois cela n’a pas marché. J’ai bien vérifié et j’ai pensé à cocher le module dans target package.

Auriez vous une idée d’où le problème peut venir ?

Merci d’avance pour votre aide.

Tes liens sont mauvais, tu pourrais les corriger s’il te plaît ?

Sinon je n’ai pas compris ton histoire dans le dossier dl, tu peux expliquer clairement la hiérarchie de tes fichiers à l’intérieur ?

Enfin, tu es sûr que buildroot compile ton module et l’installe ? Car il faut que le fichier .config de buildroot y fasse référence.

+0 -0

Bonjour, Veuillez m’excuser pour les liens, en voici des nouveaux fonctionnels: lien du projet que je souhaite transformé en noyau: https://github.com/hzeller/rpi-rgb-led-matrix?fbclid=IwAR2DvZqufFFHPeaV2QCVa92mdd6bxavRySjZDHP3_UHiBg1pakR972OzFos

lien du tutoriel: https://www.blaess.fr/christophe/2014/07/22/ajouter-un-module-noyau-personnel-dans-buildroot/ ainsi qu’un second dont je me suis aussi grandement inspiré et ou il est question du dossier dl : http://www.linuxembedded.fr/2011/03/ajouter-un-package-dans-buildroot-en-5-minutes/

voici une capture d’écran de ce que j’ai à l’intérieur de mon dossier dl: Image utilisateur ainsi que l’arborescence du dossier:

dl
├── acl
│   └── acl-2.2.53.tar.gz
├── attr
│   └── attr-2.4.48.tar.gz
├── autoconf
│   └── autoconf-2.69.tar.xz
├── automake
│   └── automake-1.15.1.tar.xz
├── binutils
│   └── binutils-2.29.1.tar.xz
├── bison
│   └── bison-3.0.4.tar.xz
├── busybox
│   └── busybox-1.29.3.tar.bz2
├── dosfstools
│   └── dosfstools-4.1.tar.xz
├── e2fsprogs
│   └── e2fsprogs-1.44.5.tar.xz
├── fakeroot
│   └── fakeroot_1.20.2.orig.tar.bz2
├── flex
│   └── flex-2.6.4.tar.gz
├── gawk
│   └── gawk-4.2.1.tar.xz
├── gcc
│   └── gcc-7.4.0.tar.xz
├── genimage
│   └── genimage-10.tar.xz
├── gettext
│   └── gettext-0.19.8.1.tar.xz
├── glibc
│   └── glibc-glibc-2.28-94-g4aeff335ca19286ee2382d8eba794ae5fd49281a.tar.gz
├── gmp
│   └── gmp-6.1.2.tar.xz
├── kmod
│   └── kmod-25.tar.xz
├── led
│   └── led.tar.gz
├── libconfuse
│   └── confuse-3.2.2.tar.xz
├── libtool
│   └── libtool-2.4.6.tar.xz
├── libxml2
│   └── libxml2-2.9.9.tar.gz
├── libzlib
│   └── zlib-1.2.11.tar.xz
├── linux
│   ├── linux-4.14.109.tar.xz
│   └── linux-83b36f98e1a48d143f0b466fcf9f8c4e382c9a1c.tar.gz
├── lzip
│   └── lzip-1.20.tar.gz
├── m4
│   └── m4-1.4.18.tar.xz
├── mpc
│   └── mpc-1.0.3.tar.gz
├── mpfr
│   └── mpfr-3.1.6.tar.xz
├── mtools
│   └── mtools-4.0.18.tar.bz2
├── patchelf
│   └── patchelf-0.9.tar.bz2
├── pkgconf
│   └── pkgconf-1.5.3.tar.xz
├── rpi-firmware
│   └── rpi-firmware-81cca1a9380c828299e884dba5efd0d4acb39e8d.tar.gz
└── util-linux
    └── util-linux-2.33.tar.xz

A l’interieur de chaque dossier on trouve un fichier .tar.gz possédant les fichier du programme en question ainsi qu’un Makefile, dans le fichier .tar.gz de mon module (le dossier led) on trouve la totalité de ce qu’il se trouve dans le lien du projet git Je vais vérifier mes fichiers Config.in demain au cas ou le problème soit lié à cela, il me semble aussi que le fichier .config de buildroot fait référence à mes fichier mais je le vérifierais aussi, sinon j’ai modifié mon fichier.mk aujourd’hui, voici le nouveau:

################################################################################
#
# led-module
#
################################################################################

LED_VERSION     = 1.0.0
LED_SOURCE = led.tar.gz
LED_SITE        = /home/norian/br-tree/dl/led/led.tar.gz
LED_SITE_METHOD = local
LED_DEPENDENCIES = linux

define ROTATION_SENSOR_MODULE_BUILD_CMDS
    $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KERNELDIR=$(LINUX_DIR)
endef

define ROTATION_SENSOR_MODULE_INSTALL_TARGET_CMDS
    $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KERNELDIR=$(LINUX_DIR) modules_install
endef

$(eval $(generic-package))

J’ai modifié les lignes LED_SITE et LED_SITE_MEHODE, je pense que le problème pourrais venir de mon .mk mais je n’en suis pas sûr.

Donc en fait tu as pris ce projet tel quel et tu espères qu’en le compilant ainsi cela sera un module noyau, c’est ça ?

Car ce n’est pas aussi simple, le noyau exige que tu programmes de manière spécifique, tu ne peux espérer aboutir à ton résultat en prenant le code d’un logiciel en espace utilisateur et que automagiquement cela fonctionne en espace noyau.

Pourquoi par ailleurs tu voudrais que ce bout de code soit un module du noyau ? C’est quoi ton but avec ce code et avec ce buildroot ? Ce sont quoi tes connaissances en programmation bas niveau ?

+0 -0

Bonjour, je suis étudiant en électronique, j’ai déjà travaillé sur des microcontrolleurs et sur l’ostr Freertos mais jamais sur une installation linux embarqué. Dans le cadre d’un projet linux embarqué je doit entre autre utiliser cette bibliothèque afin de piloter une matrice led mais j’ai décidé également afin d’apprendre à le faire puisque je n’avais jamais travaillé sur les modules sur un système linux d’utiliser cet outil tel qu’un module. Je me suis rendu compte en regardant le tutoriel de Christophe qu’effectivement j’avais beaucoup trop de fichier pour un module. Ce soir je vais récupérer les fichiers sources nécessaires à ce que je souhaite faire et réessayer, je vous tiens au courant.

Salut,

Je ne connais pas du tout buildroot, mais il me semble étonnant que le module soit compilé juste comme un generic-package, d’ailleurs la doc de buildroot a un eval kernel-module

ensuite, avant de flasher, tu peux regarder si ton module a bien été buildé et ajouté au rootfs. les modules kernel sont dans /lib/modules/<nom du kernel>/kernel (celui du rootfs généré, pas celuis de ta machine de compilation).

Enfin, comme Renault, je suis curieux de savoir exactement quel code tu veux faire tourner dans le noyau, et pourquoi tu veux le faire tourner dans le noyau plutôt qu’en userland. Le nombre de fichiers n’est pas un critère, il y a des modules compilés à partir d’une centaine de fichiers, et peut être plus.

Ce soir je vais récupérer les fichiers sources nécessaires à ce que je souhaite faire et réessayer, je vous tiens au courant.

Ce n’est pas aussi simple que cela.

Une application en espace utilisateur va utiliser l’abstraction qu’offre le noyau Linux pour piloter le matériel, ce qu’on peut nommer comme l’API externe du noyau, celui qui sert aux applications pour dialoguer avec lui. Mais un module du noyau doit utiliser l’API interne qui est radicalement différent. Les fonctions et abstractions sont différentes et tu dois gérer des choses que l’application n’a pas à se soucier.

Bref, ton portage ne peut pas aboutir simplement, il serait limite plus efficient de partir de la doc de ton composant et écrire le pilote que tu veux de zéro. Et sans connaissances du noyau, cela risque d’être ardu pour toi.

Je te conseille plutôt de partir de documents pour apprendre à coder un module. Il y en a sur le net mais tu as aussi quelques bouquins. Et quand tu te sentiras prêt tu pourras aborder ce cas pratique. En attendant c’est trop tôt et difficile selon moi. Il faut commencer par la base : écrire un hello world au niveau noyau, puis un pilote simple que tu complexifies au fur et à mesure.

+2 -0

Rebonjour,

Jacen, il n’y avait pas de raisons technique pour laquelle je souhaitais faire tourner ces codes dans le noyau, la seule raison pour laquelle je voulais le faire était pour apprendre.

Sinon, si j’ai bien compris, le projet présenté plus haut ne peux pas en l’état être ajouté dans ma distribution linux en tant que module ?

Les generics packages sont ils tous des modules ou correspondent ils aussi à d’autres choses pour la distribution ? Est il possible de quand même ajouté quelques un des codes de la démo voir la totalité grâce aux tutoriels que j’ai suivit dans ma distribution sans que les codes ne fassent parti des modules ?

Je vais suivre votre conseil Renault et essayer de créer un module helloworld.

Merci beaucoup pour vos conseils, ils me sont très précieux.

EDIT: A l’aide du second tutoriel que j’ai suivit sur embedded linux, je vais essayer d’ajouter quelques demos du projet venant de github dans le repertoire bin de ma distribution plutot que d’ajouter ces codes en tant que module.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte