OpenOCD: руководство пользователя, продолжение

Добавил(а) microsin

В этой части документации OpenOCD представлены разделы:

10. Декларирование TAP.
11. Конфигурация CPU.
12. Команды Flash.
13. Программирование Flash.
14. Команды NAND Flash.
15. Команды PLD/FPGA.
16. Общие команды.

Непонятные термины и сокращения см. в последней части перевода, в разделе Словарик (OpenOCD: руководство пользователя, окончание). Раздел Ссылки также размещен в последней части перевода.

OpenOCD: руководство пользователя, начало
OpenOCD: руководство пользователя, окончание

[10. Декларирование TAP]

Порты Test Access Port (TAP-ы) являются ядром JTAG. TAP-ы выполняют многие роли, включая:

• Debug Target (отладка цели). CPU TAP может использоваться как GDB debug target.
• Flash Programing (программирование памяти FLASH). Некоторые чипы программируют flash напрямую через JTAG. Другие это делают косвенно, через использование CPU.
• Program Download (загрузка программы). Используя тот же CPU, поддерживающий GDB, Вы можете инициализировать контроллер DRAM, загрузить код в DRAM, и затем этот код запустить на выполнение.
• Boundary Scan. Многие чипы поддерживают boundary scan, который помогает протестировать наличие проблем в сборке платы - наподобие наличия мостиков припоя (solder bridges) или непропаев.

OpenOCD должна знать о том, какие используются активные TAP-ы на Вашей плате (или платах). Настройка TAP-ов является основной задачей в Ваших файлах конфигурации. Как только эти TAP-ы настроены, Вы можете затем передать их имена коду, который настраивает все CPU и экспортировать их как GDB target-ы, пробы памяти FLASH (probes flash memory), выполнять низкоуровневые операции JTAG, и многое другое.

10.1. Цепочки сканирования JTAG (Scan Chains)

TAP-ы являются частью аппаратуры are part of a hardware scan chain, в которой TAP-ы соединены в последовательную цепочку (daisy chain). Они также должны быть добавлены в программное отражение OpenOCD в виде списка аппаратуры, где каждому участнику дано имя и связанные с ним другие данные. Простые scan chain, имеющие только один TAP, встречаются наиболее часто в системах, основанных на одном микроконтроллере или микропроцессоре. Более сложные чипы могут иметь несколько внутренних TAP-ов. Очень сложные scan chain могут иметь дюжину TAP-ов и более: некоторые в одном чипе, другие в следующем, и могут быть соединения с другими платами с их чипами и TAP-ами.

Вы можете отобразить список командой scan_chain. (Не перепутайте это со списком, отображаемым командой targets, представленной в следующей части. Она только отображает TAP-ы для тех CPU, которые были сконфигурированы как target-ы отладки.) Вот как может выглядеть scan chain для чипа, в котором больше одной TAP:

  TapName             Enabled IdCode     Expected   IrLen IrCap IrMask
-- ------------------ ------- ---------- ---------- ----- ----- ------
0 omap5912.dsp           Y    0x03df1d81 0x03df1d81    38 0x01  0x03
1 omap5912.arm           Y    0x0692602f 0x0692602f     4 0x01  0x0f
2 omap5912.unknown       Y    0x00000000 0x00000000     8 0x01  0x03

OpenOCD может сама определить некоторое из этой информации, но не все. См. раздел 10.7. Автоматическое распознавание (Autoprobing). К сожалению, такие TAP-ы не всегда могут быть сконфигурированы автоматически, потому что не все устройства предоставляют хорошую поддержку для этого. JTA не требует поддержки инструкций IDCODE, и чипы с роутерами JTAG могут не связаться с TAP-ами в цепочке, пока не указать установить связь и как это сделать.

Конфигурационный механизм, в настоящее время поддерживаемый OpenOCD, требует явного конфигурирования всех устройств, имеющих TAP, используя команды jtag newtap, как детально описано далее в этом разделе. Команда наподобие этой будет декларировать один TAP и дает ему имя chip1.cpu:

jtag newtap chip1 cpu -irlen 4 -expected-id 0x3ba00477

Каждый файл target config перечисляет TAP-ы предоставленные в имеющемся чипе. Файлы board config комбинируют все target-ы на плате, и так далее. Имейте в виду, что очень важен порядок, в котором TAP-ы объявлены. Порядок объявления должен соответствовать порядку подключения в JTAG scan chain, как внутри одного чипа, так и между ними. См. раздел [23. FAQ], топик "TAP Order".

