Le retro-hacking poussé à son paroxysme ! Un ingénieur a réussi l’exploit de faire tourner Linux en mode SMP (multitraitement symétrique) sur la mythique extension Sega 32X. Sans primitives de synchronisation matérielle, il a tout géré en logiciel via l’algorithme de Peterson. Performance désastreuse, mais concept génial.
Certes, faire tourner le noyau de Linus Torvalds sur des appareils insolites ou obsolètes est une tradition particulièrement respectée chez les développeurs système, mais pousser l’audace jusqu’à activer un véritable multitraitement symétrique sur l’extension de console la plus chaotique des années 90 relève du génie absolu. L’ingénieur en systèmes embarqués connu sous le pseudonyme de cakehonolulu vient de publier les détails d’un projet personnel hors norme : injecter et exécuter Linux sur la Sega 32X. Un défi technique de board bringup dont le créateur résume lui-même le verdict avec un détachement typique des développeurs de bas niveau : « Les performances sont catastrophiques, la contention de bus est délirante ; mais ça fonctionne, et ça me suffit. »
Le défi de la mémoire ou comment arracher 4 Mo de RAM à une cartouche de jeu
Commercialisé en novembre 1994, le module de mise à niveau Sega 32X avait pour ambition d’offrir une transition matérielle bon marché avant l’arrivée des consoles de nouvelle génération. Si l’architecture surpasse largement la console hôte, elle souffre d’une limite dramatique pour le génie logiciel moderne : elle ne dispose que de 256 Ko de RAM système. Une quantité de mémoire vive bien en deçà des exigences minimales du moindre noyau monolithique.
Pour briser cette contrainte physique, l’ingénieur a détourné l’usage d’une cartouche flash haut de gamme conçue par le constructeur Krikzz. En exploitant les capacités d’un mappeur étendu (Extended SSFv2 Mapper), le script de démarrage reconfigure les registres de la cartouche pour rendre l’espace normalement alloué à la ROM accessible en écriture. Ce tour de passe-passe technique permet d’obtenir un espace de 4 Mo de RAM fonctionnelle. Après avoir isolé 540 Ko pour y stocker l’image du noyau compressée et son système de fichiers temporaire (initramfs), le système dispose enfin de la marge nécessaire pour s’initialiser.
Fiche technique et comparaison des architectures matérielles
| Composant système | Console de base (Sega Genesis / Mega Drive) | Module d’extension Sega 32X |
| Processeur principal | 1 x Motorola 68000 cadencé à 7,6 MHz | 2 x Hitachi SuperH SH2 cadencés à 23 MHz |
| Largeur du bus | 16 bits | 32 bits |
| Mémoire vive (RAM) | 64 Ko de RAM système | 256 Ko de SDRAM (+ 4 Mo via hack de cartouche) |
| Mémoire vidéo (VRAM) | 64 Ko | 256 Ko avec double tampon (double-buffered) |
| Rendu graphique | Calculs basés sur les sprites | 3D logicielle (faces pleines, ombrage Gouraud) |
L’algorithme de Peterson pour dompter l’absence de synchronisation des puces
Le véritable chef-d’œuvre de l’implémentation logicielle réside dans la mise en place du mode SMP (Symmetric Multiprocessing). Faire coopérer les deux processeurs Hitachi SH2 à 23 MHz s’apparentait à un cauchemar d’ingénierie puisque le composant de Sega est totalement dépourvu de primitives matérielles de synchronisation ou de mécanismes de cohérence de cache inter-CPU.
Pour résoudre cette absence de garde-fous, cakehonolulu a déployé une solution radicale :
-
Désactivation du cache : tous les mappages mémoire ont été configurés en mode non mis en cache afin d’éviter que les deux processeurs ne traitent des variables obsolètes.
-
Implémentation logicielle pure : l’ingénieur a réécrit les mécanismes de verrouillage (locks) en adaptant l’algorithme de Peterson au code de l’architecture sh du noyau, en s’inspirant des travaux historiques réalisés sur la branche sparc32.
-
Détournement du processeur 68000 : le processeur central d’origine de la Mega Drive a été converti en arbitre de bus et en routeur d’interruptions inter-processeurs (IPI) pour forcer les puces SH2 à communiquer.
-
Création d’un registre CPU ID : un registre de diviseur matériel normalement inutilisé (DVSR) a été détourné pour servir de registre d’identification d’arborescence, permettant au système d’exploitation de savoir instantanément quel processeur exécute le code.
Au prix de lourds ajustements sur la gestion de la pile pour corriger des corruptions de registres générées par le compilateur GCC, le système parvient à franchir l’étape de calibration de l’horloge et à charger l’environnement utilisateur BusyBox via une chaîne d’outils optimisée sh2eb-linux-muslfdpic. Les scripts de configuration ainsi que le code source ont été publiés en open source par l’auteur pour permettre aux passionnés de reproduire l’expérience sur leur propre console de salon.
🦋 L’actualité de l’open source en français dans votre flux. Suivez Goodtech sur Bluesky (ou vos applications AT Protocol comme W Social et Mu) grâce à notre compte officiel. Suivez, partagez, abonnez-vous à @goodtech.info !
