Переместимся сюда с сахары - тут покомфортнее, можно сосредоточится на деталях.
Касательно протокола GDB - он описан в документации по GDB, в исходниках и еще есть
статейка - ее прилагаю. Теперь относительно вигглера - из доступных, сравнительно быстро работающих реализаций - это флешер, я им пользуюсь постоянно, скорость примерно та же,
что и у CrossWorks. Его тоже прилагаю. Еще у атмела был аппликейшн на at91 - программатор флеша через JTAG, т.е. TAP автомат и протокол обмена с ICE уже реализован.

Хорошая статейка на счет GDB. Выкладываю снятое снифером. Это так для общей информации. Это был сеанс работы GDB и OCDemmon с LPC2124. Подключение , загрузка, выполнение, прерывание и пошаговое выполнение. Все сходиться с тем что написано в документации. Теперь буду разбираться со стороны JTAG. Просмоторю исходники флешера - должны помочь. Еще не знаю точно как сделать но есть идея чтобы обслуживание JTAG поделить на модули. Тоесть будет реализация ТАР контролера для ядра АРМ7. Теоретически все процесоры на базе АРМ7 должны будут работать. А дальше реализация конкретного процесора (как дополнительный параметр) ето позволит например писать во флеш и отлаживать и еще получать доступ к портам. Вобщем все что можно будет сделать с процесором через JTAG.

Модульность - безусловно. Если нет аллергии к плюсам, хорошо организован и документирован проект Jelie - там правда для xscale, а у него ICE по другому устроен, нет
выбора цепочки. Я его уже помещал в этой конференции, ну если интересно - могу повторить, есть вариант чуть поновее, но все изменения - добавлена поддержка еще одного контроллера JTAG через USB (базовый вариант - только ezUSB).
Кстати, как вариант - USB в некоторых отношениях предпочтительнее etherbnet-а -
скорость повыше, реализация проще и сейчас уже везде есть.

Просмотрел исходники и вроде все есть. Ели флешер с виглером хорошо работает то значить что ТАР контроллер практически сделан. Нашел исходный проект ТАР контроллера который использован во флешере http://openwince.sourceforge.net/jtag/. В Jelie есть парсер комуникации с ГДБ - так что комлект есть. А на счет УСБ в случае Jelie (http://lapwww.epfl.ch/dev/arm/jelie/index.php кажеться это тот проект ) то помоему и так производительность не выше чем у ОСДемона, потомучто ГДБ подклучен через ТСР. В принципе узкое место это порт принтера. И если ГДБ будет непосредственно работать с JTAG по сети то мне кажеться что это будет гораздо лучшим вариантом. Можно еще один вариант просмотреть - доложить и перекомпилировать ГДБ который непосредственно будет работать с JTAG подключеным через УСБ. А может существуют еще какие нибудь возможности которых я не знаю , чтобы использовать УСБ с ГДБ.

В случае USB параллельный порт не используется - запускается на хосте программы, которая по TCP/IP через локалхост общается с GDB, обрабатвает его протокол и доводит до уровня TAP-автомата, а вот он уже реализуется на ezUSB или еще какой-нибудь малютке, вот с ней и происходит общение через USB.

Тот вариант, что вы предложили - примерно соответствует MPDEMON от макрегора,
у него еще, правда есть подключение через посл. и паралл. порты. На него, кстати, и прошивка имеется, нет только схем.

Через паралл. порт может еще подключатся raven - от того же макрегора, скорость
выше в 5-6 раз, чем у вигглера - за счет реализации низкоуровевых функций JTAG-а
на PLD. Когда я несколько лет назад возился с разными вариантами поддержки вигглеров/
байт-бластеров - обнаружил, что только за счет отточенного алгоритма реализации функций низкого уровня - т.е. временной диаграммы, можно довольно существенно влиять на скорость работы. Но с тех пор объемы кода существенно возросли (с гуями),
и вигглер в любом варианте не устраивает.

Да это я точно написал не то что надо ... понедельник . Я имел ввиду, что в случае Jelie получаеться так GDB->Jelie->USB->target а я думаю над GDB->JTAGIP->target (JTAGIP - это то устройство которое хочу сделать) а виглер мне нужен только для емуляции и отладки кода на РС. Как пойдет перенесу на JTAGIP.

