Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5

Problème avec BSP + Toolchain fabre de fabricega
#1

Bonjour à tous,
Malgré une certaine dose de persévérance, j'aurais besoin d'aide....

Situation :
PC sous Ubuntu 10.04.2LTS
Obectif :
Préparer une chaine de compilation croisée pour RPI avec BSP sur mesure et support pour application Qt4
Base de travail :
BSP + Toolchain fabricega sur la base de ptxdist.

Ce que j'ai suivi :
Code :
[== Indéfini ==]
OSELAS.BSP-RaspberryPi:

derived from: OSELAS.BSP-Pengutronix-Generic-2011.11.0

This PTXdist[1] based project supports:

- Raspberry Pi

For further information please read the following documents (part of this
archive):

For the generic PC (x86 architecture):
documentation/OSELAS.BSP-Pengutronix-Generic-x86-Quickstart.pdf

For the "versatilepb" (ARM architecture):
documentation/OSELAS.BSP-Pengutronix-Generic-arm-Quickstart.pdf

More PTXdist related information can be found at [1].

Enjoy!

Your Pengutronix Development Team

[1] http://www.pengutronix.de/software/ptxdist/index_en.html

-----------------------------------
Install guidelines :

1 - install toolchain
OSELAS.Toolchain-2011.11.1
==========================

OSELAS.Toolchain for Raspberry Pi

First, install ptxdist-2011.11.0 and its dependencies:
$ apt-get install ...
$ wget ptxdist-2011.11.0.tar.bz2
$ tar -xjvf ptxdist-2011.11.0.tar.bz2
$ ./configure
$ sudo make install

Then, configure OSELAS.Toolchain-2011.11.1:
$ cd OSELAS.Toolchain-2011.11.1
$ ptxdist select ptxconfigs/arm-1176jzfs-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig
$ ptxdist go

2 - prepare BSP, then GO
==========================
First, install ptxdist-2012.10.0 and its dependencies:
$ apt-get install ...
$ wget ptxdist-2012.10.0.tar.bz2
$ tar -xjvf ptxdist-2012.10.0.tar.bz2
$ ./configure
$ sudo make install

Then, configure OSELAS.BSP-RaspberryPi
$ cd OSELAS.BSP-RaspberryPi:
$ ptxdist select configs/ptxconfig
$ ptxdist platform configs/raspberrypi-2012.10.0/platformconfig
$ ptxdist toolchain /opt/OSELAS.Toolchain-2011.11.1/arm-1176jzfs-linux-gnueabi/gcc-4.6.2-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin
$ ptxdist go
$ ptxdist images

Mon problème :
J'ai réussi à compiler la chaine de compilation croisée qui est sous /opt/....
L'installation de ptxdist est correcte.
Au moment de compiler le BSP (boot + kernel + rootfs) des erreurs dont je n'arrive pas à déterminer l'origine apparaissent et stop la compilation :
Code :
[== Indéfini ==]
---------------------------
target: libatasmart.prepare
---------------------------

checking for a BSD-compatible install... /usr/local/lib/ptxdist-2012.10.0/bin/install -c
checking whether build environment is sane... yes


..............


puis.......



checking pkg-config is at least version 0.9.0... yes
checking for LIBUDEV... no
configure: error: Package requirements (libudev >= 143) were not met:

No package 'libudev' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBUDEV_CFLAGS
and LIBUDEV_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Malgré l'installation de divers paquets qui me semblaient en relation avec l'erreur ci-dessus, rien n'y fait, je suis au point mort !

Est ce que quelqu'un aurait essayé ce BSP fabricega ?

Merci de votre précieuse aide....
Bonne soirée.
Rey.
Répondre
#2

Reyrey a écrit :
Code :
checking pkg-config is at least version 0.9.0... yes
checking for LIBUDEV... no
configure: error: Package requirements (libudev >= 143) were not met:

No package 'libudev' found

Salut !

$ sudo apt-get install libudev-dev
Répondre
#3

Merci pour la suggestion mais c'est fait et ca n'a rien changé.
Une autre idée, elles sont toutes le bienvenu.......
Répondre
#4

