реклама на сайте
подробности

 
 
4 страниц V  < 1 2 3 4 >  
Reply to this topicStart new topic
> Open-source эмулятор для TMS320: DLE500USB, Таки разродился
Raven
сообщение Jun 8 2016, 10:55
Сообщение #31


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987



Цитата(gagel @ Jun 7 2016, 23:43) *
Идеальную картину я себе обрисовал некоторое время назад. Поддержка c55x не только в openocd, но и в gdb (иначе что толку от openocd?) и binutils(?). С одной стороны gcc умеет c6x и gdb тоже, но вот с c55x не сложилось. На этом идеал закончился, потому что реализовать поддержку в gdb хоть и можно (13 лет назад кто-то интересовался этим вопросом в списке рассылок gdb), но точно не в одиночку как хобби.

Поддержать новый CPU в GDB - это да, дело непростое... Но для обозримых времен, похоже, актуальнее будет обеспечить работу с CodeComposer'ом (если он работает с c55x).

Вообще, самым, наверное, ценным в этом проекте является reverse engineering API драйвера - можно просто другие готовые кабели приспосабливать для работы с TI DSP через JTAG.

Цитата(gagel @ Jun 7 2016, 23:43) *
Кстати, openocd пришлось бы перерабатывать: ведь здесь вместо нормального разделения команда по irscan, данные по drscan применяют исключительно irscan.

Тут нужно доисследовать. Разницу в подходе к использованию IR у Техаса я заметил (и тут не OOCD "виноват", а ARM и подавляющее большинство других чипмейкеров), но объем сложности в модификации OOCD -- для меня пока вопрос открытый.

Цитата(gagel @ Jun 7 2016, 23:43) *
Запустить в обособленном режиме через libftdi могу попробовать. Но это даст слишком мало: только читать/писать память и, может, старт/стоп (уже загруженной) программы. Без возможности загрузки программы, без точек останова, CIO printf, Log.printf DSPBIOS,..

Запустить что?

Цитата(gagel @ Jun 7 2016, 23:43) *
Кстати, что ещё было бы интересно (и просто?) - это попробовать с помощью самописной маленькой программки через boundary scan подёргать пин, на котором висит светодиодик. Но вот куда копать?

А вот для этого уже много сделано до нас ;-) Во-первых, есть удобные проприетарные программы с GUI, во-вторых, OpenOCD через самописные скрипты может это делать, и в-третьих, существует проект UrJTAG.
Go to the top of the page
 
+Quote Post
gagel
сообщение Jun 8 2016, 11:33
Сообщение #32





Группа: Участник
Сообщений: 13
Регистрация: 3-06-15
Пользователь №: 86 999



Цитата(Raven @ Jun 8 2016, 12:55) *
Поддержать новый CPU в GDB - это да, дело непростое... Но для обозримых времен, похоже, актуальнее будет обеспечить работу с CodeComposer'ом (если он работает с c55x).

Да, работает wink.gif А то как бы я вообще этим вопросом заинтересовался: есть ещё какие-то IDE для c55x?

Цитата(Raven @ Jun 8 2016, 12:55) *
Вообще, самым, наверное, ценным в этом проекте является reverse engineering API драйвера - можно просто другие готовые кабели приспосабливать для работы с TI DSP через JTAG.

Точно.

Цитата(Raven @ Jun 8 2016, 12:55) *
Тут нужно доисследовать. Разницу в подходе к использованию IR у Техаса я заметил (и тут не OOCD "виноват", а ARM и подавляющее большинство других чипмейкеров), но объем сложности в модификации OOCD -- для меня пока вопрос открытый.

Мне показалось, что как раз у Техаса отклонение от нормы: ведь они не используют DR. Или для чего DR придумали?

Цитата(Raven @ Jun 8 2016, 12:55) *
Запустить что?

Самописную мини-программку для демонстрации, что результаты реверса в принципе работают через libftdi и xds100 на c55x.

Цитата(Raven @ Jun 8 2016, 12:55) *
А вот для этого уже много сделано до нас ;-) Во-первых, есть удобные проприетарные программы с GUI, во-вторых, OpenOCD через самописные скрипты может это делать, и в-третьих, существует проект UrJTAG.

Проприетарные не интересуют в принципе. А есть примеры скриптов для OpenOCD? В UrJTAG последний значимый коммит был почти 2 года назад. Им ещё пользуются? И я так понимаю, что если мне нужно всего один пин дёргать, то всё равно нужно доставать BSDL-файлы? И не может так оказаться, что аналогично с IR/DR Техас по-другому реализовали доступ для boundary scan и OpenOCD снова не в состоянии помочь? Эх, мне бы просто информацию, какую команду в IR послать, какой формат для выбора пина и данных, и всё.
Go to the top of the page
 
+Quote Post
Edmundo
сообщение Jun 8 2016, 12:41
Сообщение #33


Мастер
****

Группа: Свой
Сообщений: 727
Регистрация: 18-02-06
Из: Москва
Пользователь №: 14 474



Прошу прощения за такое безответственное поведение с исходниками, надо сделать над собой волевое усилие, и выложить все, что есть, на github, хотя бы свалку для начала, а потом уже разобрать. Надо пошуршать по старым жёстким дискам.

Вообще заточить все это под GDB -- была у меня такая лихая идея. Но сложность её я не оценивал. А так да, можно было бы тогда отлаживать в прочих IDE, например в Qt Creator.

По драйверам. PTI_*, TRG_* -- это более низкий уровень взаимодествия с железом, и моему разуму он оказался не подвластен. Когда в своё время я обменивался своими мыслями с Сергеем Марковым aka SM, он как раз рекомендовал ломать протокол на более низком уровне, что бы не переписывать высокоуровневые драйвера под каждую платформу. В то время он уже перешёл на светлую сторону Силы под крыло Sauris, поэтому эта тема для него актуальность потеряла, у него уже был доступ к SEPK (или как он там называется). Я пошел-таки своим путем, что позволило мне добиться неплохих результатов по скорости обмена данными (на мой субъективный взгляд).

