TheBreton a écrit 927 commentaires

Si je lis le billet précédant c'est un soucis avec le module ark3116.c pour communiquer avec ton téléphone non ?
Comme tous module et toute partie du kernel, il dispose d'un mainteneur spécifique (personne chargé de cette partie de code)

Ici c'est bart.hartgers+ark3116(at)gmail.com qui est indiqué en haut de la source
http://lxr.free-electrons.com/source/drivers/usb/serial/ark3116.c
Donc commence par contacter cette personne par mail de préférence en anglais en expliquant ton problème.

Hop pour le sens Amiga->PC
http://www.amigaforever.com/tutorials/migration/
Pour le sens PC->Amiga
L'amiga lisait les disk 720Ko (mais pas 1440Ko) en utilisant un programme qui s'apellait dos2dos

Le lsusb tu l'as fait après ta tentative de scan ou tout de suite après le boot du système ?
Sinon mon premier conseil, surtout si ton poste est un portable, est d'essayer d'utiliser un Hub USB avec une alimentation externe (pas de hub usb auto alimenté par le port usb) car la déclaration d'enum
>bmAttributes 0x80
> (Bus Powered)
> MaxPower 100mA

me parait légère pour un tel device....

Ca ressemble à ces vieille protection que l'on avait sur l'amstrad où les disquette contenait des secteurs au formatage invalide.
En l'occurence le DVD contiendrait des bad-blocks pour vautrer un programme qui fais une lecture sequentielle brute mais qui ne poserait aucun problème pour un programme qui suit la séquence de lecture des pistes décrite dans les menu comme le ferait un lecteur DVD (peut etre l'option dvdnav de mplayer fais cela).
Désolé mais je ne sait pas comment passer outre cela.

Le link-time-optimisation ?
Non, pas essayé tout simplement parce qu'en embarqué c'est vraiment du bas niveau dont j'ai besoin et pas de l'objet elf. Je ré-écris le crt0.s (normal il faut bien initialiser le bus externe du micro et lui dire qu'il y a du monde dehors ;-) ), je vire le crt1 (mais en c++ tu en aura besoin c'est lui qui invoque les constructeurs de tes class globales) et j'écris mes script ld correspondant à la mémory map de la carte. Pas de stdlibs, je crée en assembleur les trucs vraiment indispensable (comme memcpy,save_interrupt et restore_interrupt) pour que le link fonctionne.
En gros le dernier programme que j'ai fais l'objet elf fais 90Ko mais en hex à flasher il fait moins de 30Ko (et il fait plein de choses)
Les programmes que j'écris sont stand alone, pas d'os ni fs ni beaucoup de flash ni beaucoup de ram, c'est byzance quand une des deux mémoire fais plus de 128ko.

Bon je comprend pas vraiment le coups des nombres ni le soucis avec le C++ mais voici les règles que j'utilise pour du code en C (donc ça devrais etre transposable).
Si j'ai deux fichiers (ou plusieurs ) contenant du code potentiellement non-utilisé mais sans que je souhaite le supprimer manuellement je fais

gcc -c -Os -fdata-sections -ffunction-sections main.c -o main.o
gcc -c -Os -fdata-sections -ffunction-sections file1.c -o file1.o

Ca demande à GCC pour chaque fichier de créer une section header elf spécifique à chacun de ces fichiers.
Un fichier contient a minima une section .bss pour les données et une section .text pour le programme. Quand tu ne spécifie rien, un fichier = une section de chaque type.

Donc l'élimination du code inutilisé ce base sur l'entité d'un fichier, si une partie est utilisé le fichier est entièrement mis dans l'exe finale.

Si à l’intérieur d'un fichier je souhaite plusieurs sections pour permettre une élimination plus fine (par exemple une par fonction ) je dois spécifier ca dans l'attribut de la fonction

void foobar (void) attribute ((section ("bar")));

ensuite l’édition de lien (soit avec ld soit avec gcc en front-end) ce fait avec l'option
--gc-sections (pour garbage collector section ) c'est a dire mettre à la poubelle les sections non-utilisée.

ensuite j'utilise soit readelf (des binutils), soit objdump -Dslhx pour voir ce que contient le code finalement linké

Il faut bien ce rendre compte qu'en faisant ça, on multiplie le nombre de section et donc on augmente la taille de l'exe finale il faut donc faire des compromis.

Je fais ca régulièrement car j'utilise gcc pour produire du code embarqué ou chaque kilo de mémoire est compté et je dois maitrisé le placement de certaine fonction en flash et d'autre en RAM.
Voila mes deux cts

