Mon routeur (WRT54G) et point d'accès wifi avait quelques problèmes de fiabilité (freezes, coupures de réseau...), j'ai essayé de voir si on pouvait trouver un remplaçant vallable.
Le Nexx WT3020 est une Chinoiserie avec deux interfaces ethernet, une interface wifi, un port usb host et un SoC compatible avec OpenWRT.
Software
Le firmware d'origine à l'air utilisable avec un noyau Linux contrôlable par telnet et une interface web en Anglais (ou en Chinois).
Adresse IP : 192.168.8.1
Login (http) : admin
Mot de passe (http) : admin
Login (telnet) : nexxadmin
Mot de passe (telnet) : y1n2inc.com0755
On peut changer le firmware directement depuis l'interface web ou bien par telnet.
OpenWRT
Il faut d'abord connaître la quantité de mémoire flash embarquée. Comme la puce est difficile à lire, il semble que les modèles dont l'adresse MAC commence par 20:28:18 ont 8Mio de flash.
On peut ensuite télécharger l'image d'OpenWRT adaptée au routeur et utiliser l'interface web d'origine pour flasher le firmware.
Au reboot, l'adresse IP change et devient 192.168.1.1, et une fois un mot de passe choisi, on peut utiliser ssh.
Hardware
En ouvrant le boitier (quasiment impossible sans casser de clip), on voir un SoC Mediatek MT7620N, une mémoire flash SPI (8Mio), deux transformateurs d'impulsion (ethernet), de la SDRAM (64Mio), et quelques régulateurs de tension.
On voit directement que la capacité d'entrée est trop faible (400 à 900mV de ripple mesurés, en fonction de la charge). Par contre le ripple est faible après le régulateur LDO qui alimente le SoC.
J'ai préféré rajouter une capacité chimique de 220µF (16V, ESR <1Ω), ce qui limite le ripple à <20mV.
Les pads qui sont accessibles entre les deux ports ethernet et le SoC servent pour une liaison série, utile pour avoir un accès direct à u-boot en cas de problème.
Par contre il n'y a pas de JTAG, du coup en cas de brickage, il faudra dessouder la mémoire flash (SPI) pour la re-flasher.
Performances
J'ai essayé de mesurer la vitesse de transfert en copiant des fichiers par NFS et en utilisant le benchmark réseau iperf :
Routeur -> PC : 24.9Mbit/s
PC -> Routeur : 22.6Mbit/s
En vérifiant, le routeur fonctionne en mode 802.11g, et est théoriquement limité à 54Mbit/s (~30 en pratique). Il y a peut-être une configuration spécifique pour OpenWRT (le hardware est censé supporter la norme 802.11n à 300Mbit/s et le MIMO).
802.11n(update 06.2016)
Avec un peu de recherches, on voit que le mode 802.11n, qui suppose une bande passante de 300Mbit/s ne peut être actif que si le mode WMM (Wi-Fi Multimedia) est activé et si les données sont encryptées en WPA (j'utilisais le mode WEP depuis mon premier routeur).
Avec quelques tests :
Routeur -> PC : 70.8Mbit/s
PC -> Routeur : 21.6Mbit/s
On a aucune différence en upload, mais le débit en download devient intéressant.
J'utilise beaucoup de flux RSS, et j'aime bien que tout le contenu soit disponible, par exemple un article complet sans commentaires dans le cas d'un blog.
Le principe est de pouvoir l'utiliser offline, par exemple en chargeant la page. Ça permet aussi d'éviter quelques clics (dont les pubs et une mise en page non neutre) et d'avoir tout le contenu directement dans le lecteur RSS.
Bons Exemples
Hackaday
Linuxfr
Blogotext
Mauvais Exemples
EDN
Feedburner
La majorité des blogs Wordpress
EDN
Comme on peut remarquer, le flux : http://www.edn.com/rss/design/analog ne contient que des liens vers les pages des articles et une description un peu vide.
Une ligne de bash suffit à faire le travail de base :
wget -qO- http://www.edn.com/rss/design/analog |sed -e 's#<link><!\[CDATA\[http://edn.com/design/analog/#<link><!\[CDATA\[http://www.edn.com/Home/PrintView?contentItemId=#' |sed -e 's#/[^/]*\]\]></link>#\]\]></link>#'
L'étape suivant est d'utiliser ce lien pour remplir le flux.
Comme mon niveau en PHP tient plus du bricolage qu'autre chose, il est sûrement possible de faire beaucoup mieux et plus efficace.
Le script commence par tester si le flux RSS a été mis à jour récemment et s'il a changé, pour économiser la bande passante et les ressources du site distant comme ceux de la machine executant le script.
Ensuite, le flux RSS est analysé, les identifiants, date et titre de chaque article sont stockés dans un tableau qui est utilisé pour construire le flux RSS final.
La librairie simple_html_dom permet de manipuler facilement les balises XML.
Bugs
La date est incorrecte dans certains articles du flux RSS d'EDN (Nov 01 2016 pour un article écrit le 11 Jan 2016), mais la majorité fonctionne.
Hardware
La carte est assez simple avec un routage très compact, avec deux buffers TTL 74ALS245 pour le port parallèle, un ASIC custom noté DL3520S (D-Link).
L'ASIC addresse directement sa mémoire cache (32k x 8bit, 70ns), une eeprom SPI de 128bits (93C46) pour sauvegarder l'adresse MAC et les réglages permanents.
Le bus entre l'ASIC et le contrôleur MAU et RJ45 (AT&T T7213) est isolé par un transformateur d'impulsions.
Le contrôleur MAU -> Coaxial (Myson MTD493V) est relié directement au bus MAU du chip AT&T, mais le port RJ45 est relié au chip AT&T par un autre transformateur d'impulsions.
L'alim est commandée par un chip "universel" LT1172 avec un transformateur, qui permet de fournir du +9V et du +5V à partir d'une unique alimentation (12V externe, le port parallèle ne fournit pas de courant).
Compilation du driver pour Linux
Le driver de620 est bien caché et n'est pas compilé par défaut, mais on peut facilement le rajouter.
Avec Debian Squeeze, on va installer les sources et les kernel-headers qui correspondent à notre noyau apt-get install linux-source-$(uname -r |awk -F "-" '{print $1}') linux-headers-$(uname -r)
Une fois tout copié, on va extraire les sources dans le dossier /usr/src/, et préparer le noyau à être installé.
GCC, make et libncurses-dev (dans la même version que celle qui a servi à compiler le noyau) sont nécessaires.
On va commencer dans le dossier contenant les sources du noyau en préparant le noyau : $ cd /usr/src/linux-image-$(uname -r |awk -F "-" '{print $1}')
$ cp ../linux-headers-$(uname -r)/Module.symvers .
$ cp /boot/config-$(uname -r) .config
$ make prepare
$ make scripts
$ make menuconfig
Dans l'interface menuconfig, il va falloir vérifier que le port parallèle est bien activé CONFIG_PARPORT=m et activer les cartes réseaux (Device Drivers ---> Network device support ---> Ethernet (10 or 100Mbit) ---> Pocket and portable adapters, D-link DE600 & D-link DE620 pocket adapter support)
Si la machine est lente, il est conseillé de retirer le maximum de modules (uniquement réseau, la compilation des autres sera évitée).
On peut vérifier que les modules vont bien être compilés : $ grep CONFIG_DE6.0 .config
CONFIG_DE600=m
CONFIG_DE620=m
Il ne reste plus qu'à compiler : $ cd drivers/net/
$ make -C ../../ M=($pwd) modules
Seulement les drivers relatifs au réseau seront recompilés (quasi uniquement DE600 et DE620).
Une fois la compilation et l'édition de liens terminées, on va pouvoir copier les modules # cp de6?0.ko /lib/modules/$(uname -r)/kernel/drivers/net/
# depmod -a
Depmod permet de mettre à jour la liste des modules chargeables par modprobe.
Utilisation
Avec le driver installé, il ne reste qu'a le charger, configurer la carte réseau, puis l'utiliser. # modprobe de620
D-Link DE-620 pocket adapter, Ethernet Address: 00:80:c8:xx:xx:xx (32k RAM, UTP)
Dans mon cas, l'interface est reconnue comme eth1, et on peut la régler avec une adresse IP statique avec ifconfig ou bien en dynamique (dhclient est installé par défaut avec Debian).
On peut rapidement tester avec les commandes ping, route, nslookup et arp que tout fonctionne correctement.
Performances
Pour tester sans être dérangé par d'autres facteurs, je branche un PC de test directement sur la carte PE-EPP avec un câble RJ45. Il n'y a que deux machines sur le réseau. iperf est un outil prévu pour mesurer la bande passante de réseaux, parfaitement adapté à ce cas. J'ai testé en alternant les modes client et serveur, pour mesurer le débit montant et descendant.
[ 3] local 192.168.10.1 port 50051 connected with 192.168.10.2 port 5001
[ 3] 0.0-10.0 sec 2.19 MBytes 1.83 Mbits/sec
[ 5] local 192.168.10.1 port 5001 connected with 192.168.10.2 port 49470
[ 5] 0.0-15.6 sec 2.00 MBytes 1.07 Mbits/sec
[ 4] local 192.168.10.2 port 49468 connected with 192.168.10.1 port 5001
[ 4] 0.0-10.0 sec 1.88 MBytes 1.57 Mbits/sec
[ 5] local 192.168.10.2 port 5001 connected with 192.168.10.1 port 50051
[ 5] 0.0-10.8 sec 2.19 MBytes 1.70 Mbits/sec
Avec plusieurs tests, on a bien 1~1.5Mbit/s en réception et 1.5~1.8Mbit/s en émission, avec une charge CPU élevée.
Ce débit peut paraître lent devant les 10Mbit/s de l'ethernet, mais il ne faut pas oublier que le port parallèle ne dépasse pas 200kio/s en mode SPP, ce qui est cohérent. Il est possible que mon port parallèle et son driver ne fonctionnent pas en mode EPP (2Mio/s maximum et accès DMA).
Note
Plusieurs fois pendant les benchmarks, la carte a arrêté de fonctionner et le noyau a affiché eth1: transmit timed out, network cable problem?. La carte refonctionne après un rechargement de driver (ifconfig eth1 down; rmmod de620; modprobe de620; ifconfig eth1 192.168.10.1).
DOS
Un driver est fourni pour DOS, Windows 3.1 et OS/2, mais DOS n'est pas vraiment pratique.
Carte mère
La carte mère est assez compacte, même pour les standards de 2016, et a un nombre impressionant de vias (dont des vias borgnes) et a probablement plus de 6 couches.
En comparaison avec les cartes mères de PC de bureau, il y a très peu de ports d'extension, et donc peu de place utilisée par des buffers et des connecteurs. Il y a aussi beaucoup d'ASICs custom, pour remplacer une partie de la glue logique (les cartes mères de 486 sont habituellement pleines de puces TTL 74xx).
Écran
La nappe J5 est reliée à une carte inverter, placée sous l'écran. Les signaux de données de l'écran DSTN (deux mots de 4 bits, Hsync, Vsync et DotCLK) sont reliés directement de la carte mère à l'écran. La carte contient une alimentation boost (LTC1172) suivie d'un régulateur LDO (LM337) pour alimenter l'écran LCD avec une tension d'environ -20V. Le reste de la carte est utilisé pour un onduleur résonant qui alimente le néon à cathode froide (CCFL) de l'écran (600~1'200V).
Les deux potentiomètres permettent de régler la luminosité (tension d'alimentation du néon), et le contraste (tension de bias de l'écran LCD).
Le brochage du connecteur de l'écran a été identifié en suivant les pistes de signaux et en mesurant les tensions moyennes/pic :
FLM (Vsync)
CP1 (Hsync)
CP2 (Dot CLK)
Vdd (5V)
GND
V- (-21.5V)
DU0
DU1
DU2
DU3
DL0
DL1
DL2
DL3
Modifications
La batterie d'origine a été remplacée par une CR2032, plus courant, en changeant le support, mais elle aurait pu être remplacée en utilisant le connecteur J11.
Hardware
Cette station est le haut de gamme de 1995.
Tout est fait sur-mesure par Sun ou utilise des composants haut-de-gamme.
Beaucoup de connecteurs internes ou externes sont exotiques, mais ont été choisis avant que les PC soient répandus, et où chaque constructeur avait ses propre standards de câblage.
Configuration :
CPU : UltraSPARC, 64-bit, 143MHz
RAM : 192Mio DSIMM (4x16Mio + 2x64Mio, 2 slots libres), bus 288bits (256 + ECC), les modules s'installent par paire
Disque dur : Quantum 1Go 5400rpm SCSI (SCA)
Lecteur CDROM : Non-installé
Lecteur disquette : Non-installé
Carte Graphique : TurboGX 1Mio, 8-bit, sbus
Carte d'extension sbus : Réseau/SCSI (un slot sbus libre)
Alimentation : Monstre de 180W (au moins deux canaux complètement distincts, et une sortie 230V commandée)
Câblage
Tout est différent des PC. Par exemple, la souris est branchée au clavier, qui est branché à la carte-mère avec un connecteur mini-din à 8-pins (incompatible avec les claviers PS/2). L'écran utilise un connecteur 13W3, avec 3 coax et 10 pins dans un connecteur de la taille d'un DB-25, mais pas avec le même pinout que les écrans SGI ou NeXT.
Par chance, j'ai pu avoir un clavier avec la machine, mais je n'ai pu récupérer qu'un câble 13W3 mâle, il va donc falloir bricoler.
Ventilateur
En branchant la machine pour la première fois, on découvre que le ventilateur du processeur ne fonctionne pas, et qu'il utilise un connecteur Molex micro-fit introuvable.
Le ventilateur d'origine est un "Elina Fan" KDA1205MB8P : 50mm de diamètre, 10mm d'épaisseur, 5 pales, "middle speed", 12V, 140mA, ~5'000rpm, ~10CFM.
Pour éviter une surchauffe, il faut le remplacer par un ventilateur équivalent, un "ADDA" AD0512MB-G76 : 50mm de diamètre, 10mm d'épaisseur, 7 pales, "middle speed", 12V, 90mA, ~4'600rpm, ~10CFM.
Le connecteur et le câble se changent en quelques coups de fer à souder.
Console
Comme j'ai mis un peu de temps à faire fonctionner l'écran, j'ai vu qu'il était possible d'utiliser la machine à partir d'une console (Port A, 9600 8N1).
C'est un câble DB25, mais il n'y a que 3 fils à souder. On peut même recycler un câble DB25 mâle d'imprimante.
Ici on va le relier à un PC avec un connecteur DB9 :
| DB25 | Signal | DB9 | Signal |
|----------+--------+-------+---------|
| 2 | Tx Out | 3 | Rx In |
| 3 | Rx In | 2 | Tx Out |
| 7 | GND | 1 | GND |
Il faut aussi même s'assurer que les ports A et B sont configurés en mode RS-232, avec les jumpers J2104 et J2105 (Reference Manual, pages 4-1 à 4-3).
Il n'y a plus qu'à brancher à un PC avec un terminal, et on devrait voir rapidement des infos quand la machine démarre.
Affichage
Faire un adaptateur 13W3 vers VGA m'a pris du temps et plusieurs essais, simplement parce qu'il y a plusieurs standards (SGI, IBM, NeXT, Apple, Sun...), il est même possible d'avoir différents standards pour une même marque.
Pour une station Sun Ultra 1 avec une carte TurboGX :
| 13W3 | Signal | VGA |
|--------+-----------+-------|
| 1 | Serial R | NC |
| 2 | V Sync | NC |
| 3 | Sense 0 | NC |
| 4 | Sense GND | | ---+
| 5 | C Sync | 13 | |
| 6 | H Sync | NC | |
| 7 | Serial W | NC | |
| 8 | Sense 1 | NC | |
| 9 | Sense 2 | | ---+
| 10 | Sync GND | 10 |
| A1 | Red | 1|6 |
| A2 | Green | 2|7 |
| A3 | Blue | 3|8 |
Les pins Sense 2 et Sense GND sont reliés pour que la carte graphique se configure en mode 1152x900@76Hz (et détecte un écran).
Sur cette carte, les synchros verticales et horizontales ne sont pas supportées, il faut utiliser la synchro composite à la place (qui n'est pas supportée par beaucoup d'écrans LCD).
RTC/NVRAM
Sur les machines SUN, des paramètres propres à la machine, l'heure et l'adresse MAC de la carte réseau sont stockées dans une SRAM avec une batterie on-chip. Ça fonctionne très bien, mais la durée de vie de ces puces est de l'ordre de 15 à 20 ans. Au delà, il faudra changer la puce ou découper la puce pour changer la pile.
On commence par enlever la puce de son support (Reference Manual, page 10-10) en notant la position du détrompeur (côté CPU) :
Ensuite, on va limer le boitier de la puce pour atteindre les contacts de la pile, du côté opposé au détrompeur :
Pendant cette étape, il est pratique de placer la puce dans un étau, pour être sûr de limer horizontalement.
Une fois les contacts atteints, on peut venir y souder un support de pile CR20xx ou bien des piles AA/AAA :
Il ne reste plus qu'a remettre la NVRAM dans son socket (détrompeur côté CPU).
Les horloges RTC/NVRAM DS1553 ont l'air compatibles pin-à-pin, avec les mêmes fonctionalités et les mêmes registres.
Upgrades
Le disque dur d'origine (1Go, 5400rpm) a été remplacé par un disque dur plus récent (18Go, 10krpm avec un bruit d'aspirateur), pour avoir un peu plus de place pour Solaris 8 (l'installation complète prend 1.3Go).
Un lecteur de DVD SCSI a été ajouté pour tenter de démarrer depuis un CD, mais il semble y avoir des histoires avec des secteurs de 2048 et 512 octets.
Notes
Il n'est pas possible d'écrire dans la console série si le clavier est branché
L'écran ne s'allume pas si le clavier n'est pas branché
En voyant une vidéo parlant des données présentes sur les divers codes barres des billets d'avion, j'ai regardé si les billets de train que j'avais en stock étaient pareil. https://www.youtube.com/watch?v=jM4_iz3RqE8
J'ai trouvé 4 types de billets avec des codes-barres différents :
Billets cartonnés (code PDF417)
E-Billets TGV et IC (code PDF417 ou Aztec)
E-Billets TER (code Aztec)
Billets "Online-Ticket" ÖBB imprimés (code Aztec)
Billet cartonné
"Billet classique", commandé puis retiré a un guichet/borne, avec un code PDF-417 imprimé à gauche
F : Drapeau de spécimen (0 pour un faux ou 1 pour un vrai)
G : Version de codage du billet (1)
H : Ticket A de B
0 : Réservé (10 caractères)
I : Type de carte de réduction (deux espaces en cas d'absence)
J : Nombre de voyageurs adultes
K : Nombre de voyageurs enfants
L : Dernier digit de l'année du voyage
M : Date d'impression (nombre de jours depuis le 01.01)
N : date de début de validité, idem
O : Date de fin de validité, idem
Premier segment :
P : Gare de départ (code ISO3166-1 du pays puis code de la gare sur 3 digits)
Q : Gare d'arrivée, idem
R : Numéro de train (6 digits, ou 5 digits + '\0', ou '0' + 4 digits + '\0')
S : Code antifraude
T : Date de départ du train (nombre de jours depuis le 01.01)
U : Numéro de voiture
V : Numéro de place
W : Classe du voyage
X : Code du tarif
Y : Conditions du services/payements
Le premier segment (de M à V) peut être complété par un second segment suivant la même syntaxe si le voyage a des correspondances. En cas d'absence, il y a 29 espaces, la classe est notée '*', puis 6 espaces.
Ici on a un un billet au format "e" pour le numéro de dossier RUZNxx, un numéro de billet 58361xxxx, le billet est valide, et il n'y a qu'un seul billet pour ce voyage. Le billet n'est pas lié à une carte de réduction, il est pour un adulte sans enfant, est vallable pour l'année 2013, a été acheté le 14.06 et est vallable du 15.06 au 14.08.
Le premier segment est au départ de Lyon Part-Dieu (France, LPD) et à destination de Genève-Cornavin (Suisse, GVA), pour le train 96506, le code est illisible, le train circule le 15.06, n'a pas de place/voiture réservée, est en 2nde classe, pour un tarif "illico Jeunes -25%" et n'est pas échangeable après le départ.
Dans tous les cas, ces billets ne posent aucun risques une fois le voyage effectué dans sa totalité (par contre il est possible de l'annuler ou de le reproduire si il n'a pas encore été utilisé).
E-Billet TGV/IC
Les E-billets sont fournis par des agences de voyages (Voyages-SNCF, Capitaine-train, E-billet-SNCF) et ont un code Aztec pour ceux imprimés soi-même ou un code PDF-417 pour ceux imprimés sur les bornes de la SNCF. Dans les deux cas ils utilisent la même organisation.
Ici on a un billet au format "i", imprimé sur une borne SNCF, le billet est une "Confirmation de voyage" pour le dossier RIKNxx, un numéro de billet 248713xxx, le billet est valide, et il n'y a qu'un seul billet pour ce voyage.
Le billet est au départ de Chambéry-Challes-les-eaux (France, CMF), à destination de Paris-Austerlitz (France, PAZ), avec le train 05706 le 13/05.
Le numéro d'identifiant du trajet est 0029009166230xxxxxx, porté par "Xavier Bo", voyageant en seconde classe avec un tarif "preum's"
La seconde partie du trajet est au départ de Paris Montparnasse (France, PMO) vers La-Ferté-Bernard (France, DLY), avec le train 16757.
Ici on a un billet au format "i", imprimé par ses propres moyens, le billet est une "Confirmation de voyage" pour le dossier QZWKxx, un numéro de billet 482593xxx, le billet est valide, et il n'y a qu'un seul billet pour ce voyage.
Le billet est au départ de Genève-Cornavin (Suisse, GVA), à destination de Lyon Part-Dieu (France, LPD), avec le train 09744 le 19/12.
Le numéro d'identifiant du trajet est 00290290169300xxxxxx, porté par "Xavier Bo", voyageant en seconde classe. Par contre les informations de tarif sont vides et le voyage n'a pas de correspondance (champs remplis par des espaces ou des '0').
Le ticket à plutôt l'air de servir à identifier le voyageur (I, J, K, Q, R) et à porter un numéro d'identifiant (Q) qui doit pointer dans une base de donnée mieux remplie (et non-modifiable).
Certains paramètres (O, P, T, V) ont l'air d'être présent en cas de base de donnée injoignable ou pas à jour pour au moins vérifier sommairement que personne ne tente de frauder.
E-Billet TER imprimé
Le billet a été commandé sur le site web des TER-Rhône-Alpes et a un code Aztec assez grand.
Le début contient des données encodées, puis la chaîne :
En interprêtant sommairement, on remarque plusieurs chaînes contenant la date du 28.12.2015 (date de commande, début et fin de validité du ticket).
La chaîne 1313 correspond à l'heure de la commande du billet, "NG02" semble être un tarif, et plusieurs champs peuvent correspondre à la classe.
Les champs FRLYL et FRHCZ sont au format des autres billets et indiquent les gares de départ et d'arrivée (France, Lyon Gorge-de-Loup et Fleurieux-sur-l'Arbresle).
Par contre je n'ai qu'un seul ticket de ce type pour l'instant, je pourrais compléter quand j'aurais comparé avec des tickets du même type pour des trajets.
Internet-Ticket ÖBB imprimé
Les tickets à imprimer soi-même sont les seuls à comporter un code-barres unique. Par contre le codage a l'air similaire et compatible avec celui utilisé par la DB (Allemagne) et les SBB (Suisse).
Pour l'instant le code comporte une en-tête dépendant du type de ticket/carte, du transporteur et de la longueur du message. Le reste est encodé en binaire mais semble décodable.
J'ai récupéré deux points d'accès D-Link DWL-G700AP hors-service, chacun de révision B3, le premier fabriqué au milieu de l'année 2006 et le 2nd au milieu de l'année 2007.
Point d'accès #1
Au branchement, il ne démarre pas et aucune LED n'est allumée.
En l'ouvrant, la tension est à 0V en sortie des selfs de choke de l'entrée d'alimentation (fonctionnelle). L'Ohm-mètre affiche un court-circuit sur le rail 3.3V (sortie du régulateur qui alimente quasiment toute la carte).
Quelques capacités sont gonflées, mais aucune n'est en court-circuit.
Point d'accès #2
Au branchement, seulement la LED D1 (Power) est allumée, mais aucune réponse par le réseau ou par le port série.
En mesurant un peu de partout, la sortie du régulateur U9 (GS1117AX-18) donne 0.95V à la place des 1.8V attendus.
Le simple échange de régulateur entre les deux points d'accès à suffit à en rendre un fonctionnel.
Notes :
Le régulateur U9 chauffe beaucoup et a une surface de dissipation trop petite...
Il est possible d'alimenter le routeur avec n'importe quelle tension entre 5V et 16V (tension limite des capacités, le régulateur Buck supporte au moins 20V).
Port série
Le connecteur J2 est cablé directement sur le SoC RTL8186 (signaux 3.3V) :
3.3V
GND
CTS*
RTS*
TX
RX
*Non-testé et non-indispensable
La connection est en 38400, 8N1 et donne un accès au bootlog de Linux et à un shell busybox.
Flash
En cas de flash du mauvais firmware, le point d'accès à un bootblock qui permet de reflasher "facilement" le point d'accès.
Débrancher l'alimentation
Tenir le bouton RESET appuyé
Brancher l'alimentation
Lâcher le bouton RESET après 5s
Brancher un PC en ethernet avec l'adresse 192.168.1.xx (différente de 192.168.1.6)
uploader le firmware par tftp :
tftp 192.168.1.6
tftp> binary
tftp> put DWLG700AP_FW231b02.bin
Sent 1025832 bytes in 2.6 seconds
tftp>
Firmwares Wive et Wive-NG
Ces deux firmware alternatifs sont disponibles et permettent plus de choses que le firmware D-Link de base (qui n'a pas les commandes ls, vi, mount ou ping...).
Par contre les firmwares Wive sont un peu buggés (un des firmware détecte aléatoirement 8 ou 16Mio de RAM et plante dès qu'on utilise une zone de mémoire inexistante), très mal documentés et il y a quelques instabilités qui freezent la machine ou la redémarrent.
Firmware Realtek/D-Link Custom
Le firmware et une partie de la toolchain RTL8186 sont fournie sur le site de D-Link, et il est possible d'y modifier pas mal de choses.
Il faut juste éviter de bricker la machine en cassant le bootloader. ÉCHEC
JTAG
Comme j'ai brické le point d'accès en cassant le bootloader, j'ai essayé de le reflasher en utilisant le bus JTAG (12 pins),
nTRST (NC)
GND
TDI (D0)
GND
TDO (!Select)
GND
TMS (D2)
GND
TCK (D1)
GND
nSRST (NC)
GND
Je n'ai pas de programmateur JTAG générique, du coup j'ai copié un programmateur Xilinx DLC5 sur port parallèle (adresse 0x378 sur ma machine), en le réglant à 250kHz (mais ça ne fonctionne pas, peu importe la fréquence).
jtag> cable DLC5 parallel 0x378
Initializing parallel port at 0x378
jtag> frequency 250000
Setting TCK frequency to 250000 Hz
requested frequency 250000, now calibrating delay loop
new real frequency 241253, delay 0
done
jtag> detect
Warning: TDO seems to be stuck at 1 ÉCHEC
J'ai un point d'accès Wifi/routeur D-Link DIR-615 (rev. H2) qui sert à couvrir la maison. Le routeur s'est arrêté de fonctionner du jour au lendemain (après 3 ans d'utilisation).
/!\ Échec des réparations
Réparation
Quand on le branche, la LED "POWERLED" (D30) reste allumée en orange et rien d'autre ne fonctionne.
Il faut enlever deux patins en caoutchouc pour acceder aux vis (1), puis déclipser le dessus du boitier (2).
L'entrée de l'alimentation est tout de suite convertie en 3.3V par un régulateur buck IT2602M. Comme rien d'autre n'est alimenté directement par le bloc d'alimentation, il (5V/1A) peut fournir entre 12V/200mA et 4.5V/800mA sans que ça ne pose de réel problème.
En sortie du régulateur, on mesure ~3.34V, mais il y a un petit glitch au démarrage. Un voltmètre en AC mesure 200mV de ripple en moyenne (et probablement bien plus quand le SoC tente de démarrer).
En posant un tournevis (en acier, non-aimanté) sur l'inductance L33, sa valeur augmente légèrement et suffisament pour que le routeur démarre et fonctionne.
En pratique, la capacité C244 (Lelon RGA 105°C, 16V) est mesurée à 426µF au lieu de 470µF (peu gênant), mais son ESR est mesurée à 1.2Ω, ce qui est critique pour une capacité en sortie d'une alimentation buck.
On peut la remplacer par une capacité 1000µF/6.3V "low-ESR" (n'importe quelle capacité entre 470µF et 1500µF de tension >6.3V devrait suffire, tant que l'ESR est faible). Pour éviter une usure rapide, on y ajoute une capacité en céramique de 4.7nF (ESR de <100mΩ).
Seconde réparation
Après quelques jours, le bloc d'alimentation et le SoC se sont mis à couiner. Il a suffit de changer le bloc d'alimentation par un bloc 7.5V/1A pour corriger le problème et supprimer le couinement.
Il est aussi popssible que la capacité de découplage de l'alimentation soit usée.
Échec
Après encore quelques jours, le SoC couine toujours (buzz à 100~1kHz) et est incapable de démarrer. Le système n'est pas debuggable facilement sans oscilloscope ni doc détaillée du SoC.
Port série
Le connecteur J4 donne accès au port série du SoC Ralink.
3.3V
GND
TX
RX
Branché à un convertisseur USB-Série 3.3V, on accède à une console qui affiche le bootlog du routeur. Il est possible d'accèder à un shell en tapant ctrl + C, puis sn2450.
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.
2016-05-25 - No comments
Tags de l'article : chinoiserie, hardware, info, linux, réseau