По эмуляции. Я экспериментировал с тремя семействами: C64хх (не плюс), C55xx, C28xx. Для них удалось реверсить содержание JTAG-цепочек таких распространённых операций как чтение/запись в память/регистры ядра, установка/снятие точек останова, запуск/останов программы и т.п. Не удалось до конца познать суть инициализационных цепочек, а также назначение всех разрядов регистра статуса (я о нем упоминал в статье).

По поводу "подёргать ножкой". Я в boundary scan не силён, для этого действительно есть специальные инструменты, BSDL-описания, в общем с эмуляцией граничное сканирование объединяет лишь одно -- физический интерфейс JTAG. В остальном это весьма разные вещи. По граничному сканированию рекомендую обратиться к знаниям ув. iosifk: http://iosifk.narod.ru/
Вы даже можете пообщаться с ним лично, ранее он бывал на этом форуме.

Ну а в остальном я готов проконсультировать в любых вопросах, на которые знаю/помню ответы. Правда род моей деятельности сменился, поэтому я сейчас от этого несколько далёк laughing.gif


--------------------
شامل
Go to the top of the page
 
+Quote Post
gagel
сообщение Jun 8 2016, 13:01
Сообщение #34





Группа: Участник
Сообщений: 13
Регистрация: 3-06-15
Пользователь №: 86 999



Так, BSDL-файлы есть. UrJTAG не знает XDS100v2. Нашёл патч, собрал UrJTAG. Но и он тоже не хочет работать с Техасом. Наверняка, пытается детектить чип по DR, а там - тишина. А как без успешного detect подсунуть ему инфу про чип и затем послать что-то вроде
Код
instruction EXTEST
shift IR
set signal GPIO(6) out 1
shift DR
set signal GPIO(6) out 0
shift DR

?

Кстати, выходит, всё должно быть очень просто с boundary scan. Если бы тольке не этот IR<->DR.

О, здОрово, что вы зашли!

Цитата(Edmundo @ Jun 8 2016, 14:41) *
Прошу прощения за такое безответственное поведение с исходниками, надо сделать над собой волевое усилие, и выложить все, что есть, на github, хотя бы свалку для начала, а потом уже разобрать. Надо пошуршать по старым жёстким дискам.

Да это было давно, так что и обижаться нельзя. С github или аналогами было бы вообще прелесть!

Цитата(Edmundo @ Jun 8 2016, 14:41) *
Вообще заточить все это под GDB -- была у меня такая лихая идея. Но сложность её я не оценивал. А так да, можно было бы тогда отлаживать в прочих IDE, например в Qt Creator.

Эх, вот тогда была бы полная независимость.

Цитата(Edmundo @ Jun 8 2016, 14:41) *
По драйверам. PTI_*, TRG_* -- это более низкий уровень взаимодествия с железом, и моему разуму он оказался не подвластен. Когда в своё время я обменивался своими мыслями с Сергеем Марковым aka SM, он как раз рекомендовал ломать протокол на более низком уровне, что бы не переписывать высокоуровневые драйвера под каждую платформу. В то время он уже перешёл на светлую сторону Силы под крыло Sauris, поэтому эта тема для него актуальность потеряла, у него уже был доступ к SEPK (или как он там называется). Я пошел-таки своим путем, что позволило мне добиться неплохих результатов по скорости обмена данными (на мой субъективный взгляд).

Да, для вашего подхода, кажется, нужен как раз минимум действий. И раз не заглядывали в это SEPK, то претензий от TI к открытому эмулятору быть не должно?..

Цитата(Edmundo @ Jun 8 2016, 14:41) *
По эмуляции. Я экспериментировал с тремя семействами: C64хх (не плюс), C55xx, C28xx. Для них удалось реверсить содержание JTAG-цепочек таких распространённых операций как чтение/запись в память/регистры ядра, установка/снятие точек останова, запуск/останов программы и т.п. Не удалось до конца познать суть инициализационных цепочек, а также назначение всех разрядов регистра статуса (я о нем упоминал в статье).

Ясно. А второй части статьи не было? Может, в черновиках на старом диске?

Цитата(Edmundo @ Jun 8 2016, 14:41) *
По поводу "подёргать ножкой". Я в boundary scan не силён, для этого действительно есть специальные инструменты, BSDL-описания, в общем с эмуляцией граничное сканирование объединяет лишь одно -- физический интерфейс JTAG. В остальном это весьма разные вещи. По граничному сканированию рекомендую обратиться к знаниям ув. iosifk: http://iosifk.narod.ru/
Вы даже можете пообщаться с ним лично, ранее он бывал на этом форуме.

Спасибо за совет. С boundary scan, вроде, всё должно быть просто, если бы не обнаруженная вами особенность TI DSP обмениваться информацией исключительно через IR, а не, как полагается(?) через IR/DR.

Цитата(Edmundo @ Jun 8 2016, 14:41) *
Ну а в остальном я готов проконсультировать в любых вопросах, на которые знаю/помню ответы. Правда род моей деятельности сменился, поэтому я сейчас от этого несколько далёк laughing.gif

Кардинально (не электроника/программирование)? В любом случае заранее спасибо!
Go to the top of the page
 
+Quote Post
Edmundo
сообщение Jun 8 2016, 13:43
Сообщение #35


Мастер
****

Группа: Свой
Сообщений: 727
Регистрация: 18-02-06
Из: Москва
Пользователь №: 14 474



Цитата(gagel @ Jun 8 2016, 16:01) *
Да, для вашего подхода, кажется, нужен как раз минимум действий. И раз не заглядывали в это SEPK, то претензий от TI к открытому эмулятору быть не должно?..

