Journal Remise en route d'un analyseur logique Philips PM3580

Salut!

Pour mes projets électroniques, j'utilisais jusqu'à présent un analyseur logique USB compatible Saleae 8 (n'achetez pas l'original, il est hors de prix et la seule justification est le logiciel non libre vendu avec qui n'apporte rien par rapport à PulseView pour mon usage), avec les outils sigrok/PulseView. Il m'a rendu quelques services, mais avec seulement 8 canaux, il permet surtout de travailler sur des protocoles série (I2C, SPI, …). Dès qu'on a un bus parallèle (ne serait-ce qu'un bête port imprimante), on se retrouve vite à court de canaux pour tout analyser d'un coup.

Après avoir surveillé quelques temps les annonces ebay, je me suis décidé pour l'achat d'un Philips PM3580, avec 64 canaux, ce qui sera plus que suffisant pour mes besoins. Contrairement au Saleae qui se connecte sur un port USB, il s'agit d'un appareil "standalone" avec son propre écran intégré (un écran cathodique de 10 pouces en niveaux de gris). On peut analyser des signaux jusqu'à 100 MHz, là aussi c'est bien plus que ce dont j'aurai besoin. Mais le prix était comparable à celui d'appareils plus modernes et moins capables.

La première étape a été de le mettre en route. La disquette système fournie avec l'appareil ne fonctionne plus. J'ai donc du télécharger une image de disquette et recréer une disquette de démarrage, ce que j'ai pu faire à l'aide d'une vieille station Sun fonctionnant sous Solaris 8 (sans raison particulière, il se trouve que c'est la seule machine chez moi qui a encore un lecteur de disquettes en état de marche). J'ai également pu créer la disquette utilitaire (qui permet, entre autres, de configurer la date, mais est victime du bug de l'an 2000) ainsi que diverses disquettes d'exemples et un pilote pour les souris série (je pourrai brancher la mienne dès que j'aurai retrouvé ou construit un adaptateur série DE9 vers DB25).

Cet analyseur Philips est un peu moins connu que les modèles de certains concurrents (HP ou Tektronix par exemple). Cela signifie qu'il existe moins d'outils pour s'interfacer avec. Ceux fournis par Philips (et trouvables sous forme d'image de disquettes) fonctionnent sous DOS. Ça ne m'arrange pas trop. Je me suis donc chargé de désassembler en particulier l'outil permettant de créer des désassembleur. Cela permet de définir des règles de décodage de signaux logiques, et, au lieu d'afficher des séries de 0 et de 1 ou de nombres hexadécimaux, on pourra ainsi décoder, par exemple, les instructions exécutées par un processeur.

J'ai donc désassemblé l'exécutable pour DOS à l'aide de IDA (version 5 Free, les versions gratuites plus récentes ne permettent plus d'ouvrir les exécutables pour DOS), et réécrit en C une nouvelle implémentation de cet outil. Je peux maintenant créer mes propres désassembleurs depuis mon système d'exploitation préféré, en l'occurrence il s'agit de Haiku.

Pour vérifier mon travail, j'ai réalisé un portage de dosemu ce qui me permet de lancer l'outil original sous Haiku et de comparer le résultat avec ma version. Vous allez me dire que j'aurais pu juste faire ça et ne pas m'embêter à réécrire un nouvel outil. C'est tout à fait vrai. Mes patchs dans dosemu ont été intégrés, et j'ai également corrigé quelques problèmes dans Haiku pour pouvoir activer le JIT et faire tournes les applications DOS super rapidement. Certaines de mes modifications bénéficient également aux versions de dosemu pour FreeBSD et Mac OS (historiquement, dosemu était étroitement lié à Linux et aux machines 32 bit x86, mais le développement sur la version 2 est très actif et retire ces limitations).

Le résultat de la compilation est un fichier binaire difficile à vérifier manuellement. J'ai essayé de porter biodiff, un outil de comparaison qui utilise des algorithmes issus de la recherche en génétique pour détecter les insertions, suppressions, et mutations dans une séquence de symboles (que ce soient des gènes ou des octets, c'est à peu près la même chose). Pour l'instant, je me heurte à quelques difficultés avec Rust (que je ne pratique pas vraiment) et des modules qui ont besoin d'être mis à jour pour fonctionner sur Haiku. J'ai donc du me passer de biodiff et me rabattre sur vbindiff, dont l'algorithme est beaucoup plus bête (si un octet est inséré ou supprimé, il considère que toute la suite du fichier est différente).

J'ai tout de même réussi à faire en sorte que mon outil génère un résultat identique au compilateur original pour tous les fichiers sources dont je dispose (moins d'une dizaine de fichiers). Je pense essayer de mettre en place du fuzzing pour mieux m'assurer que ma réimplémentation est correcte et en particulier pour vérifier la gestion des erreurs sur des fichiers invalides.

Je pense également avoir détecté quelques petits bugs dans le compilateur original.

En travaillant sur ce désassemblage, je me suis rendu compte que la sortie du compilateur n'est pas seulement un fichier de configuration. Les données générées sont intégrées dans un fichier "template" qui contient également du code assembleur 68000. Pas de surprise puisque c'est le processeur utilisé dans l'analyseur logique (il s'agit pour être précis d'un 68070, et on retrouve également le chipset vidéo associé, le même qui est utilisé dans les consoles de jeux Philips CDi).

En théorie, il devrait donc être possible d'exécuter du code arbitraire sur cet analyseur logique pour lui ajouter toutes sortes d'autres fonctionnalités. Malheureusement, l'exécutable n'est pas dans un format standard. Ce n'est pas du ELF (c'eût été surprenant pour du matériel datant de 1993), ce n'est pas non plus du a.out ou du COFF, ni rien d'autre que j'aie pu reconnaître. Je pense avoir identifié une zone de code, une zone de données et une table de relocation (permettant de faire la correspondance entre le code et les données si elles n'ont pas été chargées consécutivement en mémoire), mais je n'ai pas encore compris comment les connecter ensemble à l'aide des infos présentes dans l'en-tête du fichier.

J'ai d'abord utilisé IRA et Rehex pour commencer à désassembler le code 68000, mais ces outils montrent leurs limites dans ce cas (au passage j'ai remarqué que la version Windows 32 bits de Rehex n'incluait pas le désassembleur 68000, ce que l'auteur a rapidement corrigé).

Je me suis donc penché sur Rizin et Cutter. Outils qui semblent très puissants, mais la dernière version n'est pas encore disponible pour Haiku. J'ai une piste pour corriger le problème mais je me suis heurté à une petite difficulté avec une dépendance en Rust mal adaptée pour Haiku: une erreur dans le portage de Rustix, qui était mal configuré et pensait que Haiku ne fournit pas la fonction fstatvfs (alors que celle-ci a été ajoutée en 2005 dans Haiku, bien avant l'apparition de Rustix et même de Rust). J'ai corrigé ce souci mais il me faut maintenant attendre une nouvelle version de Rustix avant de pouvoir mettre à jour Tree-Sitter et voir si cela corrige mon problème de crash au démarrage de Cutter…

Avec tout ça, je n'ai même pas encore branché cet analyseur logique sur un de mes montages électroniques.