Bizzare, tu as exactement le même screen. Tu nous refaire une copie d'écran des erreurs ?
Répondre
#5

Bonjour,
Avec plasir, voici donc le début :
Code :
[== Indéfini ==]
~/Raspberry/OSELAS.BSP-RaspberryPi-master$ ptxdist go
---------------------------
target: libatasmart.prepare
---------------------------

checking for a BSD-compatible install... /usr/local/lib/ptxdist-2012.10.0/bin/install -c
checking whether build environment is sane... yes
checking for arm-1176jzfs-linux-gnueabi-strip... arm-1176jzfs-linux-gnueabi-strip
checking for a thread-safe mkdir -p... /usr/local/lib/ptxdist-2012.10.0/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes


..... puis après quelques lignes qui semblent ok .......
La suite :
Code :
[== Indéfini ==]
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wl,--gc-sections in envvar LDFLAGS... yes
checking pkg-config is at least version 0.9.0... yes
checking for LIBUDEV... no
configure: error: Package requirements (libudev >= 143) were not met:

No package 'libudev' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBUDEV_CFLAGS
and LIBUDEV_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

J'ai essayé d'installer tous les paquets qui me semblaient en relation avec ce problème mais rien n'y fait ?!

Alors je me demande si quelqu'un d'autre a testé le package complet de fabricega et sous quel OS (ubuntu ? version ?)
Merci encore à tous car je suis bloqué.....
Répondre
#6

Tu utilise une distrib' ubuntu ancienne, donc il se peut que la version du paquetage libudev soit ancienne.
2 solutions : - Changer de distrib' ou compiler le paquetage libudev...
Répondre
#7

Peux tu effectivement contrôler la version de ta lib avec la commande ldconfig de ton cross compilteur. Cela doir ressembler à :
arm-1176jzfs-linux-gnueabi-ldconfig -p | grep libudev

Tu devrais voir quelle est la version utilisée par le cross compilateur pour cette lib.
Répondre
#8

Voici la réponse :
Code :
[== Indéfini ==]
:/opt/OSELAS.Toolchain-2011.11.1/arm-1176jzfs-linux-gnueabi/gcc-4.6.2-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-arm-1176jzfs-linux-gnueabi/sbin$ ldconfig -p | grep libudev
    libudev.so.0 (libc6) => /lib/libudev.so.0
    libudev.so (libc6) => /usr/lib/libudev.so

Je ne vois de version dans ce résultat ?!
Si j'ai bien compris le problème, il faut que libudev soit d'une version sup ou égale à 143 ?

J'ai effectivement l'impression que mon problème trouve peut être sa source dans la version d'Ubuntu que j'utilise.
Si je n'ai pas le choix j'essairai sous le dernier ubuntu pour voir. Mais je préfèrerait rester sous 10.04.2LTS sous lequel j'ai déjà installé des compilateurs croisés qui fonctionnent avec cette version !
Merci encore du coup de main....
Répondre
#9

Je pense qu'il y a confusion entre le distribution/son environnement de développement natif et l'environnement de compilation croisée. Je m'explique :
  • Ta cible au vue des commandes de ton cross-compilateur est un ARM
  • Ton environnement hôte est sur un X86

l
  • les commandes ld et gcc sont des commandes de compilation pour l'hôte, les binaires et librairies sont donc de "type" X86
  • les commandes arm-1176jzfs-linux-gnueabi-ldconfig et arm-1176jzfs-linux-gnueabi-gcc sont des commandes pour l'environnement de cross-compilation et les binaires et librairies sont de "type" arm


Lorsque tu as fait un apt-get install libudev-dev, cela a eu pour effet d'installer la librairie dans l'environnement de l'hôte pour un X86 et absolument pas pour le cross-compilateur arm.

Il faut donc que tu installes la lib pour le cross-compilateur.
Pour ce faire le moyen le plus simple, est de de placer sur la machine cible (le raspi) de faire un apt-get install libudev-dev
cela va installer sur le raspberry pi les libs et includes suivant :
  • /usr/include/libudev.h
  • /usr/lib/libudev.a
  • /usr/lib/libudev.so


