Les employés de chez Xilinx aiment à raconter qu'ils sont les inventeurs du FPGA. Avec leurs glorieux XC2064 ils auraient été les inventeurs du concept et les premiers à en commercialiser.

Deux ingénieurs de xilinx en plein placement-routage du XC2064 ?

En est-on si sûr ?

Tout d’abord revenons à la définition d’un FPGA :

Field Programmable Gate Array

Littéralement: Grille de portes programmable sur le champ.

Les FPGA sont des composants munis d’éléments logiques plus ou moins complexes dont les connexions ne sont pas figées. Les connexions peuvent être re-programmées pour modifier l’architecture électronique du système en fonction du besoin sans avoir à démonter l’appareil à chaque fois.

L’aspect programmable ne doit pas être vu dans le sens d’un programme que l’on télécharge dans une mémoire pour qu’il soit exécuté par un processeur. Non, le bon mot serait plutôt configurable ou re-câblable (quel beau mot) au besoin.

Dans un FPGA moderne, les blocs que l’on peut connecter sont des éléments logiques (LUT), des multiplexeurs, des multiplieurs, des additionneurs, les sérialiseurs/dé-sérialiseur (serdes) sans oublier les blocs de mémoires ram (BRAM). Des PLL viennent en renfort pour générer des horloges pour cadencer tout ce bazar.

Plan du Gatemate A1 de Colognechip, les entrées sorties sont à la périphérie et les blocs logique au centre

Le « re-câblage » (on parle plutôt de configuration) est effectué en téléchargeant un fichier appelé bitstream dans la mémoire RAM ou flash du FPGA.

Mais alors revenons à l'ENIAC. Cette machine est considérée comme le premier ordinateur électronique. Quand on pense ordinateur vient tout de suite l’idée d’un processeur qui exécute des instructions enregistrées dans une mémoire.

Ça n’est pourtant pas le cas des débuts de l’ENIAC qui est conçu pour faire des calculs très rapidement, notamment pour calculer des tables de tir de missiles (pour tuer des gens). Et à chaque nouveau calcul il faut le re-câbler.

Les blocs que l’on peut connecter sont des multiplieurs, des additionneurs, des tables de fonctions (à roulettes) ainsi que des imprimantes et des lecteurs de cartes perforées pour les entrées/sorties.

