Suport technique et veille technologique

LinuxFr.org : les journaux  -  Je construis un micro-ordinateur

 -  Juillet 2023 - 

Sommaire

• Le contexte
• Les options existantes
• Le cahier des charges
• Nouvelles générations de composants
• Le logiciel
• Prochaines étapes

Bonjour!

Ce week-end j'ai construit un micro ordinateur. Je vous le présente.

Le contexte

Les micro ordinateurs (appelés parfois simplement "micros") sont apparus dans les années 1970. Ils sont nommés ainsi car ils sont plus petits que les mini ordinateurs, qui eux même sont plus petit que les ordinateurs de l'époque, qui occupaient à peu près l'espace nécessaire aujourd'hui à un supercalculateur.

En ce qui me concerne, j'ai pas mal utilisé un Amstrad CPC 6128 (plusieurs, en fait) quand j'étais plus jeune. Cette machine m'a permis de faire mes premiers pas en programmation BASIC, puis par la suite de me mettre à l'électronique pour réaliser plusieurs cartes d'extension (port USB, mémoire RAM et Flash, cartes son, …).

Il s'agit d'une machine relativement simple et sur laquelle on peut programmer en "bare metal": sans système d'exploitation et en adressant directement les composants électroniques. Le matériel est fixe et inchangé depuis longtemps et assez bien documenté aujourd'hui.

Dans l'informatique moderne, on ne parle plus trop de micro-ordinateur, le terme est passé de mode. Mais surtout, il existe peu de matériel aussi simple, ou alors, c'est très proche de ce qui se faisait dans les années 80: processeurs 8 bit ou 16 bit, quelques kilo-octets de mémoire, des composants assez peu compacts.

