benoar a écrit 4238 commentaires

Tiens d'ailleurs ce serait encore plus clair comme ça :
import csv
for prenom, nom, code in csv.reader(file("monfichier.csv")):
  print code + prenom[0] + nom

Oui, je suis lourd, mais bon :

import csv
for x in csv.reader(file("monfichier.csv")):
  print x[2] + x[0][0] + x[1]


Que je trouve, comme d'hab, plus lisible.

Encore une fois, je ne demande pas à ce qu'ils filent leur sources ! C'est exactement la fausse conclusion qui tombe à chaque fois qu'on parle des drivers Nvidia ... Non, je ne veux pas les obliger à "libérer" un travail qu'ils ont le droit de mettre sous la licence qu'ils veulent !

Ce que je veux, c'est qu'ils ouvrent l'ISA, bref, une documentation qui explique comment _s'interfacer_ avec le bouzin. Ce qui serait pour moi tout à fait normal. Point de vue utilisateur, ce qui est fait actuellement serait exactement comme te filer une boîte noire sans bouton, c'est complètement inutile.

OK, merci pour ces infos. Je comprend mieux maintenant ton besoin d'un kit complet. Par contre, je continue de penser que c'est une fausse excuse, si tu l'utilises comme argument contre l'ouverture des DSP.

Pour la standarisation des interfaces, oui, c'est toujours une bonne chose. Mais je dirais que ce n'est pas assez souple pour les besoins actuels, et qu'un accès direct au DSP serait quand même vachement plus cool.

J'en ai entendu parler ici :
http://www.armadeus.com/francais/produits-cartes_microproces(...)
Des kits à 100/200€ quoi. Par contre, je ne sais pas trop à quelle puissance ça correspond.

"ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.

Juste pour préciser, quand je dis "ouvrir", c'est avoir la doc des opcodes, c'est tout. C'est la base, quand même ...

Sur ton mobile? le simulateur android par exemple

Non, je n'en ai pas besoin.

Ou un petit gcc-arm par exemple.

Oui, ça ça me suffit, et en plus, ça existe déjà (et ça a été fait par des libristes !).

Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent)

Mais c'est quoi une "board" pour toi ? Moi, j'ai déjà mon matos (un téléphone, une beagleboard, un N900, etc) et ça me suffit pour faire marcher mon DSP !

les connecteurs

Quels connecteurs ?!!

un os debug dessus...

Pourquoi ?

J'ai l'impression que tu as une vision complètement formatée par les constructeurs ... "Il faut forcément le kit complet". Je suis d'accord que mon espoir d'avoir de la doc est un peu vain pour l'instant, mais aujourd'hui si j'arrive à reverse-engineerer ces specs, je peux compiler mon propre blob et le faire tourner par le DSP, sans aucun matos ou soft supplémentaire ! Par besoin de connecteur spécial, de debugger spécial ... ! Je ne vois pas ce dont tu veux parler.

Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).

Là je vais redevenir vulgaire : j'ai _horreur_ des mecs qui me disent ce dont je suis capable ou pas. Franchement, avec tout ce qui existe en libre dans tous les domaines aujourd'hui, je ne vois pas comment on peut continuer à sortir ce genre d'argument débile. (dans le genre de programmation "pointue", j'ai codé des routines de manipulation d'image (blending, ...) pour Enlightenment en Altivec sur PPC, avec prefetch, alignement correct, maximisation de la BP ; je veux bien que coder un DSP soit compliqué, mais quand même).

Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.

Et alors ? Tu fais dans l'obscurantisme ! "vous en serez pas capables", "vous n'avez pas l'argent", "c'est trop dur pour vous" : aucun de ces pseudo-arguments ne peut être utilisé de manière valable : c'est juste de la dissuasion. C'est tout ce dont j'ai horreur dans le monde proprio, et qui disparaît complètement dès qu'on ouvre le truc.

Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!

Aurais-tu des exemples de programmes sur DSP ? Ça m'intéresse beaucoup, car je vois beaucoup de personnes dire que c'est inchiable, mais personne n'en montre.