après tu transfères ces includes sur ton hôtes (exemple dans ton home sous /include et /lib) puis tu modfies ton script de compilation ou ton ld config pour les prendres en compte.

A ta dispo si tu as besoin de plus de précision ou si je n'ai pas été claire (j'ai fait un tuto sur le sujet sur mon blog, il y a moment mais ce n'est pas le même cross compilateur).
Répondre
#10

Je pense que tu as été clair sdelporte.
J'aimerais juste une précision sur ton résonnement :
Citation :Lorsque tu as fait un apt-get install libudev-dev, cela a eu pour effet d'installer la librairie dans l'environnement de l'hôte pour un X86 et absolument pas pour le cross-compilateur arm.
--> OK, mais il me semblait justement que 'libudev-dev' devait être cross-compilé sur mon hote (PC) pour ma cible, alors pourquoi récupérer les libs sur la cible au format ARM ?
Pour contourner le problème et le fait que je sois sous un ubuntu 10 peut être ?
Répondre
#11

haha et ben non.
si tu regarde le paquet libudev-dev, voici les fichiers que tu as sur un i386 :
  • /usr/include/libudev.h
  • /usr/lib/libudev.a
  • /usr/lib/libudev.la
  • /usr/lib/libudev.so
Tu n'as donc pas les sources pour recompiler avec ton cross-compilateur les sources de la libudev.
La solution la plus simple est de prendre la lib sur le système cible comme cela tu es sûr d'avoir la bonne version.
Sinon il faut trouver le paquet qui rammene les sources et le recompiler avec le cross-compilateur.
Répondre
#12

Bonjour sdelporte,
Merci pour tes éclaircissements.
Je vais abuser de ton temps et de ton aide si tu me le permais ?

