Sommaire
Bonjour tout le monde,
Depuis quelques temps je m'intéresse aux mini ordinateurs/cartes de développement ARM. J'ai écrit ce journal pour partager avec vous les connaissances que j'ai acquises et récupérer d'autres informations en échange.
Je vais essayer de présenter quelques possibilités actuellement offertes par des systèmes basés sur linux pour ce genre de matériel.
Attention ce n'est pas un journal exhaustif, les corrections et compléments sont les bienvenus dans les commentaires.
Présentation de devices
Je commence par la présentation des 3 devices à base d'ARM que je connais le mieux.
Wandboard (Freescale imx6) :
- projet communautaire, dispose de 3 variantes plus ou moins puissantes, complète et cher.
- Carte de développement qui dispose d'un boitier officiel plutôt sympa.
- Officiellement supporté par Fedora (en mode headless).
- Même SoC que le Cubox-i, donc peut profiter assez facilement des développements faits pour les Cubox dans différents projets (exemple OpenELEC.tv).
Cubox-i (également Freescale imx6):
- Mini PC (vraiment très petit) plutôt bien fini, avec également plusieurs variantes
- Construit par la société SolidRun qui semble jouer le jeu de l'open-source et investit dans des projets existants pour assurer le support de ses ordinateurs plutôt que de redévelopper des.
- Entreprise orienté communauté (le site a une section communauté mise en avant avec un forum et un wiki).
Soc imx6 commun au 2 "ordi" précédent:
- le boot est géré par u-boot, et permet donc des mises à jours simples des systèmes d'exploitations (une mise a jour des fichiers sur le périphérique de démarrage suffis).
- Les parties display, IPU (Image Processing Unit) et partie accélérateur graphique Hardware sont séparés. Les deux premières sont sont propre au SoC Feescale, et la dernière partie est composé d'un ou plusieurs coeurs Vivante (selon la configuration du SoC).
- La partie display a un driver kms/drm upstream qui gère la sortie HDMI.
- La partie IPU a un driver upstream : ipu-v3.
- La partie accélération 2D/3D a un driver kernel open-source accompagné d'une partie userspace fermé. La partie kernel n'est pas kms/drm mais basé sur fddev (FrameBuffer) et n'est pas upstream.
- Un driver userspace open-source qui utilise avec la partie kernel open-source de vivante : etnaviv.
- Un driver drm/kms complet avec une partie userspace incluse dans mesa est aussi en développement.
- Possède une unité de décodage et encodage vidéo, par contre je ne sais pas si c'est géré en open-source, closed-source ou les deux.
IFC6410 (Qualcomm Snapdragon 600):
- Utilise fastboot: charge directement une image de boot contenant le kernel et l'initramfs. ça veut dire qu'à chaque mise à jour du kernel il faut reconstruire l'image et la flasher/l'installer dans la partition de boot.
- Le projet Freedreno pour ajouter le support des GPU Adreno dans la stack Linux (drm/kms) est (très) bien avancé (on peut utiliser un bureau Gnome Shell, OpenGL 2.1 est supporté)
- possède 4 Go de eMMC embarqué ou l'on peu installer le système.
- par défaut le partitionnement est très "complexe" (beaucoup de partitions dont je ne vois pas l'utilité)
- Le projet Linaro sort tous les mois des builds qu'on peut flasher sur la carte tout les moins. Build basé sur Ubuntu et Gnome 3.
RaspberryPI (Je n'en possède pas mais je voulais ajouter quelques remarques sur ce projet) :
- L'énorme succès du RaspberryPi a eu d'énormes retombées sur les autres projets à base d'ARM. Ce projet a montré au "grand public"(je me comprends) que les processeurs ARM n'étaient pas limités au smartphone.
- l'embauche d'Eric Anholt par Broadcom semble porter ses fruits, le support du GPU est intégré dans mesa upstream, et la partie kernel le sera probablement aussi (je ne suis pas l'avancement de cette partie)
- L'ajout du support du RaspberryPi dans divers projets open-source permet l'ajout du support d'autres cartes ARM plus facilement (Exemple avec OpenELEC).
Divers Projets :
- Fedora supporte officiellement un certain nombre de cartes ARM (Fedora 21 : Banana Pi, CubieTruck, BeagleBone, CompuLab TrimSlice, Wandboard, PandaBoard)
- OpenELEC qui était à l'origine destiné aux ordinateurs x86(x64) avait ajouté le support des cartes RaspberryPi et vient d'ajouter le support officiel des Cubox-i pour la nouvelle release (OpenELEC 5.0). Dans ce cadre et avec l'aide et la participation de quelques autres intéressés nous sommes en train d'ajouter le support des Wandboard.
- Lakka projet visant a transformer un ordinateur en plateforme d'émulation. Ce projet semble avoir un nombre non négligeable de carte ARM dont le support est en développement. Mais le projet est encore jeune.
- Yocto : Project plus orienté industriel, c'est un système de build orienté embarqué. Il permet de construire un OS personnalisé pour un matériel particulier.
Avis personnel :
Avec tous ses projets communautaires et/ou commerciaux (ceux que j'ai cités et les autres) j'ai l'impression que les ordinateurs à base d'ARM sont en train de devenir de plus en plus accessible et facile à utiliser pour des utilisateurs moyennement initié.
Et ça ne promet que du bon :)
Ce que j'attends le plus: l'intégration upstream des drivers graphiques(et multimédia) open-source pour une utilisation facile out of the box des distributions classique.
Je sais que ce n'est pas gagné, et qu'il reste du travail, mais ça semble progresser dans le bon sens. Le projet Freedreno commencé par Rob Clark en indépendant reçois aujourd'hui des contributions de Qualcomm, le projet etnaviv qui continue(doucement pour l'instant), Nvidia qui utilise Nouveau pour le projet Tegra K1 et y contribue.
Ce que je trouve dommage c'est que les projets communautaires n'ai pas plus de moyen humain, ils ont des tarifs intéressant pour l'achat des cartes, mais ensuite les utilisateurs n'ont que peu de possibilité pour aider les projets. En ce qui me concerne par exemple, j'ai des connaissances en programmation, mais peut de temps libre pour aider, par contre je pourrais donner régulièrement un peu d'argent pour soutenir les projets, et donc bénéficier des retombées. J'ai déjà acheter assez de cartes, maintenant je pourrais.
Mais je comprends très bien que ça ne soit pas facile à mettre en place, et que ça soit risqué financièrement.
Et vous :
Suivez-vous un ou plusieurs projets de plus ou moins prêt et éventuellement à quel projet participez vous ?
# les odroid de hardkernel ?
Posté par palm123 (site web personnel) . Évalué à 8.
Bonjour
Merci pour cet état des lieux.
Un de mes amis est fan des odroid de hardkernel
http://www.hardkernel.com/main/shop/good_list.php?lang=en
en gros un CPU plus récent que le Rasp, des performances bien meilleures, un prix équivalent
Leur comparaison du odroid c1 avec le Raspberry-B+ est sévère (à partir du milieu de la page)
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433
ウィズコロナ
[^] # Re: les odroid de hardkernel ?
Posté par xoddark . Évalué à 2.
Effectivement j'avais regarder pas mal leur carte a une époque.
Il me semble que la partie display des exynos à des drivers upstream dans le kernel, par contre la partie acceleration graphique (mali) n'en a pas.
Dommage que le projet lima ne soit plus actif.
[^] # Re: les odroid de hardkernel ?
Posté par zurvan . Évalué à 2. Dernière modification le 31 décembre 2014 à 17:12.
l'odroid c1 semble très bien, mais la force du raspberry pi c'est sa diffusion et sa communauté. Pour ce que j'en fait (connexions gpio, par exemple thermomètre, et récupération de log depuis arduino), sa faible puissance ne me dérange pas. Mais je pourrai passer à l'odroid si l'occasion se présente. C'est pas mal d'avoir ajouté un capteur IR de base :)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Liste relativement restreinte
Posté par Mimoza . Évalué à 10.
Merci pour ce journal mais ta liste est plus que restreinte. Je suis d'accord que faire l'inventaire de tout ce qui existe actuellement est ardu mais là tu t'es limité a frange infime du panel des possibilité. Tant en terme de plateforme que de constructeur.
Pour moi les Sheevaplug/Guruplug ont été un point de départ des mini-ordi de taille réduite et de prix raisonnable (<200€), ensuite on a eu les Raspberry qui a fait exploser le marché et toute une série de plateforme plus ou moins original (non clone) la suivi.
Actuellement j'ai un Guruplug+ (server) et une CubieBoard 2 en auto hébergement. Avec le guru j'ai eu quelques problème de surchauffe (impossible de laisser le doigt sur le radiateur plus de 2 sec, freeze du system) mais en mettant un plus gros radiateur et en l'ouvrant il est devenu très stable.
J'ai pris une CubieBoard 2 pour avoir plus de puissance (perf vraiiiiiiiment différentes) tout en conservant un port S-ata. Malheureusement je n'arrête pas d'avoir des I/O error lors d'accès disque un temps soi peu prolongé (30 sec à quelques minutes) m'obligeant a rebooter. Donc un peu déçu de cette plateforme au final.
Donc si tu veux une liste un peu plus complète des plateformes existante il y a ça qui est déjà une bonne base :
https://wiki.debian.org/FreedomBox/TargetedHardware
http://archlinuxarm.org/platforms
Pour les constructeurs tu en a un certain nombre que tu n'a pas cité dont les plus connus :
(liste exaustive http://fr.wikipedia.org/wiki/Architecture_ARM#Fabricants_de_processeurs_ARM)
Enfin les plateforme sont un vaste sujet dont il n'est pas forcément facile de s'y retrouvé … par exemple les CubieBoard 2 sont équipé de AllWinner A20 qui sont des double cœur ARM Cortex-A7 (famille Cortex-A), avec un jeu d'instructions ARMv7-A. Et je ne parle pas du SOC en lui même qui peut être différent suivant le fondeur.
Un tableau récapitulatif des implémentations de la famille Cortex (les version les plus puissante) :
http://fr.wikipedia.org/wiki/ARM_Cortex-A#Impl.C3.A9mentations
[^] # Re: Liste relativement restreinte
Posté par xoddark . Évalué à 3.
Effectivement ma liste est très restreinte, l'idée était de parler des plate-formes que je connais pas trop mal.
Mais je reconnais que mon titre est trompeur, je m'en excuse mais je n'en ai pas trouver de mieux.
Par contre si d'autre personnes sont intéressé pour participé, peu être qu'une dépêche pourrais être créé à partir de ce journal et des différents commentaires. Peu être en orientant un peu plus sur les utilisations possible et accessible sur ce genre de matériel.
[^] # Re: Liste relativement restreinte
Posté par Mimoza . Évalué à 4.
Je suis prêt a t'aider sur le sujet. Mais en période de vacances/fêtes tu ne vas pas avoir énormément de participant, la semaine qui vient risque d'être difficile pour moi aussi. Donc ne t'attend pas à voir publier la dépêche dans la semaine.
[^] # Re: Liste relativement restreinte
Posté par xoddark . Évalué à 2.
Ok, Je ne suis pas pressé, je préfère la qualité :)
J'essaierais de préparer une base de dépêche dans les jours à venir.
[^] # Re: Liste relativement restreinte
Posté par BAud (site web personnel) . Évalué à 5.
N'hésite pas à utiliser l'espace de rédaction, on n'est pas aux pièces, c'est pas comme si certaines dépêches sont en rédaction depuis plus d'un an :D
[^] # Re: Liste relativement restreinte
Posté par Ph Husson (site web personnel) . Évalué à 2.
Je suis assez intéressé par contribuer à une dépêche du genre
Typiquement Mimoza oublie deux très gros constructeurs que sont MTK et Qualcomm (sauf que eux ils font plus du téléphone, et y a pas vraiment de cartes de dev MTK à ma connaissance), et par contre les Omap eux sont proches de la mort (disons qu'ils ont un parc installé assez important)
Après du coup ça serait une dépêche orientée sur les cartes de dev ou Linux sur ARM en général ?
Et ça serait pour connaître l'état de libritude/remontée upstream, les usages ?
[^] # Re: Liste relativement restreinte
Posté par xoddark . Évalué à 1.
Cool, tant qu'a faire autant présenté le maximum d'info.
L'idée pour moi était de parler plus des utilisations ou la bidouille est possible, à l'opposé des téléphones ou le bootloader est fermé par exemple.
Je ne pense pas qu'il y est besoin de lister toute les carte de dev. Wikipedia fait ça très bien. Par contre lister les mini ordinateur ARM orienté utilisateur final peu être sympa (Cubox, TBS matrix, etc).
Et ensuite la partie software, à la fois l'état de libritude/remonté upstream et les usages possible.
Je pense que c'est ce qui intéressera le plus les lecteurs de linuxfr :)
Ensuite si vous avez d'autres idées de contenu on rajoutera.
[^] # Re: Liste relativement restreinte
Posté par Ph Husson (site web personnel) . Évalué à 2.
Je sais pas si c'est très courant, mais aucun téléphone Archos n'a de bootloader verrouillé à ma connaissance.
Certains ont même un bootloader opensource (et pour les autres j'ai surtout pas cherché.)
Après, c'est le bootloader application, pas radio, mais vu qu'on parle de Linux, c'est bon.
Et les smartphones ont des propriétés intéressantes (compactes, sur batterie, prévu pour consommer peu), qui font qu'avec une bonne plateforme ils pourraient être utilisés pour des hacks.
Sinon, un article qui parle de tout ça va quand même faire 15km…
# du cloud à base d'ARM
Posté par palm123 (site web personnel) . Évalué à 6.
Limite HS : Iliad lance un cloud à base d'ARM
http://venturebeat.com/2014/12/29/why-french-telecom-iliad-is-launching-an-arm-based-cloud-service-and-why-it-matters/
ウィズコロナ
# Deux autres...
Posté par Tonton Th (Mastodon) . Évalué à 7. Dernière modification le 30 décembre 2014 à 16:28.
Dans le vaste monde ARM, il y a trois projets que j'ai découvert récemment, et qui semblent techniquement très amusants, quoique assez à l'écart du kernel Linux :
Et vu mon penchant pour les vieilleries, je pense qu'un Due va bientôt rejoindre mon parc de Raspi…
[^] # Re: Deux autres...
Posté par Christophe B. (site web personnel) . Évalué à 4.
WordStar sur CP/M … tu as trouvé les binaires sur des plaques d'argile au format cunéiformes ?
[^] # Re: Deux autres...
Posté par Tonton Th (Mastodon) . Évalué à 5.
Non. Mais un peu aussi. D'un autre coté, avec tous ces trucs de virtualisation de djeunz que vous avez maintenant, les bons trolls se perdent.
De mon temps, quand j'étais jeune (p'taing, ya bien plus de 30 ans !), le gros fight était hard ou soft sectored ? et je peux te dire que c'était bien plus intense que les calembredaines actuelles, genre Emacs/Vi ou fortran95-pgsql/nodej-mongo-websock-nosql…
[^] # Re: Deux autres...
Posté par Christophe B. (site web personnel) . Évalué à 2.
Encore un Cyber papy :)
J'ai connu aussi les "trous dans les disquettes" sur Commodore 64 dans les années 80
Les modems 300/1200 bauds et les premières connexions Minitel, Transpac …
Les 2 boites à chaussures de disquettes rempli de programmes divers et variés …
mais aussi … les notes de téléphones qui vont avec, la lenteur du lecteur de disquette Commodore
la connectique spécifique, les imprimantes incapables de fournir des accents …
nostalgie quand tu nous tiens …
[^] # Re: Deux autres...
Posté par pasBill pasGates . Évalué à 1.
Pfff petit jeune…. moi je sauvais mes premières lignes de code sur cassette audio avec mon Intellivision !
[^] # Re: Deux autres...
Posté par Christophe B. (site web personnel) . Évalué à 2. Dernière modification le 31 décembre 2014 à 09:19.
Tu me devances de peu … j'ai fait la même chose sur ZX81 en 1981/82
Je savais pas que ces consoles permettait de coder … en Basic ?
Bonne et heureuse année à toi, santé et prospérité pour ta famille
Oh toi pBpG notre seigneur Sith local
[^] # Re: Deux autres...
Posté par Maclag . Évalué à 3.
Intellevision? Cassette??
Complètement hors sujet, mais pour moi, l'Intellevision, c'était une console de jeu.
(d'avant garde, avec un disque tout bizarre au lieu d'une croix pour les directions et un pavé numérique complet, suis passé grand maître du jeu de bataille navale dont j'ai perdu le nom…).
Ma première expérience avec un engin programmable fut un TO8 à disquettes que nous achetâmes bien plus tard.
Puis vient l'Amstrad 1512 à deux lecteurs de disquette (et ça épatait les gens à l'époque…)
[^] # Re: Deux autres...
Posté par Kerro . Évalué à 1.
avec moins de 512 octets de mémoire vive (pas kilo-octets, non non, octets), donc c'est du pipeau d'écrire et sauvegarder des programmes sur cassette.
[^] # Re: Deux autres...
Posté par pasBill pasGates . Évalué à 4.
http://en.wikipedia.org/wiki/Entertainment_Computer_System
Hardware
- ECS EXEC/BASIC ROM, containing the built-in BASIC programming language and additional BIOS routines to handle the added hardware features
- additional 2kB of system RAM (supposedly, the system could be further expanded to as much as 64kB with add-on memory modules, but no such modules ever made it to production)
- additional AY-3-8910 sound chip (this was the same sound chip used in the Intellivision)
- a cassette recorder/printer interface (used the same peripherals as the Mattel Aquarius)
- two additional input ports for the alphanumeric Computer Keyboard, the Music Synthesizer keyboard, or two additional Intellivision Game Controllers.
[^] # Re: Deux autres...
Posté par Tonton Th (Mastodon) . Évalué à 2.
Rahhhhhaha !
[^] # Re: Deux autres...
Posté par cortex62 . Évalué à 1.
Ah oui, c'est dans le même genre que les Colecovision/Adam. Le système Intellivision lui je ne l'ai jamais vu. Sauf erreur c'etait un processeur 16 bit a moins d'un Mhz (oui, moins d'un)
[^] # Re: Deux autres...
Posté par Christophe B. (site web personnel) . Évalué à 5.
Quand tu apprends à programmer sur 1024 octets de RAM avec sauvegarde sur K7 Audio
tu comprends mieux certaines choses, car tu es obligé de réfléchir sur comment ne pas gaspiller des octets.
Ensuite cela t'obliges a factoriser ton code, tu évites d'écrire deux fois la même chose.
De plus ce genre de machine (ZX81, VIC 20, CBM64) t'amènes inévitablement vers l'assembleur
et la tu découvres vraiment ce qu'est l'informatique.
Et pour ce qui est du pipeau, au siècle dernier j'ai développé un devis pour imprimeur complet avec un IS 11 avec 80Ko de RAM et sauvegarde sur K7 et impression du devis.
Quand je vois des personnes, se dire informaticien, alors qu'ils se bornent à pisser des lignes de codes en copiant/collant sans trop réfléchir aux besoins CPU et RAM.
Ou d'autres qui préfèrent gaspiller 100 Go plutôt que de réfléchir à comment on pourrait faire un jeu d'essai de 3 ou 4 go.
je vois bien qu'on a pas eu le même parcours
[^] # Re: Deux autres...
Posté par Maclag . Évalué à 3.
Restons calmes. "C'était mieux avant", je veux bien, mais aujourd'hui, on a d'autres objectifs et contraintes qui tiennent compte des progrès techniques.
Effectivement, aujourd'hui, il y a certainement beaucoup de dévs qui n'optimisent que peu ou pas du tout leur code.
Mais aujourd'hui, on leur demande de faire en 3 jours ce qui aurait pris 1 mois en assembleur optimisé auparavant.
[^] # Re: Deux autres...
Posté par Christophe B. (site web personnel) . Évalué à 4.
Mais je suis CAAAAAAAAAAAAALLLLLLLLLLLLLMMMMMMMMMMMMMMEEEEEEEEEE
Je plaisante :)
"C'était mieux avant" … NON c'est mieux maintenant, je te l'assure
AVANT : pour coder il fallait acquérir le compilateur et c'était TRES cher
MAINTENANT : tu as gratuitement PLEIN de langages
AVANT : la doc papier (quand tu l'avais) était le seul moyen d'apprendre
MAINTENANT : tu copie/colle ton problème google te trouves la solution
AVANT : connecter une imprimante / un modem n'importe quel périphérique pouvait prendre des jours
MAINTENANT : vive l'USB et le RJ45
AVANT : transférer 1 Mo prenais des heures et parfois cela n'allait pas jusqu'au bout
MAINTENANT : 10 Go prends des heures
Et je pourrais continuer comme cela longtemps
Ce que je trouve dommage c'est que l'on gaspille le CPU / la RAM le stockage comme si c'était des ressources infinies.
Après on se retrouve avec des situations aberrantes et des problèmes aberrants et crois moi je suis très bien placé pour le savoir …
Car quand les chefs de projets dev et autres bestiaux nuisibles sont dans la m…. il viennent chouigner vers mon collègue et moi.
Bon j'exagère mais à peine
[^] # Re: Deux autres...
Posté par Kerro . Évalué à 2.
Moi aussi je suis vieux : j'ai appris à programmer en assembleur sur une machine avec 1 kio de RAM. Et donc ?
À ma connaissance une machine avec 512 octets de mémoire n'avait pas de quoi enregistrer/lire un programme externe. Sur 500 octets on faisant un truc animé à l'écran, on bricolait un bidule amusant, et… et c'est tout. Le fabricant n'augmentait pas le prix pour implémenter de quoi brancher un magnétophone.
Par contre les machines avec des extensions oui. Le ZX81 par exemple était livré avec 1 kio, mais était nativement fait pour accepter au moins 16 kio. Donc magnétophone connectable.
[^] # Re: Deux autres...
Posté par lasher . Évalué à 2.
J'étais vert d'envie envers mes potes au CPC et mes potes au PC1512. Par contre, un cousin avait fini par me filer une console TI99A, qui était « meilleure » qu'un MO5 ou TO7, mais qui n'avait pas de lecteur 3"½.
[^] # Re: Deux autres...
Posté par cortex62 . Évalué à 7.
Les vieilleries…. En effet, la mode est au "retrogaming", quand je vois CP/M sur un arduino DUE et Alan Cox qui code un noyau pour Z80 , on en arrive au "retrocoding" semble t'il.
# Périphérique USB ARM
Posté par erdnaxeli (site web personnel) . Évalué à 3.
Je profite de ce journal pour demander de l'aide. Je recherche une carte ARM sachant faire de l'USB en tant que périphérique (et non pas hôte) ainsi que du WiFi (ou au pire de l'ethernet. Il y a plusieurs carte qui font ça, notamment le beagle bone, mais c'est physiquement gros (dans l'idéal ça ne devrait pas être plus gros qu'une clef USB) et il y a plein de choses qui me seront inutiles (comme le processeur graphique).
Je dis ARM mais en fait ce que je veux surtout pouvoir faire tourner du Linux, parce que c'est beaucoup plus simple. Je ferais bien de l'arduino où quelque chose du genre, mais s'il y a déjà plein de code pour se faire passer pour un clavier, il n'y en a pas pour faire de l'UMS. Et je n'ai pas vraiment envie de le coder, c'est pour ça que du Linux (qui gère ça très bien) serait préférable.
D'ailleurs je dis USB, mais quelque chose qui sait se faire passer pour une carte SD me conviendrait aussi. Je dis ça en pensant aux cartes SD WiFi comme la Transcend ou la PQI Air. Ces cartes (qui partagent le même matériel) se hackent très bien et font tourner du Linux. Malheureusement ce n'est pas le firmware Linux qui s'occupe de communiquer en SD, c'est une puce spéciale qui gère les accès en lecture depuis deux sources (l'host et le firmware linux), ce qui ne permet pas l'écriture sans risquer de corrompre le système.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Périphérique USB ARM
Posté par Ph Husson (site web personnel) . Évalué à 2.
En carte de dev grand public et relativement abordable, je pense pas que tu trouveras vraiment mieux que la Beagle Bone pour ça
(Tu veux simuler un périphérique de stockage en soft ? ça a l'air marrant)
[^] # Re: Périphérique USB ARM
Posté par samydb . Évalué à 2.
Peut-être - si j'ai bien compris ton besoin, une connexion du genre USB2TTL - la carte VoCore ( http://vocore.io/wiki/index ) devrait être un candidat potentiel. Ca marche sous openwrt.
[^] # Re: Périphérique USB ARM
Posté par Ph Husson (site web personnel) . Évalué à 3.
De ce que je comprends, son besoin c'est d'avoir accès direct au bus usb ou sdio lui-même, sans intermédiaire.
[^] # Re: Périphérique USB ARM
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
Le RT5350 permet de se mettre en mode USB-CDC en slave, il suffit de changer la DTS du kernel pour qu'une pin (je dois retrouver laquelle) soit en mode up. De plus, le chip consomme en dessous des 500mA.
# Armadeus
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
Armadeus Project est spécialisée depuis longtemps aussi dans les cartes à base d'arm.
Ils sortent en ce moment l'apf6 à base d'i.MX6.
Le support d'un bsp à base de buildroot est dispo sur sourceforge.
Ce qui est spécifique avec ces cartes, c'est qu'il y a toujours (hormis apf28) une version disponible avec un FPGA. Cela permet d'étendre la possibilité des périphériques déjà disponibles dans le processeur freescale.
J'ai plus qu'une balle
# TrimSlice
Posté par Damien Thébault . Évalué à 2.
Merci pour ce journal, je ne savais pas que le TrimSlice était supporté par Fedora !
Du coup je vais peut-être installer ça plutôt que ça reste trainer dans un coin par faute de temps pour créer une distribution aux petits oignons :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.