A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).

Je viens d'aller voir, je ne connaissais pas, mais ça a l'air de s'approcher d'OpenCL. C'est vrai que ça pourrait être une solution qui aiderait à résoudre le problème des codecs. Mais si j'aurais mon côté râleur qui dirait que ça ne change rien à la situation fermée des DSP. Mais bon, au moins, ce sera plus souple.

Rhaa, injonctions bien sûr.
Le pire c'est que je suis moi-même sur la page que tu cites ...

Bon, effectivement, c'est abusé de ma part de dire qu'on achète que des puces "toutes prêtes" et qu'on ne fond rien : TI ou Freescale fondent effectivement des IPs. Et fournissent un gros travail d'intégration.

Ce que je souhaitais préciser, c'est que ces IPs sont des trucs relativement "standards", comme le ARM ou le C64. Et aussi que moi je ne me fous pas de ce que ne fournit pas le toolkit : je suis un bidouilleur libriste qui veut savoir ce qu'il y a "derrière" (bon, là je m'écarte du sujet pour relancer mon idée, déjà citée plus haut, d'ouvrir un peu plus ces trucs).

Parce que le problème d'accélération dont on parle ici est exactement ça : quelle est la limite entre ce qu'"on" peut reprogrammer ou non (sachant qui si tu as un gros porte-feuille, je pense que tu peux "tout" reprogrammer, car tu peux par exemple fondre tes propres IPs ... oui, j'ai dit un très gros porte-feuille).

Mon argument était que, les DSP étant reprogrammable (d'ailleurs j'ai du mal à voir ton IP de DCT en interne du DSP : que veux tu dire exactement par là ? genre un peu comme on intègre du MMX dans un CPU ?), pour moi, l'argument du "on ne peut pas faire autre chose que du H264 car c'est câblé en dur" est caduc. Car n'importe qui avec des compétence sur un C64 pourrait te refaire la même chose pour VP8 ou Theora (des compétences et "un peu" de temps, certes, mais comme dans n'importe quel domaine ou le libre avance).

Toi, tu pars du principe que comme le toolkit ne présente qu'un accès "haut niveau" au décodage H264, en gros, c'est câblé "en dur" et on ne peut rien faire d'autre. J'ai bien reformulé ton idée ?

Alors, d'un point de vue pragmatique, je suis d'accord avec toi. Mais d'un point vue même pas théorique, mais simplement pratique, c'est débile car un DSP est reprogrammable par définition : c'est toi-même avec ton linux qui va même charger le programme du DSP en mémoire !

Bref, pour moi, la barrière de la fermeture du DSP est complètement artificielle, et pourrait facilement sauter si les DSP retrouvaient leur vrai nature.

Je remarque aussi qu'on a le même problème avec les FPGA. Je ne sais pas si les constructeurs se rendent compte que s'ils ouvraient un peu plus leur produits, ils auraient un public énorme en plus (ok, ce n'est qu'un avis de libriste ...).

(sauf problèmes de transit éventuels)

Effectivement, vu l'utilisation de ton forfait Internet, si tu as un problème de transit, tu risques d'exploser ton forfait /o\

Encore une fois, je ne te demande pas de me faire des leçons (merci, je connais "en gros") mais de me dire quelles sont tes sources qui te parlent de ces IPs : pour moi c'est faux, comme dit Nicolas, c'est souvent juste un CPU + DSP. J'ai également bossé sur des STB (Phillips, Sagem, Scientific Atlanta) et des téléphones (Motorola) et je connais un peu leurs architectures. Par exemple, sur les téls motos sur lesquels j'ai bossé, le baseband c'est un ARM7 + DSP (le fameux Calypso dont on parlait dans une news récente) et processeur d'application est un ARM9. Fondre des IPs revient _beaucoup_ trop cher dans tous ces domaines, et c'est donc pourquoi je te demande d'où tu tiens ces infos.

Comme je disais en réponse à mon commentaire, je me suis trompé : je parlais du ST7100, qui est un CPU généraliste (ARM ou MIPS, je sais pu) + 2 copro VLIW.

Quant au 3430, c'est un ARM qui "contrôle" _un_ DSP : de quoi tu parles en disant les "autres cœurs" ?

Ce commentaire va être un peu rude, mais d'un côté, tu l'as cherché.

J'ai rarement vu un mec sur ce site se comporter de manière aussi autoritaire. Tu as fourni un beau travaille avec ce livre, certes, et maintenant tu voudrais que tout le monde soit à tes pieds sans critiquer ? Qu'on obéisse à tes injections sur un site qui "appartient" à tout le monde ?

J'avoue que je n'aime pas du tout ta manière d'éviter les réponses (quoique, tu as quand même sorti la raison du décalage entre ton apparente volonté et la licence (ton éditeur) ou bout de quelques temps ... mais quelle épreuve !) et surtout, tes menaces : c'est ce qui m'a fait basculer.

Enfin, sache que la majorité des personnes que tu cites sont à l'opposé de ce que tu t'imagines, contribuent largement au libre, et sont des personnes respectueuses et responsables. Arrêtes avec tes idées préconçues et ta mégalomanie.

Ta dernière comparaison est pas mal, mais encore une fois, d'où te viennent tes infos ? quelles sont tes sources ?

Et pour revenir au sujet, quel périphérique embarqué se targue de faire de la HD ? Où est-il écrit qu'il utilise du hard dédié ?

Enfin, je ne vois pas l'intérêt de mettre du hard différent en plus pour "simplement" traiter plus de donner (bon, je sens qu'on va me dire que c'est pas le même profile, blahblah, mais pour l'instant on parlait simplement de différence de résolution il me semble) : si ton DSP n'est pas assez rapide, t'en prends un autre plus rapide, ou t'en mets deux.