Нужно перехыватывать все GTI_* функции вместо того, чтобы перехватить парочку низкоуровневых. В этом сложность.
Насколько я помню, лицензионное соглашение CCS не очень приветствует реверс-инжиниринг, так что о лицензионной чистоте можно спорить. Но в остальном да, никаких NDA и прочих ограничений нету. Как мне кажется, TI идёт в сторону либерализации, вон даже бесплатная версия CCS есть, когда во времена v2-v3 мы и помыслить о таком не могли. XDS100 опять же -- полный opensource hardware! Так что сомневаюсь, что они будут преследовать таких вот горе-исследователей wink.gif

Цитата(gagel @ Jun 8 2016, 16:01) *
Ясно. А второй части статьи не было? Может, в черновиках на старом диске?

Нет, до второй статьи руки не дошли. Я вообще думал, что с появлением XDS100 эта тема утратила актуальность не только для меня. Видать, ошибался rolleyes.gif Да и процессоры сейчас пошли сплошь многоядерные, а как там производится эмуляция -- тёмный лес для меня.

Цитата(gagel @ Jun 8 2016, 16:01) *
Спасибо за совет. С boundary scan, вроде, всё должно быть просто, если бы не обнаруженная вами особенность TI DSP обмениваться информацией исключительно через IR, а не, как полагается(?) через IR/DR.

Как мне кажется, в режиме boundary scan используются как IR, так и DR. Это в режиме эмуляции задействован только IR. Тут надо анализировать BDSL-описание на конкретный камень. Но возможно, что ошибаюсь, ибо не вникал глубоко.
CCS действительно определяет тип процессора по информации в статусном регистре который считывает в узле IR автомата состояний JTAG. Но так же ли это делается в режиме boundary scan -- не ведаю.

Цитата(gagel @ Jun 8 2016, 16:01) *
Кардинально (не электроника/программирование)?

Не сильно кардинально, но электроника и программирование свелись к минимуму, однако в рамках хобби остались по-любому biggrin.gif


--------------------
شامل
Go to the top of the page
 
+Quote Post
Raven
сообщение Jun 8 2016, 18:55
Сообщение #36


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987



Да, страничка по XDS100 действительно дает много новой интересной информации. Но, если я правильно понял из беглого ознакомления, раскрывается только HW JTAG-кабеля (притом, имеющего целый ряд ограничений по функционалу), а протокол общения с ним (самое вкусное :-)) - это пока Техас оберегает от "грязных хакерских ручек".

Так что ценность RE интерфейса драйвера только подтверждается. Нужно будет просто еще дальше пройти, до полной победы ;-)

По Boundary Scan. Это стандартная вещь JTAG'а, и если уж она поддерживается данным TAP'ом, то можно брать BSDL, анализировать его и дрыгать ножкой. Другое дело, что в чипе может быть и несколько TAP'ов (например, 1 для BSCAN, другой - для OCD). Но об этом тоже можно разузнать и работать с нужным.

Цитата(gagel @ Jun 8 2016, 16:01) *
Так, BSDL-файлы есть. UrJTAG не знает XDS100v2. Нашёл патч, собрал UrJTAG. Но и он тоже не хочет работать с Техасом. Наверняка, пытается детектить чип по DR, а там - тишина. А как без успешного detect подсунуть ему инфу про чип и затем послать что-то вроде

Да нет, особенность работы Техасовского OCD здесь ни при чем - идентификация должна поддерживаться стандартно, путем вычитывания IDCODE. Это любой, кто назвался IEEE 1149.1 TAP'ом, должен делать единообразно. Просто UrJTAG, конечно же, не знает про XDS100 - во времена последнего обновления UrJTAG еще, поди, и XDS100 не было sm.gif. Но для BSCAN он нам и не нужен. А нужен любой другой кабель, знакомый UrJTAG'у. У вас что есть, помимо XDS100? Вот здесь список поддерживаемых кабелей: список.

Можете выложить BSDL-файлы чипа, о котором идет речь? Надо взглянуть.

И еще. Если мы начинаем совместно что-то исследовать, то неплохо бы хотя бы в какой-то степени синхронизировать программно-аппаратный инструментарий. Конкретно на данный момент - надо бы и мне собрать UrJTAG. Если не сложно, не поделитесь описанием проблем при сборке, патчем и т.п. ? Чтобы быстрей дело пошло...

Полной синхронизации в ближайшее время пока не будет, конечно (например, TMS'ов у меня ни в каком виде под руками пока нет), но для первых шагов оно и необязательно. Зато есть некоторое знание JTAG'остроения и RTL-design'а (включая FPGA), что сейчас важнее.
Go to the top of the page
 
+Quote Post
gagel
сообщение Jun 9 2016, 02:47
Сообщение #37





Группа: Участник
Сообщений: 13
Регистрация: 3-06-15
Пользователь №: 86 999



Цитата(Raven @ Jun 8 2016, 20:55) *
Да, страничка по XDS100 действительно дает много новой интересной информации. Но, если я правильно понял из беглого ознакомления, раскрывается только HW JTAG-кабеля (притом, имеющего целый ряд ограничений по функционалу), а протокол общения с ним (самое вкусное :-)) - это пока Техас оберегает от "грязных хакерских ручек".

Вообще, xds100v2 и стандартная платка с ft2232h - это как найдите 7 отличий. Или там есть всё же какое-то принципиальное отличие?

Цитата(Raven @ Jun 8 2016, 20:55) *
Так что ценность RE интерфейса драйвера только подтверждается. Нужно будет просто еще дальше пройти, до полной победы ;-)

По Boundary Scan. Это стандартная вещь JTAG'а, и если уж она поддерживается данным TAP'ом, то можно брать BSDL, анализировать его и дрыгать ножкой. Другое дело, что в чипе может быть и несколько TAP'ов (например, 1 для BSCAN, другой - для OCD). Но об этом тоже можно разузнать и работать с нужным.

Да, вот тут интересно.