Plan de l’ENIAC, il y quelques similitudes avec un FPGA. Cependant les blocs sont à l’extérieur et le multiplexage et les entrées sorties se font au centre. (sources https://historyofinformation.com)

Pour re-câbler l’ENIAC point de bitstream mais des équipes de câbleuses qui reconfigurent la machine pour lancer un nouveau calcul histoire de faire péter une bombe plus fort (nucléaire) ou de bien atteindre la cible avec un canon.

Câbleuses en pleine action, maintenant on télécharge un bitstream (source sigarch)

Mais, attendez, cette description ressemble furieusement à la description d’un FPGA non ?

Et oui, Xilinx n’a qu’à bien se tenir, le premier ordinateur électronique était également le premier FPGA de l’histoire. D’autres ont fait le lien également.

Peut-être pourrait-on l’inclure dans les outils de synthèse libre comme Yosys ?

Pas sûr.

Apple et Google font la promotion de leur technologie de certification de matériel.

Au nom de la sécurité, les deux gros fournisseurs d’OS mobiles sont en train de verrouiller un marché où ils seraient les seuls acteurs mondiaux à décider qui a le droit d’utiliser tel ou tel matériel.

Le principe

Le but de ces technologies est d’interdire aux gens d’utiliser du matériel et du logiciel non approuvé par Google et Apple.

Faussement présenté comme une fonctionnalité de sécurité, les banques et les gouvernements les adoptent avec enthousiasme, car cela leur permet d’imposer l’usage de logiciels privateurs à leurs clients/citoyens, quitte à sacrifier la souveraineté.

Les technologies

API Play Integrity de Google

Cette API Android permet à une application de vérifier :

1. qu’elle n’a pas été modifiée par l’utilisateur ;
2. que l’utilisateur a bien payé pour l’utiliser ;
3. que l’exécution n’a pas lieu sur un émulateur ;
4. que le matériel sur lequel elle s’exécute est certifié par Google.

Quelques fournisseurs d’Android proposent des alternatives à ce service :

• Unified Attestation, créé par Volla ;
• Android hardware attestation, présenté par Graphene OS comme une alternative à Google’s Play Integrity API plus ouverte.

API App Attest d'Apple

https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service

Privacy Pass

Ce protocole a pour but d’authentifier un utilisateur anonyme. Cela peut sembler contradictoire, mais il s’agit de remplacer les solutions pour stopper les vils bots (captcha, anubis…).

Concrètement l’utilisateur doit obtenir un jeton avant d’accéder à un service.

Malheureusement de vils humains d’Apple et Cloudflare ont trouvé opportun d’implémenter ce système en rendant obligatoire l’usage d’un matériel certifié.

reCAPTCHA

Cette solution de Google impose aussi l’usage des services Google pour vérifier un mobile pour pouvoir accéder à certains services, notamment des sites web.

La certification de matériel du point de vue des utilisateurs

Pour le consommateur, la certification du matériel (appliqué aux ordiphones) revient à :

• limiter son choix de matériel neuf ;
• limiter son choix de matériel d’occasion ;
• accélérer l’obsolescence du matériel possédé.

Bref il faudra plus régulièrement « tout racheter ».

(Source: sketch des Guignols sur les "iAiles-dans-les-dos", une révolution de Steeve Jobs qui innove au paradis, 2011)

Pour le citoyen, c’est :

• l’usage obligatoire de logiciels privateurs ;
• une inscription forcé et donc l’acceptation des contrats de société “agressives” sur la vie privée et les données personnelles.

Pour les États et l’Union Européenne, c’est un nouvel abandon de souveraineté.

Certifier du matériel, c’est privateur. Certifier des gens c’est pire.

Si vous avez un diplôme d’ingénieur, un permis de chasse, un passe sanitaire ou un tatouage mafieux, vous savez que les organisations adorent certifier les personnes, par exemple pour être bien certaine de recruter un bon tireur pour une mission spéciale en pleine pandémie.

Toutefois si vous êtes un braconnier antivax de l’école 42, vous pouvez aussi télétravailler du côté obscur, par exemple comme développeur Android.

Enfin jusqu’ici, car Google demandera bientôt que tout développeur d’applications Android s’inscrive avec des obligations comme fournir une pièce d’identité officielle et lister tous ses identifiants d’applications actuels et futurs…

Une campagne est en cours pour défendre le droit des braconniers antivax de l’école 42gens normaux de continuer à développer librement sur Android : https://keepandroidopen.org/fr/

À partir du 20 mai 2026, Amazon mettra fin au support de huit modèles de liseuses Kindle et de certaines tablettes Kindle Fire commercialisées entre 2007 et 2012.

C'est l'occasion de réviser et partager entre nous toutes les solutions FOSS en 2026 pour lire, stocker et partager des ouvrages électroniques multimédias sans se faire piéger par les solutions propriétaires. À vos claviers pour les commentaires !

Ces appareils ne pourront plus accéder à la boutique Kindle pour acheter, emprunter ou télécharger de nouveaux livres ou contenus. Amazon justifie cette décision par l’évolution technologique et le fait que ces modèles ont été pris en charge pendant au moins 14 ans, voire 18 ans pour certains.

Modèles concernés : Les liseuses Kindle et tablettes Kindle Fire de 2012 ou antérieures. Après cette date, il sera impossible d’ajouter de nouveaux livres sur ces appareils, et en cas de réinitialisation ou de déconnexion du compte Amazon, ils ne pourront plus être réenregistrés. Amazon annonce qu'une réduction de 20 % sur l’achat d’un nouveau modèle sera proposée aux utilisateurs concernés, ainsi qu’un crédit pour l’achat de livres électroniques.

À l’occasion de ses 10 ans de Macé Robotics, l’entreprise organise un concours qui se déroulera jusqu'au 26 février 2026.

Macé Robotics est une entreprise individuelle fondée et gérée par moi-même (Nicolas), basée en Bretagne, spécialisée dans la conception et la réparation électronique, aussi bien pour les entreprises que pour les particuliers. Depuis 2016, je fabrique aussi du matériel Open Source également des robots mobiles Open Source destinés à l’enseignement supérieur et à la recherche. Ces robots sont basés sur un système Linux (Raspberry Pi OS), intégrant une carte Raspberry Pi ainsi qu’un microcontrôleur (Pico) dédié à la gestion des moteurs et des capteurs. J’utilise la suite logicielle KiCad sous licence GNU GPL (https://www.kicad.org/) pour la conception des circuits imprimés de ces robots.
Ces robots sont principalement utilisés dans les filières de génie informatique afin de faciliter l’apprentissage du système Linux, des réseaux informatiques et du langage Python à travers des projets concrets et ludiques.

Attribution des lots par tirage au sort :

→ 1er lot : une carte Raspberry Pi 5 (2 Go)

→ 2e lot : une carte Raspberry Pi Pico 2W

La livraison est offerte en France.

Retour sur la course de robots – Saint-Brock Robot Race d'une dépêche précédente

Suite à la dépêche de décembre 2024 concernant l’organisation de la course de robots mobiles, voici quelques retours sur cet événement : malgré plusieurs annulations d’écoles survenues quelques semaines avant la compétition, la course a tout de même pu avoir lieu.

Environ quinze participants ont pris part à la compétition. Parmi les robots engagés, on comptait un robot DIY piloté par un microcontrôleur ESP32, aux côtés de plusieurs robots basé sur Raspberry Pi, offrant ainsi une belle diversité technologique.

Linus Torvalds est invité dans cette toute récente vidéo sur la chaîne Linus Tech Tips. La vidéo dure presque une heure, ce qui est inhabituellement long pour cette chaîne, et permet de laisser s'exprimer un Linus Torvalds invité. Torvalds s'exprime sur de nombreux sujets tout en regardant un PC « idéal » être monté pour lui et ses travaux sur le noyau Linux.

Il discute du Libre, Gaming, Linux, Git, A.I., de son travail, dans une atmosphère bon enfant et avec un humour mordant.

Les méandres de l'espace de rédaction sont parfois mystérieux. La rédaction de certaines dépêches s'étalent parfois sur de long mois, parfois sans même comprendre pourquoi la dépêche ne part pas vers le stade de la publication. C'est ce qui est arrivé à cette dépêche qui ne suit donc pas autant qu'elle aurait pu l'actualité de la sortie de la nouvelle mouture de la microcarte de la Fondation Raspberry Pi, qui porte le nom très original de Raspberry Pi 5. Cette dépêche - qui nous offre une comparaison de cette nouvelle édition avec son illustre ancêtre ainsi qu'une investigation de ses nouveautés - reste substantielle et il nous a semblé qu'il valait mieux la publier même tardivement plutôt que de la plonger dans l'oubli éternel.

Sommaire

• Comparaison entre Raspberry Pi 4 et Raspberry Pi 5
• Détail des améliorations de la Raspberry Pi 5
  • Raspberry Pi 5 : Nouveau South Bridge RP1 vs Raspberry Pi 4
    • Architecture du South Bridge RP1
    • Sources des informations sur le RP1
  • Impacts du RP1
  • Évolution des performances
    • performances des I/O
    • Interfaces USB et Ethernet
    • Interfaces MIPI CSI/DSI
• Les points discutables/discutés
  • Le réarrangement de la carte
  • Le non réarrangement de la carte
  • Les limites du format carte de crédit

Cette dépêche ne traitera pas de l’ensemble de ce que l’on peut faire, la précédente dépêche sur les SoC faite pour la sortie de la Raspberry Pi 4 est toujours d’actualité en ce qui concerne ces sujets.

Comparaison entre Raspberry Pi 4 et Raspberry Pi 5

Sorti en 2019, le RPi4 avait fait forte impression—mais quasiment en constante pénurie entre 2020 et 2023, il commençait par accuser le coup par rapport à la concurrence du Rockchip RK3588 (Quad-core Cortex-A76 + Quad-core Cortex-A55).

Aussi, la Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, dont le Tableau 1 présente une synthèse des différences.

Tableau 1 : comparatif des Raspberry Pi 4 et 5

Détail des améliorations de la Raspberry Pi 5

La Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, en particulier avec l’introduction du southbridge RP1. Voici une comparaison détaillée mettant en évidence les principales différences et l’impact du RP1 :

• Processeur : La Raspberry Pi 5 est équipée d’un CPU ARM Cortex-A76, une amélioration substantielle par rapport au Cortex-A72 trouvé dans la Raspberry Pi 4. Cette mise à niveau fait que la Pi 5 est deux à trois fois plus rapide que son prédécesseur.
• RAM : La Raspberry Pi 5 utilise de la LPDDR4X-4267 SDRAM, nettement plus rapide que la LPDDR4-3200 SDRAM utilisée dans la Pi 4. Cette amélioration offre plus de bande passante, contribuant à des performances globalement plus rapides.
• Puissance graphique : La Raspberry Pi 5 dispose d’un GPU VideoCore VII plus puissant, cadencé à 800 MHz et prenant en charge OpenGL ES 3.1 et Vulkan 1.2. C’est une avancée par rapport au GPU VideoCore VI de la Raspberry Pi 4, qui prend en charge OpenGL ES 3.1 et Vulkan 1.0. Le GPU de la Pi 5 comprend également un nouveau processeur de signal d’image pour la gestion des données des caméras.
• Chip RP1 Southbridge : La puce RP1 est une innovation majeure dans la Raspberry Pi 5. Elle agit comme un southbridge, gérant la plupart des fonctions I/O (entrée/sortie), réduisant ainsi la charge sur le CPU. Cela permet une augmentation de la bande passante I/O, bénéficiant aux dispositifs de stockage, USB et autres périphériques.
• Vitesse des cartes MicroSD : Le port microSD de la Pi 5 prend en charge le mode haute vitesse HDR 104 avec les cartes microSD UHS-1, offrant des vitesses de lecture de 80-90 Mbps, soit le double de la vitesse de 40-50 Mbps de la Pi 4.
• Ports USB : Dans la Raspberry Pi 5, chacun des deux ports USB 3.0 dispose d’une bande passante dédiée de 5 Gbps, grâce à la puce RP1. C’est une amélioration par rapport à la Pi 4, où les deux ports USB 3.0 partageaient la bande passante de 5 Gbps.
• Connecteur PCIe : La Pi 5 inclut un connecteur PCIe (PCI Express), une nouvelle addition répondant à la demande pour des interfaces plus rapides. Cependant, l’interface PCIe de la Pi 5 n’est pas un connecteur M.2 standard ; elle nécessite un câble ruban pour se connecter à un HAT, et le dispositif M.2 se connectera au HAT. Caractéristiques
• Un bouton marche/arrêt : Eh oui, on est quand même dans le 3ᵉ millénaire ;-)
• Alimentation : Tout comme la Raspberry Pi 4, la Raspberry Pi 5 utilise un connecteur d’alimentation au format USB Type-C. En revanche, doublement de la puissance oblige, la puissance nécessaire à son fonctionnement passe de 7.5 W à 15 W, il faudra donc une alimentation en 3A minimum pour être tranquille. À noter que si vous souhaitez utiliser des périphériques externes qui consomment beaucoup comme des disques durs ou SSD, il est conseillé d’avoir une alimentation de 25 W (5A). La Raspberry Pi détecte si l’alimentation fournit plus de puissance et passe la limite de consommation USB à 1,6A au lieu de 1,2A.

Raspberry Pi 5 : Nouveau South Bridge RP1 vs Raspberry Pi 4

Le RP1 est un contrôleur d’entrée/sortie (I/O) conçu pour le Raspberry Pi 5, représentant le programme d’ingénierie le plus complexe et coûteux entrepris par Raspberry Pi, avec un développement s’étendant sur plus de sept ans et ayant coûté environ 25 millions de dollars. Ce contrôleur est le premier produit phare de Raspberry Pi à utiliser une puce conçue en interne​.

Architecture du South Bridge RP1

— Description : Le RP1 est un southbridge de 12×12 mm avec un pas de 0.65 mm en BGA (Ball Grid Array), fournissant la majorité des capacités d’E/S pour la Raspberry Pi 5.
— Caractéristiques : Il comprend un point de terminaison PCIe 2.0 à 4 voies, un contrôleur Ethernet MAC Gigabit et deux contrôleurs hôtes USB 3.
— Améliorations : Plus du double de la bande passante USB utilisable par rapport à la Raspberry Pi 4.
— Documentation RP1 : RP1 Datasheet

Sources des informations sur le RP1

— L’article d’Eben Upton pour annoncer le RP1 : RP1 : the silicon controlling Raspberry Pi 5 (ce court article est accompagné d’une vidéo YT de 35 minutes à ce sujet, mais dont le contenu est reproduit textuellement en suivant un lien)
— Lien direct vers la vidéo YT : RP1 : the silicon controlling Raspberry Pi 5

Impacts du RP1

Le RP1 constitue une avancée importante, puisque les GPIOs “physiques” de la carte ne sont plus directement reliées aux GPIOs du microprocesseur et de leurs fonctions possibles (SPI/I2C/UART/I2S) attribuées par le fondeur dans le silicium.

1. Connectivité principale : Le RP1 se connecte à un processeur d’application (AP) via un bus PCIe 2.0 x4, consolidant de nombreux contrôleurs numériques et PHYs analogiques pour les interfaces externes du Raspberry Pi 5​​.
2. Contrôle du trafic : Le tissu interne du RP1 permet de prioriser le trafic en temps réel de la caméra et de l’affichage sur le trafic non en temps réel de l’USB et de l’Ethernet. Des signaux de qualité de service (QoS) sur le lien PCI Express soutiennent la priorisation dynamique entre le trafic provenant du RP1 et le trafic des maîtres de bus en temps réel et non en temps réel au sein de l’AP​​.
3. Fonctionnalités supplémentaires : Pour une flexibilité maximale des cas d’utilisation, le RP1 dispose de plusieurs fonctionnalités telles qu’un contrôleur DMA à huit canaux pour les périphériques à basse vitesse, trois PLL intégrées pour la génération d’horloges vidéo et audio indépendantes, un convertisseur analogique-numérique à cinq entrées, 64kB de SRAM partagée, et des générateurs de base temporelle pour le rythme de la DMA ou pour le debouncing des événements GPIO​​​​.
4. Gestion des contrôleurs de bus : Les modules de régulation intégrés à chaque port de contrôleur de bus permettent de surveiller ou de limiter leur comportement. Ces modules régulent le flux de données selon le nombre de transactions en attente, assurent le respect des limites d’adresses AXI et PCIe, et disposent de compteurs statistiques pour évaluer la qualité de service ou les performances.
5. Interfaces clés externes : Le RP1 fournit des interfaces externes clés telles que deux contrôleurs XHCI indépendants connectés à un seul PHY USB 3.0 et un seul PHY USB 2.0, deux contrôleurs de caméra MIPI CSI-2 et deux contrôleurs d’affichage MIPI DSI connectés à deux PHY transceivers MIPI DPHY à 4 voies partagées, et un contrôleur d’accès média (MAC) intégré pour l’Ethernet Gigabit​​​​.
6. Compatibilité et évolution : Le RP1 maintient la compatibilité avec la gamme de fonctions offerte sur le Raspberry Pi 4 Model B, tout en permettant une évolution vers des processus de géométrie réduite, sans avoir à reproduire tous les éléments analogiques du système. Cela pourrait permettre à changer plus facilement de fournisseur de SoC.

Évolution des performances

Afin de permettre de mieux visualiser les évolutions des performances Alasdair Allan a fait un benchmark complet dont certains éléments sont repris ici.

Tout d’abord une analyse des performances du CPU avec geekbench. Les Figures 1 et 2 montrent une augmentation des performances en single core d’approximativement 2.2x,

Figure 1. : Comparaison des performances single core entre RPi4 et 5

Figure 2. : Comparaison des performances multi core entre RPi4 et 5

Compilation de différents benchmarks entre RPi 4 et 5

performances des I/O

La Figure 3. issue du travail d’Adafruit permet de mettre à jour le graphique sur la vitesse performance de la commutation des I/O proposé dans la dépêche sur la RPi4. La Figure 4. quant à elle montre une légère amélioration de la performance par Watt sur le nouveau modèle.

Figure 3. Évolution de la vitesse de commutation d’une sortie numérique

Figure 4. Évolution de la performance en fonction de la puissance électrique

Interfaces USB et Ethernet

— Interfaces: Le RP1 fournit deux interfaces USB 3.0 et deux interfaces USB 2.0, ainsi qu’un contrôleur Ethernet Gigabit.
— Source: Circuit Digest – The New Raspberry Pi 5 is here

Le Gigabit Ethernet fourni par le RP1 est en tout point semblable à celui du RBPi4 (voir : RP1 : the silicon controlling Raspberry Pi 5:

Liam 13:21: So we’ve got the Ethernet MAC but not the PHY. So the Ethernet’s brought out to an RGMII interface, which then connects to an on-board Ethernet PHY.

Eben 13:35: And this is a fairly similar architecture to Raspberry Pi 4, except that in that case, the MAC was in the Broadcom device, but there was still an external – in fact exactly the same external – PHY, [BCM]54213. Cool. So that’s the overall structure of the design.

Interfaces MIPI CSI/DSI

Ces interfaces d’entrée/sortie vidéo peuvent être qualifiées d’historiques dans l’écosystème RaspberryPi puisqu’elles sont présentes depuis la version 1. Le RBPi5 apporte toutefois une nouveauté assez remarquable par rapport à ses prédécesseurs : au lieu d’avoir un port CSI (pour une caméra) et un port DSI (pour un écran), les ports du RBPi5 peuvent être configurés pour l’une ou l’autre fonction. Malheureusement, cela s’est traduit par des changements notables au niveau de la disposition des composants sur la carte, qui ne sont pas sans susciter quelques grincements de dents parmi les utilisateurs.

Les points discutables/discutés

Le réarrangement de la carte

— Le port audio a disparu, pour laisser sa place au port MIPI DSI (qui peut faire CSI à présent), lui-même remplacé, au-dessus du lecteur de carte microSD, par un connecteur FPC exposant les lignes PCIe.
— le port DSI est passé de 15 pins à 22 pins (comme sur la carte CMIo4)
— Et, encore une fois, les ports Ethernet et USB ont été inversés.

Si cela ne pose pas de problèmes particuliers pour un utilisateur lambda, de nombreux projets basés sur les cartes RasperryPi à la recherche de performance de calcul (et donc potentiellement intéressés par ce nouveau RBPi5) doivent entièrement revoir la conception de leur matériel.

Le non réarrangement de la carte

C’est un reproche que l’on peut trouver dans de nombreux témoignages : mettre un HAT (carte d’extension) sur un RBPi, juste au dessus du CPU, c’est un non-sens en termes de refroidissement (et ce, quelle que soit la version du RBPi).
Mais, pour relativiser, on peut dire la même chose de quasiment toutes les autres solutions alternatives au RBPi.

Les limites du format carte de crédit

Ce format (86x56 mm) est devenu une référence pour presque tous les acteurs du monde des SBC. Et donc, il s’agit là aussi d’un constat plus général, non spécifiquement adressé à RaspberryPi. Mais sachant que ce sont les locomotives du marché, peut être pourraient-ils initier une nouvelle approche…
Certes, ce format permet d’élaborer des solutions compactes, mais l’on peut constater :

— qu’augmenter la puissance et les fonctionnalités des puces embarquées tout en restant sur ce format conduit à un gaspillage inutile de ressources : il est en effet impossible d’implémenter toutes les fonctionnalités matérielles proposées par les puces sur une si petite surface, et par ailleurs il devient difficile de refroidir efficacement le système.
— pour exposer le port PCIe, RaspberryPi a supprimé le port audio, déplacé le port DSI ; mais pour alimenter le bouzin, il vous faut du 5V 4A. Ensuite un peu tout le monde se trouve planté là : débrouillez-vous.

Les calculatrices graphiques sont de lointains dérivés des ordinateurs de poche des années 1980, dans lesquelles subsiste cette capacité native à pouvoir être programmé.
J’en serais probablement resté à mon expérience de lycéen, et l’éternel combat Casio / Texas Instrument, s’il n’y avait pas eu un virage (pas forcément bien courbe) autour de Python dans la fin des années 2010.

Entre passion de l’informatique, doux rêveur, promesse de calculatrice libre et réalité du marché… j’avais l’envie de vous partager mes quelques heures de recherches et de réflexions sur le sujet.

Sommaire

• • Ordinateur de poche, calculatrice et langage BASIC
  • Une évolution de rupture
  • Libre - Un peu, beaucoup, à la folie, passionnément… pas du tout
  • Omega
  • Ma petite CASIO
  • NumWorks - L’esprit d’ouverture… ou pas
  • La magie du libre
  • Vers la fin des applications avancées

Ordinateur de poche, calculatrice et langage BASIC

Les ordinateurs de poche existent depuis les années 80 et ont fait le succès de sociétés telles que Sharp, Casio ou Psion. Ils se confondent avec les calculatrices les plus évoluées, et restent aujourd’hui les seules survivantes de ces deux mondes.

Elles sont programmables, majoritairement dans de nombreux dialectes du langage BASIC, directement sur la machine, mais aussi dans d’autres langages plus bas niveau, souvent via un ordinateur plus conventionnel.

Une évolution de rupture

Dans la fin des années 2010, deux évolutions sont poussées dans le monde des calculatrices : le « mode examen » et le besoin d’un langage plus moderne, beaucoup se tournant vers le langage Python.

C’est l’occasion pour NumWorks de se lancer dans ce marché très spécial. Deux point sont mis en avant :

• Le langage Python comme le langage de programmation utilisateur (alors que ce n’est qu’un autre ajout pour les constructeurs historiques).
• Un modèle « libre », qui as fait beaucoup parler de ce nouveau venu, notamment ici.

Libre - Un peu, beaucoup, à la folie, passionnément… pas du tout

La mise en application s’est vite montrée moins claire. La libération matérielle tient, à en juger par leur GitHub, à huit fichiers STL, sous licence CC-BY-NC-ND, et dont la dernière mise à jour date de 2020. Il est donc interdit d’en faire des modifications et/ou une utilisation commerciale… une liberté relative.

Le système d’exploitation, nommé epsilon, qui offre une bonne implémentation de Python, mais qui souffre de plusieurs problèmes de jeunesse, est bien disponible… mais également sous cette même licence CC-BY-NC-ND.

Omega

Critiquée pour cette différence entre le discours commercial de liberté, et la réalité de la licence, en mai 2018 elle fut finalement modifiée en CC-BY-NC-SA, autorisant donc la modification et la redistribution de versions modifiées. Il en naîtra notamment Omega un dérivé communautaire d’Epsilon, alors en version 11.

Ma petite CASIO

Dans un esprit de découverte, j’ai eu l’envie d’explorer moi-même ce nouveau monde du Python sur calculatrice. Peut-être un peu entrainé par les différentes lectures sur la calculatrice libre que je lisais un peu partout.

Cependant, l’interprétation assez personnelle de NumWorks du libre, et l’obligation de passer par leur site pour communiquer avec la calculatrice a orienté mon choix vers une Casio Graph 90E.

Pas que cette dernière soit plus libre, bien au contraire… juste qu’elle est simplement reconnue comme une clef USB pour y transférer des éléments depuis l’ordinateur et qu’elle a une communauté plus importante.

Le micro-python qui y est intégré est limité, et s’il permet de faire des choses… on voit que le constructeur s’est limité à ce qui était juste nécessaire. Ce qui limite les possibilités laissées aux utilisateurs.

J’aurais pu en rester là, et c’est même un peu ce que j’ai fait jusqu’à peu.

NumWorks - L’esprit d’ouverture… ou pas

Alors que j’explorais d’autres domaines, et que ma Casio prenait la poussière, le monde évoluait, et NumWorks en était à la 4ᵉ variante matérielle de sa calculatrice révolutionnaire.

La définition du « Libre » par l’entreprise avait elle aussi eu le temps d’évoluer.

Epsilon depuis sa version 16 du 30 novembre 2021, verrouille les calculatrices pour n’autoriser que les systèmes officiels du constructeur. Un peu à l’image des consoles de jeu, que certains hackent pour installer des homebrew ou firmware modifiés, il en devient de même pour la « calculatrice libre » : on chasse les évolutions communautaires.

Epsilon en est aujourd’hui (28 février 2025) à sa version 23… sans volonté affichée d’ouverture supplémentaire. Le dépôt GitHub n’affiche pas de licence dans ses métadonnées, mais une mention « Copyright - All rights reserved. NumWorks is a registered trademark. » figure en bas de la page de présentation.

Oméga a mis en pause son développement depuis février 2024, renvoyant vers une autre alternative Upsilon, qui ne s’installe pas mieux sur une calculatrice NumWorks verrouillée… mais quelqu’un a compilé pour la CASIO.

La magie du libre

C’est M. Bernard PARISSE qui a compilé une version d’Upsilon comme application pour la génération de CASIO que je possède. Je vous invite à en lire tous les détails sur la page de son projet.

Arrivant donc à avoir le meilleur des mondes, le travail de NumWorks, les additions de la communauté et plus de puissance supplémentaire de ce matériel.

Mais cela est conditionné par la possibilité de pouvoir faire fonctionner des applications tierces sur ces calculatrices…

Vers la fin des applications avancées

Il y a historiquement deux méthodes pour développer des applications pour ces calculatrices.

Un langage haut niveau, qui est un dialecte BASIC, une adaptation de Python, ou d’autres langages plus ou moins évolués, qui sont directement modifiables sur l’appareil (même si le clavier d’une calculatrice n’y est pas toujours optimal).

Un langage bas niveau, typiquement du C ou même de l’assembleur, édité et compilé sur un ordinateur puis transféré vers la calculatrice (même si certaines machines Sharp pouvaient se programmer en C directement sur la machine).

Et c’est un point que met en valeur Bernard PARISSE dans son argumentaire sur Upsilon pour CASIO : l’ouverture de ce constructeur aux développements tiers.

Mais voila, ce n’est pas forcément le sens que prennent les constructeurs, même chez CASIO.

Le test communautaire de la CASIO Math+, qui succède à la Graph 90E, ne permet pas ces applications tierces développées en langage de bas niveau, et la conclusion sur ce point est tout sauf optimiste.

Voila qui conclut ce petit tour dans le sous-domaine de l’informatique qu’est celui des calculatrices graphiques, même si ce n’est probablement pas ce qui vous servira dans une discussion autour de la machine à café (sauf, peut-être, si vous êtes prof de math).

L’open source dans l’informatique embarquée se limitait historiquement aux systèmes d’exploitation et aux compilateurs. On connaît bien GCC, BusyBox et FreeRTOS. Puis, Arduino a fait son entrée dans le monde du semi-professionnel. Mais cela évolue rapidement. Trois domaines se développent avec des logiciels, et, parfois des produits open source, qui commencent à se croiser.

À part les liens Wikipedia, les sites pointés sont en anglais.

Drone

Le domaine des drones, principalement les quadcopters mais aussi les avions, rovers et même sous-marins (AUV), a vu naître des projets comme PX4 et ArduPilot. Ces firmwares d’autopilotes permettent un asservissement entre ce que l’on demande au drone et la réalité grâce à des centrales inertielles. Ils gèrent des tâches comme le quadrillage d’un secteur ou le retour automatique au point de départ, à l’aide de GPS ou de caméras de flux optique utilisant une technologie similaire à celle des souris. Les développements actuels se concentrent sur l’évitement automatique d’obstacles, comme les arbres.

PX4 repose sur le système d’exploitation temps réel NuttX, soutenu par la Fondation Apache. Ce système m’était encore inconnu jusqu’à récemment.

QGroundControl est un logiciel pour préparer des missions (points GPS, prises d’images, largages…), lire des journaux transmis par radio et configurer les drones sous PX4 ou ArduPilot, ainsi que pour mettre à jour leur firmware.

Le projet Pixhawk définit une plateforme matérielle supportée par ces deux firmwares. On en est à plus de six versions de FMU (“Flight management unit”), utilisant des processeurs STM32 avec des gyroscopes, accéléromètres, magnétomètres et baromètres, souvent avec des redondances. Les cartes comportent de nombreux connecteurs pour brancher les radiocommandes (plusieurs protocoles), les servos, les contrôleurs moteurs (ESC), les GPS, ainsi que des bus CAN utilisant des protocoles open source comme DroneCAN ou Cyphal.

Radio commande

Les ESC (Electronic Speed Controllers) transforment une commande de vitesse en une gestion complexe de trois signaux pour contrôler des moteurs synchrones. Le VESC Project propose un firmware open source, offrant des réglages avancés, comme la limitation du courant ou l’asservissement via des capteurs à effet Hall. Un programme Android permet de gérer des moteurs pour trottinettes ou voiturettes.

Dans le domaine des radiocommandes, le projet OpenTX, forké en EdgeTX, remplace le firmware des radiocommandes. RadioMaster, un outsider, utilise directement ces logiciels, contrairement aux fabricants haut de gamme plus conservateurs (Futaba, Spektrum, JR, Flysky, etc.). Ces firmwares permettent une personnalisation via des scripts Lua.

Pour les protocoles radio, plusieurs solutions propriétaires existent avec des portées annoncées de plus de 2 km. Cependant, un protocole ouvert, ExpressLRS, reposant sur LoRaWAN, permet des portées jusqu’à 5 km (en 2.4 GHz) ou 15 km (à 900 MHz). Les émetteurs et récepteurs bi-bandes commencent à apparaître.

Et robotique

Dans le domaine de la robotique, Gazebo est en train de devenir un simulateur et visualiseur polyvalent. Il repose sur le moteur de rendu OGRE et le moteur physique ODE. Il est intégré aux outils de développement de PX4 et même utilisé dans des concours de drones virtuels.

ROS2 (“Robot Operating System”) est un middleware généraliste basé sur un protocole Pub/Sub à faible latence, permettant à plusieurs ordinateurs de communiquer. Il tend à remplacer MAVLink, un protocole de commande plus léger, encore majoritaire dans le domaine des drones.

Les trois domaines (drones, robotique et radiocommande) se croisent de plus en plus. Les autopilotes permettent de gérer tous types de véhicules, tandis que des outils comme QGroundControl et ROS2 facilitent le développement de missions automatiques de plus en plus complexes.

Lors de leur keynote à l'Open Source Summit 2024, Linus Torvalds et Dirk Hohndel ont échangé sur l’avenir des architectures matérielles libres, en particulier RISC-V. Linus, avec son franc-parler habituel, a partagé ses craintes et ses espoirs concernant l’évolution de RISC-V et le rôle crucial que peuvent jouer les communautés open source pour éviter les erreurs passées, notamment dans le développement des plateformes comme ARM et x86.

Linus estime qu’il existe un risque majeur que RISC-V répète les erreurs commises par les architectures précédentes, comme lorsqu’ARM est devenu une plateforme serveur et a ignoré en partie les leçons apprises lors du développement de l’architecture x86, notamment en matière de sécurité. Cependant, il reconnaît également que grâce à l’expérience accumulée, ces erreurs ont été corrigées plus rapidement. La question cruciale est à présent de savoir si RISC-V saura tirer parti de cette expérience collective pour éviter ces écueils ou s’il devra traverser les mêmes cycles d’apprentissage douloureux.

Leçons du passé et rôle des logiciels libres

Les erreurs évoquées par Linus sont multiples. Il parle notamment des problèmes de compatibilité et d’interopérabilité qui ont compliqué l’adoption de nouvelles architectures matérielles. Il mentionne également le manque de communication entre les concepteurs de matériel et les développeurs de logiciels, créant un fossé qui ralentit l’innovation et entraîne des inefficacités. Enfin, il rappelle que les délais nécessaires pour corriger les erreurs matérielles sont bien plus longs que pour les logiciels, ce qui peut freiner l’évolution des nouvelles technologies.

Cependant, l’open source présente une opportunité unique pour surmonter ces obstacles. Une architecture matérielle ouverte comme RISC-V permet une transparence totale, où les développeurs de logiciels peuvent intervenir dès les premières phases de conception pour s’assurer que les erreurs du passé ne se reproduisent pas. Cette collaboration précoce entre développeurs matériels et logiciels est essentielle pour anticiper et résoudre les problèmes avant qu’ils ne deviennent des obstacles majeurs.

L’open source a déjà prouvé sa valeur dans le domaine des logiciels en offrant une flexibilité et une adaptabilité incomparables. Cette même philosophie appliquée au matériel peut accélérer l’innovation et permettre de répondre plus rapidement aux besoins du marché. De plus, une communauté ouverte permet de partager les connaissances et les meilleures pratiques, réduisant ainsi les risques de répéter les erreurs passées.

Sécurité et architecture matérielle open source

Un point crucial soulevé par Linus concerne la sécurité, en particulier les défis posés par les failles matérielles et les attaques par canal auxiliaire. Ces vulnérabilités résultent souvent des optimisations dans le silicium, comme l'exécution spéculative, qui peuvent être exploitées pour compromettre la sécurité des systèmes.

Linus a exprimé sa frustration face à la nature secrète des processus de gestion des failles de sécurité dans le domaine du matériel. Il a souligné que cette opacité empêche de travailler en toute transparence sur ces problèmes intéressants et techniques. Une architecture matérielle open source, comme RISC-V, pourrait potentiellement atténuer ces frustrations en permettant une collaboration ouverte dès le début, facilitant ainsi la détection et la correction rapide des vulnérabilités.

L’open source offre également un modèle de confiance basé sur la transparence et la vérification par les pairs. Dans le contexte de la sécurité, cela signifie que les failles peuvent être identifiées et corrigées plus rapidement grâce à une surveillance continue et à une coopération étroite entre les développeurs de matériel et de logiciels.

La vision d’un avenir open source pour le hardware

L’un des points forts de l’open source est sa capacité à démocratiser l’accès à la technologie. Avec des projets comme RISC-V, il est possible de voir émerger des solutions matérielles qui ne sont pas seulement le produit de quelques grandes entreprises, mais le fruit d’une collaboration globale. Cela peut mener à des avancées significatives non seulement en termes de performances, mais aussi de coûts et d’efficacité énergétique, en offrant des alternatives viables aux architectures propriétaires.

Linus Torvalds a également évoqué l’évolution des pratiques du développement du matériel. Il y a dix ans, il était difficile de passer de x86 à une autre plateforme, mais aujourd’hui, grâce à l’open source, la transition est beaucoup plus fluide. Les utilisateurs finaux ne se soucient plus de savoir si leur serveur fonctionne sur un processeur Intel, AMD ou ARM ; ce qui compte, c’est que l’infrastructure logicielle soit solide et interopérable.

Pour que RISC-V réalise pleinement son potentiel, il est donc crucial que les communautés du logiciel et du matériel libres continuent de favoriser une culture de partage et de collaboration. Les développeurs de logiciels doivent être encouragés à s’impliquer dans le processus de conception matérielle, et vice versa. En travaillant ensemble, ils peuvent s’assurer que les erreurs du passé ne se reproduisent pas et que les nouvelles technologies répondent aux besoins réels du marché.

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il utilise une réserve de secteurs de rechange pour réparer quand il détecte un secteur en anomalie.
Le programme Linux badblocks teste les blocs d’un média par écriture+relecture+comparaison. À l’origine il servait à mettre les blocs mauvais en liste noire dans le file-system.

Est-il utile de nos jours de vérifier ses médias ?
Comment se situe S.M.A.R.T. par rapport à l’outil badblocks ?
Comment vérifier un média en tenant compte de sa surveillance par S.M.A.R.T. ?

C'est ce que nous allons voir dans la suite de la dépêche.

Sommaire

• Préambule
• S.M.A.R.T.
• BADBLOCKS
• BADBLOCKS2
• En pratique
  • Si S.M.A.R.T. n’est pas sur le média
  • Si S.M.A.R.T. est sur le média

Préambule

Quelle précaution prendre vis-à-vis du risque de mauvaise qualité du stockage, quand je viens d’acheter un média (disque SSD, disque rotatif, clé USB, carte SD) ou un appareil sous Linux équipé d’un espace de stockage dont j’ignore la technologie ?
Sans être parano, je me dis qu’avant d’envoyer des données précieuses sur l’espace de stockage, c’est le moment de faire certaines vérifications. Mais quelles vérifications ? Qu’est-il possible de faire ?

Sur un média connectable, tout est possible.
Sur un appareil neuf sans système ni données, tout est possible en utilisant une distrib Live.
Sur les autres, ça dépend, il y en a où on n’a même pas un accès root pour lancer une vérification « dure » ou « molle » (Android, routeur…).

En écrivant cet article, je me suis rendu compte que je ne me suis jusqu’ici jamais posé de questions sur l’opportunité de vérifier les espaces de stockage de mes téléphones, PC portables, routeurs, box… bref tous les appareils vendus prêts à être utilisés. Pourtant, que sais-je de la vérification faite par celui qui a installé le système ? Rien, et j’utilise, sans penser que l’espace de stockage de l’appareil n’est ni plus ni moins robuste que celui du PC Linux que j’ai installé dernièrement, mais que j’ai vérifié consciencieusement.

S.M.A.R.T.

S.M.A.R.T. est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il surveille un maximum de paramètres (température, temps de fonctionnement, vitesse de rotation pour les disques magnétiques, nombre de démarrages et d’arrêts…) et dépend de l’expérience du fabricant. La réparation de secteurs utilise une réserve de secteurs et le mapping entre secteurs logiques et secteurs physiques.

On pourrait se dire que, de nos jours, les supports sont fiables et testés par les intégrateurs. D’autres considèrent que la technologie S.M.A.R.T. suffit… et c’est bien commode de ne plus se soucier de la fiabilité des supports de stockage. Mais à la première galère due à un média défaillant, tu évolueras dans ta confiance.

Sais-tu seulement sur lesquels de tes médias S.M.A.R.T. est installé et actif ?
Si tu utilises un RaspberryPi, ton média système est… une carte SD. Elle n’a pas S.M.A.R.T.. Idem pour l’extension de mémoire que tu as ajoutée à ton téléphone.

Je t’invite à lire la page Wikipedia sur S.M.A.R.T. et son paragraphe « Standard, implémentation et limitations ». Que fait et que ne fait pas le S.M.A.R.T. qui fonctionne sur le disque du PC qui te permet de lire cet article ? Difficile de savoir. Comment est-il configuré ? Fais un sondage autour de toi à ce sujet et tu seras pris pour un parano.

Sur ton PC, sais-tu qu’il y a une option S.M.A.R.T. dans le BIOS (ou UEFI) ? Sais-tu qu’il y a un service smartd dans ton Linux ? As-tu compris aussi qu’avec du RAID il n’est pas toujours opportun d’activer S.M.A.R.T. ? Les communications entre S.M.A.R.T. RAID et l’O.S. peuvent se passer plus ou moins bien selon la qualité de ces éléments. Il te faut bien comprendre ce qu’il est possible de paramétrer et deviner comment ça marche derrière.

Si tu demandes une vérification à S.M.A.R.T. par smartctl, sais-tu ce qu’il fait ? Se contente-t-il de lire ou fait-il un test en écriture ?

Enfin, quand S.M.A.R.T. détecte qu’un secteur est devenu défectueux, il ne peut pas deviner quels bits sont défaillants, aussi il renseigne le secteur de secours avec ce qu’il peut, qui est l’état du secteur après défaillance. S.M.A.R.T. a ses limites, il répare comme il peut. S’il est configuré pour, il alerte quand il prévoit de la défaillance, mais sais-tu reconnaître ses alertes ? As-tu compris ce que tu dois faire en réponse aux alertes ?

Je t’invite à apercevoir la complexité de prise en main de S.M.A.R.T. en faisant quelques recherches sur ces listes de mots :

smartctl howto
smartctl configure self test
smartd howto

et tu verras que ce n’est pas simple à comprendre et à configurer.

Tu peux te dire naïvement que tout est bien configuré par défaut et que tes médias seront toujours impeccables. Sinon, il va falloir investir en temps et faire quelques essais. À toi de choisir.

S.M.A.R.T. est une belle avancée technologique, mais il est dangereux de lui attribuer des mérites indus.

BADBLOCKS

Le programme Linux badblocks a été créé en même temps que le paquetage e2fsprogs (mkfs.ext2, mkfs.ext3, mkfs.ext4, fsck.ext2…). À l’époque S.M.A.R.T. n’existait pas et il n’y avait pas de mapping entre les adresses logiques et physiques. C’est le file-system qui devait tout gérer quand il détectait un bloc défectueux, notamment la mise du bloc en liste noire. C’est pour cela que mke2fs et e2fsck lancent un badblocks « dur » quand on leur spécifie deux fois l’option -c. Cela dure trèèès longtemps car les paramètres par défaut ne sont plus bien optimisés.

Depuis l’arrivée de S.M.A.R.T., certains considèrent badblocks comme obsolète. Mais qui peut affirmer que TOUS les médias utilisés par TOUS les usages de Linux sont équipés de S.M.A.R.T. ?
Peut-être qu’au M.I.T. avec un réseau de classe A, on ne s’abaisse pas à utiliser une clé USB ou un RaspberryPi. Je me demande dans quel type de bulle vivent ceux qui pensent que S.M.A.R.T. est sur tous les médias de stockage.

Quand j’achète une clé USB, je lui passe badblocks dessus et s’il y a des mauvais blocs, je la rends et je me fais rembourser.
J’ai essayé d’interroger les fonctionnalités S.M.A.R.T. de diverses clés USB et je n’ai rien obtenu, comme si cette utilité n’y était pas installée :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Mes recherches sur Internet n’ont abouti à rien qui me permette de voir une réponse de la part de clés USB. Peut-être que si j’achetais (cher) des clés USB de très haute qualité, j’y trouverais S.M.A.R.T. ?

Comme l’intervenant du message #25 de ce rapport de bug (en), je pense que badblocks est loin d’être obsolète.
J’ai envie d’imiter le message #20 juste au-dessus en disant : « Je dois demander --- ***pourquoi*** vous (et d’autres personnes) mettez de l’essence dans vos voitures en 2024 ? L’essence en tant que chose a commencé à devenir inutile pour les voitures vers 2011, lorsque la voiture électrique s’est répandue, et que les batteries sont devenues suffisamment énergétiques pour faire rouler des véhicules sur des centaines de km ».

Je t’invite aussi à une recherche sur la liste de mots « courbe en baignoire composants électroniques ». Le programme badblocks peut servir au déverminage. On sait en détail ce qu’il fait. Son résultat est clair, contrairement aux implémentations propriétaires de S.M.A.R.T..
Sans déverminage (rodage) on court le risque de subir trop tôt une réparation discrète incomplète : le secteur réparé sera physiquement bon mais son contenu sera corrompu. La conséquence peut être catastrophiquement discrète. Par exemple, un fichier LibreOffice est une archive zip (compressée), la corruption d’un seul bit y a des conséquences imprévisibles.

De mon côté, j’utilise badblocks pour tester les médias nouvellement acquis et pour effacer ceux bons à réformer. Ce programme permet aussi la chasse aux médias « fake-size », du genre carte SD de 1To qui accepte de recevoir 1To de fichiers, mais qui ne stocke en réalité que 8Go. On trouve de nos jours (juin 2024) des clés USB de 16To vendues au prix de 5 € ! L’application h2testw sous windows et son équivalent f3 sous linux sont spécialement conçus pour cette chasse. Le microprogramme de ces clés USB ou de ces disques a été détourné pour déclarer un espace de stockage falsifié. C’est de l’escroquerie.

BADBLOCKS2

Mon usage du badblocks du paquetage e2fsprogs-1.47.0 m’a amené à y caractériser un bug reproductible en novembre 2023. J’ai eu l’intention de remonter le bug aux équipes ad hoc de ma distribution (Mageia) mais je me suis d’abord mis à regarder le source.

J’y ai trouvé l’origine du bug, et j’ai trouvé d’autres bugs. En ajoutant des instructions de traçage et de simulation d’erreurs du média, j’ai mis en évidence encore d’autres bugs. De fil en aiguille, j’ai fini par retoucher profondément certains algorithmes, et j’ai appelé badblocks2 cette nouvelle version. J’y ai ajouté diverses options faciles à programmer et commodes à l’usage. J’ai copieusement testé.

Si tu veux essayer badblocks2 et/ou prendre connaissance de ma démarche, je livre tout sur mon site. Tu verras pourquoi je me suis rabattu sur la création d’une nouvelle version, plutôt que de faire remplacer l’ancienne (ce qui aurait profité à tous).
Tu peux te faire une idée des fonctionnalités ajoutées en consultant les *.8.txt .
Tu peux t’inspirer des tests décrits dans le fichier Alire.txt, tester diverses valeurs pour -c -t et voir l’effet sur la vitesse de traitement. Tu peux même jouer à arracher la clé en cours de test (Ctrl-C pour arrêter) !

J’espère que ce programme servira à d’autres que moi.

En pratique

Voici une suggestion d’actions à faire lors de l’acquisition d’un nouveau média (disque SSD, disque rotatif, clé USB, carte SD…). Les commandes doivent être lancées par l’opérateur root.
Avec cela, quand dans quelques années tu satureras le média, tu seras sûr que le dernier secteur utilisé aura été déverminé avant la mise en production.

ATTENTION : les usages de badblocks proposés sont destructifs pour les données présentes sur le média. Le mode non-destructif du badblocks actuel comporte des bugs (version e2fsprogs-1.47.0). Celui de badblocks2 a été corrigé.
ATTENTION : la liste des mauvais blocs renvoyée par le badblocks actuel est fausse (version e2fsprogs-1.47.0). Le nombre de mauvais blocs est correct. La liste renvoyée par badblocks2 est correcte.
ATTENTION : le paramètre device du média est supposé être /dev/sdc. Ne pas se tromper, au risque d’effacer un autre média en cours d’usage.

D’abord déterminer le block-size du noyau, c’est une bonne valeur à prendre comme block-size du file-system :

# blockdev --getbsz /dev/sdc

Dans ce qui suit, je suppose que la valeur 4096 a été renvoyée.

Ensuite déterminer si S.M.A.R.T. est sur le média :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Si S.M.A.R.T. n’est pas sur le média

Passer badblocks2 pour voir s’il y a 0 ou peu de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrrvvss -t r -t r -e 40 -o /tmp/sdc.bb /dev/sdc

L’option -e peut être supprimée ou modifiée selon la limite du nombre de mauvais blocs considérée acceptable ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man).

S’il y a trop de mauvais blocs, refuser d’utiliser le média (->garantie ?).

S’il y a 0 mauvais bloc on peut formater en toute tranquillité (partitionner éventuellement avant) :

# mkfs.ext? -b 4096 ... /dev/sdc

S’il y a quelques mauvais blocs, sans que la limite -e soit atteinte, on pourra formater en utilisant la liste sauvée de mauvais blocs :

# mkfs.ext? -b 4096 -l /tmp/sdc.bb ... /dev/sdc

Si l’on veut partitionner, il faudra recalculer la liste des mauvais blocs de chaque partition avant de formater (remplacer sdc par sdc1 dans les commandes badblocks2 et mkfs.ext? ci-dessus).

Si l’on veut formater en vfat exfat ou f2fs (clés USB en général), il n’est pas possible d’utiliser la liste des mauvais blocs détectés ; la seule solution est de refuser d’utiliser le média s’il y a des mauvais blocs (ou alors de restreindre l’usage à une zone saine… à localiser)

Si S.M.A.R.T. est sur le média

On peut vérifier son activation par smartctl :

# smartctl -i /dev/sdc

Ensuite, il faut interroger le média sur l’état et les capacités de son S.M.A.R.T. :

# smartctl -a /dev/sdc

Noter le nombre de réallocations faites et prévues :

# smartctl -a /dev/sdc | grep -i _sector

Puis faire une passe de déverminage, en écriture+lecture car on ne sait pas si l’écriture seule suffit ; ne pas utiliser l’option -p de badblocks ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man) :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb1 /dev/sdc