Non, malgrès se réglage en "me demander" de mon Firefox 5, le passage en 6 à été imposé d'office se foutant de mes réglages.

Nan, ce qui est nouveau c'est que cette option à toujours été positionnée sur mon poste à "me demander", ce que firefox faisait effectivement en me demande poliment si je voulais mettre à jour et que lors de la dernière mise à jour cette option à été autoritairement et sans m'avertir mise à "mise à jour automatique" ce que je ne souhaitait explicitement pas.

Merci pour l'info, c'est donc un changement de politique imposé d'office par la MozCorp en "télécharger et installer automatiquement" car auparavant firefox demandait poliment si il devait téléchargé les nouvelles versions.

Moi aussi au démarrage mise a jour sans que j'ai rien demandé et gros moulinage du PC.
Par contre je suis sur de n'avoir cliqué nulle part.

Donc, le cast sert juste à supprimer un avertissement du compilo ?
Le cast sur la valeur du malloc oui, un avertissement est à prendre quand même au sérieux car t'indique un problème potentielle.
Exemple tu fais ton prog et tu le teste sur un x86 (donc 32 bits), puis ton PC change et tu le recompile sur 64 bits et la paf, plus rien ne marche à cause d'un cast inconsidéré/aux effetr mal évalué à l'époque, tu peut passer beaucoup de temps à trouver l'origine du pb...il faut absolument réfléchir avant de faire un cast sur les archi possible du programme.

c'est comme mettre entre parenthèse une affectation en guise de test ?
Ca c'est pas un test puisque c'est toujours vrai (de faire une affectation).

vu que toute les valeurs affectées sont converties dans le type de la variable qui la reçoit.
Normalement tu dois avoir un warning a faire des conversion implicites en cas de perte de bits significatif (exemple tu mets le résultat d'une opération 64bit dans un char qui fais 8 bits (sur beaucoup d'arch) tu perd au passage de l'information ), mais comme sur x86 presque tous les type de variable C sont codé vers du 32bits par les compilos...

La différence entre "cc -S" et objdump c'est que objdump te montre tout le code de ton appli (incluant ctr0 et crt1 les fichier de préambule des programme réalisant les initialisation des variables et des piles avant démarrage du main) ainsi que les libs static lié à ton programme, "cc -S" ne montre que ton fichier compilé avant linkage (donc les variables/fonctions externe ne sont pas référencées)

« movl $0, %eax »
return 0;

J'ai encore du boulot ^^
Surtout il ne faut pas croire que tout ce que fais le compilo est conforme à ce que tu veux et ne compter que sur lui pour indiquer les erreurs. C'est ton job de programmeur ca. ;-)

(j'ai jamais d'inspiration pour les titres des commentaires...)

Dans ce qui précède, l'étoile s'applique en gros à ce qu'il y a à sa droite, mais, les opérateurs de cast :
pf * tableau_pointeurs_fonctions = (pf *) malloc( sizeof(pf) * 4)
// déclare un pointeur sur 4 pointeurs sur fonction qui retournent un int
pourquoi est-ce que l'opérateur de cast s'écrit (pf *) ?