Цитата(Raven @ Jun 8 2016, 20:55) *
Да нет, особенность работы Техасовского OCD здесь ни при чем - идентификация должна поддерживаться стандартно, путем вычитывания IDCODE. Это любой, кто назвался IEEE 1149.1 TAP'ом, должен делать единообразно. Просто UrJTAG, конечно же, не знает про XDS100 - во времена последнего обновления UrJTAG еще, поди, и XDS100 не было sm.gif. Но для BSCAN он нам и не нужен. А нужен любой другой кабель, знакомый UrJTAG'у. У вас что есть, помимо XDS100? Вот здесь список поддерживаемых кабелей: список.

Кроме xds100v2 есть стандартная платка ft2232h и STM Discovery-F4 (паяльника нет). Я читал, что IDCODE - это сходу где угодно. Благодаря этому вообще находят нужные JTAG-пины. Так что очень странно, что оно пока не получается с C55x, когда пины известны. Разве что инициализация этого xds100v2 может быть причиной?

Цитата(Raven @ Jun 8 2016, 20:55) *
Можете выложить BSDL-файлы чипа, о котором идет речь? Надо взглянуть.

Вот тут они в свободном доступе: 5502 и 5509a. Я пользуюсь ezdsp5502, там xds100v2 встроенный. Иногда есть доступ к 5509a (с xds100v2-кабелем). Кстати, BSDL у 5509a выглядит более подробным.

Цитата(Raven @ Jun 8 2016, 20:55) *
И еще. Если мы начинаем совместно что-то исследовать, то неплохо бы хотя бы в какой-то степени синхронизировать программно-аппаратный инструментарий. Конкретно на данный момент - надо бы и мне собрать UrJTAG. Если не сложно, не поделитесь описанием проблем при сборке, патчем и т.п. ? Чтобы быстрей дело пошло...

Проблем со сборкой не было. Патч брал здесь: XDS100 для UrJTAG. Собирал под Debian testing последнюю svn-ревизию 2052 из git'а:
Код
git clone git://git.code.sf.net/p/urjtag/git urjtag-git


Цитата(Raven @ Jun 8 2016, 20:55) *
Полной синхронизации в ближайшее время пока не будет, конечно (например, TMS'ов у меня ни в каком виде под руками пока нет), но для первых шагов оно и необязательно. Зато есть некоторое знание JTAG'остроения и RTL-design'а (включая FPGA), что сейчас важнее.

Интересно, есть ли они вообще ещё у кого-то или C55x - уже совсем антиквариат?
Go to the top of the page
 
+Quote Post
Raven
сообщение Jun 9 2016, 13:34
Сообщение #38


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987



Цитата(gagel @ Jun 9 2016, 05:47) *
Вообще, xds100v2 и стандартная платка с ft2232h - это как найдите 7 отличий. Или там есть всё же какое-то принципиальное отличие?

Я, признаться, пока на внутренности XDS100 не смотрел. Если они на FT2232H - тем лучше.

Цитата(gagel @ Jun 9 2016, 05:47) *
Кроме xds100v2 есть стандартная платка ft2232h и STM Discovery-F4 (паяльника нет).

Стандартная плата ft2232h - тоже хорошо, будет дублером для перепроверок. Если на ней есть header'ные контакты - то соединения можно будет делать и без паяльника, с помощью готовых оконцованных проводочков. С STM Discovery я пока, как ни странно, дела не имел, и поэтому для меня он в качестве инструмента пока отодвигается в конец списка. А вот если для вас он - старый добрый друг, то вполне может сгодится на каком-то этапе (с микроконтроллером какие-то итерации исследований/тестов могут быть быстрее).

Цитата(gagel @ Jun 9 2016, 05:47) *
Я читал, что IDCODE - это сходу где угодно. Благодаря этому вообще находят нужные JTAG-пины. Так что очень странно, что оно пока не получается с C55x, когда пины известны. Разве что инициализация этого xds100v2 может быть причиной?

Взглянул на оба BSDL-файла. Очень интересно. Факты таковы:
1) У 5502 и 5509, похоже, принципиально разный интерфейс к OCD-функционалу. 5502 предполагает работу с использованием "длинного" 38-битового IR, а 5509 выглядит в этой части более похожим на нынешний OCD-мейнстрим со сравнительно "коротким" IR (у 5509 - 6 бит).

2) 5502, как можно догадаться по номеру, древнее 5509, и НЕ ПОДДЕРЖИВАЕТ IDCODE инструкцию (это из BSDL видно). Давненько такое в мои руки не попадало sm.gif Соответственно, автоматические процедуры распознавания устройств в JTAG-цепочке будут упираться лбом в 5502. Что потребует какого-то ручного разъяснения для них, кто есть кто. 5509 поддерживает IDCODE (0x0805002F).

3) Чтобы их JTAG-пины подключились к TAP'у и заработали именно в качестве JTAG-интерфейса (а не обслуживали factory test mode), нужно, чтобы в момент положительного фронта TRSTn (т.е., в момент выхода из Test Reset) на пинах EMU0 и EMU1 были определенные уровни: 0b11 для 5502, и 0b00 для 5509. Возможно, на плате все уже для этого сделано и намертво притянуто к нужным уровням, но проверить не помешает (если будут проблемы).

Цитата(gagel @ Jun 9 2016, 05:47) *
Проблем со сборкой не было. Патч брал здесь: XDS100 для UrJTAG. Собирал под Debian testing последнюю svn-ревизию 2052 из git'а:
Код
git clone git://git.code.sf.net/p/urjtag/git urjtag-git

Понял. Я буду начинать с CygWin'а. Кстати, вы собирали HEAD или TAG_0-10-0?

Цитата(gagel @ Jun 9 2016, 05:47) *
Интересно, есть ли они вообще ещё у кого-то или C55x - уже совсем антиквариат?

Настолько древние? Ладно, лишь бы платы были исправными, процы поддерживались CCS и была документация sm.gif.
Go to the top of the page
 
