У меня есть сомнения, что JTAG-эмулятор для отладки процессоров фирмы Texas Instruments — настолько распространённое устройство, чтобы его реанимация была бы кому-то интересна. Однако статья может быть полезна тем, кто пытается реанимировать что-нибудь на базе одноплатника с Linux, имея ограниченные ресурсы и информацию. Можно рассматривать это как некоторый практикум работы с U-Boot.
Вместо предисловия
Тот, кто занимался отладкой программ для встраиваемых систем, знает, что для подключения к процессорам нужно использовать специальные устройства. Для семейства процессоров фирмы Texas Instruments используются адаптеры, называемые JTAG-эмуляторами.
Их существует множество, и от разных производителей. В моём парке помимо прочих значится Blackhawk USB560v2. Надо признаться, не самая дешёвая железка. И вот однажды она перестала работать без видимых на то причин.
Симптомы
Всё произошло в один прекрасный день, девайс просто перестал загружаться и определяться по USB. Моргал светодиод, но в состояние «готово к использованию» не переходил.
У этого устройства есть занятный документированный режим: после 10-15 неудачных загрузок оно должно было перейти в специальный режим (safe mode), который позволил бы его перепрошить. Однако моё устройство в этот режим переходить отказывалось, до этапа USB нумерации не доходило, и поэтому возможности перепрошить штатной утилитой не было. Переписка со службой поддержки ни к чему не привела: по технике помогать они мне отказались, предложив лишь отправить (за свой счёт) девайс им в США на диагностику и ремонт.
Ничего не оставалось, как приступить к самостоятельной починке.
На хосте установлен Ubuntu, некоторые использованные утилиты входят в дистрибутив, некоторые устанавливаются через apt.
Внешний осмотр
Разбираем, смотрим на плату. На плате расположены:
- Микропроцессор TI TMS320DM6441
- Flash Micron MT29F1G08ABBDAHC
- 2x DRAM Micron MT47H64M16HR-3
- ПЛИС Altera MAX II (EPM570GF00C5N) и Cyclon III (EP3C25U256C8N)
Особенно порадовал заботливо офомленный разъём UART, который мало того, что был разведён под стандартную гребёнку 2.54 мм, так ещё и контакты были подписаны. Такого я не встречал уже давно, максимум пятачки на плате, да ещё и с ничего не значащими маркировками типа TP1 и т.п.
Приступим
Подключаем USB-UART (не забываем про уровень, он здесь 3.3 В). Запускаем minicom, получаем:
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 ## Booting kernel from Legacy Image at 80700000 ... 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 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image!
Как видим, последовательность вполне стандартная: сначала грузится bootloader (TI UBL), затем U-Boot, который в свою очередь грузит ядро Linux.
По логу очевидно, что что-то слетело во внутренней NAND Flash, при загрузке ядра Linux не сходится контрольная сумма. Однако можно прервать загрузку и войти в консоль U-Boot.
Ознакомимся с доступными командами:
U-Boot > help ? - alias for 'help' askenv - get environment variables from stdin base - print or set address offset boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., 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
Посмотрим переменные окружения:
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
Первым делом я попытался отключить проверку и загрузиться с помощью команд U-Boot.
U-Boot > setenv verify n U-Boot > boot
Продвинулся чуть дальше, но не намного:
## Booting kernel from Legacy Image at 80700000 ... 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 Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux................................................................................. crc error te
Дальше устройство виснет.
Из переменных окружения видно, что образ ядра лежит в NAND Flash со смещением 0x60000, при загрузке копируется по адресу 0x80700000 (согласно memory map процессора это адресное пространство внешней памяти DRAM) и загружается. Размер образа ядра, как видно из лога, составляет 1236292 байт. Я попробовал проделать это вручную. Предполагаем, что образ хранится в формате uImage, поэтому накидываем 64 байта на заголовок, получаем 1236356 байт = 0x12DD84:
U-Boot > nand read 80700000 60000 12dd84 U-Boot > iminfo ## Checking Image at 80700000 ... Legacy image found 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 Verifying Checksum ... Bad Data CRC
Дальше мне захотелось выкачать дамп образа на компьютер, чтобы поиграться с ним. Я не придумал ничего лучше, как записать лог консоли с выводом памяти на экран, а затем преобразовать его в бинарный файл.
Запускаем minicom с записью лога:
minicom -C orig-uImage.txt
Выводим содержимое памяти на экран:
U-Boot > md.b 80700000 12dd84
Выходим из minicom, редактируем лог, убрав лишние строчки, преобразуем в бинарник:
xxd -r -seek -0x80700000 orig-uImage.txt orig-uImage
Мне захотелось перепаковать образ, чтобы он не выдавал ошибки контрольной суммы. Удаляем первые 64 байта, а затем делаем новый uImage:
mkimage -A arm -T kernel -C none -a 80008000 -e 80008000 -n "Linux-2.6.10_mvl401-xds560" -d orig-uImage patched-uImage
Заливаем полученный файл обратно по протоколу YModem:
U-Boot > loady ## Ready for binary (ymodem) download to 0x80700000 at 115200 bps... C## Total Size = 0x0012dd84 = 1236356 Bytes U-Boot > iminfo ## Checking Image at 80700000 ... Legacy image found 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 Verifying Checksum ... OK
Пробуем загрузиться, но также виснем на этапе распаковки ядра:
U-Boot > bootm ## Booting kernel from Legacy Image at 80700000 ... 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 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux................................................................................. crc error te
Вполне ожидаемо, на что тут можно было надеяться. Но хотя бы прокачали воркфлоу обмена файлами, уже неплохо.
Всё, что у нас есть, это файл прошивки с сайта производителя, USB560v2_firmware_5.0.573.0.bin. Я предполагал, что в этом файле содержится образ ядра, но разумно было бы ожидать, что файл зашифрован хотя бы простеньким ключом. Поэтому, признаюсь, я сорвался и написал производителю просьбу предоставить мне небитый uImage с тем, чтобы я его залил в устройство и загрузился с него, а потом уже смог бы перепрошить устройство штатной утилитой по USB. Даже сослался на условия GPL (под которой распространяется Linux), по которым им не мешало бы в дополнение предоставить и исходные коды ядра.
Сразу после отправки запроса я решил всё же попробовать распаковать файл прошивки, как простой архив. И, о чудо, получилось!
tar -xf USB560v2_firmware_5.0.573.0.bin
После распаковки появилось два файла: uImage и rootfs.tar.gz. То, что доктор прописал, образ ядра и корневая файловая система.
Осталось залить uImage в память устройства по YModem и запуститься, что я и сделал. Устройство успешно загрузилось в тот самый safe mode, я дал отбой тех. поддержке производителя и, думая, что прошью устройство в следующий раз, спокойно отправился спать.
Вторая серия
Однако на следующий день меня ждал неприятный сюрприз. Устройство перестало успешно загружаться. Что я только не перепробовал, получал ошибку:
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
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.
Я сделал вывод, что корневая файловая система так же повредилась. Что ж, значит надо прошить и её.
Для начала запишем uImage в NAND, чтобы не грузить какждый раз через UART (надо признаться, на скорости 115200 файл даже размером в один мегабайт грузится ощутимое время). При работе с NAND на всякий случай выравниваем размер образа до размера страницы NAND в большую сторону (где-то встречал такую рекомендацию), а размер страницы у нас составляет 1024 байта = 0x800 (см. самый первый лог).
U-Boot > loady ... U-Boot > nand erase 60000 12DC00 U-Boot > nand write 80700000 60000 12DC00
Из лога загрузки ядра выделяем полезную информацию:
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 со смещением 0x260000. Осталось только понять, в каком формате. Вспоминаем про переменные окружения U-Boot, в частности про вот эту строчку:
setbootargsnand=setenv bootargs mem=64M console=ttyS0,${baudrate}n8 root=${autoroot} rw rootfstype=jffs2 ip=off
Значит, нам надо преобразовать наш rootfs.tar.gz, выуженный из файла прошивки, в формат JFFS2. По подсказке с Wiki от Texas Instruments делаем это (sudo нужен для tar, так без него выдаёт ошибки при запуске команды mknod):
mkdir rootfs sudo tar -xf rootfs.tar.gz -C rootfs mkfs.jffs2 -n -r rootfs -e 16 -o rootfs.jffs2
Загружаем полученный файл в память устройство, а затем копируем в нужный участок NAND (размер также округляем до страницы):
U-Boot > loady ... U-Boot > nand erase 260000 39f000 U-Boot > nand write 80700000 260000 39f000
Скрещиваем пальцы, перезагружаемся, ну теперь уж всё точно хорошо.
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 ## Booting kernel from Legacy Image at 80700000 ... 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 Verifying Checksum ... OK Loading Kernel Image ... OK OK 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/mtdblock5 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 mtd->read(0x400 bytes from 0x0) returned ECC error VFS: Mounted root (jffs2 filesystem). Freeing init memory: 136K INIT: version 2.85 booting 0 Mounting local filesystems: mount none on /var/log type tmpfs (rw,size=2M) none on /var/lock type tmpfs (rw) none on /var/run type tmpfs (rw) INIT: Entering runlevel: 3 /etc/rc.d/rc3.d/S88davinci_mmc: 69: /usr/local/bin/sd_app: not found Registering platform device 'mmc0.1'. Parent at platform : Supporting 4-bit mode /etc/rc.d/rc3.d/S90fsemulator: 72: /usr/local/bin/sd_app: not found bh560v2u gadget: Blackhawk USB560v2 System Trace Emulator, version: 1.00 bh560v2u gadget: using musb_hdrc, OUT ep1out IN ep1in bh560v2u gadget: DTC-USB device attached to major/minor numbers 254 0 /etc/rc.d/rc3.d/S93dsplink: 69: /usr/local/bin/sd_app: not found bh560v2u gadget: high speed config #1: High-speed configuration dsplinkk: no version for "struct_module" found: kernel tainted. DSPLINK Module (1.51) created on Date: Mar 29 2012 Time: 12:48:55 /etc/rc.d/rc3.d/S95fpgaprog: 72: /usr/local/bin/sd_app: not found Device '/dev/mem' opened successfully. Turned off Debug Clock Turned off Trace Clock FPGA erased successfully FPGA data length=460284 Device '/dev/mem' opened successfully. Programming FPGA: FPGA Image CRC=39550, FPGA programmed CRC=28013 Turned on Debug Clock Turned on Trace Clock Device #1 IDCODE is 020F30DD configuring SRAM device(s)... DONE Exit code = 0... Success /etc/rc.d/rc3.d/S96dtc_main: 70: /usr/local/bin/sd_app: not found MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980) (none) login: emac_control:4584[0]ioctl called when device is NOT open<3>ERROR: davinci_emac: eth0 error: Error 3000000E from EMAC TX Channel O) SIOCSIFHWADDR: Input/output error Failed to reset boot progress: dtc_periph_lock.cpp(78) : timeout : /var/lock/i2c MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980) 00:00:00:04:12:64 login: root Welcome to MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980). login[825]: root login on `console' #
Послесловие
Да, итоговая процедура получилась не очень-то сложной, настоящего реверс-инжиниринга здесь в сущности немного. Но я лично для себя узнал немало нового о низкоуровневых вещах в процессе загрузки встраиваемого Linux, научился работать с консолью U-Boot.
Видно, что защитой ребята особо не заморачивались. После загрузки устройство предлагается залогиниться. Логин root без пароля позволяет зайти под рутом и делать с устройством всё что угодно. Самое интересное содержится в директории /usr/local/bin.
Но это уже совсем другая история.
Надеюсь, было интересно.
ссылка на оригинал статьи https://habr.com/post/420895/
Добавить комментарий