Par une "distro", je veux dire une distribution : partir d'un ensemble kernel + userspace déjà prêt, genre openembedded, buildroot-ng (openwrt), etc. Parce que partir de 0 (comme ça a l'air d'être ton cas) c'est un peu "hardcore".

Sinon, vu ton script, et mes souvenirs (d'où l'importance d'une distro : on évite les oublis bêtes), ça a l'air "correct". Peut-être que udev n'a pas encore le temps de créer les périphs avant qu'une autre partie de l'OS veuille y accéder. Ou peut-être qu'il manque un truc, mais je ne vois pas. D'où l'importance (encore) de mon premier point.

Après, udev n'est pas indispensable non plus si tu fait de l'embarqué minimal. À voir.

Non,

Essaye d'être un peu plus clair dans tes réponses, là je ne sais pas à quelle question tu réponds.

Bon OK, je comprends mieux maintenant tes problèmes.

Alors j'ai cherché vite fait sur google, je suis tombé sur ça : http://www.compulab.co.il/x270cm/html/x270-developer.py
Il y a peut-être qqch d'intéressant (mais ça a l'air très bordélique).
Après, tu as peut-être déjà trouvé ce lien, et déjà essayé, mais vu que tu n'as pas mis beaucoup de contexte dans ta requête ...
Après, je ne peux pas t'aider plus, mes compétences ne le permettent pas.

Bon courage.

Un signe que c'est le "futur" quand même, c'est que l'autoconfiguration est intégrée de base à IPv6.

Pour tous les possesseurs de Mac PPC, sachez que Benjamin Herrenschmidt a inclus dans cette release son driver macio qui est le portage vers la "nouvelle" pile ATA (libata) de l'ensemble des drivers ATA (IDE) utilisés sur les PowerPC newworld (au moins ; je ne sais pas pour les autres).

Vu que l'ancienne pile va sûrement jarter un jour, c'est une bonne nouvelle pour cette archi qui se voit ainsi encore un peu considérée. Par contre, même si c'est un "simple" portage, testez !

Je ne sais pas de quel kernel tu viens, mais le firmware de cette carte a été enlevé du kernel pour le 2.6.32. Maintenant, il faut le charger de "l'extérieur".