+Quote Post
gagel
сообщение Jun 10 2016, 01:11
Сообщение #39





Группа: Участник
Сообщений: 13
Регистрация: 3-06-15
Пользователь №: 86 999



Цитата(Raven @ Jun 9 2016, 15:34) *
Я, признаться, пока на внутренности XDS100 не смотрел. Если они на FT2232H - тем лучше.

Стандартная плата ft2232h - тоже хорошо, будет дублером для перепроверок. Если на ней есть header'ные контакты - то соединения можно будет делать и без паяльника, с помощью готовых оконцованных проводочков. С STM Discovery я пока, как ни странно, дела не имел, и поэтому для меня он в качестве инструмента пока отодвигается в конец списка. А вот если для вас он - старый добрый друг, то вполне может сгодится на каком-то этапе (с микроконтроллером какие-то итерации исследований/тестов могут быть быстрее).

Ну, я не совсем электронщик - так что друг он не старый. Но проводки есть. Разве что с платой ezdsp5502 они бесполезны, т.к. в отличие от STM Техас не предусмотрели возможность подключения внешнего отладчика, только впаянный. А с платой 5509a я не могу так свободно экспериментировать: только с имеющимся xds100v2-кабелем.

Цитата(Raven @ Jun 9 2016, 15:34) *
Взглянул на оба BSDL-файла. Очень интересно. Факты таковы:
1) У 5502 и 5509, похоже, принципиально разный интерфейс к OCD-функционалу. 5502 предполагает работу с использованием "длинного" 38-битового IR, а 5509 выглядит в этой части более похожим на нынешний OCD-мейнстрим со сравнительно "коротким" IR (у 5509 - 6 бит).

Хочется верить, что факты, а не ещё не исправленные баги, как:
Цитата
5502:
BSDL Revision : 1.1 - Changed Inst length from 6 to 38 bits.

И, кстати, не смотря на 38 бит, всё равно Edmundo обнаружил, что слать надо 54, а, значит, и устанавливать irlen в 54.

Цитата(Raven @ Jun 9 2016, 15:34) *
2) 5502, как можно догадаться по номеру, древнее 5509, и НЕ ПОДДЕРЖИВАЕТ IDCODE инструкцию (это из BSDL видно). Давненько такое в мои руки не попадало sm.gif Соответственно, автоматические процедуры распознавания устройств в JTAG-цепочке будут упираться лбом в 5502. Что потребует какого-то ручного разъяснения для них, кто есть кто. 5509 поддерживает IDCODE (0x0805002F).

Как-то я этим номерам не очень доверяю, кто из них древнее. Хотя IDCODE и опциональна, но всё равно не верится, чтобы она была не реализована. Это же просто беспрецедентно за всю историю развития UrJTAG и OpenOCD!

Цитата(Raven @ Jun 9 2016, 15:34) *
3) Чтобы их JTAG-пины подключились к TAP'у и заработали именно в качестве JTAG-интерфейса (а не обслуживали factory test mode), нужно, чтобы в момент положительного фронта TRSTn (т.е., в момент выхода из Test Reset) на пинах EMU0 и EMU1 были определенные уровни: 0b11 для 5502, и 0b00 для 5509. Возможно, на плате все уже для этого сделано и намертво притянуто к нужным уровням, но проверить не помешает (если будут проблемы).

Так для отладки и для boundary scan разные условия для этих пинов? И т.к. xds100v2 предназначен в первую очередь для отладки, не окажется, что там пины намертво так притянуты, что нельзя выбрать нужный для скана режим? Вот проверить все эти соответствия на схеме с описаниями и таймингами и не запутаться для меня сложновато. Надеюсь, к ним есть программный доступ через libftdi.

Цитата(Raven @ Jun 9 2016, 15:34) *
Понял. Я буду начинать с CygWin'а. Кстати, вы собирали HEAD или TAG_0-10-0?

TAG_0-10-0 - это, наверное, релиз 0.10, вышедший 7 лет назад. А HEAD - это только указатель. Собирал я git master (основная ветка, где, как правило, ведётся разработка). Сам UrJTAG разрабатывается в svn, а git - это только зеркало. Поэтому в логе можно видеть текущую svn-ревизию (git-svn-id: ... trunk@2052 ...):
Код
$ git log -1
commit bac6b34d8e278df25b178ea929d2c41ba6a146e5
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Sun Oct 11 04:57:45 2015 +0000

    ignore .dirstamp files
    
    git-svn-id: svn://svn.code.sf.net/p/urjtag/svn/trunk@2052 b68d4a1b-bc3d-0410-92ed-d4ac073336b7



Цитата(gagel @ Jun 10 2016, 02:45) *
Надеюсь, к ним есть программный доступ через libftdi.

Так, глянул на ezdsp5502_Schematics_RevC.pdf. EMU0 и EMU1 пулапнуты. Значит, TAP и для дебага, и для boundary scan - один и тот же. И значит, нет доступа только к factory test, что и не нужно. Да и с libftdi, значит, меньше ошибок будет.

А вот для 5509a - требования с точностью до наоборот: пины должны быть заземлены для boundary scan.

Чтобы не запутаться:
Цитата
5502
============
EMU0 (I/O/Z)
-----
Emulator 0 pin. When nTRST is driven low, EMU0 must be high for activation of the
nOFF condition. When nTRST is driven high, EMU0 is used as an interrupt to or from
the emulator system and is defined as I/O by way of the IEEE standard 1149.1 scan
system.
The EMU0 and EMU1/nOFF pins must be pulled up when an emulator is not
connected. Internal pullups have been included for the purpose. If the user chooses
to disable these pullups through the XBCR, external pullup resistors must be added
to these two pins.

