Le principe d'un asservissement est d'utiliser un capteur pour contrôler un actionneur.
Si le capteur est fiable et qu'on reste dans les limites de l'actionneur, il est possible de le contrôler précisément, même avec des perturbations (tension d'alimentation, frottements, contraintes mécaniques...).
L'asservissement d'un système ne va pas augmenter ses performances, au contraire, il faut disposer de "marge" pour qu'un asservissement soit efficace.
Ici, j'ai utilisé un moteur/réducteur d'imprimante Canon Pixma, avec un disque/encodeur optique (QEI) de 720pas/tour. (résolution de 150LPI).
Le codeur optique est branché sur les entrées d'interruption d'une carte Arduino Uno (qui permet de coder vite et mal...), et une / commande le moteur, alimenté en 12V.
Asservissement numérique
Plutôt que d'asservir avec un système analogique, on acquiert les capteurs et commande l'actionneur à intervalles fixes. Le système est en boucle ouverte entre ces instants. L'approximation d'un système discret équivalent à un système continu n'est vallable que pour une constante de temps grande devant la période d'asservissement (10ms).
Asservissement en position ErreurPosition = ConsignePosition - MesurePosition;
Commande = PPosition*ErreurPosition;
Sur la courbe et sur la video, on peut voir qu'on donne au système la consigne de faire un déplacement, puis un déplacement en frottant sur le moteur, ensuite on force sur l'arbre du moteur immobile.
Avec un tel système, on a une erreur statique (0.4%), des dépassements (4.3%) et un courant énorme (400mA au démarrage, 1.2A en forçant, pour un moteur spécifié à ~250mA). Par contre le temps de réponse est très faible (320ms).
Un système PID bien réglé permet de réduire les dépassements et de réduire l'erreur statique, mais le temps de montée dépend toujours des contraintes exterieures.
Asservissement en vitesse
Comme on ne dispose pas de capteur de vitesse mais d'un capteur de position, sa dérivée va nous donner la vitesse moyenne avec un retard d'une demi-période. EstimationVitesse = MesurePosition - AnciennePosition;
AnciennePosition = MesurePosition;
ErreurVitesse = ConsigneVitesse - EstimationVitesse;
Commande = PVitesse*ErreurVitesse;
Pour éviter les dépassements, on va commander le moteur en vitesse plutôt qu'en puissance. Un contrôleur PI permet d'avoir une erreur statique faible sur la vitesse, et donc aussi sur la position.
Une grande partie du déplacement s'effectue à vitesse constante. Mais le courant reste très élevé pendant l'accélération.
On a réduit l'erreur statique (0.13%), les dépassements (1.67%) et même le courant au démarrage (200mA). Par contre on a légèrement ralenti le système (400ms) et le courant est toujours trop élevé en forçant sur l'arbre (425mA).
Pour éviter d'avoir une mesure de vitesse aussi peu précise, il faudrait diminuer la fréquence de l'asservissement, ou utiliser un capteur avec une résolution plus fine.
Asservissement en couple
Ici, on ne dispose pas de dynamomètre, mais les cartes de puissance ont un retour sur le courant consommé. Comme ce signal est assez bruité (offset + bruit de commutation du moteur), il a été filtré avec un filtre passif (RC à 16Hz) et un filtre numérique à 50Hz.
On ralentit encore le système (440ms) et on n'a pas réduit l'erreur statique et les overshots, mais le courant est contrôlé (overshoot à 145mA en début d'accélération et 240mA quand le rotor est bloqué).
Intégrateur
Les intégrateurs intègrent l'erreur. Cela veut dire que la correction augmente de plus en plus jusqu'à ce que l'erreur statique du système soit compensée. Seulement la correction varie lentement (une correction proportionnelle est quasi instantannée), ce qui rend les dépassements quasi obligatoires.
Pour éviter cela, le plus courant est d'avoir un intégrateur avec un faible gain et une période d'intégration relativement rapide (<50 fois plus lent que la boucle d'asservissement).
Le problème c'est qu'un intégrateur peut diverger et tendre vers l'infini. Une bonne pratique est de borner son entrée et sa sortie (à la manière des intégrateurs analogiques qui saturent).
Réglages
Le système se régle du plus petit en plus grand.
On commande par la boucle de courant avec une valeur fixe, en réglant ses gains et son temps d'intégration pour avoir un faible écart statique et peu de dépassements. Il faut perturber le système manuellement pour vérifier la correction. Il est utile de borner la vitesse pour contrôler un minimum le moteur.
La boucle de vitesse va directement commander la boucle de courant, et est réglée de la même façon.
En dernier, la boucle de position va commander la boucle de vitesse.
Il faut tout faire pour éviter d'avoir un système qui oscille (même si ce n'est qu'un couinement à la fréquence d'asservissement).
Tips and tricks
La seule ruse restante permet d'avoir un écart statique rapidement compensé (avec un gain assez élevé) sans risquer des instabilités.
Il suffit de réduire la valeur de saturation au voisinage de la consigne, et donc de limiter l'action de l'intégrateur.
Une technique souvent utilisée est de compenser une action externe (typiquement le poids d'un objet "monté" par un actionneur linéaire) directement dans la boucle. Même une compensation partielle suffit à "aider" l'asservissement.
Une autre méthode est de faire varier les coefficients (P, I, D, saturations) en fonction du système : montée/descente, tension des batteries, masse (pas forcément constante si on attrape des objets).
Les problèmes les plus gênants viennent de la précision des capteurs ("sauts" sur des potentiomètres), mais surtout de problèmes mécaniques (jeu dans les engrenages, courroies élastiques, frottements non-constants, glissement de courroies/roues). Le plus grand risque est d'avoir un système oscillant.
Depuis que je suis à Galiléo, on utilise couramment des moteurs à courant-continu.
Comme les besoins sont toujours à peu près les mêmes :
Tension : 12V à 36V
Courant : <3A max
Commande : PWM et Direction
Puce résistante (limite de courant, protection thermique, boitier large)
Les ponts en H LMD18200 et LMD18201 de National Semiconductors/Texas Instruments supportent tous ces points et le LMD18200 rajoute une mesure de courant.
Ce chip a été utilisé par Galiléo depuis au moins 2005 avec diverses cartes.
La dernière version avait été conçue par la Oufff'Team. Plutôt que de commander les mêmes, j'ai refait le routage en utilisant des composants en boitiers SMD 1206 ou traversants (empreintes communes). Il a aussi été possible d'avoir un routage simple face (seulement les composants facultatifs sont sur la face top).
Schéma
La carte a un filtre CEM assez surdimensionné, un buffer pour le retour de courant et le schéma du LMD18200 issu de sa datasheet.
Il est possible de sous-dimensionner le filtre CEM si la carte ne risque pas de polluer les cartes environnantes et de shunter le buffer de retour de courant par R21 (voir de le supprimer si on utilise un LMD18201).
Routage
Top :
Si le buffer de courant n'est pas utilisé, il est possible de se passer de la couche top en n'oubliant pas le strap entre les pattes du LMD18200.
Le plan de masse de la couche top est isolé de la masse de l'alimentation (relié par des capacités) et est à relier à la masse mécanique du montage dans lequel est utilisée cette carte.
Bottom :
Le plan de masse est relié à l'alimentation par un filtre LC, pour éviter de transmettre le bruit du hachage à l'alimentation.
PCB assemblé :
Le schéma a tous les composants possibles, mais il est possible d'adapter certains composants à l'utilisation de la carte.
Utilisation
Le connecteur Molex a le brochage suivant :
GND
PWM (Activation)
DIR (Direction)
Sense (Retour de courant)
Le signal + de l'alimentation est à câbler sur le connecteur "24V" du côté extérieur à la carte.
Sur cette carte, le polyswitch/fusible et le retour de courant ne sont pas câblés, et le filtrage de l'alimentation est réduit (~500µF, pas d'inductances ni de résistances d'ammortissement).
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
Après avoir été utilisé, il est détecté aléatoirement par le pc, et sa LED s'éclaire faiblement. Dès qu'on y branche un périphérique USB, sa LED s'éteint et il ne fonctionne plus, ce qui présuppose un problème d'alimentation.
L'alimentation provenant du port USB est filtrée par une inductance de choke et une capacité, avec ensuite un régulateur LDO pour alimenter le hub en 3.3V.
L'inductance LB1 est légèrement gondolée et à une résistance série de 2.4kΩ, ce qui la rend inutilisable. Il est possible qu'elle ait chauffée en consommant trop de courant sur le hub (qui n'a aucun polyfuse ni protection).
Une réparation sommaire conciste à remplacer l'inductance LB1 par un fil.
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.
Cette imprimante a un lecteur de cartes SD et Compact Flash sur une carte séparée (réf. QK1-3752-03, QM3-2812).
Identification
La carte utilise 3 puces : deux puces qui ressemblent à des régulateurs LDO, mais sans documentation vallable (marquages illisibles ou références introuvables), et le chip Genesys Logic GL819SA111 en boitier TQFP.
D'après le pinout de la puce, et un Ohmmètre, on en déduit une partie du brochage du connecteur :
Vdd (3.3V)
USB D-
USB D+
GND
?
?
?
GND
En identifiant le connecteur de la carte mère de l'imprimante à l'Ohmmètre et au Voltmètre, on arrive à identifier quelques autres pins :
Vdd (3.3V)
USB D-
USB D+
GND
+3.3V
Pin tiré à Vdd via un pullup de 15kΩ, à forcer à GND pour activer la puce.
+5V
GND
Câblage
Une fois les pins identifiés au connecteur USB et sur la carte, il ne reste plus qu'a tout souder.
Comme le +3.3V n'est pas disponible sur un port USB, et que la puce accepte une tension de 2.7V à 3.6V (idem pour les cartes SD), il est possible de relier le +5V à Vdd avec 3 diodes Si en série (les 1N400x conviennent et donnent une chute de tension proche de 0.65V en charge et à vide).
Par contre, la carte fonctionne en USB2.0 Hi-Speed, il faut donc un câble USB relativement propre (paire torsadée 90Ω).
En pratique, un câble sale (fils volants) fonctionne seulement si les fils sont de mêmes longueur (±5%) et courts (<50mm), La qualité des soudures peut aussi poser des problèmes.
Tests
En le branchant sur un PC (Linux), on peut avoir les messages d'erreur suivants (affichables avec la commande dmesg) :
usb 1-1.1.2: new high-speed USB device number n using ehci-pci, avec n bouclant entre 0 et 127.
Cette erreur arrive lorsque le câble est trop "sale" pour communiquer en mode high-speed.
usb 1-1.1.2: device descriptor read/64, error -n
usb 1-1.1-port2: Cannot enable. Maybe the USB cable is bad?
usb 1-1.1-port2: unable to enumerate USB device
Ces erreurs arrivent typiquement lorsque les pins D+ et D- sont échangés.
usb 1-1.1.2: reset high-speed USB device number 19 using ehci-pci
Si ces resets arrivent fréquemment, il est possible que l'alimentation de la puce ne fournisse pas assez de courant ou soit mal découplée.
Ils peuvent aussi arriver si le câble USB est trop long et non-torsadé/blindé.
Si aucun message n'apparaît lorsque la carte ou même un autre périphérique USB est branché sur ce port, c'est parce que les ports sont individuellement désactivés lorsqu'ils ont généré trop d'erreurs. Il est nécessaire de recharger les modules le gérant (ehci-hcd et ehci-pci sur ma machine)
Lorsque tout est fonctionnel, le noyau doit renvoyer : usb 1-1.1.2: new high-speed USB device number 8 using ehci-pci
usb 1-1.1.2: New USB device found, idVendor=05e3, idProduct=070e
usb 1-1.1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=2
usb 1-1.1.2: Product: USB Storage
usb 1-1.1.2: SerialNumber: 000000009514
usb-storage 1-1.1.2:1.0: USB Mass Storage device detected
scsi145 : usb-storage 1-1.1.2:1.0
scsi 145:0:0:0: Direct-Access Generic STORAGE DEVICE 9514 PQ: 0 ANSI: 0
sd 145:0:0:0: Attached scsi generic sg2 type 0
sd 145:0:0:0: [sdb] 7698432 512-byte logical blocks: (3.94 GB/3.67 GiB)
sd 145:0:0:0: [sdb] Write Protect is off
sd 145:0:0:0: [sdb] Mode Sense: 37 00 00 08
sd 145:0:0:0: [sdb] No Caching mode page found
sd 145:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 145:0:0:0: [sdb] Attached SCSI removable disk
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).
Les EEPROMS en boitier 32 pins sont très répandues (BIOS de PC), et la plupart sont faciles à flasher (toutes les operations se font en 5V).
Par contre la plupart des cartes réseaux n'acceptent que des puces à 28 pins pour leur image PXE, et les seules puces que j'ai sont soit des PROMs OTP (impossibles à reflasher), soit nécessitent 12.5V pour être effacées/programmées.
Du coup j'ai essayé de placer une SST29EE10 (128kio, 32 pins, 5V) dans un socket vide de 28 pins.
En regardant bien tous les pins nécessaires à la lecture sont connectables directement (bus d'adresse, bus de données, !CS). .
Les pins VPP peuvent aussi être laissés en l'air, !WE et !OE peuvent être laissés en l'air (ou respectivement tirés à VCC et VSS). A16 n'est pas nécessaire si on n'a pas besoin de toute la taille de l'EEPROM (beaucoup de cartes réseau limitent à 32kio ou 64kio).
Au final, on a une pile de sockets avec des fils au milieu :
Et l'EEPROM est capable de booter (flashée avec flashrom sur une carte-mère de PC) :
2015-12-24 - No comments
Tags de l'article : 
.