Похоже падало что то, части сообщений не вижу, поэтому повторяю еще раз - помогу оттестировать любой вариант сложнее Wiglera, при условии поддержки GDB для target процессоров AT91RM9200, S3C4530 и некоторых других АРМов.

Еще один кривой демон - gdb-jtag-arm

Motivation
==========
This tool has been created as part of our diploma project:
porting linux 2.6 on the arm9tdmi based microcontroller p2001 on
the evaluation board lpec2001 (http://www.mazbr.de/frames/products.html).
This tool is based on jtag-arm9 by Simon Wood.

Собрался сразу, что подозрительно, jtag-arm связался через вигглер с процессором,
а вот gdb-jtag-arm: GDB remote server - с ним связатся gdb удалось, только когда под
отладчиком его запустил. Впрочем, больше ничего вразумительного получить не удалось,
только порт он мне залочил насмерть и все. Дальше пока не разбирался.

Чем глубже копаю тем больше гимороя видать. Поискал я на гоглях как к этой теме люди подходили. Видно что с такимиже проблемами сталкиваются все кто береться за это дело. Нашел что по этоиу поводу что Torsten Mohr писал http://www.mycgiserver.com/~edgp/str ... автор рррсв. Я так понял что он доходил методом брутал форсе (если так не работает то может по другому). В исходниках вадать что сам не знал сколоко команд НОП на ядро подавать в каких ситуациях. Вот у меня и такая просьба если у кого есть информация как правильно делать останов ядра , востановление регистров, пошаговый режим итд на уровне JTAG то попрошу поделиться информацией. Копал в документации к АРМ но там кокретных примеров нет. Из исходников вытягивать нет смысла потомучто работать вроде будет а понятия почему иммено так не будет.

Не видел раньше эту ссылку - спасибо. Саму переписку - почти все читал, а вот собранного вместе - не было. А что касается использования исходников - другого пути (реального) - не видать. Просто использовать работающие, тогда может что и прояснится. А так - картина в общем очень знакомая - энтузиазм, натиск, охлаждение. Новая итерация. И так - до какого-нибудь конца. Но раз есть работающие под линуксом отладчики с вигглером - CW,
значит дело не в линуксе. Т.е. положительный результат возможен.
Для полноты - со стороны вигглера на PC - я бы порекомендовал еще посмотреть на макрегоре есть ссылка (где-то в FAQ-е) на их древний патч для Linux-GDB, что позволя по их словам использовать вигглер под линуксовым GDB - проверить не удалось, т.к. это чудо
не желало собиратся. Я так подозреваю, примерно на том месте они его и бросили. А в варианте оьдельного девайса - эмулятора JTAG - атмеловский аппликейшн. Тот просто должен работать, пробовать его я не пробовал, но на исходники смотрел - внушаеть.

Если чего-то из перечисленного не удастся быстро найти - так я в своих архивах пороюсь,
должно быть.

Появилась у меня еще одна идея. Определить алгоритмы работы с ядром АРМ через JTAG. Просто я хочу точно разобраться как это работает. Идея была такая чтобы сначало сделать WIGGLER под GDB (это версия 1) а потом если будет работать перенести на встроенную платформу (это версия 2). Но как 1 так и 2 версия это готовая реализация которая скрывает внутри всю функциональность поэтому захотелось мне иметь доступ к низкоуровневым функциям JTAG (пусть это будет версия 0.5) для прокручивания алгоритмов. Вообщем если кому интересно то http://www.mycgiserver.com/~edgp/jarm/. Дошел до считывания регистров и тут оказалось, что не очень удобно вписывать вручную. Поэтому следующим этапом будет реализация програмы которая позволит на ходу исполнять и тестировать алгоритмы (это будет похоже на исполнение скриптов). Как будут готовы и оттестированы алгоритмы будет следующий этап. Прошу ногами не пинать (на линух я пока что перехожу). Хотелось бы узнать как компилируеться проект и если у кого нибудь есть WIGGLER и возможность подключения к какому нибудь процессору (имеется ввиду ARM7) то работает то что пока описано или нет? Вобщем за каждую информацию буду признателен.

Это уже что-то.
Замечания - при попытке собрать утилиту - вот что происходит:
[vs@vs Release]$ make
make: stat:/root/workspace/jarm/include/testarm7tdmi.hpp: Permission denied
make: *** Нет правила для сборки цели `/root/workspace/jarm/include/testarm7tdmi.hpp', требуемой для `src/testarm7tdmi.d'. Останов.

1. root - это администратор, для работы лучше сделать другого юзера, ну я на одном из рабочих столов держу открытую консоль roota - если что срочно надо от его имени запустить, можно и по другому - sudo.
make clean тоже не работает.

А это я запустил готовый jarm, попытался с ним из GDB связатся.
GDB не вяжется, впрочем и не должен.

[vs@vs Release]$ << Start JArm - JTAG debugger driver>>
-------parameters sumary---------
port: 8888
lptname: /dev/parport0
lptdrv: ppdev
---------------------------------
serversocket TEST start ... listen port 8889
Initializing Macraigor Wiggler JTAG Cable on ppdev port /dev/parport0
serversocket GDB start ... listen port 8888
Server: connect from host 127.0.0.1, port 33075.

Все остальное - работает, как описано:

Connected to elfa.ru (127.0.0.1).
Escape character is '^]'.
<<<<< Jarm test server connect >>>>>
jtag_reset
OK
tap_reset
OK
tap_state
tap_state=8:Run_Test_Idle.
tap_instr IDCODE
OK
shove_data 32
output[0]=1F0F0F0F:output[1]=0

ice_write_reg 0 7
OK
^[[A
ice_write_reg 8 0
OK
ice_write_reg 9 0xffffffff
OK
ice_write_reg 10 0
OK
ice_write_reg 11 0xffffffff
OK
ice_write_reg 12 0x100
OK
ice_write_reg 13 0xf7
OK
ice_read_reg 1
ice_reg(1)=9

------ Тут я перезапустил контроллер ----
jtag_reset
OK
tap_reset
OK
ice_read_reg 1
ice_reg(1)=4


Контроллер - от Atmel

Сделал поправку для утилиты (вроде должно собираться) и добавил програмку для прокрутки скриптов (executor). Приготовил пару скриптов для считывания-записи регистров. Алгоритм считывания-записи регистров взял из флешера (newafu-0.2). Пока делал скрипты то оказываеться что возможностей executor не хватает. Буду думать чтобы тут еще сделать. Появлаються интересные моменты. При считывании регистров программный счетчик идет вперед. Я уже гдето это видел. Надо будет подумать как востанавливать программный счетчик и регистр CPSR. И помоему будет проблема с THUMB (при останове и выполнении команд ядра надо будет переводить в режим АРМ а потом назад в THUMB). Вообщем надо будет повозиться. Посмотрю на рррсв может оттуда удасться что нибудь полезное вытащить.

Теперь собирается. И работает.
Думаю, было бы неплохо освобождать порт при выходе - а то при перезапуске
сразу же ругается, что порт уже используется. Приходится подождать, пока сам освободится.

И еще - если в питоновском скрипте первой строкой сделать #!/usr/bin/python,
то он может запускатся сам - ./jarmexecuter.py readreg.js
Скрипты тоже работают, но у меня idcode выдается только при останове процессора.

Привет!
Не знаю, может вы видели уже, но по моему здесь подробно все расписано:
http://www.atmel.com/dyn/resources/prod_do...nts/doc2668.pdf -
Using an AT91EB40A Evaluation Board to Control an AT91 ARM7TDMI® Processor Via the JTAG-ICE Interf (22 pages, updated 01/03)
This application note describes how to use an AT91EB40A Evaluation Board based on the AT91R40008 microcontroller to control an AT91 ARM7TDMI processor via the standard ARM JTAG-ICE Interface.

http://www.arm.com/pdfs/DAI0031C_using_eice.pdf
http://www.arm.com/pdfs/DAI0028A_arm7tdmi_debug.pdf

Оооо не знаю как мне удалось это пропустить. Отличный документ. Много выясняеться но не все. Надо будет поэксперементировать. Но особенно понравилось мне: Restarting the ARM7TDMI core can be difficult ..... ( это конечно шутка ) полное предложение звучит так : Restarting the ARM7TDMI core can be difficult to do because the PC register value must be controlled. Essentially, the core must start at the correct address. Впринципе они писали этот документ на уровне понятия работы флешера к полноценному отладчику еще далеко. Спасибо за линк.