Ça a l'air d'un truc spécifique à ta carte, donc déjà : regarde ce que fournis le constructeur. Il a sûrement fourni un noyau pour, ou des patchs ? (peut-être pas pour la bonne version)
Ensuite, tu veux dire quoi par "porté" ? À mon avis, linux tournait dessus bien avant que tu ne le fasses. T'as ajouté le support de qqch en particulier ?
Enfin, je ne suis pas sûr que ce forum soit la meilleure place pour un problème si particulier ; enfin, c'est à voir.

Change le disque et ajoute de la RAM ; c'est une bonne solution pour ne pas avoir à tout changer.

Ou si t'en veux absolument un neuf, mets le plus d'argent dans le disque et la RAM.

C'est le plus important, le reste ça ne change rien.

Sache que l'autoconfiguration que fait Windows, Linux peut aussi la faire, et tout ça c'est dans une RFC (les adresses en 169.254.0.0/16) cf http://en.wikipedia.org/wiki/IP_address#Address_autoconfigur(...)

Bon alors je ne sais pas comment te répondre, vu que ton commentaire n'apporte strictement rien ... Bah, je sais pas, mes "preuves" c'est qu'un DSP c'est fait pour être programmable (c'est son but) et que donc on peut le reprogrammer ... Et c'est à peu près ce qui est contenu dans les smartphone modernes (le sujet dont on parlait), donc ... je ne vois pas quoi ajouter.

En fait, c'est très fort votre technique de demander à justifier des trucs "normaux" face à des arguments bidons qui ne veulent rien dire.

Bon, ça ne me dit toujours pas si tu bosses sur une distro faite maison ou non, mais bon ...

Donc, à priori tu fais ce qu'il faut, maintenant il faudrait savoir plus précisément d'où vient le problème : t'as un message d'erreur ? Quelque chose d'autre ? T'aurais un log à montrer, ou un bout de ton sysinit ? T'as bien monté /proc et /sys ?

Bon, déjà ce serait bien de savoir sur quel genre de distro tu te bases : si c'est du fait main complet ou pas.

Ensuite, oui, le userspace va avoir besoin d'accéder à certains devices avant que udev soit lancé. Ce sera en gros ceux que t'as listé (je crois même qu'avec juste ces deux là, on peut se démerder). Udev sera lancé après.

Par contre, apprend d'abord ce qu'est un montage. Udev va effectivement travailler dans un tmpfs, que tu dois monter avant de le lancer. Mais comme il faut que tu aies aussi un /dev avec tes devices minimum avant ça, il faudra (en général) que tu les aies dans ton FS racine sous /dev. Quand le tmpfs sera monté, bien sûr, il les recouvrira, mais udev créera alors tout ce qu'il faut.

Pour les créer, bah ... fait les mknod qui vont bien dans le FS correspondant.

Ha oui, aussi, t'as pas précisé si t'étais dans un initramfs (je suppose que non, mais on sait jamais).

Bon, j'en ai marre des gens à côté de la plaque ; ce genre de discussion mène toujours à ça car les gens parlent sur du vent, à propos de technologies tellement fermées que c'est impossible d'y arriver sans qu'un mec sorte un "je sais parfaitement que ...". C'est pour ça que je demande du concret. Ce que personne ne me donne jamais (je viens de retrouver une discussion sur le même sujet il y a 6 mois ici avec le même flagos qui sort les mêmes propos non vérifiés).

Pour revenir au point de départ (relire le journal) : le décodage soit-disant "hard" du H264, même dans l'embarqué, peut parfaitement être reprogrammé pour décoder du Théora, ou du VP8, ou quoi que ce soit de puissance équivalente (cette remarques est pour éviter qu'on me sorte du SVC ou du 1080p, qui sont des arguments inutiles ici balancés pour pourrir le débat). Il "suffit" de changer la partie soft (le firmware). C'est dur dans le sens où il n'y a pas de volonté industrielle vers ça pour l'instant, mais il n'y a aucune barrière technique.

Et d'ailleurs, comme je disais plus haut, ce serait vachement plus simple si les DSP étaient ouvert : on n'aurait pas ce problème.