Non, c'est pareil,
malloc retourne un void, et donc le compilo gueulerait disant que tu associe un void à ton pointeur de tableau qui est de type pf. Le cast (pf)malloc dis au compilo que tu sait ce que tu fais et que le void* est comme un pf* (on appelle ça transtypage d'une variable).
La ligne complète cumule déclaration d'une variable de type pf* et la création d'un espace mémoire de taille 4 pf

Je sais bien que toutes ces affectations n'ont pas de sens, c'est juste pour tenter de comprendre le compilateur (gcc 4.6 en l’occurrence), et à quoi ressemble un tableau de pointeur sur fonctions qui retournent un int en mémoire ? est-ce que les argument des fonctions de ce tableau changent sa représentation ?
J'imagine que par ailleurs c'est très dépendant de l’architecture.

Alors la pour faire simple on va faire du pseudo assembleur, il faut comprendre comment marche un micro. Un pointeur sur fonction ce n'est jamais rien d'autre qu'une adresse mémoire ou aller exécuter du code.
En pseudo asm on doit donc lire un adresse dans un tableau et sauter à cette adresse (si ta fonction n'as pas d'argument).
Après le passage d'argument et la valeur de retour de la fonction sont dépendant du micro utilisé.

Sur certaines architecture RISC on va passer les arguments dans des registres micro (et si il y a trop d'argument par un pointeur un emplacement dans la pile), le code retour de la fonction est toujours dans un registre/pseudo registre défini à l'avance (pseudo registre car si le code retour est 64bits sur un micro 16bits soit c'est un pointeur sur la valeur 64bits qui est retourné, soit la valeur est séparée sur plusieurs registres).
Ce qui complique beaucoup les choses si on mixe du code venant de compilo différent et le rend presque impossible sans l'utilisation de thunk écris en assembleur (je vois pas le mots français pour ces routines à part glue-logique).

Sur les architecture CISC (comme le x86) on n'as souvent que très peut de registre donc les arguments sont mis d'office dans la pile et on passe un pointeur dans un registre à la fonction. Le code retour est dans EAX (de mémoire).

Qu'est-ce que je peux lire ou faire pour mieux comprendre ?
Le compilo produit de l'assembleur, donc apprendre à le lire est une bonne chose pour vérifier que le résultat produit est bien celui attendu. En programmation embarqué je regarde toujours toujours l'assembleur généré.

faire objdump -D mon_fichier.o |less

est riche d'enseignement.

>Comment fonctionne le chargement automatique des modules sur une distribution ?
Sous linux un module doit être explicitement chargé (ou compilé statiquement avec le kernel)

>Je sais que le fichier /etc/modules.conf permet de charger des modules au démarrage, mais cette liste a été créée à partir de quoi ?
En général ta distro lors de l'installation fait une énumération du matériel avec les commandes lspci, lsusb (ou autres comme lshw), ensuite en parcourant un fichier XML reliant les PID/VID du matériel avec les modules gérant le matériel le fichier de chargement de module est construit.

>En fait, comment est gérée la détection automatique et la liaison avec les modules sous Linux, c'est là ma problématique :)
La c'est à la fois plus simple et plus complexe, en fait les modules sont compilée sous forme de fichier objet et l'étape du linkage n'est effectué que lors du chargement par la commande modprobe.
En clair c'est pour cela que si erreur il y as, elle n'est connu que sous la forme de fonction ou de donnée non-trouvée qu'au chargement du module avec le kernel.

Bref c'est une éditions de liens dynamique des modules et du kernel, c'est pour cela que pour compiler un module il faut impérativement les header de son kernel.

A l'époque du 2.2 existait le 2.3 (2.2 stable et 2.3 experimental), a l'époque du 2.4 existait le 2.5 avec le même schéma de numérotation (impair intègre les plus récents developpement et paire stable une fois le dev experimental passant les tests).
C'est le dernier 2.4 qui est devenu 2.6 (puisque le dernier 2.5 était devenu 2.4).

Avec le 2.6 Linus à décider de laisser tomber le système qui causait des effets pervers (peut de personne voulait utiliser le 2.5 car trop risqué et lui générait double branche à maintenir) il à déclarer que le 2.7 n'existerait pas.
Donc au devrait passer au 2.8 apres le 2.6 pour ne pas bouleverser de vielle habitude.

Oui mais le module kernel n'est pas chargé non plus...
il faut regarder dans les fichiers .ko lequel contient le driver de ta clef et faire
lsmod pour voir si un vieux module est présent en mémoire (si oui faire un rmmod)
puis faire modprobe mon_driver et voir ce qui se passe

Voici la page qui parle du driver, le nom du module n'est pas indiqué mais ca devrais ressembler à tm6000.ko

http://linuxtv.org/wiki/index.php/Trident_TM6000#Kernel_module_parameter

Oui 4Mo c'est peut, c'est pour cela que j'ai mentionné la disponibilité d'un port USB sur lequel il faudra mettre une clef pour le stockage du site.

Si ton port est /dev/ttyS2 tu peut identifier le driver qui le gère (/proc/tty/drivers)
modifier les sources du modules ou du kernel pour inserer les traces des octets recu/emis (printk) et puis c'est tout.

Etonnant pour un driver usb de ne pas inclure "usb.h"
Je te conseille de vérifier dans le makefile de voir si des chemins ne sont pas incorrecte et de regarder le sources
Soit lors de la compilation il ne trouve pas le chemin vers les includes du kernel, soit une options de compilations est manquante.

http://lxr.free-electrons.com/source/include/linux/usb.h?v=2.6.33

Concernant les erreurs de compilations du driver lui-même cela est du aux modifications des stacks USB pour le support de l'USB 3.0 (SuperSpeed), je crois que cela à commencer dans le 2.6.31.
Ton driver est donc écris pour fonctionner avec une version antérieure (à une vache près je ne sait plus exactement quand les interfaces on évolué).En général dans l’entête des sources du driver on trouve la version de kernel en référence.

Je part du principe que tu travaille et compile sur ta cible, c'est plus simple
(mais le NFS est mieux que la clef USB car cela use la clef d'effacer/écrire alors que par le réseau on a des temps souvent meilleur)
Ta clef est formaté en ext3? pas FAT32 j’espère ?

Ai-je bien installé tous les prérequis ? (sources, header, outils de compilation)

outils de compilation je ne sait pas, si tu compile sur ta cible tu peut simplement récupérer les sources du kernel supporté par ton driver ici ftp://ftp.kernel.org/pub/linux/kernel/v2.6/

• Des erreurs lors de la décompression du tar.gz Non acceptable, on doit recuperer les sources proprement puis dans le répertoire ou tu as décompresser tout cela make oldconfig make

Si cela compile et que tu peut booter sur ce kernel on peut envisager de poursuivre en rajoutant le driver mais sans cette étape pas la peine de tenter d'aller plus loin déjà

En premier si j'ai bien compris tu compile sur un PC (donc X86) pour un ARM (Marvel), si le kernel se compilait de toute facons il ne démarrerait pas.

Deux procs différent, deux solutions :
1)-cross compilation (construire une chaine GCC pour produire du binaire ARM)
2)-compilation sur ton archi ARM avec un serveur distant (tu démarre ton système ARM qui doit être équipé d'un GCC-ARM et tu monte un répertoire NFS hébérgé sur ton PC qui contient les sources du kernel à compiler)

Je te conseille la solutions 2 qui à l'inconvénient du temps de compilation le plus long mais qui sera sans doute la plus simple a mettre en oeuvre.

Sur ton système ARM tu fais ensuite comme l'indique le post précédant

make oldconfig (pour avoir les options de compilation de ton kernel ARM correspondant à la carte livrée)
make menuconfig (si tu veut faire des changements)
avant de compiler...

Je ne sait pas trop, mais si le besoin exprimé est aussi basic j'ai vu récemment une démo de ces petit modules la
http://www.digi.com/products/wireless-wired-embedded-solutions/solutions-on-module/digi-connect/digiconnectme9210.jsp
qui intègre un apache de base et moyennant quelques fils à tirer d'un connecteur on peut lui rajouter une clef usb (pour ajouter de l'espace de stockage car 4Mo de base c'est pas de trop), il faut prévoir une alim 220V/3V mais on trouve ca dans le commerce pour une poignée d'euro ou mieux cela supporte le PPoE.
Le module consomme 2W(sans la clef USB) donc les couts d'exploitations je sait pas si on peut faire moins.

sata_sil24 9227 3
libata 115753 3 ata_generic,ata_piix,sata_sil24

cela indique que le module est chargé en mémoire et qu'il est utilisé par libata.
ce qui indique que le raid est directement utilisable sur ton systeme (tu dois pouvoir voir les disques) sans installation supplémentaire.
La question est pourquoi cherche tu un driver ?
Si tu pense qu'il n'est pas a jour il faut que tu change de version de kernel.
si tu veut créer et utiliser un RAID sur tes disques tu dois utiliser l'outil mdadm.
si tu ne voit pas tes disques connectés sur ce controleur il faut voir si il n'y as pas de message d'erreur en faisant un 'dmesg' dans la console

Oui le courant in-rush est mauvais pour les composants d'alimentation qui le subbissent de plein fouet (vieillissement prématuré des condensateurs, des transistors de l'alim à découpages,self,etc...)

Mais dans ton cas je suppose que l'alimentation est externe au disque (même si dans le même boitier)?

Dans ce cas dans la température et le temps de mise sous tension joue un grand rôle dans le vieillissement des composants du disque dur (condo,moteur) qui une fois en panne augmente directement le risque de perdre les données définitivement (voir MTBF du disque puisque on l'exprime en heures de fonctionnement à 25°C).

Alors qu'une alimentation défaillante demanderais simplement le changement de boitier d'acceuil du disque pour retrouver les données !

AMHA le mieux est d'éteindre le disque quand on ne s'en sert pas...

Sur un PC on regarde la RAM dispo et l'espace disque aussi pour savoir quoi faire tourner dessus.
Dans le doute je te conseille de choisir Xubuntu qui est assez léger et que je fais tourner
sur un P3-700Mhz 256Mo de ram. Par contre oublie les effets 3D (compiz fusion) et tout ca qui sont trés gourmand en CPU/RAM

http://www.xubuntu-fr.org/telechargement

-très
+très souvent