Например, чип STR912 компании ST Microsystems имеет 3 отдельные TAP-а (см. документ ST "STR91xFAxxx", секция "3.15 Jtag Interface", рис. 3: "JTAG chaining inside the STR91xFA" http://eu.st.com/stonline/products/literature/ds/13495.pdf). Для конфигурирования этих TAP-ов файл target/str912.cfg включает использование команд наподобие таких:

jtag newtap str912 flash ... параметры ...
jtag newtap str912 cpu ... параметры ...
jtag newtap str912 bs ... параметры ...

Реальные файлы конфигурации используют переменные вместо строковых значений типа str912, чтобы поддержать больше одного чипа каждого типа. См. раздел [6. Указания по составлению файла конфигурации (Config File Guidelines)].

jtag names [Command]

Возвращает имена всех текущих TAP-ов в scan chain. Используйте jtag cget или jtag tapisenabled для проверки атрибутов и состояния каждого TAP-а.

foreach t [jtag names] {
    puts [format "TAP: %sn" $t]
}

scan_chain [Command]

Отображает TAP-ы в конфигурации scan chain и их состояние. Набор TAP-в, перечисленный в этой команде, фиксирован на выходе из стадии конфигурирования OpenOCD configuration stage, но системы с роутером JTAG могут динамически разрешать или запрещать TAP-ы.

10.2. Имена TAP (TAP Names)

Когда объекты TAP декларируются через jtag newtap имя_с_точкой (dotted.name), созданное для TAP, комбинируется с именем модуля (обычно это чип) и меткой для TAP. Например: xilinx.tap, str912.flash, omap3530.jrc, dm6446.dsp или stm32.cpu. Многие другие команды используют dotted.name для манипулирования TAP или ссылок на них. Например, конфигурация CPU использует имя, как делается при декларации банков NAND или NOR.

Компоненты, у которых есть имя с точкой, следуют правилам символьных имен языка "C": имя начинаются с алфавитного символа, затем разрешены цифры и подчеркивания; все другие символы (включая точки!) не допускаются.

Подсказка: в старом коде JTAG TAP-ы нумеровались от 0 до N. Эта возможность все еще имеется. Однако очень не рекомендуется её использовать, это планируется удалить в середине 2010 года. Обновите все Ваши скрипты для использования имен TAP, а не цифро, обратите внимания на предупреждения, появляющиеся во время выполнения. Использование номеров TAP в скриптах target config предотвращает возможность повторного использования этих скриптов на платах с несколькими target-ами.

10.3. Команды декларирования TAP

jtag newtap chipname tapname configparams... [Command]

Декларирует новый TAP, у которого есть имя с точкой (chipname.tapname), и конфигурирует его в соответствии с разными конфигурационными параметрами.

Имя chipname является символическим именем для чипа. Традиционно файлы target config используют $_CHIPNAME, по умолчанию для имени модели используется вендор чипа, но это можно перезадать.

Имя tapname отражает роль TAP, и оно должно следовать такому соглашению:

• bs – для boundary scan, если для него имеется отдельный TAP;
• cpu – главный CPU в чипе, альтернативно arm и dsp на чипе с обоими CPU для ARM и DSP CPU, arm1 и arm2 на чипах с двумя ARM, и так далее;
• etb – для встроенного буфера трассировки (embedded trace buffer, например: an ARM ETB11);
• flash – если чип имеет flash TAP, наподобие str912;
• jrc – для JTAG route controller (маршрутизатор, роутер JTAG, пример: модули ICEpick на многих чипах компании Texas Instruments, наподобие OMAP3530 на Beagleboard-ах);
• tap – должно использоваться только для устройств наподобие FPGA или CPLD с одним TAP;
• unknownN – (неизвестно) если у Вас нет идеи, что это за TAP (здесь N число);
• when in doubt – (когда есть сомнения) используйте имя производителя чипа из его даташита. Например, Freescale IMX31 имеет SDMA (Smart DMA) с JTAG TAP; такой TAP должен называться sdma.

Каждый TAP требует как минимум следующих параметров конфигурации:

• -irlen NUMBER
Длина в битах регистра инструкций, как например 4 или 5 бит.

TAP может также предоставлять необязательные параметры конфигурации:

• -disable (или -enable)
Используйте параметр -disable для пометки TAP-а, который не подсоединен к scan chain после сброса с использованием либо TRST, либо машинного состояния сброса JTAG. Вы можете использовать -enable, чтобы выделить состояние по умолчанию (TAP подсоединен). См. раздел 10.6. Разрешение и запрет TAP-ов.

• -expected-id number
Ненулевое число number представляет 32-битный IDCODE, который ожидается найти при проверке scan chain. Эти коды не требуются всеми устройствами JTAG. Повторите опцию несколько раз, как это необходимо, если имеется больше одного кода ID (например, несколько версий). Укажите вместо номера 0 для подавления предупреждений о значениях IDCODE, которые найдены, но не добавлены в список.

Предоставляйте это значение всегда, когда есть возможность, поскольку оно позволяет OpenOCD говорить, когда scan chain представлена неправильно. Эти значения предоставлены в документации вендора на чип, обычно в техническом руководстве. Иногда Вам может потребоваться попробовать аппаратуру JTAG, чтобы найти эти значения. См. раздел 10.7. Автоматическое распознавание (Autoprobing).

• -ignore-version
Игнорировать версию. Укажите это для игнорирования поле версии JTAG в опции -expected-id. Когда вендор выпускает несколько версий чипа, или использует один и тот же JTAG-level ID для нескольких значительно совместимых чипов, может быть более практичным игнорировать поле версии, чем обновлять файлы конфигурации для поддержки всех различных ID чипов. Поле версии задается как биты 28-31 от IDCODE.

• -ircapture NUMBER
Битовый паттерн, загружаемый через TAP в регистр сдвига JTAG на входе в состояние ircapture, такое как 0x01. JTAG требует 01 для двух младших битов этого значения. По умолчанию, -ircapture и -irmask устанавливаются для проверки двухбитного значения. Вы можете предоставить дополнительные биты, если Вы их знаете, или показать, что TAP не соответствует стандарту JTAG.

• -irmask NUMBER
Маска, используемая вместе с -ircapture для проверки инструкция сканирования работает нормально. Такие сканирования не используются OpenOCD, за исключением проверки, что они не создают проблем на операциях с JTAG scan chain.

10.4. Другие команды TAP

jtag cget dotted.name -event name             [Command]
jtag configure dotted.name -event name string [Command]

Как здесь написано, это механизм атрибутов TAP, используемый только для обработки событий. (Это не прямой аналог механизма cget/configure для target-ов отладчика.) См. следующую секцию для информации по доступным событиям.

Подкоманда configure назначает обработчик события (event handler), строку TCL, которая вычисляется, когда срабатывает событие. Подкоманда cget возвращает этот обработчик.

10.5. События TAP (TAP Events)

OpenOCD включает в себя два механизма событий. Один, представленный здесь, прикладывается ко всем JTAG TAP-ам. Другие прикладываются к target-ам отладчика, которые связаны с определенными TAP-ами.

В настоящее время заданы следующие события TAP:

• post-reset
TAP только что завершил сброс JTAG. TAP все еще может быть в состоянии JTAG reset state. Обработчики для этих событий могут выполнять инициализационные последовательности, такие как выдача циклов TCK, последовательностей TMS, чтобы убедится, что произошел выход из режима ARM SWD, и другие.

Поскольку scan chain пока не проверена, обработчики этих событий не должны выдавать команды, которые сканируют регистры JTAG IR или DR на частной target. Внимание: как было написано (сентябрь 2009), ничто не защищает от такого доступа.

• setup
Цепочка сканирования (scan chain) была сброшена и проверена. Этот обработчик может разрешить TAP-ы, как это необходимо.

• tap-disable
TAP нужно запретить. Этот обработчик должен реализовать jtag tapdisable путем выдачи соответствующих команд JTAG.

• tap-enable
TAP нужно разрешить. Этот обработчик должен реализовать jtag tapenable путем выдачи соответствующих команд JTAG.

Если Вам нужны некоторые действия после каждого сброса JTAG, которые не имеют актуальной специфики для любого TAP (пока Вы не можете еще точно доверять содержимому scan chain), то Вы можете:

jtag configure CHIP.jrc -event post-reset {
    echo "JTAG Reset done"
    ... операции, не сканирующие JTAG, для выполнения после сброса
}

10.6. Разрешение и запрет TAP-ов

В некоторых системах используется контроллер маршрутизатора JTAG In (JTAG Route Controller, JRC) для разрешения и/или запрета специфичных JTAG TAP-ов. Многие основанные на ARM чипы от компании Texas Instruments включают в себя модуль "ICEpick", который тоже является JRC. Такие чипы включают процессоры DaVinci и OMAP3.

Определенный TAP может быть невидим, пока не указать JRC подключить его к цепочке JTAG scan chain; и если для JRC сказали отключить этот TAP, то он больше не будет видимым. Такие роутеры решают проблемы такие как игнорирование JTAG в "bypass mode" (сквозной режим), как например:

• Цепочка JTAG scan chain может работать не быстрее, чем самый медленный TAP.
• Наличие нескольких TAP-ов замедляет сканирование инструкций, поскольку все TAP-ы получают новые инструкции.
• TAP-ы в JTAG scan chain должны быть запитаны, что приводит к потере мощности и и не дает отлаживаться при использовании некоторых механизмов управления питанием.

В стандарте IEEE 1149.1 JTAG нет концепции "disabled" (отключенного, запрещенного) TAP, как подразумевается при существовании маршрутизаторов JTAG. Однако появившийся фреймворк IEEE 1149.7 (который работает поверх JTAG) включает в себя вид функциональности роутера JTAG.

В OpenOCD разрешение/запрет (enabling/disabling) TAP вовлекается командами Tcl, как показано ниже, и реализовано с использованием обработчиков событий TAP (TAP event handlers). Так например, когда задается TAP для CPU, подключенного к роутеру JTAG, Ваш файл target.cfg должен задать обработчики события, используя код наподобие такого:

jtag configure CHIP.cpu -event tap-enable {
    ... операции jtag, использующие CHIP.jrc
}
jtag configure CHIP.cpu -event tap-disable {
    ... операции jtag, использующие CHIP.jrc
}

Тогда Вы можете захотеть, чтобы TAP для CPU был разрешен всегда:

jtag configure $CHIP.jrc -event setup "jtag tapenable $CHIP.cpu"

Имейте в виду, что частная декларация обработчика события настройки (setup event handler declaration) использует кавычки для вычисления $CHIP, когда событие сконфигурировано. Использование скобок { } приведет к тому, что оно будет вычислено позднее, во время выполнения, когда оно может иметь другое значение.

jtag tapdisable dotted.name [Command]

Если необходимо, запрещает TAP отправкой события tap-disable. Возвращает строку "1", если TAP, указанный через dotted.name, разрешен, и "0", если запрещен.

jtag tapenable dotted.name [Command]

Если необходимо, разрешает TAP отправкой события tap-enable. Также возвращает строку "1", если TAP, указанный через dotted.name, разрешен, и "0", если запрещен.

jtag tapisenabled dotted.name [Command]

Возвращает строку "1", если TAP, указанный через dotted.name, разрешен, и "0", если запрещен.

Внимание: для людей может оказаться более полезной команда scan_chain, если нужно запросить состояние TAP-ов JTAG.

10.7. Автоматическое распознавание (Autoprobing)

Конфигурирование TAP - первое, что нужно сделать после настройки и сброса интерфейса и конфигурации. Иногда бывает трудно найти, какие имеются TAP-ы, и нужно их идентифицировать. Не всегда бывает просто найти и использовать документацию от вендора чипа.

Чтобы помочь решить такие проблемы, в OpenOCD встроена ограниченная возможность автодетектирования (autoprobing) для просмотра scan chain, делая опрос вслепую (blind interrogation) и с последующим сообщением о найденных TAP-ах. Чтобы задействовать этот механизм, запустите сервер OpenOCD только с данными конфигурации Вашего интерфейса JTAG, и настройте его на низкую тактовую частоту (многие устройства не поддерживают быстрые такты JTAG, когда они вышли из сброса).

Например, Вам подойдет такой файл openocd.cfg:

source [find interface/olimex-arm-usb-tiny-h.cfg]
reset_config trst_and_srst
jtag_rclk 8

Когда Вы запустите сервер без сконфигурированных TAP-ов, он попытается автоматически сконфигурировать TAP-ы. Здесь есть две части этого процесса:

1. TAP discovery (поиск, определение TAP). После сброса JTAG (иногда также нужен также и сброс системы), каждый регистр данных TAP будет содержать либо значение IDCODE, либо регистра BYPASS. Если обмен по JTAG работает, то OpenOCD увидит каждый TAP и сообщит -expected-id для использования его.
2. IR Length discovery (определение длины IR). К сожалению JTAG не предоставляет надежный путь нахождения значения параметра -irlen чтобы можно было использовать его с распознанным TAP. Если OpenOCD смогла распознать длину регистра инструкции TAP, то она сообщит об этом. Иначе Вам нужно проконсультироваться с документацией вендора на чип, такой как даташит или файлы BSDL.

Во многих случаях Ваша плата будет иметь простую scan chain только с одним устройством. Вот пример несколько более сложного отчета OpenOCD для платы:

clock speed 8 kHz
There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x2b900f0f ..."
AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x07926001 ..."
AUTO auto2.tap - use "jtag newtap auto2 tap -expected-id 0x0b73b02f ..."
AUTO auto0.tap - use "... -irlen 4"
AUTO auto1.tap - use "... -irlen 4"
AUTO auto2.tap - use "... -irlen 6"
no gdb ports allocated as no target has been specified

По этой информации Вы должны найти для использования некоторые готовые файлы конфигурации, либо создать свои собственные. Если Вы создаете свои файлы, Вы должны сконфигурировать их в восходящем направлении: сначала файл target.cfg с этими TAP-ами, любыми target-ами, связанными с ним, и любыми ресурсами, встроенными в чип; затем board.cfg с ресурсами, расположенными вне чипа: тактирование и т. п.

[11. Конфигурация CPU]

В этой части обсуждается, как настроить GDB debug target-ы для CPU. Вы можете также получить доступ к этим target-ам без GDB (см. раздел [17. Команды архитектуры и ядра (Architecture and Core Commands)], и 16.2. Обработка состояния цели (Target State handling)) и через различные команды NAND и NOR flash. Если у Вас несколько CPU, то Вы можете иметь несколько таких target-ов. Хороший старт - посмотреть, как можно определить имеющиеся у Вас цели, и затем посмотреть, как добавить одну и большее количество целей, и как конфигурировать их.

11.1. Список целей (Target List)

Все target-ы, которые были настроены, являются частью списка, где каждый член имеет имя. Это имя должно быть обычно то же самое, что и имя TAP. Вы можете командой отобразить список с target-ами. В этом отображении часто отображается только один CPU; вот как это может выглядеть, когда CPU больше одного:

   TargetName         Type       Endian TapName            State
-- ------------------ ---------- ------ ------------------ ------------
0* at91rm9200.cpu     arm920t    little at91rm9200.cpu     running
1  MyTarget           cortex_m   little mychip.foo         tap-disabled

Один член в этом списке текущая target, которая неявно фигурирует во многих командах. Это тот, который помечен * около имени target. В частности, адреса памяти часто ссылаются на адресное пространство, которое относится к текущей цели. Команды типа mdw (memory display words, отображение слов памяти) и flash erase_address (очистка блоков NOR flash) могут служить примером, и многие другие. Несколько команд позволят Вам проверить список целей:

target count [Command]

Внимание: номера target-ов устарели, поэтому не используйте их. Их планируют удалить после августа 2010 года, включая эту команду. Просматривайте target-ы по именам, не по номерам.

Возвращает количество target-ов N. Самый большой номер у цели равен N - 1.

set c [target count]
for { set x 0 } { $x < $c } { incr x } {
    # Подразумевается, что Вы создали эту функцию
    print_target_details $x
}

target current [Command]

Возвращает имя текущей target.

target names [Command]

Выводит список имен всех текущих target-ов.

foreach t [target names] {
    puts [format "Target: %sn" $t]
}

target number number [Command]

Внимание: номера target-ов устарели, поэтому не используйте их. Их планируют удалить после августа 2010 года, включая эту команду.

Список целей, пронумерованный начиная с 0. Эта команда возвращает target-а по номеру индекса.

set thename [target number $x]
puts [format "Target %d is: %sn" $x $thename]

targets [name] [Command]

Внимание: имя этой команды представлено в множественном числе. Другие команды для target в единственном числе. Без параметра эта команда отображает таблицу всех известных target-ов в виде, понятном для пользователя.

С параметром эта команда устанавливает текущую target по указанному имени; это относится только к платам, которые имеют больше одной target.

11.2. Типы целей CPU и варианты (Target CPU Types and Variants)

Каждая target имеет тип CPU, как показано в выводе команды targets. Вам нужно указать тип такой тип, когда создаете target. Тип CPU показывает нечто большее, чем просто набор инструкций. Он также показывает как реализован набор команд, какая вместе с ним интегрирована поддержка отладки, есть или нет MMU (и если есть, какой он), какие специфичные для ядра команды доступны (см. раздел [17. Команды архитектуры и ядра (Architecture and Core Commands)]), и другое.

Для некоторых типов CPU система OpenOCD также определяет варианты, которые показывают различия, влияющие на обработку. Например, баги в реализации чипа могут потребовать соответствующей обработки для некоторых версий чипа.

Это просто - посмотреть какие типы target поддерживаются, с тех пор как есть команда, которая выводит список target-ов. Однако пока нет способа посмотреть, какие варианты target-ов поддерживаются (кроме как смотреть исходный код OpenOCD).

target types [Command]

Выводит все поддерживаемые типы target-ов. На момент написания этого руководства, имеются следующие поддерживаемые типы CPU и варианты:

• arm11 – генерация ядер ARMv6
• arm720t – ядро ARMv4 с MMU
• arm7tdmi – ядро ARMv4
• arm920t – ядро ARMv4 с MMU
• arm926ejs – ядро ARMv5 с MMU
• arm966e – ядро ARMv5
• arm9tdmi – ядро ARMv4
• avr – реализует набор инструкций 8-битных Atmel AVR. (Поддержка ограниченная и неполная.)
• cortex_a – ядро ARMv7 с MMU
• cortex_m – ядро ARMv7, поддерживающее только компактные инструкции Thumb2
• dragonite – напоминает arm966e
• dsp563xx – реализован Freescale’s 24-bit DSP. (Поддержка все еще неполная.)
• fa526 – напоминает arm920 (без Thumb)
• feroceon – напоминает arm926
• mips_m4k – ядро MIPS. Это поддерживает один вариант.
• xscale – это в реальности архитектура, а не тип CPU. Базируется на архитектуре ARMv5. Имеется несколько заданных вариантов:
- ixp42x, ixp45x, ixp46x, pxa27x ... длина регистра инструкции 7 бит
- pxa250, pxa255, pxa26x ... длина регистра инструкции 5 бит
- pxa3xx ... длина регистра инструкции 11 бит

Чтобы избежать путаницы с разными типами ядер ARM, помните ключевой момент: ARM является компанией, лицензирующей технологию (см. http://www.arm.com). Имя CPU, используемое OpenOCD, будет отражать дизайн CPU, который был лицензирован, а не бренд вендора, который реализовал дизайн. Префиксы имен типа arm7, arm9, arm11 и cortex отражают генерации дизайна; в то время как имена типа ARMv4, ARMv5, ARMv6 и ARMv7 отражают архитектуру, реализованную дизайном CPU.

11.3. Конфигурация цели (Target Configuration)

Перед созданием "target" Вы должны добавить его TAP к цепочке JTAG (scan chain). Когда Вы добавили TAP, то получите имя_с_точкой dotted.name, которое будет использовано для настройки поддержки CPU. Файл конфигурации, специфичный для чипа, будет по обыкновению конфигурировать его ядро CPU (или несколько CPU) сразу после того, как будут добавлены TAP-ы чипа к scan chain.

Хотя Вы можете настроить target за один шаг, часто более чистая настройка будет, если Вы используете команды покороче, и сделаете настройку за 2 шага: создадите её, затем сконфигурируете необязательные части. Все операции на target, после того как она будет создана командой new, выполняются как часть создания target.

После создания target имеется две главных вещи для конфигурирования: рабочая область (work area), которая обычно специфична для умолчаний target-а даже если код board setup перезадаст их позже; и вторая вещь это обработчики событий, event handlers (см. раздел 11.5. События цели (Target Events)), которые имеют тенденцию быть более специфичными для платы. Ключевые шаги могут выглядеть наподобие таких:

target create MyTarget cortex_m -chain-position mychip.cpu
$MyTarget configure -work-area-phys 0x08000 -work-area-size 8096
$MyTarget configure -event reset-deassert-pre { jtag_rclk 5 }
$MyTarget configure -event reset-init { myboard_reinit }

Вы должны указать рабочую область, если можете; обычно для этого используется встроенная в чип SRAM. Рабочая область может ускорить многие операции, такие как: запись блоками в память target, операции с flash наподобие проверок, чтобы посмотреть, надо ли очистить память; подсчет контрольных сумм памяти GDB и другое.

Внимание: на более сложных чипах рабочая область может стать недоступной, когда код приложения (такого как операционная система) разрешает или запрещает MMU. Например, будет вероятно иметь значение частный контекст MMU, использующий раньше для доступа виртуальный адрес ... и этот контекст может не иметь простого доступа к другим нужным адресам. На момент написания этой документации, OpenOCD не имеет корректно написанного обращения с MMU.

Часто очень полезно задать обработчик события сброса (reset-init event handler). Для систем, которые нормально используются с бутлоадером, общие задачи включают обновление тактов и инициализация контроллеров памяти. Это может понадобиться, чтобы позволить бутлоадеру записывать во flash, чтобы вывести Вашу плату из состояния "кирпича" ("de-brick"); или для загрузки программ во внешнюю память DDR без запуска бутлоадера.

target create target_name type configparams... [Command]

Эта команда создает GDB debug target, которая ссылается на определенный JTAG TAP. Это вводит созданную target в список, и создает новую команду (target_name) которая используется для разных целей, включая дополнительное конфигурирование.

• target_name ... это имя debug target. По соглашению именования это должно быть такое же имя, как и dotted.name у TAP, связанного с этой target, которое должно быть указано с использованием параметра конфигурации -chain-position dotted.name. Это имя также используется для создание команд target object, связанных с $target_name, и других мест, которые нуждаются в идентификации target.
• type ... указывает тип target. См. target types в разделе 11.2. Типы целей CPU и варианты (Target CPU Types and Variants).
• configparams ... все параметры, принимаемые $target_name configure разрешены. Если target является big-endian, установите здесь с -endian big. Если произошел вариант, установите его с -variant. Вы должны здесь установить -chain-position dotted.name.

$target_name configure configparams... [Command]

Опции, принимаемые этой командой, могут быть также указаны как параметры для target create. Их значения могут быть позже запрошены по одному за один раз используя команду $target_name cget.

Внимание: опасно после настройки менять значение некоторых из этих параметров. Например, перемещение target от одного TAP к другому; и изменение endianness или варианта.

• -chain-position dotted.name – именует TAP, используемый для доступа к этой target.
• -endian (big|little) – указывает, использует ли CPU big или little endian соглашения по порядку байт.
• -event event_name event_body – см. раздел 11.5. События цели (Target Events). Имейте в виду, что это обновляет список именованных обработчиков событий (named event handlers). Если вызвать это дважды с двумя разными именами события, то будет назначено два разных обработчика, но вызов дважды с одним и тем же именем создаст только один обработчик.
• -variant name – указывает вариант target, о котором OpenOCD должна знать.
• -work-area-backup (0|1) – говорит, должен ли быть бекап у рабочей области; по умолчанию рабочая область не сохраняется. Когда возможно, используйте рабочую область, которая не нуждается в сохранении, поскольку выполнение бекапа замедляет операции. Например, начало блока SRAM скорее всего будет использовано большинством систем сборки, но конец часто остается неиспользованным.
• -work-area-size size – указывает размер рабочей области в байтах. Тот же самый размер применяется
независимо от того, используется ли физический или действительный адрес.
• -work-area-phys address – устанавливает базовый адрес рабочей области для использования, когда не активен MMU.
• -work-area-virt address – устанавливает базовый адрес рабочей области для использования, когда активен MMU. Не указывайте значения для этого за исключением случаев, когда на target есть MMU. Значение обычно должно соответствовать статической привязке (static mapping) для адреса -work-area-phys, установленного текущей операционной системой.
• -rtos rtos_type – разрешить поддержку rtos для target, rtos_type может быть одним из вариантов auto|eCos|ThreadX| FreeRTOS|linux|ChibiOS.

11.4. Другие команды $target_name

Язык Tcl/Tk имеет концепцию команд объекта, и OpenOCD адаптировала ту же самую модель для target-ов.

Хороший пример Tk это кнопка на экране. Как только кнопка создана, у неё появляется имя (путь path в терминах Tk), и это имя можно использовать как первую команду класса. Например в Tk, можно создать кнопку и после сконфигурировать её:

# Создание
button .foobar -background red -command { foo }
# Модификация
.foobar configure -foreground blue
# Опрос
set x [.foobar cget -background]
# Репорт
puts [format "The button is %s" $x]

В терминах OpenOCD "target" это объект наподобие кнопки в Tcl/Tk, и команды этого объекта выполняются таким же способом.

str912.cpu   mww 0x1234 0x42
omap3530.cpu mww 0x5555 123

Вот команды, поддерживаемые OpenOCD для объектов target:

$target_name arp_examine   [Command]
$target_name arp_halt      [Command]
$target_name arp_poll      [Command]
$target_name arp_reset     [Command]
$target_name arp_waitstate [Command]

Используйте это внутри скриптов OpenOCD (прежде всего внутри startup.tcl), чтобы обработать специфические случаи сброса. Иначе они здесь не задокументированы.

$target_name array2mem arrayname width address count [Command]
$target_name mem2array arrayname width address count [Command]

Эти команды предоставляют эффективный скрипт-ориентированный интерфейс к памяти. Примитив array2mem записывает байты bytes, полуслова или слова; mem2array читает их. В обоих случаях на стороне TCL используется массив, и на стороне target используется голая память (raw memory).

Можно достичь эффективной работы, если разрешить использовать операции блоковых передач JTAG (bulk JTAG data transfer). Скриптовая ориентация поставляется от работы со значениями данных, которые упакованы для использования скриптами TCL; тип примитивов mdw только печатает данные по запросу, и ни сохраняет, ни возвращает эти значения.

• arrayname ... имя переменной - массива
• width ... 8/16/32 - показывает размер доступа к памяти
• address ... адрес памяти target
• count ... количество элементов для обработки

$target_name cget queryparm [Command]

Каждый параметр конфигурации, принятый $target_name configure, может быть индивидуально запрошен для возврата его текущего значения. Здесь queryparm является именем параметра, принятого командой, такой как -work-area-phys. Имеется несколько специальных случаев:

• -event event_name – возвращает обработчик для события с именем event_name. Это специальный случай, потому что установка обработчика требует два параметра.
• -type – возвращает тип target-а. Это специальный случай, потому что это установка с использованием target create, и она не может быть изменена с использованием $target_name configure.

Например, если Вы хотите обобщить информацию обо всех целях, то можете использовать что-то наподобие этого:

foreach name [target names] {
    set y [$name cget -endian]
    set z [$name cget -type]
    puts [format "Chip %d is %s, Endian: %s, type: %s" 
                 $x $name $y $z]
}

$target_name curstate [Command]

Отображает текущее состояние target: debug-running (работа в сессии отладки), halted (остановлена), reset (сброс), running (запущена) или unknown (состояние неизвестно). Также см. раздел 7.5. Опрос событий (Event Polling).

$target_name eventlist [Command]

Отображает таблицу списка всех обработчиков, связанных в настоящее время с этой target. См. раздел 11.5. События цели (Target Events).

$target_name invoke-event event_name [Command]

Вызывает обработчик для события по имени event_name. (Это главным образом предназначено для использования кодом фреймворка OpenOCD, например кодом сброса в startup.tcl.)

$target_name mdw addr [count] [Command]
$target_name mdh addr [count] [Command]
$target_name mdb addr [count] [Command]

Отображает содержимое по адресу addr в виде 32-битных слов (mdw), 16-битных полуслов (mdh) или 8-битных байтов (mdb). Если указан count, то обображет указанное количество единицisplays that many units. (Если Вы хотите манипулировать данными, вместо того чтобы их отобразить, см. примитивы mem2array.)

$target_name mww addr word     [Command]
$target_name mwh addr halfword [Command]
$target_name mwb addr byte     [Command]

Записывает указанное слово (32 бита), полуслово (16 бит) или байт (8 бит) по указанному адресу addr.

11.5. События цели (Target Events)

Неоднократно могут происходить некоторые вещи, или Вы можете захотеть, чтобы они произошли. Например:

• Что должно случиться, когда подключается GDB? Нужно ли сбросить Вашу target?
• Когда GDB пытается прошить память flash у target, нужно ли разрешить работу flash специальной командой?
• Используется ли подходящий сигнал SRST (возможно) в Вашей системе? Или вместо этого нужно выдать команды JTAG для срабатывания сброса? SRST обычно сбрасывает все в scan chain, и это может быть неподходящим.
• Во время сброса нужно ли Вам записать некоторые области памяти для настройки тактов системы или для реконфигурирования SDRAM? Что по поводу конфигурирования таймера watchdog или другой периферии, для останова выполнения, пока Вы удерживаете ядро остановленным во время отладки?

Все вышеуказанное может быть адресовано через обработчики событий цели (target event handlers). Они настраиваются через $target_name configure -event или target create ... -event.

Модель программирования соответствует опции -command, используемой в кнопках и событиях языка Tcl/Tk. Два примера ниже работают так же, но один создает и вызывает маленькую процедуру, в то время как другая встраивает (inlines) её.

proc my_attach_proc { } {
    echo "Reset..."
    reset halt
}
mychip.cpu configure -event gdb-attach my_attach_proc
mychip.cpu configure -event gdb-attach {
    echo "Reset..."
    # Чтобы сделать flash probe и загрузку gdb во flash,
    #  нужно выполнить reset init.
    reset init
}

Определены следующие события цели (target events):

• debug-halted
В целях отладки target была остановлена (например в месте breakpoint).

• debug-resumed
Было возоблено выполнение программы target (например, было указано run для gdb).

• early-halted
Срабатывает на ранней стадии процесса остановки (halt).

• examine-start
Вызывается перед проверкой target.

• examine-end
Вызывается после проверки target, прошедшей без ошибок.

• gdb-attach
Вызывается при подключении GDB. Происходит перед любым обменом с target, так что это может использоваться для настройки target, и возможно для probe flash. Пробинг flash необходим во время подключения gdb, если gdb загружает это для записи образа во flash. Другое использование flash memory map для того, чтобы GDB мог автоматически использовать аппаратные / программные breakpoint-ы в зависимости от того, где находится breakpoint - в RAM или в памяти только для чтения.

• gdb-detach
Когда GDB отключается.

• gdb-end
Когда target был остановлен и GDB ничего не делает (см. halt).

• gdb-flash-erase-start
Перед тем, как процесс прошивки GDB flash попытается очистить flash.

• gdb-flash-erase-end
После того, как процесс прошивки GDB flash завершит очистку flash.

• gdb-flash-write-start
Перед тем, как GDB записывает во flash.

• gdb-flash-write-end
После того, как GDB записал во flash.

• gdb-start
Перед тем, как target выполнит шаг, gdb пытается запустить/возобновить (start/resume) target.

• halted
Цель target остановлена.

• reset-assert-pre
Выдается как часть обработки сброса после того, как сработал reset_init, но перед либо повторной выдачи одного SRST на scan chain, либо при срабатывании reset-assert.

• reset-assert
Выдается как часть обработки сброса после того, как сработал reset-assert-pre. Когда такой обработчик имеется, ядра, которые поддерживают это событие будут использовать его вместо выдачи SRST. Это поддерживается только для отладки через интерфейсы JTAG, в которых нет сигнала SRST (JTAG не требует SRST), и для селективного сброса, когда scan chain имеет несколько target-ов.

• reset-assert-post
Выдается как часть обработки сброса после того, как сработал reset-assert, или выставлен для target сигнал SRST на всей scan chain.

• reset-deassert-pre
Выдается как часть обработки сброса после того, как сработал reset-assert-post.

• reset-deassert-post
Выдается как часть обработки сброса после того, как сработал reset-deassert-pre и (если target использует это) после того, как был убран SRST с цепочки JTAG (scan chain).

• reset-end
Выдается, когда выполняются последние шаги сброса.

• reset-init
Используется командой reset init для инициализации, специфичной для платы. Это событие срабатывает после reset-deassert-post. Это где Вы должны сконфигурировать PLL и тактирование, настройки DRAM, так что Вы сможете загрузить программы, которые не помещаются во встроенную память SRAM чипа, настройка мультиплексирования выводов и так далее. (Вы можете также переключиться на быструю тактовую частоту JTAG, после того, как такты target-а будут полностью настроены.)

• reset-start
Выдается как часть обработки сброса перед вызовом reset_init. Это самое подходящее место для использования jtag_rclk или adapter_khz для переключения на низкую тактовую частоту JTAG, когда сброс сбрасывает PLL, необходимый для использования быстрой тактовой частоты.

• resume-start
Перед возобновлением любой target.

• resume-end
После того, как все target-ы были возобновлены.

• resumed
Target была возоблена.

[12. Команды Flash]

OpenOCD имеет разные команды для NOR и NAND flash; команда "flash" работает с NOR flash, в то время как команда "nand" работает с NAND flash. Этот факт частично отражает разные аппаратные технологии: NOR flash обычно поддерживает прямой доступ через шину данных к инструкциям CPU, в то время как данные из NAND flash должны быть скопированы в память перед тем, как они могут быть использованы. (Содержимое SPI flash также должно быть скопировано в память перед использованием.) Однако документация также использует "flash" как стандартный термин; например, "Put flash configuration in board-specific files" (разместите конфигурацию flash в файлах, специфичных для платы).

Шаги по настройке flash:

1. Сконфигурируйте её использованием команды flash bank. Сделайте это в файле board config, отражающем специфику платы, передачей параметров, которые нужны драйверу.
2. Работайте с flash через подкоманду flash. Часто команды для манипулирования памятью flash вводятся человеком, или запускаются через скрипт автоматическим способом. Общие задачи включают написание бутлоадера, операционной системы или других данных.
3. GDB Flashing. Прошивка через GDB требует конфигурирования flash через "flash bank", и тогда возможности GDB flash будут разрешены. См. раздел 7.4. Конфигурация GDB. Многие CPU имеют возможность "загрузки" (boot) из первого банка flash. Это означает, что неправильное программирование этого банка может порушить систему, так что она не сможет загрузиться. Инструменты JTAG, наподобие OpenOCD, часто используются для восстановления ("de-brick") платы путем (пере)установки рабочего firmware загрузки (бутлоадер или операционная система).

12.1. Команды конфигурации Flash

flash bank name driver base size chip_width bus_width target [driver_options] [Config Command]

Конфигурирует банк flash, который предоставляет основное хранилище для адресов от base до base+size-1. Эти банки будут часто видны для GDB через карту памяти target. В некоторых случаях, конфигурирование банка flash будет активировать дополнительные команды; см. документацию, специфичную для драйвера.

• name ... может быть использовано как ссылка на flash bank в других командах flash. Можно использовать также номер.
• driver ... идентифицирует драйвер контроллера, связанный с декларируемым банком flash. это обычно cfi для внешней flash, или иначе имя микроконтроллера со встроенной памятью flash. См. раздел 12.4. Список драйверов Flash.
• base ... базовый адрес чипа flash.
• size ... размер чипа в байтах. Для некоторых драйверов это значение детектируется из аппаратуры.
• chip width ... ширина чипа flash chip, в байтах; игнорируется многими драйверами микроконтроллера.
• bus width ... ширина шины данных, используемой для доступа к чипу, в байтах; игнорируется многими драйверами микроконтроллера.
• target ... именует target, используемую для выдачи команд контроллеру flash.
• driver options ... драйверы могут поддерживать или требовать дополнительные параметры. См. специфичную для драйвера документацию для подробностей.

Внимание: эта команда не доступна после того, как будет завершена инициализация OpenOCD. Используйте её в специфичных файлах board config, не интерактивно.

flash banks [Command]

Печатает одну строку общей сводки по каждому устройству, которое было декларировано с использованием flash bank, с нумерацией относительно 0. Имейте в виду, что команда имеет слово во множественном числе; слово в единственном число это совсем другая команда.

flash list [Command]

Запрашивает список ассоциативных массивов для каждого устройства, которое было декларировано для использования flash bank, с нумерацией от 0. Этот возвращенный список может легко манипулироваться из скриптов.

flash probe num [Command]

Идентификация flash, или проверка параметров сконфигурированной flash. Операция зависит от типа flash. Параметр num является значением, показанным командой flash banks. Многие команды flash будут неявно выполнять autoprobe для банка; драйвера flash могут различать между probing и autoprobing, но большинство об этом не беспокоятся.

12.2. Стирание (Erasing), чтение (Reading), запись (Writing) памяти Flash

Одна особенность, которой отличаются технологии NOR flash от NAND или serial flash - доступ на чтение, которая работает так же, как и другая адресуемая память. Это означает, что с ней Вы можете использовать обычные команды чтения наподобие mdw или dump_image, без специальных подкоманд flash. См. разделы 16.4. Команды доступа к памяти и 16.5. Команды загрузки образа.

Доступ на запись работает по-разному. Память Flash обычно должна быть очищена (erased) перед записью. Очистка сектора переводит все её биты в лог. 1, и запись может некоторые биты (которые нужно) переводить в лог. 0. Это причина, по которой есть специальные команды для интерактивной очистки и записи, и почему GDB нужно знать, какие части адресного пространства заняты под NOR flash.

Внимание: большинство этих команд стирания и записи подчеркивают факт, что чипы NOR flash занимают адресное пространство target. Они неявно ссылаются на текущую JTAG target, и привязываются от адреса в адресном пространстве target-а обратно в банк flash. Несколько команд используют абстрактную адресацию, основанную на номерах банка и сектора, и не зависят от поиска текущей target и её адресного пространства. Не перепутайте эти две модели команд.

Некоторые чипы flash имеют программную защиту от случайной записи, поскольку такие записи приведут в некоторых случаях к полному отказу системы. Для таких систем стирание и запись может сначала потребовать запрета защиты сектора. Примеры включают в себя CFI flash, такую как "Intel Advanced Bootblock flash", и память встроенная в микроконтроллер AT91SAM7. См. flash protect в разделе 12.3. Другие команды flash.

flash erase_sector num first last [Command]

Очистить секторы в банке num, начиная с сектора first до и включая last. Нумерация секторов начинается с 0. Если указать в качестве последнего сектора слово last, то это укажет "до конца банка flash". Параметр num это значение, показываемое командой flash banks.

flash erase_address [pad] [unlock] address length [Command]

Очистить сектора начиная с address на length байт. Исключая случая, когда указан pad, должен начинаться с сектора flash, и address + length - 1 должен указывать на конец сектора. Указание pad очищает дополнительные данные в начале и/или конце указанного региона, как необходимо для только для очистки полных секторов. Банк flash для использования выводится из address, и указанная длина должна оставаться в пределах этого банка. В специальном случае, когда length равна 0 и address указывает на начало банка, будет очищена вся память flash. Если указан unlock, то на flash перед началом очистки будет отключена защита от записи.

flash fillw address word length     [Command]
flash fillh address halfword length [Command]
flash fillb address byte length     [Command]

Заполняет память flash указанным словом word (32 бита), полусловом halfword (16 бит), или байтом byte (8 бит), начиная с address и продолжая на length единиц (word/halfword/byte). Перед записью не будет делаться очистка; когда нужно, это должно быть выполнено перед запуском команды заполнения. Запись выполняется блоками по 1024 байта, и каждая запись проверяется путем обратного чтения данных и сравнения с тем, что было записано. Используемый банк flash вычисляется от address для каждого блока, и указанная длина должна оставаться в пределах этого банка.

flash write_bank num filename offset [Command]

Записывает бинарный файл filename в банк flash num, начиная с offset байтов от начала банка. Параметр num это значение, показываемое командой flash banks.

flash write_image [erase] [unlock] filename [offset] [type] [Command]

Записывает файл образа (image) filename в банки flash текущей target. Может быть указано смещение для изменения положения данных, в этом случае оно будет добавлено к базовому адресу для каждой секции образа. Тип файла [type] может быть указан явно как bin (binary, двоичный), ihex (Intel hex), elf (файл в формате ELF), s19 (Motorola s19), mem или builder. Соответствующие сектора flash будут очищены перед программированием, если указан параметр erase. Если указан unlock, то на flash перед очисткой и программированием будет отключена защита от записи. Используемый банк flash вычисляется от адреса каждой секции образа.

Предупреждение: будьте внимательны при использовании флага erase, когда flash содержит данные, которые Вы хотели бы сохранить. Порции flash вне описанного в секциях пространства могут быть очищены без всякого предупреждения.

• Когда секция записываемого образа не заполняет все сектора, которые использует, то не записанные части этих секторов должны быть также очищены, потому что сектора не могут быть очищены по отдельности.
• На данные, которые сохранены в "дырках" между секциями образа, запись также влияет. Например, "flash write_image erase ..." с образом размером в 1 байт при записи его с начала банка приведет к очистке всего банка – не просто двух записываемых секторов. Также когда важна защита flash, Вы должны потом восстановить её, так как защита отключается флагом unlock.

12.3. Другие команды Flash

flash erase_check num [Command]

Проверка очищенного состояния секторов в flash банке num, и отображение этого состояния. Параметр num это значение, показываемое командой flash banks.

flash info num [Command]

Печатает информацию о банке flash номер num. Параметр num это значение, показываемое командой flash banks. Эта команда делает первый опрос аппаратуры, он не печатает кэшированную и возможно устаревшую информацию.

flash protect num first last (on|off) [Command]

Разрешение (on) или запрет (off) защиты секторов flash в банке flash номер num, начиная с первого сектора и далее, включая последний сектор last. Предоставление вместо последнего сектора слова last указывает "до конца банка flash". Параметр num это значение, показываемое командой flash banks.

program filename [verify] [reset] [offset] [Command]

Это скрипт хелпера, который упрощает использование OpenOCD в качестве стандартного программатора. Единственный требуемый параметр filename, остальные необязательные. См. раздел [13. Программирование Flash].

12.4. Список драйверов Flash

Как было указано выше, команда flash bank требует имени драйвера, и позволяет использовать зависящие от драйвера опции и варианты поведения. Некоторые драйвера также активизируют команды, специфичные для драйвера.

12.4.1. Внешняя память flash (External Flash)

cfi [Flash Driver]

"Common Flash Interface" (CFI) - основной стандарт лоя внешних чипов NOR flash, каждый из которых подключается к специальному отдельному сигналу выборки (chip select), приходящему от CPU. Часто такой первый чип используется для загрузки системы. Обработчик сброса платы (reset-init handler) может потребоваться для конфигурирования дополнительных сигналов выборки с использованием других команд (наподобие: mww для конфигурирования шины и её таймингов), или возможно конфигурирование вывода GPIO, который управляет выводом "write protect" чипа flash. Драйвер CFI может использовать зависящую от target рабочую область для значительного ускорения работы.

Драйвер CFI может принять следующие необязательные параметры, в любом порядке:

• jedec probe ... используется для детектирования основных не-CFI flash ROM-ов, наподобие AM29LV010 и подобных типов.
• x16 as x8 ... когда 16-битный flash подцеплен к 8-битной шине.

Для конфигурирования двух соседних банков по 16 мегабайт каждый, оба с 16-битной шиной (2 байта):

flash bank $_FLASHNAME cfi 0x00000000 0x01000000 2 2 $_TARGETNAME
flash bank $_FLASHNAME cfi 0x01000000 0x01000000 2 2 $_TARGETNAME

Для конфигурирования одного банка 32 мегабайт построенного из двух 16-битных (2 байта) чипа, подключенных параллельно для создания 32-битной шины (4 байта), с двойной пропускной способностью:

flash bank $_FLASHNAME cfi 0x00000000 0x02000000 2 4 $_TARGETNAME

lpcspifi [Flash Driver]

Семейства NXP LPC43xx и LPC18xx включают периферию проприетарного интерфейса SPI Flash (SPIFI), который может управлять и предоставлять привязанный к памяти доступ к внешним устройствам SPI flash.

Драйвер lpcspifi инициализирует этот интерфейс и предоставляет функционал программирования и очистки для этих последовательных устройств flash. Использование этого драйвера требует конфигурирования на устройстве target рабочей области как минимум 1 килобайт; большее число значительно уменьшит время программирования flash.

Команда настройки требует только параметра base. Все другие параметры игнорируются, и размер flash и разводка конфигурируются драйвером.

flash bank $_FLASHNAME lpcspifi 0x14000000 0 0 0 $_TARGETNAME

stmsmi [Flash Driver]

Некоторые устройства от компании STMicroelectronics (например MCU семейство STR75x, семейство MPU SPEAr) имеют проприетарный "Serial Memory Interface" (SMI) контроллер, который может обслуживать внешние микросхемы SPI flash. В зависимости от специфичного устройства и конфигурации платы, может быть подключено до 4 внешних устройств flash.

SMI работают так, что содержимое flash становится напрямую доступно в адресном пространстве CPU; каждое внешнее устройство памяти привязано (mapped) к банку памяти. CPU может напрямую читать данные, выполнять код и загружаться из банков SMI. Обычные команды OpenOCD наподобие mdw могут использоваться для отображения содержимого flash.

Команда настройки требует только параметр base для идентификации банка памяти. Все другие параметры игнорируются. Дополнительная информация, наподобие размера flash, детектируется автоматически.

flash bank $_FLASHNAME stmsmi 0xf8000000 0 0 0 $_TARGETNAME

12.4.2. Внутренняя память FLASH (Internal Flash, микроконтроллеры)

aduc702x [Flash Driver]

ADUC702x аналоговые микроконтроллеры от компании Analog Devices, которые встроена внутренняя flash, и они используют ядра ARM7TDMI. Драйвер flash aduc702x работает с моделями от ADUC7019 до ADUC7028. Команда настройки требует только аргумент target, потому что все устройства этого семейства имеют одно и то же построение памяти.

flash bank $_FLASHNAME aduc702x 0 0 0 0 $_TARGETNAME

at91sam3 [Flash Driver]

Все члены семейства микроконтроллеров AT91SAM3 от Atmel имеют внутреннюю flash и используют ядро ARM Cortex-M3. В настоящий момент (6/22/09) драйвер распознает чипы AT91SAM3U[1/2/4][C/E]. Имейте в виду, что драйвер изначально был разработан и протестирован на AT91SAM3U4E, с использованием отладочной платы SAM3U-EK eval board. Поддержка для других чипов была списана с даташита. Замечание для будущих читателей / обновителей: пожалуйста удалите этот беспокоящий комментарий после того, как будет подтверждена проверка других чипов.

Чипы AT91SAM3U4[E/C] (256K) имеют 2 банка flash; большинство других чипов имеют один банк flash. Все другие случаи банков flash расположены по следующим фиксированным местам:

# Flash bank 0 - все чипы
flash bank $_FLASHNAME at91sam3 0x00080000 0 1 1 $_TARGETNAME
# Flash bank 1 - только 256K чипы
flash bank $_FLASHNAME at91sam3 0x00100000 0 1 1 $_TARGETNAME

Внутренне память flash AT91SAM3 организована следующим образом. В отличие от чипов AT91SAM7, они не используются в качестве параметров команды flash bank:

• N-Banks: 256K чипы имеют 2 банка, у других 1 банк.
• Bank Size: 128K/64K на один банк flash.
• Sectors: 16 или 8 на банк.
• SectorSize: размер сектора 8K.
• PageSize: 256 байт на страницу. Имейте в виду, что OpenOCD работает с размерами сектора, а не с размерами страницы.

Драйвер AT91SAM3 добавляет некоторые дополнительные команды:

    at91sam3 gpnvm                   [Command]
    at91sam3 gpnvm clear number      [Command]
    at91sam3 gpnvm set number        [Command]
    at91sam3 gpnvm show [all|number] [Command]

Без параметров показывают либо все (show all), либо статус всех бит GPNVM. С show number отображает соответствующий бит. С set number или clear number модифицирует указанный бит GPNVM.

    at91sam3 info [Command]

Эта команда пытается получить информацию о чипе AT91SAM3. Первым читается CHIPID_CIDR [адрес 0x400e0740, см. секцию 28.2.1 даташита AT91SAM3U 29/05/2009, document id: doc6430A] и декодируются значения. Вторым читается различные регистры конфигурации тактов и делается попытка отобразить, как сконфигурирован чип. По

    at91sam3 slowclk [value] [Command]

Эта команда показывает/устанавливает медленную тактовую частоту, используемую в вычислениях команды at91sam3 info, показанной выше.

at91sam4 [Flash Driver]

Все члены семейства микроконтроллеров AT91SAM4 от Atmel имеют внутреннюю flash и используют ядро ARM Cortex-M4. Этот драйвер использует тот же синтаксис и имена, как и команды at91sam3.

at91sam7 [Flash Driver]

Все члены семейства микроконтроллеров AT91SAM7 от Atmel имеют внутреннюю flash и используют ядра ARM7TDMI. Драйвер автоматически распознает номер чипа по регистру идентификации, встроенному в чип, и автоматически выполняет конфигурирование.

flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME

Для чипов, которые не распознаются драйвером контроллера, Вы должны предоставить дополнительные параметры в следующем порядке:

• chip_model ... метка, используемая в команде flash info
• banks
• sectors_per_bank
• pages_per_sector
• pages_size
• num_nvm_bits
• freq_khz ... требуется, если предоставлена внешняя тактовая частота, необязательный (но рекомендуемый) параметр, когда известна тактовая частота генератора

Рекомендуется Вам предоставить нулевые значения для всех этих параметров, за исключением тактовой частоты, так как все они будут сконфигурированы автоматически. Знание частоты помогает применить корректный тайминг для доступа к flash.

Контроллер flash поддерживает автоматическое стирание на базе страниц (128/256 байт), так что не нужно использовать явно команды очистки при программировании flash. Однако, здесь есть команда "EraseAll", которая может очистить всю плоскость flash plane (до 256KB), и она будет использоваться автоматически, когда выдадите команды flash erase_sector или flash erase_address.

    at91sam7 gpnvm bitnum (set|clear) [Command]

Установка или очистка бита "General Purpose Non-Volatile Memory" (GPNVM) для процессора. Каждый процессор имеет некоторое количество таких бит, используемых для управления такими возможностями, как brownout detection (детектирование пропадания питания, что в общем не относится к битам общего назначения).

Внимание: это подразумевает, что первый банк flash (номер 0) связан с соответствующей at91sam7 target.

avr [Flash Driver]

Микроконтроллеры AVR 8-бит от Atmel, в которых встроена память flash. Текущая реализация OpenOCD для них пока не завершена.

efm32 [Flash Driver]

Все члены семейства микроконтроллеров EFM32 от компании Energy Micro имеют встроенную flash и используют ядра ARM Cortex M3. Драйвер автоматически распознает номер этих чипов, используя для этого регистр идентификации чипа, и конфигурирует сам себя.

flash bank $_FLASHNAME efm32 0 0 0 0 $_TARGETNAME

Текущая реализация не завершена. Отмена защиты страниц flash не поддерживается.

lpc2000 [Flash Driver]

Большинство членов семейства микроконтроллеров LPC1700, LPC1800, LPC2000 и LPC4300 от компании NXP имеют внутреннюю flash и используют ядра Cortex-M3 (LPC1700, LPC1800), Cortex-M4 (LPC4300) или ARM7TDMI (LPC2000).

Внимание: есть устройства LPC2000, которые не поддерживаются драйвером lpc2000: LPC2888 поддерживается отдельным драйвером lpc288x. Семейство LPC29xx
поддерживается драйвером lpc2900.

Драйвер lpc2000 определяет два обязательных и один необязательный параметры, которые должны появляться в следующем порядке:

• variant ... обязательный параметр может быть lpc2000_v1 (старые LPC21xx и LPC22xx), lpc2000_v2 (LPC213x, LPC214x, LPC210[123], LPC23xx и LPC24xx), lpc1700 (LPC175x и LPC176x) или lpc4300 - доступные также как алиас lpc1800 (LPC18x[2357] and LPC43x[2357])
• clock kHz ... частота в килогерцах, на которой работает ядро.
• calc_checksum ... необязательно (но возможно Вы захотите указать это!), что говорит драйверу вычислить правильную контрольную сумму для таблицы векторов исключений (прерываний, exception vector table).

Внимание: если Вам не надо предоставить calc_checksum, когда записываете таблицу векторов, boot ROM почти наверняка проигнорирует Ваш образ flash. Однако, если Вы его предоставите, большинство тулчейнов выдадут ошибку с verify_image.

Память LPC flash не требует указания чипа и ширины шины.

flash bank $_FLASHNAME lpc2000 0x0 0x7d000 0 0 $_TARGETNAME 
      lpc2000_v2 14765 calc_checksum

    lpc2000 part_id bank [Command]

Отображает 4 байта идентификатора модели чипа, связанного с указанным flash bank.

lpc288x [Flash Driver]

Микроконтроллер LPC2888 от NXP нуждается в несколько отличающейся от его родного брата lpc2000 поддержке flash. Драйвер lpc288x определяет один обязательный параметр, частоту тактов программирования в Гц. Память LPC flash не требует указания чипа и ширины шины.

flash bank $_FLASHNAME lpc288x 0 0 0 0 $_TARGETNAME 12000000

lpc2900 [Flash Driver]

Этот драйвер поддерживает микроконтроллер LPC29xx, основанный на семействе ARM968E компании NXP. Предопределенные параметры base, size, chip_width и bus_width команды flash bank будут игнорированы. Размер Flash и конфигурация sector-а автоконфигурируются драйвером. Драйвер имеет одни дополнительный обязательный параметр: CPU clock rate (тактовая частота CPU, в килогерцах) в то время, когда имеют место операции flash. В большинстве случаев это будет не частота кварца, а более высокая частота, полученная с помощью PLL. Обработчик события reset-init event handler в скрипте платы (board script) обычно то место, где Вы запускаете PLL.

Драйвер отвергает устройства без flash (сейчас это LPC2930). EEPROM в устройствах LPC2900 не отображено напрямую на адресное пространство. Это требует намного большей обработки, чем у памяти NAND flash, и будет таким образом поддерживаться отдельным драйвером lpc2900_eeprom (он пока недоступен).

Защита сектора в терминах LPC2900 обрабатывается прозрачно. Каждый раз, когда сектор нужно очистить или запрограммировать, защита автоматически отключается. То, что показано как protection status (состояние защиты) в команде flash info, в действительности безопасность сектора (sector security) LPC2900. Это механизм, который защищает от того, что сектор будет очищен или запрограммирован заново. Поскольку это - необратимый механизм, он поддерживается специальной командой (lpc2900 secure_sector), а не стандартной командой flash protect.

Пример для тактовой частоты 125 МГц:

flash bank $_FLASHNAME lpc2900 0 0 0 0 $_TARGETNAME 125000

Заданы некоторые специфичные для lpc2900 команды. В следующем списке команд параметр bank является номером банка, полученный командой flash banks.

    lpc2900 signature bank [Command]

Вычисляет значение 128-битного хэша, signature, от всего содержимого flash. Это аппаратная особенность блока flash, поскольку вычисление происходит очень быстро. Это можно использовать для проверки запрограммированного устройства по известной сигнатуре. Пример:

lpc2900 signature 0
  signature: 0x5f40cdc8:0xc64e592e:0x10490f89:0x32a0f317

    lpc2900 read_custom bank filename [Command]

Читает 912 байт информации пользователя из сектора индекса (flash index sector), и сохраняет его в файл в бинарном формате. Пример:

lpc2900 read_custom 0 /path_to/customer_info.bin

Индексный сектор flash является сектором только для записи (write-only sector). Он не может быть очищен! Чтобы защитить его от нежелательного доступа на запись, всегда надо использовать успешный вызов команды пароля:

    lpc2900 password bank password [Command]

Вам нужно использовать эту команду перед каждой из последующих команд: lpc2900 write_custom, lpc2900 secure_sector, lpc2900 secure_jtag. Строка пароля фиксирована на "I know what I am doing". Пример:

lpc2900 password 0 I_know_what_I_am_doing
  Potentially dangerous operation allowed in next command!

Команда предупреждает: "В следующей команде может быть потенциально опасная операция!".

    lpc2900 write_custom bank filename type [Command]

Записывает содержимое файла в пространство пользователя (customer info space) индексного сектора (flash index sector). Тип файла filetype может быть указан в поле type. Возможны значения: bin (binary, двоичный), ihex (формат Intel hex), elf (двоичный ELF) или s19 (Motorola S-records). Файл должен содержать одну секцию, и содержащиеся данные должны быть размером ровно 912 байт. Внимание: эту операцию нельзя отменить, будьте внимательны! Пример:

lpc2900 write_custom 0 /path_to/customer_info.bin bin

    lpc2900 secure_sector bank first last [Command]

Защищает диапазон секторов от first до last (включительно) от дальнейших операций программирования и очистки. Защита сектора (sector security) эффективно применится после следующего выключения и нового включения питания. Внимание: эту операцию нельзя отменить, будьте внимательны! Защищенные сектора будут видны как protected в команде flash info. Пример:

lpc2900 secure_sector 0 1 1
flash info 0
  #0 : lpc2900 at 0x20000000, size 0x000c0000, (...)
          #  0: 0x00000000 (0x2000 8kB) not protected
          #  1: 0x00002000 (0x2000 8kB) protected
          #  2: 0x00004000 (0x2000 8kB) not protected

    lpc2900 secure_jtag bank [Command]

Необратимо запрещает порт JTAG. Новая установка JTAG security применится после следующего выключения и нового включения питания. Внимание: эту операцию нельзя отменить, будьте внимательны! Примеры:

lpc2900 secure_jtag 0

ocl [Flash Driver]

Нет никаких идей, что это такое, кроме как что-то для использования с ядром arm7/arm9.

flash bank $_FLASHNAME ocl 0 0 0 0 $_TARGETNAME

pic32mx [Flash Driver]

Микроконтроллеры PIC32MX, базирующиеся на ядрах MIPS 4K, которые имеют встроенную память flash.

flash bank $_FLASHNAME pix32mx 0x1fc00000 0 0 0 $_TARGETNAME
flash bank $_FLASHNAME pix32mx 0x1d000000 0 0 0 $_TARGETNAME

Этим драйвером задаются специфичные для pic32mx команды:

    pic32mx pgm_word address value bank [Command]

Программирует указанное 32-битное значение по указанному адресу в указанный банк чипа.

    pic32mx unlock bank [Command]

Разблокирование и очистка указанного банка чипа. Это полностью удалит защиту кода (Code Protection).

stellaris [Flash Driver]

Все члены семейства микроконтроллеров Stellaris LM3Sxxx компании Texas Instruments имеют встроенную внутреннюю память flash и используют ядра ARM Cortex M3. Драйвер автоматически распознает количество этих чипов, используя регистр идентификации чипа, и конфигурирует сам себя автоматически.

flash bank $_FLASHNAME stellaris 0 0 0 0 $_TARGETNAME

Примечание: сейчас здесь имеется команда stellaris mass_erase. Эта команда кажется бессмысленной, так как того же эффекта можно достичь стандартной командой flash erase_address.

    stellaris recover bank_id [Command]

Выполняет процедуру восстановления (Recovering) "заблокированного" устройства ("Locked" Device) для восстановления flash, указанной по идентификатору bank_id и её связанные энергонезависимые (nonvolatile) регистры в свое заводское состояние по умолчанию (очищено). Это единственный способ удалить защиту flash или заново разрешить отладку, если эта возможность была запрещена.

Имейте в виду, что последний шаг в этой процедуре - "power cycle the chip" (выключение питание чипа и повторное включение) - должен быть выполнен вручную, поскольку OpenOCD не может это выполнить.

Внимание: если подключено больше одного чипа Stellaris, то эта процедура повлияет на их всех.

stm32f1x [Flash Driver]

Все члены семейства микроконтроллеров STM32F0, STM32F1 и STM32F3 от компании ST Microelectronics имеют встроенную память flash и используют ядра ARM Cortex-M0/M3/M4. Драйвер автоматически распознает номер этих чипов по регистру идентификации чипа, и конфигурирует сам себя автоматически.

flash bank $_FLASHNAME stm32f1x 0 0 0 0 $_TARGETNAME

Имейте в виду, что могут найтись некоторые устройства, которые имеют неправильное значение в регистре размера flash, и для обхода этой проблемы Вы можете перезадать считанное значение, используемое драйвером flash.

flash bank $_FLASHNAME stm32f1x 0 0x20000 0 0 $_TARGETNAME

Если у Вас target с двойными банками flash, то задайте второй банк по следующему примеру.

flash bank $_FLASHNAME stm32f1x 0x08080000 0 0 0 $_TARGETNAME

Определены некоторые специфичные для stm32f1x команды (примечание: сейчас имеется команда stm32f1x mass_erase command. Это кажется бесполезным, так как того же эффекта можно достичь применением стандартной команды flash erase_address):

    stm32f1x lock num [Command]

Полностью блокирует все устройство stm32. Параметр num является значением, показанным командой flash banks.

    stm32f1x unlock num [Command]

Полностью разблокирует все устройство stm32. Параметр num является значением, показанным командой flash banks.

    stm32f1x options_read num [Command]

Читает и отображает байты опций stm32, записанные командой stm32f1x options_write. Параметр num является значением, показанным командой flash banks.

    stm32f1x options_write num (SWWDG|HWWDG) (RSTSTNDBY|NORSTSTNDBY) (RSTSTOP|NORSTSTOP) [Command]

Записывает байт опций stm32 в указанные значения. Параметр num является значением, показанным командой flash banks.

stm32f2x [Flash Driver]

Все члены семейства микроконтроллеров STM32F2 и STM32F4 от компании ST Microelectronics имеют встроенную память flash, и используют ядра ARM Cortex-M3/M4. Драйвер автоматически распознает номер этих чипов по регистру идентификации чипа, и автоматически конфигурирует сам себя.

flash bank $_FLASHNAME stm32f2x 0 0x20000 0 0 $_TARGETNAME

Определены некоторые специфичные для stm32f2x команды:

    stm32f2x lock num [Command]

Полностью блокирует все устройство stm32. Параметр num является значением, показанным командой flash banks.

    stm32f2x unlock num [Command]

Полностью разблокирует все устройство stm32. Параметр num является значением, показанным командой flash banks.

stm32lx [Flash Driver]

Все члены семейства микроконтроллеров STM32L от компании ST Microelectronics имеют встроенную память flash, и используют ядра ARM Cortex-M3. Драйвер автоматически распознает номер этих чипов по регистру идентификации чипа, и автоматически конфигурирует сам себя.

flash bank $_FLASHNAME stm32lx 0 0x20000 0 0 $_TARGETNAME

str7x [Flash Driver]

Все члены семейства микроконтроллеров STR7 от компании ST Microelectronics имеют встроенную память flash, и используют ядра ARM7TDMI. Драйвер str7x задает один обязательный параметр, variant, который один из: STR71x, STR73x или STR75x.

flash bank $_FLASHNAME str7x 0x40000000 0x00040000 0 0 $_TARGETNAME STR71x

    str7x disable_jtag bank [Command]

Активизирует механизм защиты от отладки/чтения (Debug/Readout protection mechanism) для указанного банка flash.

str9x [Flash Driver]

Большинство членов семейства микроконтроллеров STR9 от компании ST Microelectronics имеют встроенную память flash, и используют ядра ARM966E. Перед программированием для str9 нужно сконфигурировать контроллер flash, используя команду str9x flash_config. Пример использования str9x:

flash bank $_FLASHNAME str9x 0x40000000 0x00040000 0 0 $_TARGETNAME
str9x flash_config 0 4 2 0 0x80000

    str9x flash_config num bbsr nbbsr bbadr nbbadr [Command]

Конфигурирует str9 flash controller. Параметр num является значением, показанным командой flash banks.

• bbsr - регистр Boot Bank Size (размер банка загрузки)
• nbbsr - регистр Non Boot Bank Size (размер банка, не относящегося к загрузке)
• bbadr - регистр Boot Bank Start Address (начальный адрес банка загрузки)
• nbbadr - регистр Non Boot Bank Start Address (начальный адрес банка, не относящегося к загрузке)

tms470 [Flash Driver]

Большинство членов семейства микроконтроллеров TMS470 от компании Texas Instruments имеют встроенную память flash, и используют ядра ARM7TDMI. Для этого драйвера не надо указывать чип и ширину шины.

Определены некоторые команды, специфичные для tms470:

    tms470 flash_keyset key0 key1 key2 key3 [Command]

Сохраняет программируемые ключи в регистр, чтобы разрешить команды очистки и записи flash.

    tms470 osc_mhz clock_mhz [Command]

Сообщает тактовую частоту, которая используется для вычисления таймингов.

    tms470 plldis (0|1) [Command]

Запрещает (1) или разрешает (0) использование PLL для повышения тактовой частоты flash.

virtual [Flash Driver]

Это специальный драйвер, который отображает ранее определенный банк на другой адрес. Все установки банка будут скопированы из главного физического банка (master physical bank).

Драйвер virtual задает один обязательный параметр,

• master_bank банк, к которому относится этот виртуальный адрес.

В следующем примере адреса 0xbfc00000 и 0x9fc00000 ссылаются на банк flash, определенный по адресу 0x1fc00000. Любые команды, выполненные на виртуальных банках, на самом деле выполняются на физических банках.

flash bank $_FLASHNAME pic32mx 0x1fc00000 0 0 0 $_TARGETNAME
flash bank vbank0 virtual 0xbfc00000 0 0 0 $_TARGETNAME $_FLASHNAME
flash bank vbank1 virtual 0x9fc00000 0 0 0 $_TARGETNAME $_FLASHNAME

fm3 [Flash Driver]

Все члены семейства микроконтроллеров FM3 от компании Fujitsu имеют встроенную память flash, и используют ядра ARM Cortex M3. Драйвер fm3 использует параметр target для выбора конкретной конфигурации банка, в настоящее это следующее: mb9bfxx1.cpu, mb9bfxx2.cpu, mb9bfxx3.cpu, mb9bfxx4.cpu, mb9bfxx5.cpu или mb9bfxx6.cpu.

flash bank $_FLASHNAME fm3 0 0 0 0 $_TARGETNAME

12.4.3. Драйвер str9xpec

Здесь приведена некоторая дополнительная информация, которая может помочь Вам лучше понять, как этот драйвер работает. OpenOCD имеет два драйвера flash для str9:

1. Стандартный драйвер str9x, программируемый через ядро str9. Нормально используется для программирования flash, как более быстрый драйвер, чем str9xpec.
2. Драйвер str9xpec, использующий прямое программирование через контроллер flash. Он совместим с ISC (IEEE 1532) TAP, подключенным (в цепочку JTAG) последовательно с ядром str9. Чтобы программировать через этот драйвер flash, не нужно запущенное ядро str9. Типичное использование этого драйвера - блокирование/разблокировка target и программирование байтов опций.

Перед тем, как мы запустим любую команду с использованием драйвера str9xpec, мы сначала должны запретить ядро str9. Этот пример подразумевает, что драйвер str9xpec был сконфигурирован для банка 0 flash.

# Выставление сигнала srst, нам не нужно работающее ядро,
# пока работаем через flash-драйвер str9xpec.
jtag_reset 0 1
# выключение опроса target
poll off
# запрет ядра str9
str9xpec enable_turbo 0
# чтение байта опций
str9xpec options_read 0
# заново разрешаем ядро str9
str9xpec disable_turbo 0
poll on
reset halt

Пример выше будет читать байт опций str9. Когда выполняется unlock, помните, что Вы не сможете остановить (halt) str9 - от будет заблокирован (locked). Остановка ядра не требуется для драйвера str9xpec, как было указано ранее, просто выдайте вышеуказанные команды вручную или через командную строку telnet.

str9xpec [Flash Driver]

Используйте этот драйвер только для блокировки/разблокирования (locking/unlocking) устройства или конфигурирования байтов опций. Используйте для программирования стандартный драйвер str9. Перед использованием команд flash должен быть разрешен режим turbo с использованием команды str9xpec enable_turbo.

Задано несколько специфичных для str9xpec команд:

    str9xpec disable_turbo num [Command]

Восстановить str9 в цепочку JTAG.

    str9xpec enable_turbo num [Command]

Разрешить turbo mode, это просто удалит str9 из цепочки и общение напрямую будет осуществляться со встроенным контроллером flash.

    str9xpec lock num [Command]

Заблокировать (Lock) устройство str9. str9 будет отвечать только на команду unlock, которая очистит (erase) устройство.

    str9xpec part_id num [Command]

Печатает идентификатор чипа для банка num.

    str9xpec options_cmap num (bank0|bank1) [Command]

Конфигурирует банк загрузки str9 (boot bank).

    str9xpec options_lvdsel num (vdd|vdd_vddq) [Command]

Конфигурирует источник str9 lvd.

    str9xpec options_lvdthd num (2.4v|2.7v) [Command]

Конфигурирует порог str9 lvd.

    str9xpec options_lvdwarn bank (vdd|vdd_vddq) [Command]

Конфигурирует источник предупреждения сброса str9 lvd (reset warning source).

    str9xpec options_read num [Command]

Читает байт опций str9.

    str9xpec options_write num [Command]

Записывает байт опций str9.

    str9xpec unlock num [Command]

Разблокирует (unlock) устройство str9.

12.5. mFlash

12.5.1. Конфигурация mFlash

mflash bank soc base RST_pin target [Config Command]

Конфигурирует mflash для soc банка хоста по адресу base. Формат имени номера зависит от системы именования (naming convention) GPIO. В настоящее время драйвер mflash поддерживает s3c2440 и pxa270.

Пример для s3c2440 mflash, где вывод RST является GPIO B1:

mflash bank $_FLASHNAME s3c2440 0x10000000 1b 0

Пример для pxa270 mflash, где вывод RST является GPIO 43:

mflash bank $_FLASHNAME pxa270 0x08000000 43 0

12.5.2. Команды mFlash

mflash config pll frequency [Command]

Конфигурирует mflash PLL. Параметр frequency является входной частотой mflash, в Гц. Выдача этой команды полностью очистит внутреннюю nand и записывает новую pll. После этой команды для нормальной работы mflash нуждается в сбросе при включении питания (power-on-reset) for normal operation. Если pll была заново сконфигурирована, нужно обновить хранилище (storage) и нужно также обновить (это необязательно) информацию загрузки (boot info).

mflash config boot [Command]

Конфигурирует опцию загрузки. Если опция загрузки установлена, mflash предоставляет первые 8 секторов (4kB) для загрузки (boot).

mflash config storage [Command]

Конфигурирует информацию хранилища. Эта информация должна быть записана для нормальной работы хранилища.

mflash dump num filename offset size [Command]

Вывести дамп размеров size байт, со смещением offset байт от начала банка num, в файл с именем filename.

mflash probe [Command]

Probe mflash.

mflash write num filename offset [Command]

Записать двоичный (binary) файл в mflash банк num, со смещением offset байт от начала банка.

[13. Программирование Flash]

OpenOCD реализует несколько способов для программирования target flash, либо внутренней, либо внешней. Программирование можно осуществить либо с использованием GDB (см. раздел 21.4. Программирование с использованием GDB), либо используя для этого команды (см. раздел 12.2. Стирание (Erasing), чтение (Reading), запись (Writing) памяти Flash).

Для упрощения использования команд flash напрямую доступен скрипт jimtcl, который поддерживает стадию программирования и проверки (verify). OpenOCD будет поддерживает программирование/проверку/сброс (program/verify/reset) target и выключение (shutdown). Скрипт выполняется, как следует, и по умолчанию выполняются следующие действия.

1. Выполняется 'init'.
2. Вызывается 'reset init' для сброса и остановки (halt) target-а, выполняются любые скрипты 'reset init'.
3. Вызывается flash write_image для очистки и записи любой flash с использованием указанного filename.
4. Вызывается verify_image, если предоставляется параметр verify (проверка).
5. Вызывается reset run, если указан параметр reset.
6. OpenOCD завершается (shutdown).

Пример использования приведен ниже. См. [program], в разделе 12.3. Другие команды Flash.

# программирование и проверка с использованием elf/hex/s19. verify и reset
# необязательные параметры
openocd -f board/stm32f3discovery.cfg 
-c "program filename.elf verify reset"
 
# двоичные файлы нуждаются в передаче адреса flash
openocd -f board/stm32f3discovery.cfg 
-c "program filename.bin 0x08000000"

[14. Команды NAND Flash]

В сравнении с NOR или SPI flash, устройства NAND недороги и имеют высокую плотность. Сегодня чипы NAND и многочиповые модули могут хранить несколько гигабайт данных. Чипы NAND состоят из некоторого количества "блоков очистки" (erase blocks) указанного размера (такой как 128 килобайт), каждый из которых делится на некоторое количество страниц page (может быть по 512 или 2048 байт каждая). Каждая страница NAND flash имеет область "out of band" (OOB, "вне диапазона"), содержащую коды коррекции ошибок (Error Correcting Code, ECC) и другие метаданные, обычно 16 байт OOB для каждых 512 байт данных страницы.

Одной из ключевых характеристик NAND flash является более высокий уровень возникновения ошибок по сравнению с NOR flash. В нормальной работе ECC используется для корректирования и детектирования ошибок. Однако блоки NAND могут также стереться и стать невозможными для использования; эти блоки помечаются как "bad" (плохие). Чипы NAND поставляются от производителя с некоторым количеством bad блоков. Чипы с повышенной плотностью используют технологию (MLC), в которой ячейки выходят из строя быстрее, так что поддержка ECC увеличивает свою значимость как способ детектирования блоков, которые скоро испортятся, и помочь сохранить целостность данных с помощью специальных технологий, таких как wear leveling.

Для поддержки ECC используется специальное (встроенное) программное обеспечение. Некоторые контроллеры не поддерживают ECC напрямую; в таких случаях используется программная коррекция ошибок ECC. Другие контроллеры увеличивают скорость вычисления ECC с помощью аппаратуры. Обычными являются аппаратные средства коррекции однобитной ошибки. Контроллеры, поставляемые для более новых чипов MLC могут корректировать 4 или большее количество ошибок для каждых 512 байт данных. Вам нужно убедиться, что все данные, которые Вы записываете с использованием OpenOCD, включают соответствующий вид ECC. Например, это может означать передачу флага oob_softecc, когда записываются данные NAND, или нужно удостовериться, что используется корректный аппаратный режим ECC.

Базовые шаги для использования устройств NAND в включают в себя:

1. Декларация командой nand device. Сделайте это в конфигурационном файле, специфичном для платы, передавая параметры, которые необходимы для контроллера.
2. Конфигурируйте каждое устройство, используя nand probe. Делайте это после того, как связанная target будет настроена - будут выполнены такие действия как его скрипт reset-init или другие скрипты и команды для доступа к этому устройству.
3. Работайте с flash через подкоманду nand. Часто команды для манипулирования flash вводятся человеком, или запускаются через скрипт автоматизированным методом. Общие задачи включают написание бутлоадера, операционную систему или другие данные, необходимые для инициализации или приведения платы в рабочее состояние (de-brick).

Внимание: на момент написания этого текста, поддерживаемые OpenOCD самые большие NAND flash были 2 гигабайта (16 гигабит). Причина в том, что используемые переменные для хранения смещений и длин были только 32-битные. (В некоторых случаях более крупные чипы могут работать, если смещение или длина не больше 0xffffffff, самое большое число для 32-битного unsigned integer.) Некоторые устройства повышенного размера также будут работать, поскольку обычно они состоят из многочиповых модулей с двумя маленькими чипами и индивидуальными сигналами выборки.

14.1. Команды конфигурации NAND

Чипы NAND должны декларироваться в скриптах конфигурации, плюс некоторая дополнительная конфигурация, которая делается после того, как OpenOCD была инициализирована.

nand device name driver target [configparams...] [Config Command]

Декларирует устройство NAND, которое можно читать и записывать после того, как оно будет сконфигурировано через nand probe. В OpenOCD устройства представляют из себя одиночные чипы; это непохоже на некоторые операционные системы, которые управляют несколькими чипами как если бы они были одним устройством повышенной емкости. В некоторых случаях конфигурирование устройства будет активировать дополнительные команды; см. документацию, специфичную для контроллера.

Внимание: эта команда не доступна после завершения инициализации OpenOCD. Используйте это в файлах, специфичных для платы (board config), не интерактивно.

• name ... может использоваться для ссылки на банк NAND в большинстве команд NAND. Может использоваться также номер.
• driver ... идентифицирует драйвер контроллера NAND, связанный с декларированным устройством NAND. См. раздел 14.4. Список драйверов NAND.
• target ... именует target, используемую для выдачи команд контроллером NAND.
• configparams ... контроллеры могут поддерживать, или требовать дополнительных параметров. Для дополнительной информации см. документацию, специфичную для контроллера.

nand list [Command]

Печатает сводку по каждому устройству, которое декларировано через nand device, с нумерацией начиная от 0. Имейте в виду, что не опробованные (un-probed) устройства не показывают детали.

> nand list
#0: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8,
        blocksize: 131072, blocks: 8192
#1: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8,
        blocksize: 131072, blocks: 8192
>

nand probe num [Command]

Пробует (Probe) указанное устройство для определения ключевых характеристик, наподобие их размеров страницы и блока, и сколько блоков оно имеет. Параметр num является значением, показываемым через nand list. Вы можете (успешно) опробовать (probe) устройство перед тем, как сможете использовать его с большинством других команд NAND.

14.2. Очистка (Erasing), чтение (Reading), запись (Writing) NAND Flash

nand dump num filename offset length [oob_option] [Command]

Читает двоичные данные из устройства NAND и записывает их в файл, начиная с указанного смещения. Параметр num является значением, показанным через nand list.

Используйте полный путь для имени filename, так Вы не будете зависеть от каталога, используемого для запуска сервера OpenOCD.

Параметры offset и length должны быть точно кратны размеру страницы устройства. Они описывают регион данных; может быть получен доступ к данным OOB, связанным с каждой такой страницей.

Внимание: во время написания этого текста не сделана коррекция ошибки для читаемых данных, за исключением случая, когда прямой доступ (raw access) был запрещен и нижележащий драйвер контроллера NAND имеет метод read_page, который поддерживает такую коррекцию ошибки.

По умолчанию в указанный файл записываются только данные страницы. Используйте параметр oob_option для сохранения данных OOB:

• нет параметра oob_*.
Выходной файл содержит только данные страницы; OOB отбрасывается.
• oob_raw
В выходном файле чередуются данные страницы и данные OOB; файл по размеру будет больше, чем "length" на размер дополнительных областей, связанных с каждой страницей данных. Имейте в виду, что такой сырой "raw" доступ отличается от того, что подразумевается nand raw_access, который просто управляет тем, что используется ли аппаратный метод доступа.
• oob_only
Выходной файл содержит только чистые данные OOB (raw OOB data), и будет меньше чем "length", поскольку будет содержать только дополнительные области, связанные с каждой страницей данных.

nand erase num [offset length] [Command]

Очищает блоки указанного устройства NAND, начиная с указанного смещения offset и продолжая очистку для length байт. Обе эти величины должны точно быть кратны размеру блока устройства, и регион, на который они указывают, должен полностью умещаться в чипе. Если эти параметры не указаны, то будет полностью очищен весь чип NAND. Параметр num является значением, показанным через nand list.

Внимание: эта команда будет пытаться очистить плохие блоки (bad blocks), когда указано делать это, причем эти блоки возможно были помечены производителем через маркировку плохих блоков. По информации, оставшейся от текущей сессии сервера, nand info все еще будет сообщать о том, что эти блоки "являются" плохими (bad).

nand write num filename offset [option...] [Command]

Записывает двоичные данные из файла в указанное устройство NAND, начиная с указанного смещения offset. Эти страницы должны быть предварительно очищены; при записи Вы не можете поменять биты с нуля на единицу (это делается только при очистке памяти). Параметр num является значением, которое показывает команда nand list.

Параметры offset и length должны быть точно кратны размеру страницы устройства. Все данные из файла будут записаны, и подразумевается, что запись не будет перекрывать последнюю ячейку устройства. Будут записаны только страницы целиком, и любое дополнительное пространство в на последней странице будет заполнено байтами 0xff. (Это относится и к данным OOB, если они будут записаны.)

Внимание: во время написания этого текста bad блоки игнорируются. Таким образом, эта подпрограмма не пропустит bad блоки, и вместо этого попытается записать их. Это может привести к проблемам.

Предоставьте как минимум параметр option. С некоторыми драйверами NAND значение этих параметров может быть изменено, если используется nand raw_access для запрета аппаратного ECC.

• нет параметра oob_*.
Входной файл содержит только данные страниц, которые записываются. Если используется доступ raw, область OOB не будет записана. Иначе нижележащий драйвер контроллера NAND имеет подпрограмму write_page, и эта подпрограмма может записывать OOB с аппаратно вычисленными данными ECC.
• oob_only
Входной файл содержит только чистые данные OOB, которые будут записаны в область OOB. Область данных на каждой странице останется нетронутой. Это может быть опасной опцией, поскольку она может испортить данные ECC. Вам может понадобиться прямой доступ (raw access) для использования этого режима.
• oob_raw
Во входном файле чередуются полезные данные и данные OOB, и обе эти области будут записаны. Если прямой доступ (raw access) разрешен, то сначала записываются данные, затем неизмененные OOB. Иначе, если нижележащий драйвер контроллера NAND имеет подпрограмму write_page, то подпрограмма может модифицировать OOB перед тем, как запишет их, чтобы добавить аппаратно вычисленные данные ECC.
• oob_softecc
В файле есть только данные страницы, которые будут записаны. Данные OOB будут заполнены 0xff, за исключением стандартного 1-битного программного кода ECC, сохраненного в обычных месторасположениях. Вам может понадобиться полный доступ (raw access) для использования этого режима, чтобы предотвратить наложение аппаратного ECC от нижележащего драйвера.
• oob_softecc_kw
В файле есть только данные страницы, которые будут записаны. Данные OOB будут заполнены 0xff, за исключением 4-битного программного ECC, специфичного для boot ROM Marvell Kirkwood SoC-ах. Вам может понадобиться полный доступ (raw access) для использования этого режима, чтобы предотвратить наложение аппаратного ECC от нижележащего драйвера.

nand verify num filename offset [option...] [Command]

Проверяет бинарные данные в файле на соответствие данным, запрограммированным в указанном устройстве NAND, начиная с указанного смещения offset. Параметр num является значением, которое показано командой nand list.

Параметры offset и length должны быть точно кратны размеру страницы устройства. Все данные из файла будут прочитаны и сравнены с содержимым flash, и подразумевается, что данные файла не будут перекрывать последнюю ячейку устройства. Как и для команды nand write, будут проверены только страницы целиком, и любое дополнительное пространство в на последней странице будет заполнено байтами 0xff. (Это относится и к данным OOB, если они будут записаны.)

Те же самые options принимает и nand write, и файл будет обработан просто для генерации буферов, которые будут сравнены с содержимым, полученным от nand dump.

Внимание: Это не будет работать, когда подпрограмма write_page нижележащего драйвера контроллера NAND должна обновить OOB с аппаратно-вычисленной ECC перед тем, как данные записываются. Это ограничение будет удалено в будущем релизе.

14.3. Другие команды NAND

nand check_bad_blocks num [offset length] [Command]

Проверяет маркеры производителя, помечающие плохие секторы на указанном устройстве NAND. Если не предоставлены параметры, будет проверено все устройство целиком; иначе проверка начнется с указанного смещения offset и будет продолжено на length байт. Параметры offset и length должны быть точно кратны размеру страницы устройства, и регион, на который они указывают, должен полностью принадлежать чипу. Параметр num является значением, которое показано командой nand list.

Внимание: перед использованием этой команды Вы должны принудительно включить прямой доступ (raw access) командой nand raw_access enable, чтобы обеспечить, что нижележащий драйвер не будет пытаться наложить аппаратный ECC.

nand info num [Command]

Печатает текущую суммарную информацию от "nand list", плюс для устройств, которые были здесь опробованы также печатается статус для каждого блока. Параметр num является значением, которое показано командой nand list.

nand raw_access num (enable|disable) [Command]

Устанавливает или очищает флаг, влияющий на то как выполняется ввод/вывод страницы (page I/O). Параметр num является значением, которое показано командой nand list.

По умолчанию этот флаг очищен (запрещено), но изменение этого значения не будет оказывать влияния на все устройства NAND. Ключевой фактор - предоставляет или нет нижележащий драйвер методы read_page или write_page. Если эти методы не предоставлены, то установка или сброс флага не имеет значения, любой доступ всегда будет прямым "raw".

Когда эти методы присутствуют, они нормально используются при чтении данных (nand dump или чтение маркеров bad block) или при записи (nand write). Однако разрешение прямого доступа (raw access) установкой флага предотвращает от использования этих методов, при этом отключается аппаратная логика ECC. Это может быть опасной опцией, поскольку запись блоков с неправильными данными ECC может привести к тому, что они будут помечены как bad.

14.4. Список драйверов NAND

Как было указано ранее, команда nand device позволяет использовать опции и поведения, зависящие от драйвера. Некоторые контроллеры также активируются специальными командами, специфичными для определенного контроллера.

at91sam9 [NAND Driver]

Этот драйвер обрабатывает контроллеры NAND, которые имеются в чипах AT91SAM9 компании Atmel. Он имеет 2 дополнительных параметра: адрес чипа NAND и адрес контроллера ECC.

nand device $NANDFLASH at91sam9 $CHIPNAME 0x40000000 0xfffffe800

AT91SAM9 поддерживает аппаратный однобитный ECC. Методы write_page и read_page используется для поддержки этого аппаратного ECC, за исключением того, когда это запрещено командой nand raw_access. Есть 4 дополнительные команды, которые необходимы для полного конфигурирования контроллера NAND AT91SAM9. Два из них необязательны; большинство плат используют одну и ту же разводку ALE/CLE:

    at91sam9 cle num addr_line [Command]

Конфигурирует сигнал адреса, используемый для защелкивания команд. Параметр num является значением, которое показано командой nand list.

    at91sam9 ale num addr_line [Command]

Конфигурирует сигнал адреса, используемый для защелкивания адресов. Параметр num является значением, которое показано командой nand list.

Для следующих двух команд подразумевается, что эти выводы уже правильно сконфигурированы для входа или выхода.

    at91sam9 rdy_busy num pio_base_addr pin [Command]

Конфигурирует вход RDY/nBUSY от устройства NAND. Параметр num является значением, которое показано командой nand list. Параметр pio_base_addr является базовым адресом контроллера PIO и параметр pin является на номер вывода.

    at91sam9 ce num pio_base_addr pin [Command]

Конфигурирует вход разрешения чипа для устройства NAND. Параметр num является значением, которое показано командой nand list. Параметр pio_base_addr является базовым адресом контроллера PIO и параметр pin является на номер вывода.

davinci [NAND Driver]

Этот драйвер поддерживает контроллеры NAND, которые находятся в чипах семейства DaVinci компании Texas Instruments. Он поддерживает три дополнительных параметра: адрес чипа NAND; используемый режим аппаратного ECC (hwecc1, hwecc4, hwecc4_infix); адрес контроллера AEMIF на этом процессоре.

nand device davinci dm355.arm 0x02000000 hwecc4 0x01e10000

Все процессоры DaVinci поддерживают аппаратуру однобитного ECC, и новые процессоры также поддерживают 4-битную аппаратуру ECC. Методы write_page и read_page используются для реализации этих режимов ECC, исключая случай, когда это запрещено командой nand raw_access.

lpc3180 [NAND Driver]

Эти контроллеры требуют дополнительный параметр nand device: тактовую частоту, используемую контроллером.

    lpc3180 select num [mlc|slc] [Command]

Конфигурирует режим контроллера MLC или SLC. MLC реализует аппаратный ECC. Параметр num является значением, которое показано командой nand list.

На момент написания этого текста, драйвер реализует методы write_page и read_page. Использование nand raw_access для запрета этих методов предотвратит использование аппаратного ECC в режиме контроллера MLC, но не может повлиять на поведение SLC.

mx3 [NAND Driver]

Этот драйвер поддерживает контроллер NAND в i.MX31. Драйвер mxc должен работать также для этого чипа.

mxc [NAND Driver]

Этот драйвер поддерживает контроллер NAND, который есть в чипах Freescale i.MX. Драйвер поддерживает v1 (i.MX27 и i.MX31) и v2 (i.MX35). Драйвер принимает 3 дополнительные аргумента, чип (mx27, mx31, mx35), ecc (noecc, hwecc) и опционально если bad block информация должна быть обменена между главной областью и запасной (biswap), по умолчанию выключено.

nand device mx35.nand mxc imx35.cpu mx35 hwecc biswap

    mxc biswap bank_num [enable|disable] [Command]

Включает или выключает переключение bad block информации из главной области, без параметра опрашивает состояние.

orion [NAND Driver]

Эти контроллеры требуют дополнительный параметр устройства nand: адрес контроллера.

nand device orion 0xd8000000

Эти контроллеры не задают любые специализированные команды. На момент написания этой документации их драйверы не имеют методов write_page или read_page, так что команда nand raw_access не меняет поведение драйвера.

s3c2410 [NAND Driver]
s3c2412 [NAND Driver]
s3c2440 [NAND Driver]
s3c2443 [NAND Driver]
s3c6400 [NAND Driver]

Семейство контроллеров S3 C, которое не имеет специальных опций nand device, и не задает никаких специализированных команд. На момент написания этой документации драйверы не имели методов write_page или read_page, так что команда nand raw_access не меняет поведение драйвера.

[15. Команды PLD/FPGA]

Устройства программируемой логики (PLD) и более гибкие FPGA поддерживают программируемую аппаратуру. OpenOCD может поддерживать такие микросхемы. Поскольку PLD обычно имеют ограничения (ячейки менее функциональны, и здесь нет специальных ячеек для памяти или вычислительных задач), они разделяют одинаковую инфраструктуру OpenOCD. И соответственно, и PLD, и FPGA здесь именуются одинаково как PLD.

15.1. Команды, соответствующие конфигурации PLD/FPGA

Как это делается для JTAG TAP, debug target-ов, чипов flash (и NOR, и NAND), OpenOCD поддерживает список PLD, доступных для использования в разных командах. Также каждая такая PLD требует драйвера. К драйверу идет обращение по номеру, показываемому командой pld devices, и новые PLD определяются командой pld device driver_name.

pld device driver_name tap_name [driver_options] [Config Command]

Задает новое устройство PLD, поддерживаемое драйвером driver_name с использованием TAP под именем tap_name. Драйвер может использовать любые опции драйвера для конфигурирования своего поведения.

pld devices [Command]

Выводит список PLD с их номерами.

pld load num filename [Command]

Загружает файл filename в PLD, идентифицированное по номеру num. Формат файла должен быть такой, какой подразумевает драйвер.

15.2. Драйверы PLD/FPGA, их опции и команды

Драйверы могут поддержать опции, специфичные для PLD, для команды pld device, и могут также задать команды, которые можно использовать только с PLD определенного типа.

virtex2 [FPGA Driver]

Virtex-II являются семейством FPGA от компании Xilinx. Для ISC они поддерживают стандарт IEEE 1532. Для определения PLD не используются опции, специфичные для драйвера, и задается одна специфичная для драйвера команда.

    virtex2 read_stat num [Command]

Читает и отображает регистр статуса Virtex-II (STAT) для FPGA номер num.

[16. Общие команды]

Команды, задокументированные в этом разделе, являются командами общего назначения, которые Вы, как человек, можете ввести в консоли и посмотреть на то, что они выведут. Команды типа конфигурации задокументированы в другом месте.

• Источник команд (Source Of Commands). Команды OpenOCD могут появиться в скрипте конфигурации (это обсуждается в другом месте), или могут быть введены человеком, или могут быть предоставлены программно, или через несколько портов TCP/IP.
• От человека (From the human). Человек должен взаимодействовать через интерфейс telnet (порт по умолчанию 4444) или через GDB (порт по умолчанию 3333). Для выдачи команд из сессии GDB используйте команду monitor, например используйте monitor poll для выдачи команды poll. Весь вывод команды poll будет перенаправлен через сессию GDB.
• Машинный интерфейс (Machine Interface) Tcl предназначен для того, чтобы работать как интерфейс с компьютером. Порт TCP по умолчанию 5555.

16.1. Команды для управления сервисом (Daemon Commands)

exit [Command]

Выход из текущей сессии telnet.

help [string] [Command]

Без параметров выводит текст подсказки для всех команд. Иначе печатает каждый текст подсказки (helptext), который содержит указанную строку. Не все команды предоставляют helptext. Команды конфигурации, и команды, которые доступны всегда, помечены явно круглыми скобками. В большинстве случаев нет подобного ограничения; это показывает команды, которые доступны только после завершения стадии конфигурации.

sleep msec [busy] [Command]

Ожидание как минимум msec миллисекунд перед тем, как работа будет возобновлена (resuming). Если в команде указано busy, то произойдет ожидание по занятости (busy-wait) вместо простого засыпания (sleeping). (Этот вариант опции busy строго не рекомендуется использовать.) Полезно в соединении с файлами скриптов (команда script и конфигурация target_name).

shutdown [Command]

Закрыть демона OpenOCD, отключить всех клиентов (GDB, telnet и других).

debug_level [n] [Command]

Отобразить уровень отладки. Если указан n (диапазон 0..3), то установить такой уровень отладки. Это влияет на то, какие сообщения будут посылаться в лог сервера. Уровень 0 только для сообщений об ошибках (error messages); уровень 1 добавляет к выводу предупреждения (warnings); уровень 2 добавляет информационные сообщения; и уровень 3 добавляет сообщения для отладки (debugging messages). По умолчанию активен уровень 2, но он может быть перезадан через командную строку наряду вместе с размещением файла лога (который по умолчанию назначен на стандартный вывод сервера). См. раздел [4. Запуск OpenOCD].

echo [-n] message [Command]

Выводит в лог сообщение с приоритетом пользователя ("user" priority). Выводит message в stdout. Опция "-n" подавляет переход на новую строку. Пример:

echo "Downloading kernel -- please wait"

log_output [filename] [Command]

Перенаправляет вывод лога в файл filename; изначальный канал для вывода лога - stderr.

add_script_search_dir [directory] [Command]

Добавляет директорию directory в путь поиска файла/скрипта.

16.2. Обработка состояния цели (Target State handling)

В этой секции под термином "target" подразумевается CPU, сконфигурированный так, как было показано ранее (см. раздел [11. Конфигурация CPU]). Эти команды, как и большинство команд, неявно ссылаются на текущую target, которая используется для выполнения разных операций. Текущая target может быть изменена командой targets с указанием имени target, которая должна теперь стать текущей target.

reg [(number|name) [value]] [Command]

Дает доступ к одиночному регистру по его имени. Цель target должна быть обычно остановлена (halted) перед тем, как будет разрешен доступ к регистрам ядра CPU. С зависимости от аппаратуры, некоторые регистры могут быть доступны и во время работы программы на target.

Если аргументы команды reg не указаны, то выводятся все регистры, доступные для текущей target, где показаны номер (number), имя (name), размер (size), значение (value) и состояние кэша (cache status). Для допустимых записей (регистров), где это разрешено, показано значение (value); допустимые регистры, которые также "грязные" (dirty, они будут позже записаны обратно), будут соответственно помечены.

Если указаны number/name: отображение значения регистра. Если одновременно указаны и number/name, и value: устанавливает значение регистра. Запись может удерживаться во внутреннем кэше (writeback cache) OpenOCD, то есть установка значения помечает регистр как "грязный" (dirty), вместо того чтобы немедленно обновить значение регистра (flushing) на это значение. Возобновление выполнения процессора (CPU execution, включая выполнение программы по шагам), или другая активация соответствующего модуля приведет к обновлению в регистре этих значений (flush). Ядра могут иметь на удивление много регистров в своей инфраструктуре отладки и трассировки:

> reg
===== ARM registers
(0) r0 (/32): 0x0000D3C2 (dirty)
(1) r1 (/32): 0xFD61F31C
(2) r2 (/32)
...
(164) ETM_contextid_comparator_mask (/32)
>

halt [ms]      [Command]
wait_halt [ms] [Command]

Команда halt сначала отправляет запрос на остановку target, в то время как wait_halt этого не делает. В другом отношении эти две команды работают одинаково: происходит ожидание на ms миллисекунд, или на 5 секунд, если параметр не указан, для target, которая должна быть остановлена (и она должна войти в режим отладки). Указание 0 для параметра ms предотвращает ожидание для OpenOCD.

Внимание: на ядрах ARM, программно использующих операцию ожидания прерывания (wait for interrupt), часто блокируют доступ JTAG, который нужен для команды halt. Это происходит потому, что такая операция также вводит ядро в режим пониженного энергопотребления (low power mode) путем управления тактовой частотой ядра; однако такты ядра нужны для того, чтобы детектировать изменения на шине JTAG. Одним из частичных способов обхода проблемы является использование адаптивного тактирования (adaptive clocking): когда работа ядра прервана на завершении операции, такты JTAG воспринимаются как минимум пока не завершится обработчик прерывания. Однако такой способ обхода проблемы часто нельзя использовать, так как процессор, плата и адаптер JTAG должны все поддерживать adaptive JTAG clocking. Также это не будет работать, пока не будет выдано прерывание. Более полное решение проблемы - не использовать такую операцию, пока работаете с отладчиком JTAG debugger. Окружения выполнения задач (tasking environment) обычно имеют циклы ожидания, где происходит ожидание поступления прерывания. (В старых ядрах за это отвечает сопроцессор; новые ядра имеют инструкцию wfi.) Такие циклы могут быть настроены для удаления операции wait for interrupt ценой увеличения энергопотребления (потому что CPU нуждается в постоянном тактировании).

resume [address] [Command]

Возобновляет выполнение кода target с её текущей позиции остановки, или по опционально указанному адресу, если он предоставлен. OpenOCD будет ждать 5 секунд target для возобновления.

step [address] [Command]

Выполняет одиночный шаг target в текущей позиции кода, или по адресу, если он указан.

reset      [Command]
reset run  [Command]
reset halt [Command]
reset init [Command]

Выполняет жесткий сброс (hard reset) если это возможно, и если возможно использует сигнал SRST. Все заданные target-ы будут сброшены, и события target-а сработают во всей последовательности сброса. Необязательный параметр указывает, что должно произойти после сброса. Если параметр не указан, то будет выполнен reset run. Другие опции не будут работать на всех системах. См. раздел [9. Конфигурация сброса (Reset Configuration)]. Значение опций:

- run запустить программу target.
- halt немедленно остановить target.
- init немедленно остановить target и выполнить скрипт reset-init.

soft_reset_halt [Command]

Запрос на останов цели и выполнение мягкого сброса (soft reset). Это часто используется, когда target не может быть сброшена и остановлена. Цель target после сброса будет отпущена на начало выполнения кода. OpenOCD попытается остановить CPU и затем установить программный счетчик обратно на вектор сброса.
reset vector. К сожалению, выполняемый код может оставить аппаратуру в неизвестном состоянии.

16.3. Утилиты ввода/вывода (I/O Utilities)

Эти команды доступны, когда OpenOCD собрана с опцией --enable-ioutil. Она полезна для встраиваемых целей (embedded targets), особенно для ZY1000. Хосты с операционными системами имеют дополнительные инструменты. Перечисленные здесь команды скорее относятся к операционной системе, чем просто к OpenOCD.

Внимание: есть еще несколько подобных команд.

append_file filename [string]* [Command]

Добавляет параметры string к текстовому файлу filename. За каждой строкой, за исключением последней, будет следовать один пробел. За последней строкой будет идти символ новой строки.

cat filename [Command]

Команда читает текстовый файл и отображает его содержимое.

cp src_filename dest_filename [Command]

Копирует содержимое одного файла src_filename в другой файл dest_filename.

ip [Command]

Здесь нет описания этой команды (см. man операционной системы).

ls [Command]

Здесь нет описания этой команды (см. man операционной системы).

mac [Command]

Здесь нет описания этой команды (см. man операционной системы).

meminfo [Command]

Отображает доступное (свободное) пространство памяти RAM на хосте OpenOCD. Используется в регрессивных скриптах тестирования OpenOCD.

peek [Command]

Здесь нет описания этой команды.

poke [Command]

Здесь нет описания этой команды.

rm filename [Command]

Удаляет (unlink) файл с именем filename.

trunc filename [Command]

Удаляет все данные (очищает файл) в файле filename.

16.4. Команды доступа к памяти

Эти команды позволяют получить доступ к памяти системы обращением к ячейкам выбранного размера. Часто используются для конфигурирования текущей target некоторым особым способом. Например - может потребоваться запись определенных значений в контроллер SDRAM, чтобы разрешить работу SDRAM.

1. Используйте команду targets (во множественном числе), чтобы поменять текущую target.
2. Эти команды устарели в скриптах уровня системы. Пожалуйста используйте синонимы объекта TARGET, чтобы избежать предположений по поводу того, что TAP является текущей target, или по поводу конфигурации MMU.

mdw [phys] addr [count] [Command]
mdh [phys] addr [count] [Command]
mdb [phys] addr [count] [Command]

Отображает содержимое памяти по адресу addr в виде 32-битных слов (mdw), 16-битных полуслов (mdh), или 8-битных байтов (mdb). Когда текущая target имеет MMU, который представлен в системе и активен, параметр addr интерпретируется как виртуальный адрес. Иначе, или если указан необязательный флаг phys, addr интерпретируется как физический адрес. Если указан count, то будет отображено указанное количество единиц памяти. (Если Вы хотите манипулировать данными вместо того, чтобы отображать их, см. примитивы mem2array.)

mww [phys] addr word     [Command]
mwh [phys] addr halfword [Command]
mwb [phys] addr byte     [Command]

Записывает указанное слово (32 бита), полуслово (16 бита) или байт (8-бит) по указанному адресу addr. Когда текущая target имеет MMU, который представлен в системе и активен, параметр addr интерпретируется как виртуальный адрес. Иначе, или если указан необязательный флаг phys, addr интерпретируется как физический адрес.

16.5. Команды загрузки образа (Image loading commands)

dump_image filename address size [Command]

Выводит дамп памяти target начиная с адреса в двоичный файл с именем filename.

fast_load [Command]

Загружает образ в текущую target, сохраненный в память командой fast_load_image. Перед командой fast_load должна быть вызвана команда fast_load_image.

fast_load_image filename address [bin|ihex|elf|s19] [Command]

Обычно Вы должны использовать load_image или загрузку из GDB (load). Однако для тестирования или когда имеет значение трата ресурсов на ввод/вывод (I/O overhead, например если OpenOCD работает на хосте embedded), сохранение образа в память и выгрузка его в target может быть выбрана как метод выгрузки - к примеру, когда есть несколько сессий отладки, когда бинарник не изменяется. Аргументы те же самые, как и у load_image, но образ сохранен в памяти хоста OpenOCD, то есть он не оказывает влияния на target. Этот метод также полезен, когда анализируется быстродействие написанного кода target (profiling, профайлинг) в качестве ввода/вывода (I/O) и профайлинг для target может быть проще выполнен отдельно.

load_image filename address [[bin|ihex|elf|s19] min_addr max_length] [Command]

Загружает образ из файла filename в память target со смещением address относительно адреса загрузки образа. Может быть опционально указан формат файла (bin, ihex, elf или s19). Дополнительно могут быть указаны следующие аргументы: min_addr - игнорировать данные ниже min_addr (это относительно к адресу загрузки target + address), max_length - максимальное количество загружаемых байт.

proc load_image_bin {fname foffset address length } {
    # Загрузка данных в target по адресу из файла fname 
    #  по смещению foffset. Будет загружено по крайней мере
    #  length байт.
load_image $fname [expr $address - $foffset] bin $address $length
}

test_image filename [address [bin|ihex|elf]] [Command]

Отображает секции размеров и адресов образа, как если бы образ filename был загружен в память target начиная с адреса address (по умолчанию 0). Опционально может быть указан формат файла (bin, ihex или elf).

verify_image filename address [bin|ihex|elf] [Command]

Проверят (сравнивает) содержимое образа и памяти target, начиная с адреса address. Опционально может быть указан формат файла (bin, ihex или elf). Сначала будет сделана попытка сравнения с использованием проверки CRC, и если она не совпала, то будет произведено двоичное сравнение.

16.6. Команды точек останова и ожидания (Breakpoint and Watchpoint commands)

CPU часто предоставляют отладку модулей через JTAG, с аппаратной поддержкой для точек останова в коде with (code breakpoint) и точек останова по ожиданию появления данных (data watchpoint). Кроме того CPU почти всегда поддерживают программные точки останова (software breakpoints).

bp [address len [hw]] [Command]

Без указанных параметров команда выводит все активные точки останова (active breakpoints). Иначе в коде будет установлена breakpoint на выполнение кода по адресу address на указанное количество байт. Это будет software breakpoint, если не указано hw (задает установку аппаратной точки останова hardware breakpoint). (См. arm9 vector_catch в секции 17.3.3. Команды, специфичные для ARM9, или xscale vector_catch в секции 17.3.7. Команды, специфичные для XScale, для похожих механизмов, которые не тратят аппаратные точки останова hardware breakpoints.)

rbp address [Command]

Удаляет breakpoint по адресу address.

rwp address [Command]

Удаляет data watchpoint по адресу address.

wp [address len [(r|w|a) [value [mask]]]] [Command]

Без указанных параметров команда выводит все активные watchpoint-ы. Иначе устанавливает data watchpoint на данные от адреса address на указанное количество байт. Точка останова watch point является точкой останова по доступу ("access") за исключением случаев, когда предоставлены параметры r или w, которые задают соответственно watchpoint на чтение (read) или запись (write). Если указано value, то это значение используется для определения того, когда сработает для watchpoint. Значение value может быть предварительно замаскировано mask, чтобы пометить данные, на которые не надо обращать внимание.

16.7. Другие команды

profile seconds filename [Command]

Делает выборки счетчика программы CPU профилирования так быстро, как это возможно, что полезно для статистического неразрушающего профайлинга (non-intrusive stochastic profiling). Сохраняет до 10000 выборок в файл filename, используя "gmon.out".

version [Command]

Отображает строку, идентифицирующую версию этого сервера OpenOCD.

virt2phys virtual_address [Command]

Запрашивает у текущей target данные привязки map указанного виртуального адреса к его соответствующему физическому адресу, и отображает запрошенный результат.

OpenOCD: руководство пользователя, начало
OpenOCD: руководство пользователя, окончание

Добавить комментарий

JComments

Поделиться

Нашли опечатку?

Добавить комментарий