Faire une passe de vérification, il ne devrait plus y avoir de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb2 /dev/sdc

S’il y a encore des mauvais blocs, c’est soit que le déverminage n’est pas terminé, soit que le média et/ou son S.M.A.R.T. sont foireux (il ne détecte pas les mauvais secteurs vus par badblocks2 ou les secteurs de réserve sont mauvais ou… pire) ; relancer des passes une par une jusqu’à ce qu’il n’y ait plus de mauvais bloc détecté.

Re-interroger S.M.A.R.T. pour voir l’évolution des réallocations :

# smartctl -a /dev/sdc | grep -i _sector

Ensuite on peut formater (partitionner éventuellement avant) en considérant que le média a remappé tous ses mauvais secteurs et est donc impeccable pour l’utilisation :

# mkfs.ext? -b 4096 ... /dev/sdc

Par la suite, on pourra de temps en temps consulter l’état de santé du média en service :

# smartctl -H /dev/sda

Si on est courageux, on peut lancer de temps en temps un contrôle du média par son S.M.A.R.T.
Si on est encore plus courageux, on configurera smartd pour que ces vérifications soient automatiques et pour que les alertes soient envoyées par courriel.

Attention à la communication entre l’O.S., S.M.A.R.T. et RAID (niveau carte mère / niveau OS / contrôleurs bas de gamme), voir la page Wikipedia sur S.M.A.R.T..

Que l’esprit « aware » soit en toi, sur tes données et sur ton espace de stockage