Hardware
J'ai récupéré une carte de développement Analog Devices EZ-LAB pour les DSP SHARC.
Ces cartes sont prévues pour accepter un DSP de la famille ADSP-2106x soudé en TQFP ou bien monté sur un socket ZIF, une EPROM, des extensions SHARCPAC, ISA et MAFE, et un connecteur JTAG pour debugger le DSP.
La carte dont je dispose a un ADSP-21062 (2Mbit de mémoire, 33MHz) soudé, une EPROM installée, un chip son de PC (ADC/DAC 2 canaux 16bit, 44.1kHz) AD1847 sur l'extension MAFE (carte fille à droite sur la photo), et pas d'extension SHARCPAC.
Ma carte est arrivée avec des pins tordus, mais qui se sont redressés sans peine avec une lame de cutter.
Le schéma est très différent de celui d'un CPU, normal, c'est celui d'un DSP. Ce qui explique les deux bus mémoire et le core relativement simple.
Toolchain
Il existe une toolchain pour Windows, avec l'IDE Visual DSP++ (version 2.0 for SHARC) et le kit de développement Bittware (qui existe aussi pour DOS), cependant il n'est pas distribué (me contacter si vous en avez une copie).
Il existe aussi une toolchain libre disponible pour GNU/Linux (probablement pas fonctionnelle avec d'autres architectures que i386).
Alimentation
Le core du processeur est alimenté par une alimentation buck synchrone contrôlée en PWM par un LM2636, qui génère sa tension de référence avec un DAC réglable par des entrées numériques VID[0:4].
Les transistors MOSFET (STP-40NE03L20) sont prévus pour fournir au moins 30A. Il n'y a aucun marquage sur la self, mais elle devrait avoir un courant de saturation >15A.
Les processeurs compatibles avec cette carte sont alimentables entre 2V et 3.5V, seulement toutes les tension possibles ne sont pas affichées :
PLL
Les horloges de toute la carte sont générées par une PLL Winbond W83194R-58A. Les horloges "auxiliaires" doivent être le plus proches de leur fréquence nominale (peu d'intérêt a overclocker un clavier ou le bus USB). Le bus PCI peut poser des problèmes à plus de 40MHz (cartes réseau, contrôleur de disque dur). Le bus AGP pose peu de problèmes à >80MHz des AGP4x.
Le plus grand intérêt est d'augmenter la bande passante du bus mémoire et d'augmenter la fréquence du processeur.
Sur cette carte-mère, le PLL est configurable par des cavaliers (remappés par un GAL16V8). Seules 6 fréquences sont configurables par des cavaliers. Mais le PLL est aussi accessible par un bus I²C qui est câblé sur le southbridge.
On charge le driver du bus I²C, et on va scanner le bus : # modprobe i2c-viapro
# i2cdetect -r 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Ici, l'adresse 0x50 correspond à l'EEPROM contenue sur les barrettes mémoire (SPD). Le PLL qui nous intéresse est situé à l'adresse 0x69.
# i2cdump 1 0x69 s
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x69, mode smbus block
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 0f 71 0f c0 13 00 .?q???.
Dans la datasheet du PLL, le registre 0x00 correspond au choix de la fréquence.
Tant que le bit 3 est à 0, la fréquence est choisie matériellement.
Les fréquences sont utilisables avec les bits SSEL[0:3] (Registre 0x00, SSEL[0:2] sur les bits 4:6, SSEL3 sur le bit 2.
Faire fonctionner le CPU à une fréquence faible (multiplieur et FSB) permet de pouvoir tester chaque fréquence de bus sans risque d'avoir un système instable.
En écrivant 0x18 dans le registre 0x00, on règle la fréquence à 66MHz (aucun changement), mais on le règle via le bus I²C. # i2cset -y 1 0x69 0x00 0x18 s
En écrivant 0x38 dans le registre 0x00, on règle la fréquence à 75MHz. # i2cset -y 1 0x69 0x00 0x38 s
Comme il n'y a aucun changement (le noyau ne surveille pas la fréquence du processeur), il faut tester la fréquence avec un benchmark dépendant de la fréquence du processeur (une boucle d'un grand nombre d'itération devrait être suffisante).
Par contre la machine se fige en tentant de passer de 66MHz à 83MHz ou 100MHz. Il est probable que certaines horloges doivent être stoppées avant de changer de prescaler pour rester dans leurs tolérances (du coup ce n'est pas vraiment gérable depuis un OS).
Références
i2cdetect, i2cdump, i2cset, version >3.0, packages Debian i2c-tools ou lm-sensors : outils pour contrôler les bus I²C d'un PC.
J'ai déjà essayé de démarrer des machines depuis le réseau, ça évite de s'embêter avec des disquettes peu fiables. Par contre je n'avais essayé que des cartes réseaux répandues sur un bus PCI et datant des années 2000. Pourquoi ne pas essayer une carte ISA datant des années 1990 ?
Choix de la carte réseau
J'ai une carte D-Link DE-220 et une 3Com 3c509 fonctionnelles qui trainent dans un carton plein de cartes ISA.
Après avoir lu leur documentation et fait quelques tests, les deux cartes se configurent sans jumpers, mais avec un programme DOS qui stocke leurs réglages (IO, IRQ, mode ISA PNP, activation de la ROM de boot) dans une eeprom.
La carte 3Com ne fonctionne qu'en mode "ISA PNP" (Plug'n'Play, mais plutôt Plug'n'Pray en pratique) sur ma machine, et ne propose pas de booter en mode ISA PNP.
La carte D-Link fonctionne en mode ISA (IRQ et IO imposés par la carte plutôt que par l'OS), accepte des ROMs de 8 ou 16Kio et des images de ROMs sont trouvables.
Premiers tests
La machine boot, affiche un peu de texte, mais boucle indéfiniment en cherchant serveur RPL. Pas de PXE sur cette carte (le protocole PXE date de 1998 et ne rentre pas dans 16Kio).
Serveur RPL
Comme je ne suis pas le premier à vouloir utiliser RPL, un serveur libre existe (et est inclus dans quelques distributions de Linux).
Sa configuration est intuitive (adresse MAC, masques, chemin du fichier à charger). Il reste les adresses de chargement et d'execution qui ne sont pas intuitives et dépendent des images.
Dans mon cas, j'ai choisi l'image ne2k_isa.pxe d'iPXE, et testé les adresses de chargement et d'execution 0x1000 et 0x1006.
Comme la documentation de RPLD n'est pas très claire, les réglages d'adresses ont dû être faits à tâtons.
Boot de la machine
Le bios initialise la machine, charge la ROM contenue sur la carte réseau (INT19), et execute le programme RPL contenu dans la ROM.
Le programme RPL charge l'image PXE que lui donne le serveur RPL, et l'execute l'image.
Ensuite, iPXE détecte la carte réseau, demande une adresse IP avec DHCP, puis charge un OS via HTTP.
Tests
Je n'ai pas réussi à faire fonctionner PXE avec ma machine 486 (la machine redémarre ou se fige au chargement d'iPXE). Par contre, ça fonctionne sans problèmes avec un Pentium 2 ou avec Qemu émulant une machine 486.
Un Schrödingbug fait que la ROM de la carte réseau n'est pas lue dans certains cas, toujours en démarrant la machine "à froid", aucun problème en cas de reboot. En pratique, c'est lorsque le BIOS effectue trop vite son POST, la carte réseau n'a pas eu le temps d'initialiser la ROM.
Cet article montrait comme mettre en place et utiliser gPXE : http://monorailc.at/cms/?d=2014/11/02/19/23/12-boot-pxe
Seulement, gPXE est un peu ancien et a été remplacé par iPXE, qui apporte des fonctionnalités en plus.
Mise a jour
On remplace le fichier undionly.kpxe situé sur le serveur par celui d'iPXE, et on modifie quelques lignes de la configuration du serveur DHCP.
Jusque là, ça fonctionne de la même façon que gPXE.
Menus
L'intérêt est de pouvoir afficher un menu nativement (sans PXELinux), qui permet de booter plusieurs OS différents.
Pour cela, on va modifier le fichier boot.gpxe présent sur le serveur, et ajouter les images que l'on veut booter.
Le menu est au debut du fichier et commence par le mot clé menu, suivi d'un choix par ligne commençant par item, un label, puis le nom affiché à l'écran.
menu
item shell iPXE shell
item dsarge Debian Sarge NFS
item dsqueeze Debian Sqeeze NFS
item dos DOS
item memtest Memtest86+
choose --default dsqueeze --timeout 5000 target && goto ${target}
La dernière ligne donne le choix par défaut et l'action a faire une fois une option choisie.
Linux
Avec Linux, on peut charger directement un noyau et une initrd. :dsqueeze
kernel http://192.168.3.3/pxe/vmlinuz-squeeze ip=:::::eth0:dhcp root=/dev/nfs nfsroot=192.168.3.3:/media/stuff/chroot/nfsroot/ panic=10 ro ipv6.disable=1
initrd http://192.168.3.3/pxe/initrd.img-squeeze
boot
La première ligne correspond au choix du menu, les deux suivantes chargent le noyau et son initrd, en leur passant des parametres, et la dernière ligne donne l'ordre de booter sur ce qui vient d'être chargé.
DOS
Le plus simple est d'utiliser une image de disquette ou de CD suffisament petite pour rentrer entièrement dans la mémoire de la machine.
Exemple
J'ai filmé un PC sans disque bootant Debian par iPXE, sans autre périphérique bootable que sa carte réseau (avec un firmware gPXE chargé dans le BIOS).
Premier boot
Au premier boot, Alphabios chargeait le noyau d'une redhat, mais le système de fichiers est abimé et plusieurs périphériques ne sont pas détectés. J'ai décidé d'utiliser SRM et d'installer une redhat sur un autre disque dur.
Activation de SRM
La procédure pour passer d'AlphaBIOS à SRM n'est pas forcément évidente :
Appuyer sur F2 au démarrage de la machine (chargement d'AlphaBIOS)
Choisir CMOS Setup
Choisir Advanced CMOS Setup avec F6
Changer Console Selection d'AlphaBIOS à OpenVMS Console (SRM)
Sauvegarder avec F10
Redémarrer en coupant l'alimentation
Il est aussi possible de repasser de SRM à AlphaBIOS en tapant au prompt de SRM : set os_type NT
Boot sur CD
La première étape est de trouver le nom du lecteur cdrom avec la commande show device >>> show device
dka0.0.0.15.0 DKA0 RZ1CF-BF 1614
dqb0.0.1.13.0 DQB0 COMPAQ CDR-8435 0013
dva0.0.0.0.0 DVA0
ewa0.0.0.9.0 EWA0 08-00-2B-86-26-5B
pka0.7.0.15.0 PKA0 SCSI Bus ID 7 5.57
Ici, la première lettre correspond au type de périphérique : disque, ethernet, ..., la seconde correspond au périphérique (SCSI, IDE, floppy), la troisième au canal/contrôleur, et la dernière à l'ID du périphérique.
Ainsi dqb0 est un disque sur le 2nd canal IDE. D'après son nom, on remarque que c'est un lecteur de CD.
SRM interprète les systèmes de fichiers (à travers aboot), par conséquence, il faut aussi connaître le chemin des fichiers à charger : le noyau et l'initrd (si-nécessaire).
On peut booter RedHat 6.2 avec la commande suivante : boot dqb0 -file /kernels/generic.gz -flags "initrd=/images/ramdisk.img root=/dev/hdc"
Ou bien pour Debian Woody : boot dqb0 -file /boot/linux -flags "root=/dev/hdc"
Partitionnement du disque
Le disque est partitionné en utilisant le disklabel d'UNIX plutôt que le MBR de DOS.
Par défaut, la slice c représente le disque entier. On va ajouter trois autres partitions :
a : 2Gio, système de fichiers /
b : 512Mio, swap
c : 18.4Gio, disque complet
d : 15+Gio, /home
Il reste à indiquer le type de chaque slice, à activer le flag de boot sur la slice a, et les formater (sauf c, évidemment).
Il faut aussi faire attention à ne pas faire commencer la première slice sur le premier secteur du disque, à priori pour laisser de la place au bootloader.
À partir de cette étape, RedHat s'installe comme sur un PC, en installant tous les paquets.
Bootloader
Avant de terminer l'installation de RedHat, il faut installer aboot sur le disque dur, avec la commande "swriteboot".
Pour booter sur le disque dur, il suffit de changer les paramètres boot_dev, boot_file et boot_osflags. Ainsi il est possible de booter directement en tapant seulement boot au prompt de SRM.
Changement de noyau
Pour une raison inexpliquée, une fois aboot installé sur le disque, il est devenu impossible pour le noyau d'origine de Redhat de détecter les disques SCSI. L'utilisation du noyau 2.2.22-generic de Debian Woody a corrigé le problème.
Il faut booter sur le cd de Debian Woody, basculer sur la console (alt + F2), puis monter la partition /, et ensuite copier le noyau présent sur le CD, pool/main/k/kernel-image-2.2.22-alpha/kernel-image-2.2.22-generic_2.2.22-2_alpha.deb, le décompresser avec ar puis tar, et enfin copier les modules dans /lib/modules/ et l'image dans /boot/ (il est nécessaire de la décompresser avec deflate ou gzip, selon la version de aboot installée).
Recompilation d'un noyau
L'USB et le réseau restent non fonctionnels.
Le contrôleur réseau est reconnu par les modules de4x5 et tulip, mais je n'ai pas réussi à les faire fonctionner.
Par contre il est possible d'ajouter une carte réseau PCI sans aucun problème, une Realtek 8139 (rtl8139 ou 8139too) a fait l'affaire.
La configuration du noyau est utilisable sur le lien précédent.
Bricolage
L'horloge système ne semble pas fonctionner correctement en 2015, en se remettant toujours en 1995. (même en la réglant dans SRM ou avec hwclock).
Une correction rapide va changer l'année à la fin du chargement d'init, en rajoutant une ligne au fichier /etc/rc.local : date $(date +%m%d%H%M2015).
L'année 2015 est à adapter manuellement (on peut aussi améliorer le script pour changer automatiquement l'année).
Sur d'anciennes cartes graphiques, la définition et la profondeur de couleur sont limitées par la quantité de mémoire :
H*V*bpp/8 : avec 1Mio de VRAM, en 256 couleurs, on ne peut afficher que du 1024*768
Avec 2Mio, on peut théoriquement arriver à 1600*1200 en 256 couleurs, ou 1024*768 en 64k couleurs.
Mais les cartes de cette génération contenait souvent des sockets pour ajouter de la mémoire, et lorsqu'il n'y a pas de socket, il y a souvent des empreintes pour souder les puces de RAM.
Mémoire d'origine : Micron MT 4C16270DJ-7
Boitier : SOJ 40 pins (JEDEC)
Organisation : 256k x 16bits
Tension d'alimentation : 5V
Temps d'accès : 70ns
Mémoire rajoutée : Samsung/SEC KM416C256D-6
Boitier : SOJ 40 pins (JEDEC)
Organisation : 256k x 16bits
Tension d'alimentation : 5V
Temps d'accès : 60ns
Il faut vérifier que la mémoire ait le même boitier, la même organisation et la même tension d'alimentation, au risque d'un non-fonctionnement, ou d'une destruction de la ram ou de la carte graphique.
Si la mémoire ajoutée est plus lente que la mémoire d'origine, on prend le risque d'erreurs d'écriture et de lecture (la mémoire EDO est souvent deux fois plus rapide que la mémoire Fast Page). Mais normalement les problèmes doivent arriver uniquement quand on utilise la mémoire rajoutée (il ne devrait y avoir aucun problèmes en console, dans le BIOS ou avec DOS).
La mémoire de ce type est difficilement trouvable en puce nues. Par contre il est possible de la dessouder depuis des cartes graphiques ou des barrettes de mémoire (SIMM 32bits à 2 ou 4 puces/barrette).
Hardware
Cette station de travail était déjà un monstre à sa sortie en 1998 : processeur 64bits entre 433 et 600MHz, 128Mio à 1.5Gio de ram, le tout en 1998 (les gens normaux se contentaient d'un processeur 32 bits à 300MHz et 64Mio de ram).
Carte riser : 3 PCI 32bits, 2 PCI 64bits, 3 ISA 16bits, 2 IDE, disquette, connecteur MAU (extension réseau), connecteurs game/midi/audio (extension audio).
Carte mère : 2 USB, Ports PS/2 clavier/souris, 2 Ports série RS-232 (câblage standard), Port parallèle IEEE-1284.
Carte audio : ESS 1887 intégrée à la carte riser, extension avec line-in, line-out et port midi, pas de synthétiseur midi.
Carte réseau : DC21143 intégrée à la carte riser, extension avec un PHY ethernet.
L'intérieur du boitier est très bien rangé, avec des câbles sur-mesure. Tout est fait pour que rien ne bouge ni ne vibre.
Aux premiers boots, la carte réseau et la carte scsi étaient détectées aléatoirement et le système plantait avec SRM ou pendant le chargement du noyau. Il a été nécessaire d'enlever la poussière et de nettoyer les connecteurs des slots de RAM et de la carte riser.
Le support en plastique noir en forme d'équerre est indispensable lorsque le boitier est à l'horizontale, pour éviter à la carte mère de plier sous son propre poids.
Les barrettes de SDRAM sont clairement impressionnantes (256Mio, en 1998) :
Les cartes système sont assez encombrantes et denses :
Il faut aussi remarquer que toutes les entrées-sorties sont protégées par des transceivers isolés.
Hardware
Cette station de travail fait partie du "bas de gamme" de Sun en 2002.
La solution pour avoir une station de travail "cheap" était d'utiliser beaucoup de pièces de PC.
Par rapport aux autres machines Sun, on remarque que tous les connecteurs sont "standard", avec un clavier et une souris à brancher en USB, et un écran en VGA.
Il n'y a que le CPU et la carte mère faits sur-mesure par Sun :
On peut voir que pas mal de capas sont à changer... Mais ça ne semble pas rendre la machine instable.
La RAM est de la SDRAM ECC unbuffered (commune sur certains serveurs et stations de travail de 1999 à 2003), le disque dur et le lecteur CD-ROM sont en IDE et l'alimentation est au format ATX, compatibles avec touts les PC de l'époque.
Carte Mère : 4 USB, 2 Firewire IEEE-1394, Port série RS-232 (câblage standard), VGA, Port parallèle IEEE-1284, 4 jacks audio.
Software
La bête fonctionne avec Sun Solaris 8 (SunOS 5.8), un UNIX des années 90 conçu pour les stations de travail.
Au démarrage, la machine effectue un self-test (POST), puis charge le noyau, démarre tous les services (Consoles, SSH, affichage X11). En moins d'une minute on arrive à un menu qui permet de s'identifier.
En ayant créé un utilisateur, la machine utilise CDE (Common Desktop Environment), qui ressemble étrangement à XFCE et aux premières versions de KDE, qui l'ont ouvertement copié.
On peut utiliser le navigateur web Netscape, taper quelques commandes dans un terminal, mais pas grand chose de plus, puisque la machine semble avoir été "nettoyée" de tout programme autre que l'OS.
On peut avoir un peu d'informations sur la machine et le système d'exploitation : # uname -a
SunOS unknown 5.8 Generic_108528-29 sun4u sparc SUNW,Sun-Blade-100
Avec SunOS 5.8 sur un processeur sparc et une machine Sun Blade 100
# psrinfo -v
Status of virtual processor 0 as of: 08/21/15 14:13:43
on-line since 08/21/15 12:07:44.
The sparcv9 processor operates at 502 MHz,
and has a sparcv9 floating point processor.
Ce qui est un peu plus clair sur le processeur (SPARC IIe, 64-bit RISC, 256Kio de cache).
On cherche des informations sur les disques : # swap -s
total: 25592k bytes allocated + 8648k reserved = 34240k used, 2546648k available
bash-2.03# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t0d0s1 136,1 16 4195280 4195280
On voit que le disque est partitionné "à la UNIX", avec une hiérarchie contrôleur ; target (SCSI ID) ; disque ; partition (slice).
On a donc 1.9Go pour la racine du système (/) et 15Gio pour les données des utilisateurs.
Pour le reste des informations, la commande qui est la plus bavarde est dmesg, qui donne les informations du système en chargeant le noyau, et les informations de chaque périphérique en chargeant leurs pilotes.
Configuration
Avec beaucoup de chance, un post-it contenant le mot-de-passe root était collé sous le capot.
Seulement, au premier boot, la souris en USB ne fonctionne pas avec X11, ni avec la console, mais ça m'a permis de découvrir que Solaris est très différent des BSD et de Linux.
Il a suffit de se connecter en SSH pour configurer la machine :
Utilisation du BASH au lieu du KSH (on y gagne la complétion automatique et la mémoire des commandes précédentes)
Configuration du réseau : DHCP était déjà activé, mais les serveurs DNS étaient à renseigner dans /etc/resolv.conf
Ajout d'un utilisateur : commande useradd
Tentative de configuration de la souris
Il a été possible d'identifier le nom du serveur graphique avec la commande /usr/ucb/ps -auxww
Qui nous donne (entre 45 processus) les programmes dt et Openwin, situés dans /usr/dt/ et /usr/openwin, mais dont la configuration est à copier de /usr/openwin/etc/ (configuration par défaut) vers /etc/openwin/server/etc (configuration modifiée).
On remarque que la souris devrait être mappée comme /dev/mouse. En réalité, elle est avec le clavier dans /dev/usb/hid{0,5}.
On peut tenter de modifier le lien /dev/mouse pour pointer vers la souris ou de modifier le fichier /etc/openwin/server/etc/OWconfig, sans succès (soit X crash, soit la souris n'est pas fonctionnelle). C'est bêtement en essayant une autre souris qu'on arrive à un un système fonctionnel (la mollette ne fonctionne pas, mais ce n'est pas critique).
Compatibilité
Souris fonctionnelles : Logitech Premium Wheel Mouse M-BT58 (2005), Microsoft Optical Mouse Blue USB (2005)
Souris non-fonctionnelle : Microsoft Comfort Mouse 3000 (2011)
J'ai pu tester une imprimante matricielle Epson LX-800 de récupération.
Au premier test, rien ne fonctionne en la branchant à un PC via un port parallèle.
Il a été nécessaire de retirer la carte d'interface série pour pouvoir utiliser le port parallèle.
Après un nettoyage et l'installation des drivers pour Windows (driver par défaut de Windows XP), tout fonctionne, voir video :
Il est possible de booter une machine sans disque dur, ni lecteur cd (ni même de clé usb).
Beaucoup de cartes réseaux (j'utilise des 3com 3C905CX) ont une EEPROM qui contient un chargeur de boot réseau.
Il y a donc plusieurs parties:
Serveur DHCP
Serveur TFTP
Image(s) PXE
Boot du noyau
Il faut d'abord configurer le serveur DHCP, pour qu'il donne les paramètres de boot à la machine qui va le lui demander. Pour l'instant, je n'ai pas réussi à configurer dnsmasq pour avoir un serveur tftp sur une autre machine que le serveur dhcp, alors j'ai adapté...
Comme le bootloader embarqué dans la carte va charger un autre bootloader (undionly.kpxe), qui lui, va charger le noyau, on va interroger le serveur DHCP deux fois. Ces deux accès sont distingués par le flag "userclass"
dnsmasq est tellement bien fait qu'il a aussi un serveur tftp embarqué. Il suffit de rajouter les lignes suivantes dans le fichier /etc/dnsmasq.conf
enable-tftp
tftp-root=/tmp
Comme le routeur a peu de flash, j'ai mis la raçine du serveur tftp dans /tmp (tmpfs) pour éviter les problèmes. Mais il faut rajouter un script qui télécharge l'image au boot de la machine. undionly.kpxe est une image de gPXE qui permet de booter sur n'importe quel protocole (même http).
2016-01-10 - No comments
Tags de l'article : hardware, vieilleries