Je pensais qu'à la compilation d'un BSP, ptxdist (puisque c'est de lui qu'il s'agit dans mon cas) récupérait tout seul, comme un grand, les sources des libs dont il avait besoin pour les cross-complier dans le but de préparer le boot, kernel et rootfs ?
J'ai eu locasion de préparer des bsp et leurs toolchain (cibles phytec) pour d'autres cibles arm et à aucun moment je n'ai eu ce genre de manipulation à faire sur des libs, pourquoi ?
Est ce que les libs qui auraient pu poser problème à ptxdist faisaient parties des sources livrées avec le BSP de ma cible et c'est pour cette raison que le problème ne ce serait pas posé ?
Merci encore à toi....
Bonne journée.
Répondre
#13

Je viens d'installer Ubuntu 12.04.4LTS afin de faire un essai est le résultat est le même ?!
Code :
[== Indéfini ==]
---------------------------
target: libatasmart.prepare
---------------------------

checking for a BSD-compatible install... /usr/local/lib/ptxdist-2012.10.0/bin/install -c
checking whether build environment is sane... yes
checking for arm-1176jzfs-linux-gnueabi-strip... arm-1176jzfs-linux-gnueabi-strip
checking for a thread-safe mkdir -p... /usr/local/lib/ptxdist-2012.10.0/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking how to create a pax tar archive... gnutar
checking whether make supports nested variables... (cached) yes
checking for arm-1176jzfs-linux-gnueabi-gcc... arm-1176jzfs-linux-gnueabi-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-1176jzfs-linux-gnueabi-gcc accepts -g... yes
checking for arm-1176jzfs-linux-gnueabi-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of arm-1176jzfs-linux-gnueabi-gcc... gcc3
checking for arm-1176jzfs-linux-gnueabi-gcc option to accept ISO C99... -std=gnu99
checking whether arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 and cc understand -c and -o together... yes
checking how to run the C preprocessor... arm-1176jzfs-linux-gnueabi-cpp
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking whether arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 needs -traditional... no
checking for build system executable suffix... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -pipe in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wall in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -W in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wextra in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Winline in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wvla in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wundef in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wformat=2 in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wlogical-op in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wsign-compare in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wformat-security in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wmissing-include-dirs in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wformat-nonliteral in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wold-style-definition in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wpointer-arith in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Winit-self in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wdeclaration-after-statement in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wfloat-equal in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wmissing-prototypes in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wstrict-prototypes in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wredundant-decls in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wmissing-declarations in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wmissing-noreturn in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wshadow in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wendif-labels in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wcast-align in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wstrict-aliasing=2 in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wwrite-strings in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wno-long-long in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wno-overlength-strings in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wno-unused-parameter in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wno-missing-field-initializers in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wno-unused-result in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wunsafe-loop-optimizations in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wpacked in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Werror=overflow in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wp,-D_FORTIFY_SOURCE=2 in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -ffast-math in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -fno-common in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -fdiagnostics-show-option in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -fno-strict-aliasing in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -ffunction-sections in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -fdata-sections in envvar CFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wl,--as-needed in envvar LDFLAGS... yes
checking if arm-1176jzfs-linux-gnueabi-gcc -std=gnu99 supports flag -Wl,--gc-sections in envvar LDFLAGS... yes
checking pkg-config is at least version 0.9.0... yes
checking for LIBUDEV... no
configure: error: Package requirements (libudev >= 143) were not met:

No package 'libudev' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBUDEV_CFLAGS
and LIBUDEV_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** [/home/perso/raspberry/OSELAS.BSP-RaspberryPi-master/platform-RaspberryPi/state/libatasmart.prepare] Error 1
Je ne comprends pas...
Répondre
#14

Logique ta distribution ne change rien à ton cross-compilateur.
Je suis désolais mais j'ai perdu ton objectif de base, peux tu me le rappeler
Répondre
#15

Avec plaisir.... Big Grin

Je cherche a créer/compiler mon BSP complet pour Raspberry, composé du boot, kernel et rootfs.
L'ensemble étant configuré pour répondre à mes besoins, comme l'ajout dans les options de ptxdist de la compilation de Qt4/Qt5 afin que je puisse coder des applications sous Qt4 et cross-compiler pour ma cible.

Ainsi avec 'MON' kernel et 'MON' rootfs pouvus des options que j'aurai choisies dans ptxdist pourront faire tourner mes applis issues de Qt4 sans soucis.

Outre l'intégration de Qt4, je compte valider l'option gstreamer afin de pouvoir utiliser phonon sous Qt4, par exemple.

En conclusion, ma raspberry tournant sous mon BSP, dont le poids sera maitrisé en fonction des options que je validerai ou non dans ma config ptxdist, pourra sans problème faire tourner une de mes applications codées sous Qt4.

Suis je assez clair ?
Répondre
#16

Salut,

Quelques remarques et questions qui me viennent en passant :
- Recompiler toutes les librairies de QT, je pense que cela va être la galère.
- En supposant que cela fonctionne, j'ai l'impression que l'application va super ramer.
- Pourquoi ne pas utiliser une distrib' classique tel que la Raspbian ?
- Sais-tu s'il y a des personnes qui ont déjà compilé des applications QT4/QT5 sur ce type d'environnement ?
Répondre
#17

J'ai désactiver le libatasmart dans le fichier platform-RaspberryPi/selected_ptxconfig
Mais j'ai une autre erreur après sur util-linux-ng
Répondre
#18

Bonjour,
Non je ne connais pas d'autre personne ayant essayée mais une distribution préparée par ptxdist ou buildroot propose dans les options de compiler ou non Qt et ainsi de l'inclure dans le BSP qu'il suffit ensuite de 'placer' sur la carte cible sous forme d'un boot + kernel + rootfs.
Du coup, une application Qt codée sur PC tournera sans problème sur la cible ARM après cross-compilation dans la mesure ou toutes les libs de Qt seront présentes sur cette cible.
J'utilise ce processus (ptxdist et buildroot) pour d'autre cible de type ARM et ca fonctionne impeccable !
J'aurais souhaité faire la même chose avec la RPI afin de pouvoir porter mes applications sur différentes cibles ARM.
Je persévères.....
Toutes les bonnes volonté sont les bienvenues.....
Bonne journée à tous.
Répondre
#19

Une autre remarque, les versions de ptxdist, de toolchain et de OSELAS.BSP-RaspberryPi sont anciennes, pourquoi ne pas utiliser Yocto pour Raspberry Pi par exemple ?
Répondre
#20

Voilà, j'ai enfin réussi à compiler un noyau et son rootfs associé avec l'ensemble des options dont j'avais besoin. Ouf ! Big Grin

Il me reste encore un point avant de pouvoir tester ma distribution avec une application Qt4 rapide, c'est de créer la carte SD !!!

Le résultat de la compilation est le suivant :
- linuximage
- rootfs.ext2 ou rootfs.jffs2
- éventuellement un bootloader

La question : comment préparer la carte SD avec ces éléments afin que la RPI boot dessus ?

Après quelques recherche rapides, j'ai vu qu'il était possible d'utiliser 'Win32DiskImager ' par exemple et de flasher un fichier ---.img sur la carte SD.
J'ai donc valider l'option de création d'image img sous ptxdist/platformconfig.
ptxdist génère bien tous les fichiers sans erreur y compris un fichier image hd.img mais qui pèse 512 octets !!!
Quelqu'un aurait il une explication sur le problème de taille de hd.img ou une autre méthode pour créer cette carte SD ?
Répondre
#21

Reyrey a écrit :Voilà, j'ai enfin réussi à compiler un noyau et son rootfs associé avec l'ensemble des options dont j'avais besoin. Ouf ! Big Grin

Comment as-tu résolu ton problème de librairie ?
Répondre
#22

Comment j'ai résolu mon problème ?
En cherchant une solution à ce problème justement, je sui tombé sur une autre version de BSP : OSELAS.BSP-fga-Raspberry-2011.11.0.
La toolchain est identique à celle de fabricega et ce BSP fonctionne...

La production des images a fonctionné impeccable, malgré les changements que j'ai effectué dans les options de la platform, du kernel et du système de fichier, pour que le résultat de la compilation intègre, par exemple, les libs de Qt4.

Il me reste désormais a préparer une carte SD afin de tester le kernel/rootfs produit.
Et la j'ai de nouveau un problème ! (ben oui ca ne serrait pas marrant autrement ?!

J'ai lu qu'il fallait flasher sur la carte SD une image de type 'img'. Or ptxdist sait produire ce genre d'image en théorie si on lui demande gentiellement.
Mise à part que dans mon cas, sans qu'aucune erreur survienne, le fichier image produit, hd.img, ne pèse que 512 octets !!!???

Je sollicite donc une fois de plus votre aide afin de savoir comment m'y prendre.....
Merci et bonne journée.
Répondre
#23

Ah un détail, si une bonne âme OSmile voulait bien corriger mon titre car je n'ai pas trouvé comment faire, en supprimant 'fabre' qui est une faute de frappe comme vous l'avez sans doute compris... Merci.
Répondre
#24

J'avance doucement....

J'ai enfin pu préparer une carte SD avec 2 partitions comprenant, entre autre, mon kernel et mon rootfs tout neuf perso !

Lors du boot de ma RPI, la séquence de démarrage boucle sur ceci :
Code :
[== Indéfini ==]
init:can't log to /dev/tty5
starting pid=575, tty '/dev/console' : 'sbin/getty 38400 tty1'
init:can't log to /dev/tty5
starting pid=576, tty '/dev/console' : 'sbin/getty 38400 tty2'
init:can't log to /dev/tty5
starting pid=577, tty '/dev/console' : 'sbin/getty 38400 tty3'
init:can't log to /dev/tty5
starting pid=578, tty '/dev/console' : 'sbin/getty 38400 tty4'
A chaque nouveau groupe de messages, le PID augmente....

D'ou vient ce genre de problème ?

Ce qui m'étonne, c'est que j'ai réussi à arriver jusqu'au login mais comme à ce moment là aucun clavier nétait branché sur ma RPI, je l'ai mise hors tension le temps de trouver un clavier et à la remise sous tension j'ai été confronté au problème ci-dessus sans arriver à revenir sur mon login :mad: !

Merci encore pour votre aide....
Répondre
#25

dans ton /etc, tu as les fichiers d'initialisation des terminaux virtuels tty.
en
1) regarde si tu as bien un tty5.conf
2) regarde dans les autres tty<X>.conf si il ne log rien dans le 5.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)