EMU1/nOFF (I/O/Z)
-----
Emulator 1 pin/disable all outputs. When nTRST is driven high, EMU1/nOFF is used
as an interrupt to or from the emulator system and is defined as I/O by way of IEEE
standard 1149.1 scan system. When nTRST is driven low, EMU1/nOFF is configured
as nOFF. The EMU1/nOFF signal, when active (low), puts all output drivers into the
high-impedance state. Note that nOFF is used exclusively for testing and emulation
purposes (not for multiprocessing applications). Therefore, for the nOFF condition, the
following apply:
• nTRST = low,
• EMU0 = high,
• EMU1/nOFF = low
The EMU0 and EMU1/nOFF pins must be pulled up when an emulator is not
connected. Internal pullups have been included for the purpose. If the user chooses
to disable these pullups through the XBCR, external pullup resistors must be added
to these two pins.


Цитата
5509a
===========

EMU0 (I/O/Z)
-----
Emulator 0 pin. When nTRST is driven low, EMU0 must be high for
activation of the nOFF condition. When nTRST is driven high, EMU0 is used
as an interrupt to or from the emulator system and is defined as I/O by way
of the IEEE standard 1149.1 scan system.

EMU1/nOFF (I/O/Z)
-----
Emulator 1 pin/disable all outputs. When nTRST is driven high, EMU1/nOFF
is used as an interrupt to or from the emulator system and is defined as I/O
by way of IEEE standard 1149.1 scan system. When nTRST is driven low,
EMU1/nOFF is configured as nOFF. The EMU1/nOFF signal, when
active-low, puts all output drivers into the high-impedance state. Note that
nOFF is used exclusively for testing and emulation purposes (not for
multiprocessing applications). Therefore, for the nOFF condition, the
following apply: nTRST = low, EMU0 = high, EMU1/nOFF = low

Интересно, там ещё и прерывания есть.

Кстати, для сборки UrJTAG нужно иметь (среди прочих зависимостей) libusb-1.0 и libftdi (или 0.20 или 1.x). Я пока пробую с 0.20.

Сообщение отредактировал gagel - Jun 10 2016, 09:10
Go to the top of the page
 
+Quote Post
Raven
сообщение Jun 10 2016, 11:39
Сообщение #40


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987



Цитата(gagel @ Jun 10 2016, 04:11) *
Хочется верить, что факты, а не ещё не исправленные баги, как:

Будем надеяться. Но в отношении 5509 сомневаюсь - слишком много в его BSDL других зявязок на IR-Length=6 (например, собственно коды инструкций). К тому же файл для 5502 все же содержит уже устоявшуюся информацию (за столько-то лет) - errata в нем уже учтена.

Цитата(gagel @ Jun 10 2016, 04:11) *
И, кстати, не смотря на 38 бит, всё равно Edmundo обнаружил, что слать надо 54, а, значит, и устанавливать irlen в 54.

А вот с этим будем разбираться - кто чего куда там добавляет в цепочку тихой сапой sm.gif.

Цитата(gagel @ Jun 10 2016, 04:11) *
Как-то я этим номерам не очень доверяю, кто из них древнее. Хотя IDCODE и опциональна, но всё равно не верится, чтобы она была не реализована. Это же просто беспрецедентно за всю историю развития UrJTAG и OpenOCD!

Да нет, это вполне по стандарту (он такое допускает), но совсем не комильфо для сегодняшнего дня.

Цитата(gagel @ Jun 10 2016, 04:11) *
А вот для 5509a - требования с точностью до наоборот: пины должны быть заземлены для boundary scan.

Чтобы не запутаться:

Это откуда цитаты?

Цитата(gagel @ Jun 10 2016, 04:11) *
Интересно, там ещё и прерывания есть.

Насколько я понимаю, это способ дернуть кабель-адаптер, чтобы сообщить ему о произошедших debug-событиях. Довольно обычная вещь в OCD системах.

Цитата(gagel @ Jun 10 2016, 04:11) *
Кстати, для сборки UrJTAG нужно иметь (среди прочих зависимостей) libusb-1.0 и libftdi (или 0.20 или 1.x). Я пока пробую с 0.20.

Я недавно проходил подобным путем при сборке OOCD, так что многое уже на месте. Но с наскока под CygWin не собралось. Еще немного помучаю его, и если за выходные не заведется - попробую под Linux.
Go to the top of the page
 
+Quote Post
gagel
сообщение Jun 12 2016, 18:36
Сообщение #41





Группа: Участник
Сообщений: 13
Регистрация: 3-06-15
Пользователь №: 86 999



Цитата(Raven @ Jun 10 2016, 13:39) *
Это откуда цитаты?

Из официальной документации: 5502, 5509a.

Edmundo,
я закончил черновик so-прокси (so - это shared object типа вин-DLL): т.е. используя найденные вами заголовки функций я набросал прокси, подменил оригинальную so'шку, а в прокси дёргаю функции из оригинальной so'шки один в один. Первое, что сделала CCS 6.1.3 - упала. Вылечить удалось быстро:
Код
- char *GTI_GETERRSTR_EX3(void)
+ char* GTI_GETERRSTR_EX3(void *pHandle, unsigned long *pParam1, unsigned long *pParam2, unsigned long *pParam3, unsigned long *pParam4, unsigned long *pParam5, unsigned long *pParam6, unsigned long *pParam7, char *str1, int unkn1, char* str2, int unkn2)

Для прокси это подошло, но как разобраться, что это за параметры для собственной реализации? Вот так это выглядит в логе:
Код
0xC9A5DB40 5855241 3 C55xx GTI C: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000000, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000000, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 )
0xC9A5DB40 5855241 3 C55xx GTI R: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000002, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000008, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 ) = 0x00000000


И ещё появились(?) как минимум несколько функций, которые не только присутствуют в libtixds55x.so, но и вызываются CCS: GTI_GET_NUM_RESETS, GTI_GET_RESET_INFO, GTI_RESET_EX:
Код
0xC9A5DB40 5851429 3 C55xx GTI C: GTI_GET_NUM_RESETS( 0x0xca953838 )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_NUM_RESETS( 0x0xca953838 ) = 0x00000001

