Linux nm4

Vous devez être identifié pour accéder aux forums. Vous pouvez faire cela ici

Auteur Message

Mouche

Lundi 04 Août 2008 11:05:38

Bonjour à tous,
Sur l'ancien forum, j'ai repéré des messages indiquant des soucis sous Linux (mais comme j'avais acheté la bestiole avant tant pis pour moi).
Ceci étant, je trouve qu'écrire compatible Linux 2.4.2 sur la boite quand absolument aucune indication n'est fournie sur comment le faire fonctionner, ça s'apparente à de l'arnaque, et je trouverais normal qu'un commercial de chez neonumeric explique la politique de la maison sur le sujet. Au vu du forum précédent (le xooit....) ça fait plus d'un an que ça dure. Mais je ferme cette parenthèse pour le moment.
Comme d'autres utilisateurs, il m'était complètement impossible de communiquer avec le lecteur depuis Linux (plantage en quelques secondes).

Le système est de type "Rock", RockUSB ou RockChip. En fouinant, j'ai trouvé le début de solution suivante (merci à http://www.sprocketandlube.com/shownews/item/67) :

Le problème viendrait su fait que le système RockChip (ou au moins celui qui équipe le nm4) ne peut pas transférer beaucoup de données d'un coup (en entrée et en sortie), en tout cas moins que la valeur par défut de Linux. Il faut donc forcer la limitation de la taille des transferts unitaires.
Pour cela, écrire 64 dans le fichier max_sectors qui se trouve dans /sys/blocks/sdf/devices, où « sdf » est le numéro de device scsi du nm4 (sdf c'est sur ma machine, sera différent sur d'autres machines). On peut trouver ce numéro de device en faisant lsscsi.
C'est toujours pas parfait (quelques plantages) et la connexion est lente, mais on arrive à faire des transferts. Neonumeric ou "Rock" pourraient faire l'effort de donner toutes les informations nécessaires pour une vraie communication.

Pour que le 64 s'écrive tout seul à partir de udev qui est le bout de Linux fait pour reconnaître tout seul les périphériques, la solution consiste à créer la règle (ajouter la ligne) :

BUS=="scsi", SYSFS{vendor}=="RockChip", RUN+="/bin/sh -c '/bin/echo 64 > /sys/block/%k/device/max_sectors'"

dans un fichier reconnu par udev (n'importe lequel a priori, son nom doit finir par .rules). J'ai crée un fichier appelé program.rules avec juste cette ligne dedans dans le répertoire /etc/udev. Sur mon système Debian (je ne sais pas si c'est pareil pour tous les systèmes Linux), les fichiers « .rules » sont recherchés par udev dans /etc/udev/rules.d, j'ai donc ensuite ajouté un lien de /etc/udev/rules.d/080-program.rules vers /etc/udev/program.rules [c'est bizarre, mais c'est comme ça que c'était fait pour d'autres fichiers .rules, j'ai juste fait pareil !].

C'est pas très joli, ça marche moyennement, mais c'est mieux que rien !
Si quelqu'un a mieux, je suis preneur !
A+

PS : j'avais déjà posté ce message sur le forulm "univers" mais c'étati pas la bonne place
PPS : ce qui reste curieux, c'est que Linux reconnait très mal la partition FAT32 sur le nm4, alors qu'il reconnait sans peine les partitions sur d'autres systèmes USB, et ce qui est encore plus curieux, c'est que ça ne l'empêche pas de fonctionner (enfin jusqu'à présent).

Mouche

Lundi 04 Août 2008 12:52:58

Addendum :
ça marche aussi avec 128 à la place de 64 dans /sys/block/sdf/device/max_sectors... et ça devrait être plus rapide.

Pour l'exemple, rècgle udev :
BUS=="scsi", SYSFS{vendor}=="RockChip", RUN+="/bin/sh -c '/bin/echo 128 > /sys/block/%k/device/max_sectors'"