Добрый день уважаемые Армоведы.

Возникла необходимость поиграться с платформой Android в чистом виде. Не на уровне Java приложений, а на уровне потрохов и внутренностей железа и пошаговой отладки исходников.
Пока все только теоретически, но хочется перейти и к практике. Для этого немного просмотрел что есть на рыке отладочных плат для Android:
1. Texas Instrumentals OMAP kit based on TI OMAP 3530 (Cortex A8) 600MHz kit здесь или здесь
2. Samsung ARM11 S3C6410 ARM1176JZF-S 800 MHz здесь или здесь. У Корейцев есть Mango64
3. Samsung ARM9 S3C2440A ARM920T 400 MHz На форуме уже писали про него. Так же нашел здесь и здесь

Пока идет выбор платы, решил посмотреть, а чем же можно зацепить ARM11 или Cortex-A8 через JTAG и подебагать в железе.
И то, что смог найти:
1. RealView
2. UDE/ARM11 Universal Debug Engine
3. EDGE debuger from Mentor Graphics

И как бы в меморис, не много полезных ссылок:
1. The ARM Solution Center for Android
2. Android source code
3. Qualcomm - Snapdragon
4. Samsung - ARM11

Есть множество ссылок и мануалов по потому как собрать исходники и получить образ системы, но для меня осталось не ясным следующее:
1. В какой среде можно отлаживать ARM11 или Cortex-A8 через JTAG?
2. Какой нужно купить JTAG что б можно было комфортно дебагать? (не изобретая велосипед)
3. Как собирать проект? Может у кого есть опыт или пожелания/наставления?

Буду очень рад обсудить выше изложенные вопросы и все что касается разработки под Android на asm,С,С++

Могу точно сказать, что если есть TI-шный CCS и совместимый отладчик (xds510 или 560), то CCS зацепит полностью со всеми потрохами ARM-11 и Cortex-A8, по крайней мере TIшного производства, драйвера в CCS для них выпущены для ARM11 с рождения 3-его композера, а для Cortex-ов (всех) кажется с сервис-релиза SR7. Если речь именно про OMAP - то будет можно дебажить параллельно и одновременно оба ядра, и DSP тоже.

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

Ну насчет OMAP процессора у меня как бы сомнений нет что его родная Code Composer Studio зацепит. Вопрос, можно ли будет создать в нем проект и редактировать исходники из него. Или он сможет только дебагать, а собирать надо будет под линуксом.
Вот нашел еще полезный ресурс Android on OMAP

Меня еще также волнует вопрос, а подружится ли он с Samsung ?

Редактировать исходники и вести проект точно можно. Собрать... Ну собиралка для АРМ в нем есть - его родные компиляторы - но я понятия не имею, соберет ли оно то, что Вам нужно. Вообще скачать и попробовать никто не мешает.


Гарантий нет. Может подружится, может не подружится. Был вот когда-то опыт с Excalibur (ARM926 кажется) - так вот, CCS 2-ой версии его подхватывал как родной, а 3-шка отказывалась. Так что только методом тыка.

Вот тут вы почувствуете всю "открытость" Андроида.
Вам по сути надо отлаживать Линукс. Причем после специфичного патча.
А вам ведь нужно перестроить ядро чтоб туда попала отладочная информация. Это первая проблема.

Далее, значит все типа CCS, RealView, EDGE-йе ... идет лесом.
Ни в чем этом вы не сможете не только собрать, но и нормально парсить и редактировать исходники.
Об отладке через JTAG даже речи быть не может, они никто не понимают файлов с отладочной информацией Линукса. (а сначала они под Линуксом сами должны работать)
Да, погонять биты по JTAG-у сможете, даже увидите регистры процессора в неизвестном модуле, процессе, треде и адресном пространстве!
Но как понимаете это не отладка.
Есть только путь через Eclipse->CDT->GDB (JTAG который выберете должен поддерживать GDB).
Но и тут собственно операционку, драйвера и процессы проблематично визуализировать.
Т.е. получится ли в принципе поставить брекпойнт в драйвере и ожидать что CDT остановиться там где надо и правильно покажет все адресное пространство с локальными переменными в контексте ядра Линукса науке не известно.
По крайней мере свидетельств этому в инете либо нет либо крайне мало.