Тут можно предположить, что просто есть один вид RESET'а, значит возвращается 1 (но int или unsigned int)?

Код
0xC9A5DB40 5851430 3 C55xx GTI C: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? ) = 0x00000000

Тут выбирается RESET номер 1 (т.е. 0) и получается указатель на инфу о RESET'е?

Код
0xC9A5DB40 5855123 3 C55xx GTI C: GTI_RESET_EX( 0x0xca953838, 0x00000000 )
0xC9A5DB40 5855140 3 C55xx GTI R: GTI_RESET_EX( 0x0xca953838, 0x00000000 ) = 0x00000000

Тут вызывается RESET номер 1 (т.е. 0) и статус 0 (нет ошибки)?

И есть ещё несколько функций, которые есть в бинарнике, но я пока не заметил их вызова из CCS:
Код
GTI_QUERY_INTERFACE
GTI_BLOCK_RESET
GTI_GET_WAIT_IN_RESET_MODE
GTI_SET_WAIT_IN_RESET
GTI_BP_TEST
GTI_STAT_EX2


Ещё, кстати, RTDX уже некоторое время как объявлен устаревшим. Но почему? Я так и не нашёл официального объяснения и предложения по замене. Так вот в 6.1.1 или 6.1.2 RTDX-функции были выброшены из so'шки. А в DSPBIOS они до сих пор место занимают. Вам доводилось их использовать? Интересно, можно ли их воскресить? Хотя, скорее всего, чисто теоретически.

Сообщение отредактировал gagel - Jun 12 2016, 18:37
Go to the top of the page
 
+Quote Post
Raven
сообщение Jun 16 2016, 10:27
Сообщение #42


Местный
***

Группа: Свой
Сообщений: 479
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987



В продолжение линии BSCAN для 5502, 5509а:
- нельзя ли выложить логи подключения UrJTAG для того и другого? В частности, хочется увидеть, как воспринимается отсутствие IDCODE в 5502 и (надеюсь) его присутствие в 5509а.
Go to the top of the page
 
+Quote Post
gagel
сообщение Jun 19 2016, 18:40
Сообщение #43





Группа: Участник
Сообщений: 13
Регистрация: 3-06-15
Пользователь №: 86 999



Raven,
да urjtag (как и oocd) не справляется даже с самым первым шагом: определение IRLEN:
CODE
jtag> debug all
debug: src/global/parse.c:167 urj_parse_line(): Return in urj_parse_line r=0 line={debug all}
jtag> cable JTAGv5
src/tap/usbconn/libftdi.c:336 usbconn_ftdi_connect(): Connected to libftdi driver.
src/tap/cable/ft2232.c:1203 ft2232_jtagv5_init(): JTAGv5: JTAG Mode Initialization OK!
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: UNKNOWN_STATE
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: TEST_LOGIC_RESET
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:0)=> RUN_TEST_IDLE
debug: src/global/parse.c:167 urj_parse_line(): Return in urj_parse_line r=0 line={cable JTAGv5}
jtag> detect
debug: src/tap/state.c:59 urj_tap_state_dump(): tap_state: TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:1)=> TEST_LOGIC_RESET
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: TEST_LOGIC_RESET =(tms:0)=> RUN_TEST_IDLE
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: RUN_TEST_IDLE =(tms:1)=> SELECT_DR_SCAN
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: SELECT_DR_SCAN =(tms:1)=> SELECT_IR_SCAN
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: SELECT_IR_SCAN =(tms:0)=> CAPTURE_IR
debug: src/tap/state.c:66 urj_tap_state_dump_2(): tap_state: CAPTURE_IR =(tms:0)=> SHIFT_IR
warning: src/tap/discovery.c:120 urj_tap_detect_register_size(): TDO seems to be stuck at 1
debug: src/global/parse.c:167 urj_parse_line(): Return in urj_parse_line r=1 line={detect}
jtag>

С 5509a ситуация та же. Я уже начал копаться в исходниках, чтобы помочь ему. Посмотрим, что выйдет.

А тем временем после написания декодера ftdi jtag, анализа его логов я написал минимальную программку - и ура! я могу считывать состояния всех пинов! Но не дёргать эти пины. Тут есть пара вопросов: инструкции PRELOAD нет, есть только SAMPLE. Остаётся пробовать её. Итак, делаю:
... --> SHIFT-IR --> (SAMPLE) --> ... --> SHIFT-DR --> (все нули) --> ... --> SHIFT-IR --> (EXTEST) --> ... --> SHIFT-DR (set control=1, value=0) --> ... --> SHIFT-IR (EXTEST) --> ... --> RUN-TEST-IDLE.

Реакция есть: выполнение загруженной программы останавливается. Но светодиодик не загорается (value = 0). Я правильно понял, что для установки значения нужно установить соответствующий ему control bit в 1? Для 5502:
Код
   "214  (bc_1,                   *,   control,  1)," &
   "215  (bc_1,                  XF,   output3,  X,     214,   1,  Z)," &

И ещё я не понял, для чего это в 5502:
Код
    attribute INSTRUCTION_CAPTURE of TMX320VC5502 : entity is  "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX01";


Сообщение отредактировал gagel - Jun 19 2016, 19:02
Go to the top of the page
 
+Quote Post
gagel
сообщение Jun 19 2016, 20:47
Сообщение #44





Группа: Участник
Сообщений: 13
Регистрация: 3-06-15
Пользователь №: 86 999



Всё, заработало!
... --> SHIFT-IR --> (SAMPLE) --> ... --> SHIFT-DR --> (все нули) --> ... --> SHIFT-IR --> (EXTEST) --> ... --> SHIFT-DR (set control=0, value=1) --> ... --> RUN-TEST-IDLE.
Нужно было только установить value (output3), а не и control тоже. Теперь только вопрос: а зачем этот control?
И ещё не ожидал, что при SAMPLE value=0 светодиодик горит, а при EXTEST для этого нужно писать 1. Я думал, что значение всего BSR можно один к одному использовать и для SAMPLE, и для EXTEST, т.е. содержимое интерпретируется одинаково, а не как пока получается: по-разному.

