J'ai des doutes sur le fait que l'émulateur Texas Instruments JTAG pour le débogage des processeurs est un appareil tellement répandu qu'il serait intéressant pour quelqu'un de le réanimer. Cependant, l'article peut être utile pour ceux qui essaient de réanimer quelque chose basé sur un système Linux à carte unique, avec des ressources et des informations limitées. Vous pouvez considérer cela comme un travail pratique avec U-Boot.
Au lieu de l'avant-propos
Quiconque débogue des programmes pour les systèmes embarqués sait que vous devez utiliser des périphériques spéciaux pour vous connecter aux processeurs. Des adaptateurs appelés émulateurs JTAG sont utilisés pour la famille de processeurs Texas Instruments.
Il y en a beaucoup, et de différents fabricants. Dans mon parc, entre autres, Blackhawk USB560v2 apparaît . Je dois admettre, pas le morceau de fer le moins cher. Et puis un jour, elle a cessé de travailler sans raison apparente.
Symptômes
Tout s'est passé un jour, l'appareil a juste arrêté de se charger et détecté via USB. La LED clignote, mais ne passe pas à l'état "prêt à l'emploi".
Cet appareil dispose d'un mode documenté divertissant: après 10 à 15 téléchargements infructueux, il aurait dû passer à un mode spécial (mode sans échec) qui lui permettrait d'être reflasher. Cependant, mon appareil a refusé de passer à ce mode, il n'a pas atteint le stade de numérotation USB, et il n'y avait donc pas de possibilité de reflasher avec l'utilitaire standard. La correspondance avec le service d'assistance n'a abouti à rien: ils ont refusé de m'aider avec du matériel technique, ne proposant que de leur envoyer (à leurs frais) un appareil aux États-Unis pour diagnostic et réparation.
Il n'y avait pas d'autre choix que de commencer une réparation indépendante.
Ubuntu est installé sur l'hôte, certains utilitaires utilisés sont inclus dans la distribution, certains sont installés via apt.
Inspection externe
Nous démontons, regardez le tableau. Sur le tableau se trouvent:
J'ai été particulièrement satisfait du connecteur UART soigneusement usé, qui, en outre, a été élevé pour un peigne standard de 2,54 mm, donc les contacts ont été signés. Je ne l'ai pas vu depuis longtemps, un maximum de cinq taches sur la planche, et même avec des marquages insignifiants comme TP1, etc.
Commençons
Nous connectons USB-UART (n'oubliez pas le niveau, c'est 3,3 V ici). Nous démarrons minicom, nous recevons:
TI UBL Version: 1.13, Flash type: NAND Booting PSP Boot Loader PSPBootMode = NAND Starting NAND Copy... Initializing NAND flash... Manufacturer ID = 0x0000002C Device ID = 0x000000A1 Pages Per Block = 0x00000040 Number of Blocks = 0x00000400 Bytes Per Page = 0x00000800 Valid MagicNum found at block 0x00000001, page 0x00000008 NAND Boot success. DONE U-Boot 2010.12 (May 09 2012 - 13:10:23) Cores: ARM 257 MHz, DSP 513 MHz DDR: 162 MHz I2C: ready DRAM: 256 MiB NAND: 128 MiB MMC: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In: serial Out: serial Err: serial Read USBID pin : DEVICE Read boot progress legacy : 0 Read boot progress : 0 Write boot progress legacy : 0 Write boot progress : 0 Hit any key to stop autoboot: 0 Loading from NAND 128MiB 1,8V 8-bit, offset 0x60000 Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1236292 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000 NAND read from offset 60000 failed -74 ** Read error
Comme vous pouvez le voir, la séquence est assez standard: le premier chargeur de démarrage (TI UBL) est chargé, puis U-Boot, qui à son tour charge le noyau Linux.
Selon le journal, il est évident que quelque chose a volé dans le flash NAND interne, lorsque le noyau Linux est démarré, la somme de contrôle ne converge pas. Cependant, vous pouvez interrompre le téléchargement et accéder à la console U-Boot.
Jetez un œil aux commandes disponibles:
Il y en a beaucoup U-Boot > help ? - alias for 'help' askenv - get environment variables from stdin base - print or set address offset boot - boot default, ie, run 'bootcmd' bootd - boot default, ie, run 'bootcmd' bootm - boot application image from memory cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo - echo args to console editenv - edit environment variable eeprom - EEPROM sub-system env - environment handling commands exit - exit script false - do nothing, unsuccessfully fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) go - start application at address 'addr' help - print command description/usage i2c - I2C sub-system iminfo - print header information for application image imxtract- extract a part of a multi-image itest - return true/false on integer compare loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mdc - memory display cyclic mii - MII utility commands mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - display MMC info mtest - simple RAM read/write test mw - memory write (fill) mwc - memory write cyclic nand - NAND sub-system nboot - boot from NAND device nm - memory modify (constant address) printenv- print environment variables reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage saves - save S-Record file over serial line setenv - set environment variables showvar - print local hushshell variables sleep - delay execution for some time source - run script from memory test - minimal test like /bin/sh true - do nothing, successfully usb - USB sub-system usbboot - boot from USB device version - print monitor version
Voyons les variables d'environnement:
U-Boot > printenv autokern=0x60000 autoroot=/dev/mtdblock3 baudrate=115200 bootcmd=nboot 80700000 0 ${autokern}; run setbootargsnand; bootm setbootargsnand=setenv bootargs mem=64M console=ttyS0,${baudrate}n8 root=${autoroot} rw rootfstype=jffs2 ip=off stderr=serial stdin=serial stdout=serial ver=U-Boot 2010.12 (May 09 2012 - 13:10:23) Environment size: 338/16380 bytes
La première chose que j'ai essayée a été de désactiver la vérification et le démarrage à l'aide des commandes U-Boot.
U-Boot > setenv verify n U-Boot > boot
Déplacé un peu plus loin, mais pas beaucoup:
De plus, l'appareil se bloque.
Les variables d'environnement montrent que l'image du noyau se trouve dans NAND Flash avec un décalage de 0x60000, lorsqu'elle est chargée, elle est copiée à l'adresse 0x80700000 (selon la carte mémoire du processeur, c'est l'espace d'adressage de la DRAM externe) et chargée. La taille de l'image du noyau, comme le montre le journal, est de 1236292 octets. J'ai essayé de le faire manuellement. Nous supposons que l'image est stockée au format uImage, donc nous jetons 64 octets sur l'en-tête, nous obtenons 1236356 octets = 0x12DD84:
U-Boot > nand read 80700000 60000 12dd84 U-Boot > iminfo
Ensuite, je voulais pomper le vidage d'image vers l'ordinateur pour jouer avec. Je n'ai rien trouvé de mieux que d'écrire un journal de console avec la sortie de mémoire à l'écran, puis de le convertir en fichier binaire.
Exécutez minicom avec la journalisation:
minicom -C orig-uImage.txt
Nous affichons le contenu de la mémoire à l'écran:
U-Boot > md.b 80700000 12dd84
Nous quittons minicom, éditons le journal, supprimons les lignes supplémentaires et convertissons-le en binaire:
xxd -r -seek -0x80700000 orig-uImage.txt orig-uImage
Je voulais reconditionner l'image afin qu'elle ne produise pas d'erreurs de somme de contrôle. Supprimez les 64 premiers octets, puis créez une nouvelle uImage:
mkimage -A arm -T kernel -C none -a 80008000 -e 80008000 -n "Linux-2.6.10_mvl401-xds560" -d orig-uImage patched-uImage
Remplissez le fichier résultant en utilisant le protocole YModem:
U-Boot > loady
Nous essayons de démarrer, mais nous nous bloquons également au stade du déballage du noyau:
U-Boot > bootm
Il fallait s'attendre à ce que l'on pouvait espérer ici. Mais au moins, ils ont téléchargé le flux de travail de partage de fichiers, pas mal.
Tout ce que nous avons est un fichier de firmware du site Web du fabricant , USB560v2_firmware_5.0.573.0.bin . J'ai supposé que ce fichier contient une image du noyau, mais il serait raisonnable de s'attendre à ce que le fichier soit chiffré avec au moins une clé simple. Par conséquent, je l'avoue, je suis tombé en panne et j'ai écrit au fabricant une demande pour me fournir une uImage ininterrompue afin de la télécharger vers l'appareil et de démarrer à partir de celui-ci, puis je pouvais déjà reflasher l'appareil avec l'utilitaire standard via USB. Il a même fait référence aux termes de la GPL (sous laquelle Linux est distribué), selon lesquels cela ne ferait pas de mal de fournir en plus les codes sources du noyau.
Immédiatement après l'envoi de la demande, j'ai tout de même décidé d'essayer de décompresser le fichier du firmware, comme une simple archive. Et voilà, il s'est avéré!
tar -xf USB560v2_firmware_5.0.573.0.bin
Après le déballage, deux fichiers sont apparus: uImage et rootfs.tar.gz . Ce que le médecin a prescrit, c'est une image du noyau et un système de fichiers racine.
Il reste à remplir uImage dans la mémoire de l'appareil en utilisant YModem et à démarrer, ce que j'ai fait. L'appareil a réussi à démarrer dans le même mode sans échec, j'ai raccroché. le soutien du fabricant et, pensant que je vais obtenir l'appareil la prochaine fois, je me suis calmement couché.
Deuxième série
Cependant, le lendemain, une surprise désagréable m'attendait. Le chargement de l'appareil a cessé. Ce que je n'ai pas essayé, j'ai eu une erreur:
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
Journal de démarrage du noyau long Starting kernel ... Uncompressing Linux................................................................................. done, booting thelLinux version 2.6.10_mvl2 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback Built 1 zonelists Kernel command line: mem=64M console=ttyS0,115200n8 root=/dev/mtdblock3 rw rootfstype=jffs2 ip=off PID hash table entries: 512 (order: 9, 8192 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB = 64MB total Memory: 62080KB available (2118K code, 448K data, 136K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok spawn_desched_task(00000000) desched cpu_callback 3/00000000 ksoftirqd started up. desched cpu_callback 2/00000000 desched thread 0 started up. NET: Registered protocol family 16 Registering platform device 'nor_davinci.0'. Parent at platform Registering platform device 'nand_davinci.0'. Parent at platform DaVinci I2C DEBUG: 12:46:30 Mar 29 2012 Registering platform device 'i2c'. Parent at platform musb_hdrc: version 2.2a/db-0.4.8 [cppi-dma] [peripheral] [debug=0] Registering platform device 'musb_hdrc'. Parent at platform musb_hdrc: USB Peripheral mode controller at c4800000 using DMA, IRQ 12 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. yaffs Mar 29 2012 12:46:15 Installing. Registering platform device 'davincifb.0'. Parent at platform Console: switching to colour frame buffer device 90x30 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled Registering platform device 'serial8250'. Parent at platform ttyS0 at MMIO 0x1c20000 (irq = 40) is a 16550A io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize Registering platform device 'ti_davinci_emac'. Parent at platform TI DaVinci EMAC: MAC address is 00:00:00:04:12:64 TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. netconsole: not configured, aborting i2c /dev entries driver elevator: using anticipatory as default io scheduler NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Unknown NAND 128MiB 1,8V 8-bit) Scanning device for bad blocks Creating 8 MTD partitions on "nand_davinci.0": 0x00000000-0x00020000 : "params" 0x00020000-0x00060000 : "bootloader" 0x00060000-0x00260000 : "safekernel" 0x00260000-0x01260000 : "saferootfs" 0x01260000-0x01460000 : "kernel" 0x01460000-0x02860000 : "rootfs" 0x02860000-0x03860000 : "application" 0x03860000-0x03c60000 : "logging" nand_davinci: hardware revision: 2.1 mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) NET: Registered protocol family 1 NET: Registered protocol family 17 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000016c: 0xffef instead Empty flash at 0x00a237fc ends at 0x00a23800 Empty flash at 0x00c3b7d8 ends at 0x00c3b800 mtd->read(0x1f320 bytes from 0xec0ce0) returned ECC error mtd->read(0x1fb8c bytes from 0xf20474) returned ECC error VFS: Mounted root (jffs2 filesystem). Freeing init memory: 136K mtd->read(0x44 bytes from 0xf39da8) returned ECC error mtd->read(0x988 bytes from 0xf39420) returned ECC error mtd->read(0x44 bytes from 0xed8d20) returned ECC error jffs2_get_inode_nodes(): Data CRC failed on node at 0x00ed8d20: Read 0xa8462b94, calculated 0xa03c90e8 mtd->read(0xa7e bytes from 0xed82a0) returned ECC error jffs2_get_inode_nodes(): Data CRC failed on node at 0x00c3ad78: Read 0x31ac7e30, calculated 0xa52ecb11 jffs2_get_inode_nodes(): Data CRC failed on node at 0x00a22d9c: Read 0x31ac7e30, calculated 0xe9f89c4c mtd->read(0x988 bytes from 0xf39420) returned ECC error mtd->read(0xa7e bytes from 0xed82a0) returned ECC error INIT: version 2.85 booting INIT: PANIC: segmentation violation! sleeping for 30 seconds. jffs2_get_inode_nodes(): Data CRC failed on node at 0x00a2ad10: Read 0x5fa921cc, calculated 0x5282f1d9 INIT: PANIC: segmentation violation! sleeping for 30 seconds.
J'ai conclu que le système de fichiers racine était également endommagé. Eh bien, vous devez aussi le flasher.
Tout d'abord, écrivez uImage dans NAND, afin de ne pas le charger via UART à chaque fois (je dois admettre, à une vitesse de 115200, un temps notable est chargé même à une taille d'un mégaoctet). Lorsque vous travaillez avec NAND, juste au cas où, nous alignerions la taille de l'image sur la taille de la page NAND (j'ai rencontré une telle recommandation quelque part), et notre taille de page est de 1024 octets = 0x800 (voir le tout premier journal).
U-Boot > loady ... U-Boot > nand erase 60000 12DC00 U-Boot > nand write 80700000 60000 12DC00
Dans le journal de démarrage du noyau, sélectionnez les informations utiles:
Creating 8 MTD partitions on "nand_davinci.0": 0x00000000-0x00020000 : "params" 0x00020000-0x00060000 : "bootloader" 0x00060000-0x00260000 : "safekernel" 0x00260000-0x01260000 : "saferootfs" 0x01260000-0x01460000 : "kernel" 0x01460000-0x02860000 : "rootfs" 0x02860000-0x03860000 : "application" 0x03860000-0x03c60000 : "logging"
Le système de fichiers racine doit donc être écrit sur NAND avec un décalage de 0x260000. Il ne reste plus qu'à comprendre dans quel format. Nous rappelons les variables d'environnement U-Boot, en particulier, cette ligne:
setbootargsnand=setenv bootargs mem=64M console=ttyS0,${baudrate}n8 root=${autoroot} rw rootfstype=jffs2 ip=off
Nous devons donc convertir notre rootfs.tar.gz , pêché à partir du fichier du firmware, au format JFFS2. À l'invite avec le wiki de Texas Instruments, nous faisons cela ( sudo nécessaire pour tar , donc il génère des erreurs lors de l'exécution de la commande mknod ):
mkdir rootfs sudo tar -xf rootfs.tar.gz -C rootfs mkfs.jffs2 -n -r rootfs -e 16 -o rootfs.jffs2
Nous chargeons le fichier résultant dans la mémoire de l'appareil, puis le copions dans la section NAND souhaitée (la taille est également arrondie à la page):
U-Boot > loady ... U-Boot > nand erase 260000 39f000 U-Boot > nand write 80700000 260000 39f000
Nous croisons les doigts, redémarrons, eh bien, maintenant tout va bien.
Journal complet très long de téléchargement réussi TI UBL Version: 1.13, Flash type: NAND Booting PSP Boot Loader PSPBootMode = NAND Starting NAND Copy... Initializing NAND flash... Manufacturer ID = 0x0000002C Device ID = 0x000000A1 Pages Per Block = 0x00000040 Number of Blocks = 0x00000400 Bytes Per Page = 0x00000800 Valid MagicNum found at block 0x00000001, page 0x00000008 NAND Boot success. DONE U-Boot 2010.12 (May 09 2012 - 13:10:23) Cores: ARM 257 MHz, DSP 513 MHz DDR: 162 MHz I2C: ready DRAM: 256 MiB NAND: 128 MiB MMC: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In: serial Out: serial Err: serial Read USBID pin : DEVICE Read boot progress legacy : 3 Read boot progress : 10 Write boot progress legacy : 2 Write boot progress : 9 Hit any key to stop autoboot: 0 Loading from NAND 128MiB 1,8V 8-bit, offset 0x1260000 Image Name: Linux-2.6.10_mvl401-xds560 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1235632 Bytes = 1.2 MiB Load Address: 80008000 Entry Point: 80008000
Postface
Oui, la procédure finale s'est avérée peu compliquée; en fait, il n'y a pas vraiment de véritable ingénierie inverse ici. Mais j'ai personnellement appris beaucoup de nouvelles choses sur les choses de bas niveau pendant le processus de démarrage de Linux embarqué, j'ai appris à travailler avec la console U-Boot.
Pour les propriétaires de Blackhawk USB560v2On peut voir que les gars ne se sont pas souciés de la protection. Après le démarrage de Linux, une invite apparaît dans la console pour se connecter. La connexion root sans mot de passe vous permet de vous connecter avec un accès administrateur et de faire quoi que ce soit avec l'appareil. Le plus intéressant se trouve dans le /usr/local/bin .
Mais c'est une histoire complètement différente.
J'espère que c'était intéressant.