| |
|
  |
 WinCE vs Linux vs eCos |
|
|
|
|
 Mar 11 2008, 15:23
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Чесно не въехал в логику вашего бизнеса. Если бухать столько денег в разработку ASIC-а (или всетаки SoC-а?), то зачем экономить на софте? Хотя, правда, нынче SoC-и можно себе сделать и с бюджетом в 100-200 тыс. баксов. А вот тот же стек мобильных устройств стоит под пол лимона для примера. Сорсы VxWorks под 120 тыс. баксов. Опять странность, у вас там подробно расписыватся периферия для чипа который вы не собираетесь продавать. А вашему рядовому юзеру это надо? Или может они понимают нафига несколько CAN интерфейсов GPS модулю? Там где описания фичей OEM модулей с трудом можно понять вообще какой коммуникационный софт и какие протоколы они используют. Т.е. можно понять, что есть голые хардварные порты CAN и USB, а то что есть еще софтварные профили и стеки поверх них ваши спецы как бы не знают, или почему о них умолчали. Или их действительно нет? Хотя, конечно, за ту цену за которую вы предлагаете свои модули можно наскоряк под каждого заказчика состряпать некое подобие стека протоколов. Весь стек TCP ограничен Raw TCP сервером (интересно что это такое ;-)) и FTP только на чтение (вообще атас). Неужто eCOS больше ничего не может предоставить. Ну хоть для рекламы бы перечислили все заявленные фичи стека lwIP. Это я все к тому, что имеено ваши модули вызывают огромные вопросы, а правильно ли вы выбрали ОС-ь, если не можете ничего продемонстрировать в плане богатства фичей и совместимости со стандартными коммуникационными решениями в индустрии для того же CAN и Ethernet. А как там с SMS-ами для коммуникации с мобильного модема, или тоже нет? Вообщем далекоо.. не убедили, скорее наоборот  Цитата(yes @ Mar 11 2008, 17:23)  это все свое (собственная разработка), одна группа основных разработчиков участвовала, поэтому "ядра" в продуктах разных фирм одинаковое то что eCos во всех кроме PPC (там RTEMS) - поверьте. сообщать эту информацию финальным пользователям нет смысла там используются чипы собственной разработки (JNScore - двухядерный, который я упоминал и делал начальный порт ecos во время разработки чипа), то есть это к утверждению о легкости портирования и доступности этого малыми силами а протащиться - ну если посмотрите стоимость - то такие платы (не говоря уже о приборных комплексах) могут стоить 50к$ и выше - что несколько  отличает от "обычного" GPS - то есть всю [добавленную] стоимость представляет софт ======================= почему не Линукс - мне кажется, что Линунс обеспечивает еще более быстрый тайм-ту-маркет и немеренную гибкость (я использовал Линукс, когда для самсунга делал систему ин-дор трекинга - тогда было не понятно, чего все-таки хочет заказчик, а действующую систему (не плату! - набор станций слежения, вычислительных узлов, протоколы обмена и т.п.) они хотели за пол-года), НО Линукс требует большИх ресурсов (памяти, выч. мощности и т.п.). с Линуксом труднее сделать реал-тайм (мы использовали ОМАР и реал-тайм крутился на DSP) и сделать энергосбережение. то есть для большинства эмбедерских задач Линукс избыточен. например, у меня есть две китайские книжки с e-ink-овскими экранами (к разработке я отношения не имел ) - при этом линуксовская сжирает аккумулятор в 3-4 раза быстрее (там экран не жрет, а все затраты на "вычисление") и глючит почаще. но зато Линуксовская книжка "читает" все форматы - то есть дофига софта уже написано и можно было его быстренько заиспользовать. думаю - такая же ситуация будет с любым эмбедерским девайсом - если есть необходимость писать много "гуд-инаф-софтварь", то линукс. если нужно более надежное решение - то RTEMS, eCos если достаточно примитивного набора функций - то scmRTOS, uCOS, salvo и т.п. я не сталкивался с VxWorks, Tornado, Symbian и пр. коммерческими операционками, поэтому не берусь судить о них. но опыт использования (общения с саппортом) крупных производителей софта, сильно смещает симпатии в сторону активных open source проектов ======================= использование WinCE оправдано, имхо, только там, где пользователь хочет увидеть "знакомые" окошки - то есть всякие наладонники, коммуникаторы и т.п. если есть возможность скрыть от пользователя "внутренности" встраиваемого устройства или пользователь удовлетворится нестандартным ГУЕм - то от виндовса можно (имхо, НУЖНО) отказаться ======================= ======================= сейчас в конторе идет обсуждение перспективного железа (конкретно, АЗИКа для будущих продуктов) и не во все споры мне удается вступить - вот оттягиваюсь в конфе простите за многословность |
|
|
|
|
|
|
|
Mar 11 2008, 15:50
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 27-09-05
Пользователь №: 9 012
|
Цитата Вообщем далекоо.. не убедили, скорее наоборот Отрасль просто несколько специфическая. Наиболее дорогая часть софта вообще не зависит от операционной системы. USB, CAN и прочее - "обвеска".
|
|
|
|
|
|
|
|
Mar 11 2008, 16:42
|
Гуру
Группа: Свой
Сообщений: 2 198
Регистрация: 23-12-04
Пользователь №: 1 640
|
2AlexandrY, как правильно заметил dezzer, клиент платит за решение своей задачи (в этом случае геодезический сурвийинг), объем данных производимый приемником мал, а в другую сторону вообще только команды почему нужен АЗИК - спутниковый сигнал принимать, а линки я я запостил не ради рекламы (вряд ли геодезисты эту конфу листают), а как демонстрацию возможности использования eCos для производства конкурентной продукции. причем eCos выбирался (как Вы верно заметили) не ради экономии, а для удобства разработки и надежности функционирования например, изделия использовались в Антарктиде для измерения подвижек льда - там некому было сброс нажать, если бы подвисло CAN интерфейсы - вопрос сложный - есть такая фича RTK, которую могут считать такие приемники - она может применятся в автомобилях, для этого и CAN-ы . какой стек на них стоит - не знаю (когда интересовался - никакого не было). но нужно будет - поставим а АЗИКи выкладывать на сайты - это своего рода демонстрация крутизны - "мы контролируем разработку полностью и не зависим от IP сторонних фирм"
|
|
|
|
|
|
|
|
Mar 11 2008, 17:35
|
Участник
Группа: Свой
Сообщений: 66
Регистрация: 27-09-05
Пользователь №: 9 012
|
Цитата причем eCos выбирался (как Вы верно заметили) не ради экономии, а для удобства разработки и надежности функционирования Однако, в новых версиях уже RTEMS...
|
|
|
|
|
|
|
|
Mar 11 2008, 18:53
|
Знающий
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847
|
Цитата(AlexandrY @ Mar 10 2008, 13:49) Благодаря инструментам трассировки, внутрисхемной отладки на базе JTAG, человек освобождается от написания бесконечных отладочных вставок и логов, которые сами искажают код в свою очередь и могут иметь местные эффекты.
В Линуксе если ошибка в ядре в каком-нибудь прекомпилированном модуле, только поиск может занять пару дней. А при чем здесь JTAG? Это если без ОС то понятно, но не всегда однако выгодно. А в Линукс gdb есть. В том числе и на уровне ядра. И ошибки находятся (и в драйверах и даже подсистеме виртуальной памяти) быстро. Может я чего-то не понимаю, но кто мне мешает посмотреть - исправить - перекомпилировать модуль? Что значит Цитата прекомпилированном модуле И кто (а главное на каком основании и по какому праву) его "прекомпилил" если это не я?
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть.
© Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
|
|
|
Mar 11 2008, 20:17
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
JTAG позволяет просмотреть значения всех абсолютно переменных и без остановки программы и без единой строчки диагностического кода и без всяких отладочных движков на целевой платформе. Он позволяет остановить программу мгновенно как только происходит несанкционированная запись или даже чтение переменной, области памяти или периферии. Он позволяет вместе с процессором заморозить периферию и смотреть неизмененный ничем снимок системы в момент краха и т.д. Трассировка же через JTAG дает еще больше возможностей. Все это приправляется эффективными визуальными отладочными оболочками как в RealView, IAR, Multi, Tasking и т.д. к которым делаются визуальные же add-on всяких компактных RTOS. У знакомых разработчиков мобильных дивайсов трассер есть у каждого на столе. Проблема же Линукса и других монструозных осей в их величине. Компиляция целиком занимает столько времени, что приходится все оформлять в виде библиотек и заранее компилировать. Если ошибка попадается в таком скомпилированном модуле, то надо переключать проект на работу с исходниками модуля, исправлять, компилировать и снова оформлять как прекомпилированную библиотеку. А если ошибка снова там? А как ядро гранулировать на библиотеки если оно вам с готовым make файлом досталось гигантских размеров считая все включения? Значит не гранулируем, пытаемся сделать ядро и делать динамически линкующиеся модули. А если ошибки всетаки в ядре, то кошмар с полной перекомпиляцией повторяется, а динамические модули не отладить JTAG-ом. Вообщем такой секс позволителен только на уже кем-то отлаженных платформах. Имею богатый опыт по отладке прог под Win mobile через ихний ActiveSync. Больше похоже на шаманство и игру в рулетку. Такие средства отладки сами на ладан дышат и падают при любом сбое в ядре. Тут еще отмечу, что веду речь только об этапе подъема оси на голой платформе. Но для проекта по контексту этим этапом все и заканчивается практически. Никто, конечно, никому не мешает. Все решает время, кто реально знает сравнительные расклады по времени на те или иные действия в технологии разработки тот и на коне. Интересно, как пользователи eCOS объясняют существование лицензии VxWors стоимостью 12 штук баксов при такой раздольной халяве какую дает eCOS или RTEMS? Цитата(amw @ Mar 11 2008, 23:23) А при чем здесь JTAG? Это если без ОС то понятно, но не всегда однако выгодно.
А в Линукс gdb есть. В том числе и на уровне ядра. И ошибки находятся (и в драйверах и даже подсистеме виртуальной памяти) быстро.
Может я чего-то не понимаю, но кто мне мешает посмотреть - исправить - перекомпилировать модуль?
Что значит
И кто (а главное на каком основании и по какому праву) его "прекомпилил" если это не я?
|
|
|
|
|
|
|
|
Mar 12 2008, 08:45
|
Знающий
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847
|
Цитата(AlexandrY @ Mar 11 2008, 22:17) JTAG позволяет просмотреть значения всех абсолютно переменных и без остановки программы и без единой строчки диагностического кода и без всяких отладочных движков на целевой платформе. Я знаю что такое JTAG и зачем он нужен. Цитата У знакомых разработчиков мобильных дивайсов трассер есть у каждого на столе. У меня тоже есть. Помогает. Но при отладке в Линукс - он только обуза и ничего больше. Цитата Проблема же Линукса и других монструозных осей в их величине. Простите меня, но мне кажется Вы слишком зациклились на "монстроидальности" того, что лично Вам не нравится (в самом широком смысле этого слова, включая, но не ограничиваясь, повышенными требования к железу, сложностью, (не)целесообразностью на данной задаче и т.п.) с одной стороны, и "минимализмом" - с другой. Всему свое место. Есть задачи, где я с Вами полностью соглашусь в ненужности, избыточности и сложности того-же Линукс. И есть задачи - где я не смогу с Вами согласится по поводу нецелесообразности применения Линукс. То-же касается и и других ОС. Цитата Компиляция целиком занимает столько времени, что приходится все оформлять в виде библиотек и заранее компилировать.
Если ошибка попадается в таком скомпилированном модуле, то надо переключать проект на работу с исходниками модуля, исправлять, компилировать и снова оформлять как прекомпилированную библиотеку.
А если ошибка снова там?
А как ядро гранулировать на библиотеки если оно вам с готовым make файлом досталось гигантских размеров считая все включения?
Значит не гранулируем, пытаемся сделать ядро и делать динамически линкующиеся модули.
А если ошибки всетаки в ядре, то кошмар с полной перекомпиляцией повторяется, а динамические модули не отладить JTAG-ом. Это уже с какой стороны посмотреть. Когда мне приходится отлаживать программы для МК без ОС или в простых RTOS я применяю JTAG так как других способов понять что происходит - просто нет! Но при этом очень жалею, что нет чего нибудь типа kprobe (как в Линукс). Лично мое мнение JTAG это иллюстрация поговорки "На безрыбье и сам раком станеш." Цитата Вообщем такой секс позволителен только на уже кем-то отлаженных платформах.
Имею богатый опыт по отладке прог под Win mobile через ихний ActiveSync. Больше похоже на шаманство и игру в рулетку. Такие средства отладки сами на ладан дышат и падают при любом сбое в ядре. Никогда не видел "уже кем-то отлаженных платформ" так как строю и отлаживаю эти самые платформы. Потому - без коментариев. Цитата Тут еще отмечу, что веду речь только об этапе подъема оси на голой платформе. Именно этим и занимаюсь. Начиная с обсуждения схемы платформы. Цитата Но для проекта по контексту этим этапом все и заканчивается практически.
Никто, конечно, никому не мешает.
Все решает время, кто реально знает сравнительные расклады по времени на те или иные действия в технологии разработки тот и на коне. +1 Цитата Интересно, как пользователи eCOS объясняют существование лицензии VxWors стоимостью 12 штук баксов при такой раздольной халяве какую дает eCOS или RTEMS?
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть.
© Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
|
|
|
Mar 12 2008, 11:28
|
Гуру
Группа: Свой
Сообщений: 2 198
Регистрация: 23-12-04
Пользователь №: 1 640
|
Цитата(dezzer @ Mar 11 2008, 20:35) Однако, в новых версиях уже RTEMS... нет, RTEMS это как раз старые версии - "legacy support" так сказать продукты с RTEMS появились до того как появилась eCos ну а потом ветка с PPC продолжается на RTEMS, хотя неоднократно поднимался вопрос - хорошо бы перенести, но нет ресурсов под эту задачу Цитата(AlexandrY @ Mar 11 2008, 23:17) JTAG позволяет просмотреть значения всех абсолютно переменных и без остановки программы и без единой строчки диагностического кода и без всяких отладочных движков на целевой платформе.
-------------
Интересно, как пользователи eCOS объясняют существование лицензии VxWors стоимостью 12 штук баксов при такой раздольной халяве какую дает eCOS или RTEMS? JTAG без останова встречается очень редко, практически нет в популярных архитектурах и если код поддержки отладчика скрыт в среде разработки/пзу/и т.п. и "невнимательный" пользователь его не видит - это не значит, что его нет попытки сделать безостановочный JTAG есть в DSP Аналога (BTC) и Тексаса (RTDX), но он требует поддержки в пользовательском коде при отладке real-time обычно не получается ничего отладить по JTAG-у, и пользуются либо "светодиодом", либо каким-либо отладочным printf-ом JTAG обычно это только начальный этап, когда осваивается чип, пишется стартап и библиотечки управления железом возможно, какой-то малый фрагмент кода (но это лучше делать симулятором, а в линуксе (и POSIX-ных RTEMS/eCos) можно делать на хосте ) ------------------------------------------------- а почему 80% бизнес приложений написано на COBOLе? почему столько бабок было заплачено за проблему 2000? почему Билл Гейтс имеет коммерческий успех со всякими уродливыми Вистами, когда есть Линукс для РС? почему люди не летают как птицы?
|
|
|
|
|
|
|
|
Mar 12 2008, 12:47
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Я поздравляю, что вы всем этим занимаетесь, теперь осталось только это доказать.  Цитата(amw @ Mar 12 2008, 13:15) Я знаю что такое JTAG и зачем он нужен.
У меня тоже есть. Помогает. Но при отладке в Линукс - он только обуза и ничего больше.
Простите меня, но мне кажется Вы слишком зациклились на "монстроидальности" того, что лично Вам не нравится (в самом широком смысле этого слова, включая, но не ограничиваясь, повышенными требования к железу, сложностью, (не)целесообразностью на данной задаче и т.п.) с одной стороны, и "минимализмом" - с другой.
Всему свое место.
Есть задачи, где я с Вами полностью соглашусь в ненужности, избыточности и сложности того-же Линукс.
И есть задачи - где я не смогу с Вами согласится по поводу нецелесообразности применения Линукс.
То-же касается и и других ОС.
Это уже с какой стороны посмотреть.
Когда мне приходится отлаживать программы для МК без ОС или в простых RTOS я применяю JTAG так как других способов понять что происходит - просто нет!
Но при этом очень жалею, что нет чего нибудь типа kprobe (как в Линукс).
Лично мое мнение JTAG это иллюстрация поговорки "На безрыбье и сам раком станеш."
Никогда не видел "уже кем-то отлаженных платформ" так как строю и отлаживаю эти самые платформы.
Потому - без коментариев.
Именно этим и занимаюсь. Начиная с обсуждения схемы платформы.
+1
|
|
|
|
|
|
|
|
Mar 12 2008, 13:00
|
Частый гость
Группа: Участник
Сообщений: 167
Регистрация: 15-08-07
Пользователь №: 29 803
|
Цитата(AlexandrY @ Mar 11 2008, 23:17) JTAG позволяет просмотреть значения всех абсолютно переменных и без остановки программы и без единой строчки диагностического кода и без всяких отладочных движков на целевой платформе.
Он позволяет остановить программу мгновенно как только происходит несанкционированная запись или даже чтение переменной, области памяти или периферии.
Он позволяет вместе с процессором заморозить периферию и смотреть неизмененный ничем снимок системы в момент краха и т.д. Особенно если целевая платформа - х86, ага Цитата Я поздравляю, что вы всем этим занимаетесь, теперь осталось только это доказать. Кому и, главное, зачем?
|
|
|
|
|
|
|
|
Mar 12 2008, 13:23
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Без останова JTAG отлично работает на Cortex M3 на которых теперь бум. Без останова проги может работать JTAG на популярных MIPS-ах в составе чипов PIC32 Также такая фишка может работать на STR912. Т.е. это уже совсем не редкость, а я бы сказал норма. Про JTAG я и говорю, что он в основном актуален на начальном этапе. Но многие тут видать либо намеренно либо по незнанию принижают значение этого этапа. Когда начинаем отлаживать верхние уровни приложений, например на уровне прикладных слоев как SNMP, WEB, маршрутизация, GUI то, конечно, JTAG помогает незначительно, там уже нужны инструменты глубокого анализа, а не просто просмотр переменных. И опять где вы такие инструменты найдете как не в малых RTOS? Далее народ почему-то забывает актуализирующуюся тему сырости железа. А не признаетесь сколько вы лет разрабатывали свой ASIC от идеи до момента когда обнаружили последний аппаратный баг в кристалле? Вот, например, в STR912 баги обнаруживаются спустя 2-а года после начала их продаж. У иных процов, как OMAP сама дока по некоторым периферийным узлам может только через год поспеть после начала продаж. Там без JTAG вообще нечего делать, это единственное спасение. Цитата(yes @ Mar 12 2008, 15:58) нет, RTEMS это как раз старые версии - "legacy support" так сказать
продукты с RTEMS появились до того как появилась eCos
ну а потом ветка с PPC продолжается на RTEMS, хотя неоднократно поднимался вопрос - хорошо бы перенести, но нет ресурсов под эту задачу
JTAG без останова встречается очень редко, практически нет в популярных архитектурах
и если код поддержки отладчика скрыт в среде разработки/пзу/и т.п. и "невнимательный" пользователь его не видит - это не значит, что его нет
попытки сделать безостановочный JTAG есть в DSP Аналога (BTC) и Тексаса (RTDX), но он требует поддержки в пользовательском коде
при отладке real-time обычно не получается ничего отладить по JTAG-у, и пользуются либо "светодиодом", либо каким-либо отладочным printf-ом
JTAG обычно это только начальный этап, когда осваивается чип, пишется стартап и библиотечки
управления железом
возможно, какой-то малый фрагмент кода (но это лучше делать симулятором, а в линуксе (и POSIX-ных RTEMS/eCos) можно делать на хосте )
-------------------------------------------------
а почему 80% бизнес приложений написано на COBOLе?
почему столько бабок было заплачено за проблему 2000?
почему Билл Гейтс имеет коммерческий успех со всякими уродливыми Вистами, когда есть Линукс для РС?
почему люди не летают как птицы?
|
|
|
|
|
|
|
|
Mar 12 2008, 15:28
|
Гуру
Группа: Свой
Сообщений: 2 198
Регистрация: 23-12-04
Пользователь №: 1 640
|
Цитата(AlexandrY @ Mar 12 2008, 16:23) Без останова JTAG отлично работает на Cortex M3 на которых теперь бум. OFF : если Вы интересовались Cortex-ами, с фичей TrustZone не сталкивались? интересна ее поддержка софтом - как коммерческими OS|компилерами/библиотеками так и Линуксом? это более старшие Cortex-ы А8/А9 ... ----------------- а по поводу RUN-TIME JTAG на них - сильно подозреваю (по-крайней мере у нас в чипе так сделано), что JTAG висит как еще один мастер на АМBA шине и может смотреть некие ресурсы, доступные по шине. но при этом доступ к внутренностям процессора закрыт (пока процессор не остановлен) со всякой периферией, которая сбрасывается по чтению - тоже проблема ну и даже имея доступ к общей памяти через жтаг нужно иметь некий протокол синхронизации при передаче сообщений (то есть что-то типа упоминавшихся BTC/RTDX) то есть функционирование JTAG в этом случае не дает особого выигрыша перед передачей данных по другому каналу (UART) может интересно содержимое TRACE буфера, но и его можно по UART передать по крайней мере усилия на это затрачиваются минимальные, а пропускная способность УАРТ на 460кбод выше чем у JTAG-а --------------- я могу ошибаться, так как не знаком с перечисленными архитектурами, но из общих соображений - делать левый доступ к регистрам ядра или еще один порт в регистровый файл - слишком трудоемкая операция, чтобы имело это смысл...
|
|
|
|
|
|
|
|
Mar 12 2008, 15:31
|
Участник
Группа: Новичок
Сообщений: 30
Регистрация: 28-01-05
Пользователь №: 2 260
|
Цитата(AlexandrY @ Mar 11 2008, 22:17) Проблема же Линукса и других монструозных осей в их величине.
Компиляция целиком занимает столько времени, что приходится все оформлять в виде библиотек и заранее компилировать.
Если ошибка попадается в таком скомпилированном модуле, то надо переключать проект на работу с исходниками модуля, исправлять, компилировать и снова оформлять как прекомпилированную библиотеку. В этом случае хорошо помогает вынос отлаживаемого куска в отдельный модуль. Далее - make, insmod, rmmod. Все компилируется очень быстро.
|
|
|
|
|
|
|
|
Mar 12 2008, 17:01
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Ну да JTAG имеет доступ ко всей системе через порт-мастер к шине AHB, но и все регистры процессора может смотреть через специальный механизм и без останова процессора. И опять же, я не вдаюсь в тех. детали на кой они мне? Я знаю одно и самое важное: в Keil с операционкой ARTX я имею к этим фичам доступ, а в eCOS c GCC нет! UART? А время у вас на портирование отладочного монитора на UART не уйдет? Или это с неба падает? А сам монитор на состояние системы что, не влияет? Я не говорю о специализированных мониторах процессов RTOS и прикладных задач, это у всех есть. Но следить за локальными переменными через UART, это извините прошлый век в прямом смысле слова. Не говоря уже что сам UART жалко на отладку отдавать. И откуда сведения о пропускной способности JTAG. Это как минимум зависит от системной частоты, но вообще для JTAG нормальная скорость 10 Mbit. Насчет TrustZone, насколько можно понять из рекламных брифов (технология то засекречена), то она нисколько не отличается от применяющихся сейчас в OMAP, iMX, PXA и прочих платформах. Никто из них не публикует спецификации на свои движки защиты. Но отладочные платы для OMAP и iMX идут с тулсами которые готовят загрузочные имиджи и ключи к их секретным движкам. От компилятора ничего не зависит, дают API и хидеры на функции защищенного монитора. Дальше все пишите сами согласно своей концепции. В свободной продаже только версии чипов с отключенными механизмами защиты. С защитой чипы делаются только по прямой договоренности с производителем. На глаза попадались доки с описанием концепции защиты построенной на основе технологии TI применяемой в их платформе Calypso. В конечном итоге там все сводилось к хешу мастер ключа хранившемуся в неких энергонезависимых ячейках на кристале. Делали декапсуляцию чипов, и с точки зрения взлома вообщем пришли к выводу что особых технических проблем нет. Во всяком случае Semiconductor Insight говорил, что проблем не видит. Т.е. это не решение для защиты софтварных ноухау, а только лишь коммерческий ход для производства субсидируемых дивайсов. Цитата(yes @ Mar 12 2008, 19:58) OFF : если Вы интересовались Cortex-ами, с фичей TrustZone не сталкивались? интересна ее поддержка софтом - как коммерческими OS|компилерами/библиотеками так и Линуксом?
это более старшие Cortex-ы А8/А9 ...
-----------------
а по поводу RUN-TIME JTAG на них - сильно подозреваю (по-крайней мере у нас в чипе так сделано), что JTAG висит как еще один мастер на АМBA шине и может смотреть некие ресурсы, доступные по шине. но при этом доступ к внутренностям процессора закрыт (пока процессор не остановлен)
со всякой периферией, которая сбрасывается по чтению - тоже проблема
ну и даже имея доступ к общей памяти через жтаг нужно иметь некий протокол синхронизации при передаче сообщений (то есть что-то типа упоминавшихся BTC/RTDX)
то есть функционирование JTAG в этом случае не дает особого выигрыша перед передачей данных по другому каналу (UART)
может интересно содержимое TRACE буфера, но и его можно по UART передать
по крайней мере усилия на это затрачиваются минимальные, а пропускная способность УАРТ на 460кбод выше чем у JTAG-а
---------------
я могу ошибаться, так как не знаком с перечисленными архитектурами, но из общих соображений - делать левый доступ к регистрам ядра или еще один порт в регистровый файл - слишком трудоемкая операция, чтобы имело это смысл...
|
|
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