On trouve sinon des machines comme les Raspberry Pi (mais il y en a plein d'autres), qui proposent un matériel unifié et moderne, mais plutôt complexe à programmer en direct: l'utilisation d'un système d'exploitation est donc indispensable, et on perd l'intérêt (à mon avis) d'une machine simple sur laquelle on peut comprendre tout le fonctionnement, de l'électronique jusqu'au logiciel haut niveau.

Les options existantes

Quelques exemples de machines qui sont plus ou moins dans cet esprit:

• La plateforme RC2014 est une carte de base avec plusieurs ports interconnectés, sur laquelle on peut assembler des modules CPU, RAM, et autres cartes d'extension diverses. La version initiale utilise un processeur Z80 mais de nombreuses alternatives sont disponibles. On reste sur un systme 8 bit, minimaliste par rapport à la concurrence dans ce domaine, mais nécessitant tout de même un certain nombre de composants électroniques pour fonctionner (surtout si on veut y ajouter un écran et un clavier, par exemple)
• Des consoles basées sur les processeurs Atmel AVR8, comme la Gamebuino ou l'Arduboy. Ce sont plutôt des consoles de jeu et les capacités de la plateforme sont plutôt limitées (et souvent moins bonnes que les ordinateurs des années 80).
• Des systèmes comme l'Agon Light, qui propose un processeur eZ80 (un descendant du z80) et des capacités graphiques et sonores intéressantes, mais qui les implémente à l'aide d'un coprocesseur ESP32 plus puissant et rapide que le processeur principal, ce qui est tout de même dommage,
• Des ordinateurs comme le Mega 65 ou le ZX spectrum Next. Dans ce cas, l'idée est d'utiliser des FPGA (composants reprogrammables) pour implémenter une version améliorée d'ordinateurs existants. On retrouve donc les "sensations" d'un micro ordinateur des années 80, mais en réalité le matériel est beaucoup plus flexible (on peut d'ailleurs souvent le reprogrammer pour faire tout autre chose). De plus, le prix me semble excessif.
• Des machines comme le Raspberry Pi qu'on ne présente plus: elles sont peu coûteuses, mais le matériel est complexe et nécessite l'assistance d'un système d'exploitation et parfois de blobs binaires dont on ne sait pas trop ce qu'ils font.

Le cahier des charges

Aucune de ces solutions ne me convenant vraiment (et puis, j'avais envie de construire quelque choise moi-même), cela fait quelques temps que je surveille de temps en temps ce qu'il se fait dans les familles de microcontrôleurs et de systems-on-chips.

En effet, les ordinateurs des années 80 étaient construit à partir d'un "chipset", un ensemble de puces (parfois conçues par le même fabricant pour fonctionner ensemble, parfois un assemblage plus ou moins hétéroclyte). Mais aujourd'hui, l'électronique est beaucoup plus miniaturisée et ça ne devrait poser aucun problème d'avoir tout l'ordinateur dans une seule puce.

Les premiers exemples d'une telle intégration sont les "personal digital assistants", dont par exemple les machines de chez Palm, qui étaient basées au départ sur un composant Motorola Dragonball, regroupant un processeur Motorola 68000, un contrôleur d'écran, et divers autres composants (ports série, entrées/sortes pour quelques boutons, …). Cependant, sur ces composants, la mémoire reste un composant externe. Il faut donc un minimum de 3 puces pour réaliser un système complet: le system-on-chip, la RAM, et de la ROM ou mémoire flash permettant d'initialiser le système. De plus, on quitte le monde des systèmes 8 bit, et on se retrouve donc avec un bus d'adresse et un bus de données sur 32 bits chacun. Cela signifie un grand nombre de connexions (plus d'une soixantaine) entre ces 3 composants.

D'un autre côté, on trouve aujhourd'hui des familles de microcontrôleurs qui se rapprochent de la même idée mais intègre de la mémoire directement dans la même puce. Par conséquent, il ne reste que les entrées-sorties à connecter. Le système s'en trouve grandement simplifié. Mais, il y a un souci: ces composants sont conçus pour des utilisations où ils sont programmés une fois, avec un système fixe, puis installés dans des systèmes embarqués. En prévoyant au mieux quelques mises à jour de firmware. Le matériel est adapté à cette utilisation avec une RAM qui plafonne à quelques centaines de Kilo-octets, et par contre une mémoire flash relativement importante (on trouve facilement des composants avec 1Mo de mémoire flash). Parfois, il n'est même pas possible d'exécuter du code chargé en RAM, ou bien, si on peut le faire, son exécution est plus lente que l'exécution depuis la mémoire Flash.

Un exemple d'un tel système est la console Bitbox, qui prend le parti d'utiliser un "bootloader" qui va charger un programme depuis une carte SD, l'enregistrer dans la mémoire flash, puis l'exécuter. Une autre particularité de la Bitbox est d'utiliser un composant qui n'a pas de contrôleur d'écran intégré, la génération des signaux pour un écran VGA se fait donc par une utilisation astucieuse de timers et de canaux DMA pour envoyer les données à l'écran à la volée. Ceci permet une grande flexibilité de l'affichage, mais demande une programmation spécifique (il faut préparer le DMA pour envoyer les bonnes données à chaque ligne de l'écran), un peu similaire à la façon dont on pouvait programmer par exemple une console de jeux Atari 2600. La console Bitbox est fournie avec un SDK qui peut prendre en charge cette programmation et fournir un "framebuffer", cependant, la quantité de mémoire fait qu'on ne peut pas utiliser la résolution d'écran maximale avec un framebuffer. De plus, toute cette programmation consomme un pourcentage non négligeable des cycles CPU disponibles, ralentissant la machine. Le résultat est plutôt bon et certains jeux tirent assez bien partie de ces contraintes, on peut par exemple facilment programmer un mode texte ou un mode graphiques à base de tuiles et de sprites, comme ce qu'on trouve sur une console de jeu NES ou Megadrive.

J'avais installé ma Bitbox avec un petit écran VGA dans un étui pour tablette avec clavier USB, pour me fabriquer un genre d'ordinateur portable. Mais, il restait difficile de l'utiliser comme un ordinateur à proprement parler, à cause du système fonctionnant principalement en mémoire Flash.

Nouvelles générations de composants

Une évolution relativement récente est l'apparition de composants de type system-on-chip qui embarquent leur propre mémoire. Il s'agit cette fois non plus de mémoire statique comme dans les microcontrôleurs, mais de mémoire RAM DDR comme on en trouve sur nos ordinateurs classiques.

Cela permet enfin d'avoir des performances acceptables (mémoire RAM rapide permettant d'exécuter du code avec un CPU fonctionnant à plus de 1GHz) tout en gardant une conception de carte électronique simple. Il est possible de trouver de tels composants en boîtiers "QFP", ce qui signifie que toutes les connexions se font autour du composant, contrairement aux "BGA" ou les connexions se font sous toute la surface du composant. Ce changement de boîtier a deux conséquences: les systèmes BGA nécessitent un circuit imprimé à 4 couches ou plus, sinon il est impossible de faire passer toutes les pistes nécessaires à tout connecter. Et d'autre part, avec un boîtier QFP, il est assez facilement envisageable d'assembler soi-même une carte électronique avec du matériel assez simple (il faudra un pistolet à air chaud tout de même).

La partie haute fréquence du composant (l'interconnexion entre le CPU et la RAM) restant en interne, on peut réaliser le reste de la carte électronique sans trop rencontrer de problèmes.

Mon choix s'est porté sur le composant Allwinner V3s, et pour simplifier encore les choses, sur le module Lichee Zero qui fournit ce composant déjà assemblé sur une petite carte électronique avec les régulateurs de tension nécessaires et le minimum de connectique (un emplacement pour carte SD et un port USB).

Ce composant propose un processeur ARM simple coeur à 1.2GHz et 64Mo de RAM. C'est suffisant pour faire tourner un système Linux minimaliste, par exemple.

J'ai ensuite conçu une carte électronique servant de "base" à ce module pour avoir la connectique supplémentaire: VGA, Ethernet, USB, et une sortie son, ainsi qu'un port d'extension pour ajouter d'autres choses plus tard.

Le montage du Lichee Zero n'est pas aussi simple qu'il pourrait l'être: toutes les entrées-sorties sont sur le bord du module, en principe, on pourrait poser le module sur un autre circuit et le souder. Mais, le concepteur du Lichee Zero l'a rempli de composants électroniques sur ses 2 faces, donc ce n'est pas possible de procéder ainsi. Il a donc fallu prévoir un trou dans le circuit imprimé pouvant accueillir le module, tout en calculant juste pour que les "pads" de soudure ne soient pas trop éloignés.

Je l'ai ensuite installé à la place de la Bitbox dans mon étuit de tablette et connecté à l'écran VGA:

Le composant Allwinner V3s est assez bien pris en charge par les versions mainline de U-Boot et de Linux, de façon suffisante en tout cas pour arriver à démarrer le système depuis la carte SD.

Le logiciel

J'ai utilisé OpenEmbedded pour compiler facilement un système Linux minimaliste d'une vingtaine de Megaoctets. OpenEmbedded fait tout le travail de compilation de toolchains, de configuration du noyau, et de génération du système de fichier et de l'image de carte SD bootable. Il n'y a plus qu'à écrire l'image résultante sur une carte SD.

Je me suis pour l'instant concentré sur le bon fonctionnement de U-Boot sans trop toucher au système Linux. En particulier j'ai du récupérer des patchs pas encore intégrés dans la version officielle de U-Boot pour:

• L'affichage sur l'écran. Le composant V3s fournit une sortie de type "LCD parallèle". Je l'utilise avec quelques résistances judicieusement choisies (pas par moi, j'ai recopié un schéma existant d'un autre projet) pour obtenir un signal VGA. En plus des patchs, il faut ajuster le device tree (le fichier qui décrit le matériel présent) pour indiquer les timings à utiliser pour piloter l'écran (ceux qui ont manipulé les modelines pour X11 voient un peu le genre de choses à faire).
• L'USB et l'ethernet. Le support est en fait déjà présent dans U-Boot car les mêmes composants matériels sont utilisés par d'autres puces de chez Allwinner. Cependant, il y a un petit peu de "câblage" à faire pour que U-Boot établisse la correspondance entre ce qui est déclaré dans le device tree, les pattes du composant, et les drivers correspondants. Il a fallu également écrire un device tree pour ma carte électronique indiquant que oui, j'ai bien mis un port USB et un port Ethernet aux endroits prévus sur ce composant.

Voilà où on en est pour l'instant.

Prochaines étapes

Je ne sais pas si je vais conserver Linux sur ce système. Rien qu'avec un shell busybox et pas grand chose d'autre, environ la moitié de la RAM est déjà utilisée. Mais je ne sais pas encore quel autre système pourrait être intéressant.

Depuis le moment où j'ai commencé ce projet, la situation a évolué et de nouveaux composants sont disponibles. Par exemple, le Allwinner V3x qui dispose de 128Mo de mémoire, ou le T113 qui a lui aussi 128Mo de RAM, et en plus, un CPU à deux coeurs.

L'augmentation des capacités de ces composants tout-en-un va probablement se poursuivre. Il n'est pas impossible que d'ici quelques années on les trouve utilisés dans des smartphones qui seront ainsi moins chers et plus légers.

Pour ma part, je pense que j'ai déjà de quoi m'occuper avec cette carte électronique pour développer le logiciel permettant de l'utiliser confortablement. Cependant, si c'était à refaire:

• Mettre un bouton ON/OFF permettant de couper l'alimentation du CPU. Actuellement, il est alimenté par un port USB-B qui sert aussi à l'UART de debug, et la seule façon d'éteindre la machine est de tout débrancher. Ce qui n'est pas pratique quand on veut accéder aux logs sur le port série pendant le démarrage.
• Envisager l'utilisation d'un composant V3x ou T113 et faire assembler toute la carte directement par le fabricant du PCB, cela m'évitera de griller des cartes ou des composants en m'essayant à la soudure au pistolet à air chaud
• Il devrait être possible de concevoir une carte s'associant bien à un écran entre 3 et 4", et d'imprimer en 3D un boîtier pour le tout, pour se fabriquer un PDA de type Palm. Il faudrait cependant ajouter de quoi contrôler la charge d'une batterie, ainsi qu'une possibilité de connexion wifi?

Commentaires : voir le flux Atom ouvrir dans le navigateur

par pulkomandy