Сообщение отредактировал gagel - Jun 19 2016, 20:58
Go to the top of the page
 
+Quote Post
Edmundo
сообщение Jun 20 2016, 15:48
Сообщение #45


Мастер
****

Группа: Свой
Сообщений: 727
Регистрация: 18-02-06
Из: Москва
Пользователь №: 14 474



Цитата(gagel @ Jun 12 2016, 21:36) *
Edmundo,
я закончил черновик so-прокси (so - это shared object типа вин-DLL): т.е. используя найденные вами заголовки функций я набросал прокси, подменил оригинальную so'шку, а в прокси дёргаю функции из оригинальной so'шки один в один. Первое, что сделала CCS 6.1.3 - упала. Вылечить удалось быстро:
Код
- char *GTI_GETERRSTR_EX3(void)
+ char* GTI_GETERRSTR_EX3(void *pHandle, unsigned long *pParam1, unsigned long *pParam2, unsigned long *pParam3, unsigned long *pParam4, unsigned long *pParam5, unsigned long *pParam6, unsigned long *pParam7, char *str1, int unkn1, char* str2, int unkn2)

Для прокси это подошло, но как разобраться, что это за параметры для собственной реализации? Вот так это выглядит в логе:
Код
0xC9A5DB40 5855241 3 C55xx GTI C: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000000, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000000, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 )
0xC9A5DB40 5855241 3 C55xx GTI R: GTI_GETERRSTR_EX3( 0x0xca953838, *0x0xc9a5c640 = 0x00000000, *0x0xc9a5c638 = 0x00000000, *0x0xc9a5c644 = 0x00000000, *0x0xc9a5c648 = 0x00000002, *0x0xc9a5c64c = 0x00000000, *0x0xc9a5c650 = 0x00000008, *0x0xc9a5c654 = 0x00000000, "", 0x00000040, "", 0x00000400 ) = 0x00000000

Понять суть параметров этих *_EX, *_EX2, *_EX3 и с каждой новой версией CCS все новых *_EX* -- сам чёрт ногу сломит. Но раньше было так, что если CCS не находил в драйвере GTI_GETERRSTR_EX*, то он обращался к GTI_GETERRSTR, параметры которой доступны для понимания.

Цитата(gagel @ Jun 12 2016, 21:36) *
И ещё появились(?) как минимум несколько функций, которые не только присутствуют в libtixds55x.so, но и вызываются CCS: GTI_GET_NUM_RESETS, GTI_GET_RESET_INFO, GTI_RESET_EX:
Код
0xC9A5DB40 5851429 3 C55xx GTI C: GTI_GET_NUM_RESETS( 0x0xca953838 )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_NUM_RESETS( 0x0xca953838 ) = 0x00000001

Тут можно предположить, что просто есть один вид RESET'а, значит возвращается 1 (но int или unsigned int)?

Наверное имеются в виду hardware reset, software reset и т.п. (то есть те варианты сброса, что есть в меню Debug)
Тип возвращаемого значения можно посмотреть дизассемблером. В общем случае int.

Цитата(gagel @ Jun 12 2016, 21:36) *
Код
0xC9A5DB40 5851430 3 C55xx GTI C: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? )
0xC9A5DB40 5851430 3 C55xx GTI R: GTI_GET_RESET_INFO( 0x0xca953838, 0x00000000, *0x0xc9a5c4fc = ??? ) = 0x00000000

Тут выбирается RESET номер 1 (т.е. 0) и получается указатель на инфу о RESET'е?

Вполне вероятно. Если инфа в виде структуры, то распарсить её поля -- задача не из лёгких.

Цитата(gagel @ Jun 12 2016, 21:36) *
Код
0xC9A5DB40 5855123 3 C55xx GTI C: GTI_RESET_EX( 0x0xca953838, 0x00000000 )
0xC9A5DB40 5855140 3 C55xx GTI R: GTI_RESET_EX( 0x0xca953838, 0x00000000 ) = 0x00000000

Тут вызывается RESET номер 1 (т.е. 0) и статус 0 (нет ошибки)?

Верно, GTI_RESET_EX, как мне помнится, шлет результат (0 в случае успеха).

Цитата(gagel @ Jun 12 2016, 21:36) *
И есть ещё несколько функций, которые есть в бинарнике, но я пока не заметил их вызова из CCS:
Код
GTI_QUERY_INTERFACE
GTI_BLOCK_RESET
GTI_GET_WAIT_IN_RESET_MODE
GTI_SET_WAIT_IN_RESET
GTI_BP_TEST
GTI_STAT_EX2

Они не относятся к разряду супер-обязательных, назначение их надо исследовать дополнительно (при необходимости).

Цитата(gagel @ Jun 12 2016, 21:36) *
Ещё, кстати, RTDX уже некоторое время как объявлен устаревшим. Но почему? Я так и не нашёл официального объяснения и предложения по замене. Так вот в 6.1.1 или 6.1.2 RTDX-функции были выброшены из so'шки. А в DSPBIOS они до сих пор место занимают. Вам доводилось их использовать? Интересно, можно ли их воскресить? Хотя, скорее всего, чисто теоретически.

Я про такое не слышал. По-моему HSRTDX -- это одна из немногих возможностей неинвазивного обмена потоками информации с процессором. Откуда информация про obsolete?


--------------------
شامل
Go to the top of the page
 
+Quote Post

4 страниц V  < 1 2 3 4 >
Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th December 2017 - 16:53
Рейтинг@Mail.ru


Страница сгенерированна за 0.01532 секунд с 7
ELECTRONIX ©2004-2016