На уровне JTAG и отладки начального загрузчика (скорее всего u-boot)
можно использовать gdb + OpenOCD

Eclipse->CDT->GDB вполне рабочий вариант
или любая другая IDE под Linux например KDevelop

А вот интересно (в разрезе OMAP) - а он (OpenOCD) разве поддерживает ICEPICK-C? Это JTAG-маршрутизатор, коммутирующий состав JTAG-цепочки внутри чипа.

Если тебе просто поиграться, то купи игруху на базе S5PC100. Odroid называется, за 350 баксов с отладочной мишурой. Сам хотел купить, но мне марвела подсунули. Пока занят.

Есть GDB сервер под Segger. Вы не пробовали его в этой цепочке Eclipse->CDT->GDB? Segger последних версий вроде бы adaptive clocking поддерживает.

Ну загрузчики Линукса это примитивные по сути программки в пару килобайт кода.
При определенном рефакторинге их можно дебагить абсолютно любой оболочкой под ARM от Keil-а и IAR-а до RealView и Tasking-а, и любым JTAG-ом
И это как бы не интересно.

Совершенно иное дело когда у вас включен по полной MMU и динамическая загрузка библиотек.
Вот определенное мнение по этому поводу: http://www.celinux.org/elc08_presentations...AG_Anderson.ppt
Из которого следует что KDevelop и CDT отдыхают. Нужен специальный агент на целевой платформе (GDB функциональности здесь недостаточно) и специальная поддержка со стороны драйверов JTAG.
Иначе светит ковыряться ручками в бессмысленных значениях регистров и бесконечных дампах памяти в поисках нужного процесса.
И похоже что на халяву таких тулсов нет.

Ну не совсем в бессмысленных, "MMU Page Table Viewer" (композерский) все таки некую помощь оказывает... А так вообще да, тяжеловато.

Не отношусь к научным работникам но делал это достаточно легко на современных ядрах linux на arm. Посмотрите про kgdb причем даже jtag не нужен. http://kgdb.wiki.kernel.org/index.php/Main_Page - в последних ядрах уже ничего не нужно патчить, он включен в основную ветку ядра.

Не вводите только в заблуждение.
Где написано с какими именно JTAG-ами kgdb умеет работать?
То что есть софтварные отладчики для Линукс нельзя не заметить, позанимавшись темой хотя бы 5 минут.
Но человека интересует именно JTAG.
Подозреваю, что именно потому что он не может поднять kgdb ввиду "открытости" Андроида.
Но и с JTAG-ом будет облом, вот и вся информация...

В заблуждение вводите Вы, причем постоянно. Я дал ответ на конкретное высказываение конкретного человека- Вас то есть, про невозможность отладки ядра linux. Про открытость андроида я ничего не знаю. А jtag для kgdb нужен как русалке лыжи - он нормально через последовательный порт работает как gdb-сервер. Потом что подразумевается под софтварным отладчиком ? kgdb - это не отладка в эмуляторе а самая настоящая отладка на настоящем железе с возможностью пошагового исполнения в разумных пределах конечно. Соответственно jtag - как промежуточное звено которе потом один фик выступает как локальный gdb-сервер между железом и отладчиком на рабочем столе не нужен как класс.

Вы правы в своих словах и в своем контексте.
Настоящий контекст нам неизвестен, человек хочет JTAG. По выложенным им ссылкам можно конечно предположить что он немного не понимает сути проблем. Скажем то, что хождением по шагам Линукс с Андроидом не понять.
Но может речь действительно идет о попытках ловли хардварных траблов на сырой платформе, скажем как раз тех китайских на которые были даны ссылки.
Софтварные отладчики типа kgdb хороши когда у вас как минимум отладочный канал работает без проблем и ядро. Но на сырых платформах падать может что угодно, там могут быть элементарные проблемы с целостностью сигналов или некорректной инициализацией в фирменном BSP.
Здесь только JTAG поможет и больше ничего, а еще лучше вместе с аппаратным трассировщиком. И JTAG потом в течении жизненного цикла постоянно будет нужен. Можно конечно и без него, но время отладки вырастает в разы.