В моих предыдущих публикациях EJTAG: аттракцион для хакеров и Black Swift: использование EJTAG рассматривался самый простой сценарий применения EJTAG — загрузка в ОЗУ и запуск на исполнение программы пользователя. Однако, возможности EJTAG этим не ограничиваются. В публикации рассказывается как организовать несложную отладку кода при помощи EJTAG, используя свободно-распространяемые программные средства openocd и GDB.
На написание данной публикации меня подтолкнуло письмо пожелавшего остаться неизвестным читателя, который обратился ко мне за помощью — устройство на базе AR9344 не грузится (виснет на этапе инициализации U-boot) — как при помощи EJTAG разобраться в чём проблема?
Так как под рукой у меня устройства на базе AR9344 не оказалось, а оказалась плата Black Swift Pro на базе родственного чипа AR9331, то повествование будет вестись с оглядкой на неё. Думаю, что изменения, которые придётся сделать для AR9344 несущественны.
Перейдём к постановке задачи:
ИМЕЕТСЯ плата Black Swift Pro, к которой мы подключились при помощи openocd по EJTAG и перевели процессор в режим останова.
ТРЕБУЕТСЯ последовательно выполнить несколько десятков инструкций процессора, останавливаясь после выполнения каждой инструкции и, при необходимости проверяя содержимое ОЗУ, загрузочного ПЗУ, регистров периферийных контроллеров или регистров процессора.
Для решения задачи вижу по крайней мере два подхода:
- простой — только при помощи openocd — базовая функциональность для выполнения требуемых действий уже есть в openocd. Надо лишь суметь ей воспользоваться;
- сложный — при помощи связки openocd + GDB — при этом пользователь будет управлять процессом исполнения инструкций процессора через GDB, а openocd станет конвертировать запросы GDB в команды EJTAG.
Теперь рассмотрим оба решения подробнее.
Дальнейшее изложение построено в предположении, что читатель ознакомился с публикацией Black Swift: использование EJTAG.
Решение 1: используем только openocd
Те кто читал мои предыдущие публикации про EJTAG должны помнить, что openocd предстаёт в них как тупой исполнитель скриптов (конфигурационных файлов), который как будто бы работает в пакетном режиме и не предусматривает взаимодействия с пользователем. Однако это не так. На самом деле, пока ПО openocd запущено есть возможность «попросить» его выполнить ту или иную команду при помощи интерфейса командной строки. Для доступа к интерфейсу командной строки openocd запускает telnet-сервер.
По умолчанию, для telnet-сервера будет использован TCP-порт 4444. При необходимости номер TCP-порта можно поменять при помощи опции telnet_port (см. пример ниже).
Попробуем потрассировать загрузчик платы Black Swift при помощи openocd.
Пример конфигурационного файла black-swift-trace.cfg для openocd, который заставляет openocd для telnet-сервера использовать порт 4455:
source [find interface/ftdi/tumpa.cfg] adapter_khz 6000 source [find black-swift.cfg] telnet_port 4455 init halt
Запуск openocd 0.9.0 от имени пользователя root выглядит так:
# openocd -f black-swift-trace.cfg Open On-Chip Debugger 0.9.0 (2015-05-28-17:08) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html none separate adapter speed: 6000 kHz Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'. Error: no device found Error: unable to open ftdi device with vid 0403, pid 8a98, description '*' and serial '*' Info : clock speed 6000 kHz Info : JTAG tap: ar9331.cpu tap/device found: 0x00000001 (mfg: 0x000, part: 0x0000, ver: 0x0) target state: halted target halted in MIPS32 mode due to debug-request, pc: 0xbfc00000 target state: halted target halted in MIPS32 mode due to single-step, pc: 0xbfc00404
Теперь мы можем открыть ещё одно окно терминала и подключиться к telnet-серверу openocd можно при помощи программы telnet:
$ telnet localhost 4455 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger >
Список всех команд openocd легко получить при помощи команды help.
Для пошагового исполнения инструкций процессора нам пригодится команда step:
step [address] выполнить одну инструкцию по адресу, определяемому регистром счётчика команд (PC). Если указан параметр address, то будет выполнена инструкция начиная с адреса address.
Пошаговое выполнение инструкций процессора в консоли выглядит так:
> step 0xbfc00400 target state: halted target halted in MIPS32 mode due to single-step, pc: 0xbfc00404 > step target state: halted target halted in MIPS32 mode due to single-step, pc: 0xbfc00408 > step target state: halted target halted in MIPS32 mode due to single-step, pc: 0xbfc0040c
Также полезными могут быть следующие команды openocd:
reg [(register_number|register_name) [(value|'force')]] прочитать или записать значение регистра процессора. Вызов reg без параметров приводит к выводу значения всех регистров. Если использован параметр 'force', производится принудительное вычитывание регистра из процессора (вместо выдачи закэшированного значения). mwb ['phys'] address value [count] записать по адресу address байт, значение которого в параметре value. Если указан параметр phys, то адрес address — физический адрес, в противном случае — виртуальный. Если задан параметр count то по адресу address будет произведена запись массива байт длины count, причём каждый элемент массива имеет значений value. mwh ['phys'] address value [count] команда аналогична mwb, но вместо байта записывается 16-разрядное слово. mww ['phys'] address value [count] команда аналогична mwb, но вместо байта записывается 32-разрядное слово. mdb ['phys'] address [count] Прочитать и вывести на печать байт по адресу address. Если указан параметр phys, то адрес address — физический адрес, в противном случае — виртуальный. Если задан параметр count то будет произведены чтение и вывод на печать массива по адресу address длины count байт. mdh ['phys'] address [count] команда аналогична mdb, но вместо байта читается 16-разрядное слово. mdw ['phys'] address [count] команда аналогична mdb, но вместо байта читается 32-разрядное слово.
Как видно, к сожалению, новейшая (на момент написания публикации) версия openocd 0.9.0 не умеет дизассемблировать инструкции процессоров с архитектурой MIPS, хотя для процессоров с архитектурой ARM такой дизассемблер имеется.
Отсутствие дизассемблера делает пошаговое исполнение инструкций процессора непосредственно при помощи openocd не слишком комфортным. Повысить уровень комфорта можно, если использовать GDB.
Решение 2: используем связку openocd + GDB
В связке openocd + GDB роли распределены так: пользователь общается с GDB, который обеспечивает удобный интерфейс именно для отладки абстрагируясь от того, при помощи какого механизма осуществляется управление выполнением инструкций, а openocd берёт на себя задачу непосредственного управления процессором по указаниям GDB.
Использование GDB для управления исполнением инструкций на процессоре MIPS через EJTAG имеет ряд преимуществ, по сравнению с openocd:
- как было сказано выше, в GDB встроен дизассемблер для архитектуры MIPS;
- возможно использовать отладочную информацию из исходных текстов; к примеру, если вы отлаживаете собственную C-программу, то GDB сможет показывать какая строка C-кода сейчас исполняется и детализировать состояние именно переменных программы, а не ячеек памяти с загадочными адресами;
- для взаимодействия между openocd и GDB используется протокол GDB Remote Serial Protocol; эмулятор qemu также поддерживает этот протокол, так что если вы перемежаете запуск своей отлаживаемой программы на реальном процессоре с запуском под эмулятором, то в обоих случаях удастся отлаживаться используя интерфейс одного и того же инструмента — GDB;
- наконец, интерфейс командной строки GDB поддерживает дополнение команд при помощи TAB.
Следует иметь в виду, что GDB оперирует высокоуровневыми понятиями, а openocd вынужден работать с той аппаратурой, которая есть и далеко не всегда хотелки GDB могут быть эффективно реализованы при помощи EJTAG.
Например, пользователь даёт указание GDB установить точку останова по указанному адресу, это указание поступает в openocd, но для процессоров архитектуры MIPS у openocd по крайней мере два способа установить точку останова:
- заменить инструкцию по адресу точки останова на инструкцию sdbbp, при достижении этой инструкции возникнет прерывание процесса исполнения, openocd заменит sdbbp на оригинальную инструкцию, но зато установит sdbbp вместо следующую за прерванной инструкцией, и запустит исполнение. Такой метод называется software breakpoint. Понятное дело, его нельзя использовать если происходит непосредственное исполнение кода из ПЗУ.
- настроить специальный блок контроля счётчика инструкций процессора на адрес останова. При достижении счётчиком инструкции указанного адреса также произойдёт прерывание исполнения. Однако количество таких точек останова, hardware breakpoint, ограничено.
Хотя внутри протокола GDB Remote Serial Protocol есть различение hardware breakpoint и software breakpoint (см. пакеты z и z0 в описании протокола), а в GDB предусмотрены соответствующие опции для выбора типа точек останова, может оказаться, что на конкретном процессоре есть ограничения на использования точек останова того или иного типа. Соответственно у openocd имеется опция gdb_breakpoint_override, которая позволяет принудительно выбрать один из двух описанных методов организации точек останова.
Для подключения отладчика GDB в openocd реализован GDB-сервер, который по умолчанию использует TCP-порт 3333. При необходимости номер TCP-порта можно поменять при помощи опции gdb_port.
Для подключения к GDB-серверу openocd, который управляет процессором MIPS, нам потребуется специальный вариант GDB с поддержкой MIPS. Я предполагаю, что для запуска openocd и GDB читатель использует ЭВМ на базе x86/amd64 под управлением Debian Linux, используется mips-linux-gnu-gdb из пакета Sourcery CodeBench. О том, как установить этот пакет написано тут, следует только ввести поправку, что на момент написания этих строк последней является версия Sourcery CodeBench mips-2015.05-18, выпущенная в мае 2015 года, скачать архив можно вот по этой ссылке.
Попробуем использовать связку openocd + GDB на практике. Запустим openocd:
# openocd -f run-u-boot_mod-trace.cfg \ > -c "gdb_breakpoint_override hard" -c "step 0xbfc00400"
Последние две команды для openocd обеспечат следующее:
- будут использованы hardware breakpoints, независимо от того, что там себе возомнил GDB (адреса 0xbfc0xxxx соответствуют ПЗУ, так что software breakpoints работать не будут);
- будет исполнена одна инструкция с адреса 0xbfc00400, после чего процессор вновь остановится.
Открываем ещё одно окно терминала и запускаем GDB:
$ /opt/mips-2015.05/bin/mips-linux-gnu-gdb GNU gdb (Sourcery CodeBench Lite 2015.05-18) 7.7.50.20140217-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=mips-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://sourcery.mentor.com/GNUToolchain/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb)
Теперь объясним GDB тип процессора с которым будем работать, попросим дизассемблировать очередную исполняемую инструкцию процессор и, наконец, подключимся к GDB-серверу openocd:
(gdb) set architecture mips:isa32r2 The target architecture is assumed to be mips:isa32r2 (gdb) set endian big The target is assumed to be big endian (gdb) set disassemble-next-line on (gdb) target remote :3333 Remote debugging using :3333 0xbfc00404 in ?? () => 0xbfc00404: 40 80 08 00 mtc0 zero,c0_random
Для выполнения одной инструкции процессора в GDB используется команда stepi. Попробуем выполнить несколько инструкций процессора и пусть вас не смущают предупреждения GDB об отсутствии отладочной информации (can’t find the start of the function), взять эту информацию в данной ситуации неоткуда.
(gdb) stepi warning: GDB can't find the start of the function at 0xbfc00408. GDB is unable to find the start of the function at 0xbfc00408 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0xbfc00408 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. 0xbfc00408 in ?? () => 0xbfc00408: 40 80 10 00 mtc0 zero,c0_entrylo0 (gdb) stepi warning: GDB can't find the start of the function at 0xbfc0040c. 0xbfc0040c in ?? () => 0xbfc0040c: 40 80 18 00 mtc0 zero,c0_entrylo1 (gdb) stepi warning: GDB can't find the start of the function at 0xbfc00410. 0xbfc00410 in ?? () => 0xbfc00410: 40 80 20 00 mtc0 zero,c0_context (gdb)
Теперь прочитаем 32-разрядное слово по адресу 0xbfc00408:
(gdb) p /x *0xbfc00408 $1 = 0x40801000
Для печати состояния регистров процессора используется команда info registers:
(gdb) info registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 37c688e2 22b15a00 28252198 0c12d319 4193c014 84e49102 06193640 t0 t1 t2 t3 t4 t5 t6 t7 R8 00000002 9f003bc0 92061301 1201c163 31d004a0 92944911 ac031248 b806001c s0 s1 s2 s3 s4 s5 s6 s7 R16 8bc81985 402da011 c94d2454 88d5a554 81808e0d cc445151 4401a826 50020402 t8 t9 k0 k1 gp sp s8 ra R24 01c06b30 01000000 10000004 fffffffe 9f003bc0 54854eab 329d626b bfc004b4 status lo hi badvaddr cause pc 00400004 00244309 b9ca872c ed6a1f00 60808350 bfc00410 fcsr fir 00000000 00000000
GDB — это развитый инструмент с большим число команд и опций; для более близкого знакомства с GDB я отсылаю читателя к официльной документации GDB.
Инициализация контроллера ОЗУ AR9331
Посмотрим, как можно при помощи GDB решить специфическую задачу: протрассировав исполнение U-boot на плате Black Swift, выявить последовательность записей в регистры контроллера ОЗУ, которая приводит к его инициализации. Выявление такой последовательности чрезвычайно полезно, если мы хотим запускать программы на Black Swift при помощи openocd минуя U-boot. Также эта инициализационная последовательность пригодится при создании альтернативного загрузчика для Black Swift.
Запустим openocd (точно также, как в предыдущем разделе):
# openocd -f run-u-boot_mod-trace.cfg \ > -c "gdb_breakpoint_override hard" -c "step 0xbfc00400"
Для запуска GDB составим скрипт bs-u-boot-trace-gdb.conf:
set architecture mips:isa32r2 set endian big set disassemble-next-line on target remote :3333 set pagination off set logging file bs_gdb.log set logging on while $pc != (void (*)()) 0x9f002ab0 stepi info registers end detach quit
По сравнению с примером в предыдущем разделе данный скрипт заставляет GDB дублировать вывод в файл bs_gdb.log, и отключает pagination (подтверждение листания страниц пользователем), а затем начинает циклически выполнять инструкции процессора и выводить состояние регисров процессора после выполнеия каждой инструкции. По достижения регистром PC (регистр адреса следующей инструкции) значения 0x9f002ab0 GDB отключается от openocd и прекращает работу. Таким образом по окончании работы GDB будет создан файл bs_gdb.log с полной трассой исполнения инструкций процессора.
Запуск GDB будет осуществляться так:
$ /opt/mips-2015.05/bin/mips-linux-gnu-gdb -x bs-u-boot-trace-gdb.conf
Замечание: скрипт
bs-u-boot-trace-gdb.conf, скорее всего, не сработает непосредственно после подачи питания на плату, так как u-boot_mod для борьбы с таинственными ошибками AR9331 производит дополнительный сброс, отчего исполнение скрипта остановится. В этом случае следует остановить openocd и GDB, а затем запустить openocd и GDB заново.
Теперь дело за малым — надо выбрать из файла bs_gdb.log все инструкции записи sw (store word, то есть запись 32-разрядного значения). Регистры контроллера памяти AR9331 32-разрядные, так, что другие инструкции из семейства store можно смело игнорировать.
Так как дизассемблер выдаёт только имена регистров-аргументов инструкции sw
=> 0xbfc004ec: ad f9 00 00 sw t9,0(t7)
но не их значения, то недостаточно из файла bs_gdb.log выбрать все строки, содержащие инструкцию sw. Для определения того, какое значение по какому адресу при помощи sw было записано надо подвергнуть файл bs_gdb.log дополнительной обработке. Обработку можно сделать при помощи скрипта parse_gdb_output.pl:
#!/usr/bin/perl -w my %r; foreach $i (qw(zero at v0 v1 a0 a1 a2 a3 t0 t1 t2 t3 t4 t5 t6 t7 s0 s1 s2 s3 s4 s5 s6 s7 t8 t9 k0 k1 gp sp s8 ra)) { $r{$i} = "none"; } sub parse_reg($) { $_ = $_[0]; if (/^ R/) { my @fields = split m'\s+'; my $f = 2; my @rgs; @rgs = qw(zero at v0 v1 a0 a1 a2 a3) if (/^ R0/); @rgs = qw(t0 t1 t2 t3 t4 t5 t6 t7) if (/^ R8/); @rgs = qw(s0 s1 s2 s3 s4 s5 s6 s7) if (/^ R1/); @rgs = qw(t8 t9 k0 k1 gp sp s8 ra) if (/^ R2/); foreach $i (@rgs) { $r{$i} = $fields[$f]; $f = $f + 1; } } } while (<>) { if (/^=>([^s]*)\tsw\t([^,]*),(\d+)\(([^)]*)\)/) { my $rs = $2; my $offset = $3; my $rd = $4; parse_reg(<>); parse_reg(<>); parse_reg(<>); parse_reg(<>); print("$1 sw $rs={0x$r{$rs}}, $offset($rd={0x$r{$rd}})\n"); } } Запуск parse_gdb_output.pl производится так:
$ grep "^=\|^ R" bs_gdb.log | ./parse_gdb_output.pl
Вот фрагмент вывода parse_gdb_output.pl (отметки ‘<<< PLL‘ и ‘<<< DDR‘ внесены вручную позднее):
... 0x9f002700: ad cf 00 00 sw t7={0x00dbd860}, 0(t6={0xb8116248}) 0x9f00271c: ad f9 00 00 sw t9={0x000fffff}, 0(t7={0xb800009c}) 0x9f0027a0: ad f9 00 00 sw t9={0x00018004}, 0(t7={0xb8050008}) <<< PLL 0x9f0027dc: ad f9 00 00 sw t9={0x00000352}, 0(t7={0xb8050004}) <<< 0x9f002840: ad f9 00 00 sw t9={0x40818000}, 0(t7={0xb8050000}) <<< 0x9f002898: ad f9 00 00 sw t9={0x001003e8}, 0(t7={0xb8050010}) <<< 0x9f0028f4: ad f9 00 00 sw t9={0x00818000}, 0(t7={0xb8050000}) <<< 0x9f002970: ad cf 00 00 sw t7={0x00800000}, 0(t6={0xb8116248}) ... 0x9f002994: ad cf 00 00 sw t7={0x40800700}, 0(t6={0xb8116248}) 0x9f002a54: ad f9 00 00 sw t9={0x00008000}, 0(t7={0xb8050008}) 0x9f00309c: af 38 00 00 sw t8={0x7fbc8cd0}, 0(t9={0xb8000000}) <<< DDR 0x9f0030b0: af 38 00 00 sw t8={0x9dd0e6a8}, 0(t9={0xb8000004}) <<< 0x9f0030dc: af 38 00 00 sw t8={0x00000a59}, 0(t9={0xb800008c}) <<< 0x9f0030ec: af 38 00 00 sw t8={0x00000008}, 0(t9={0xb8000010}) <<< ...
Так как адреса регистров формирователя тактового сигнала (PLL) и адреса регистров контроллера памяти типа DDR известны, то легко сообразить какие числа по каким адресам надо записать, чтобы правильно инициализировать контроллер ОЗУ.
Итоги
Как видно вести отладку через JTAG при помощи openocd и GDB совсем не сложно, а описанные приёмы работы годятся не только для AR9331, но, после некоторой адаптации, и даже для процессоров с другой архитектурой, для которых есть поддержка в openocd и GDB.
ссылка на оригинал статьи http://geektimes.ru/post/261092/
Добавить комментарий