Коллеги!

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

Были предложения S3C6410, потом i.MX51.
Заданы вопросы относительно защиты, на которые пока не найдены ответы.

У меня была идея попробовать решать задачу защиты простым способом и без помощи производителя процессора.
1. Применяю шифрование для флэш или ее важной части
2. В зашифрованной части храню ключ и несколько резервных ключей
3. Каждое изделие снабжаю уникальным серийным номером, например с помощью DS28CN01
4. При заливке и тестировании устройств запоминаю в базе данных сформированные ключи и резервы в соответствии с серийным номером.

Ключи создаю специально разработанным аналоговым методом (который также можно патентовать ), что позволяет получить их уникальность даже при огромной серии.
Джитаг не вывожу. Консольный порт секречу: контактные точки разбросаны, вывод по-умолчанию отключен, пока не задано сочетание сигналов на вспомогательных контактах.
Если u-PC потерян или украден, то разборка его на детали сразу не дает результатов: во-первых нужно демонтировать БГА и попробовать считать зашифрованную часть, во-вторых вкрытие одного u-PC не рушит всю инфраструктуру, так как эти ключи подходят только для этого компьютера. Эти ключи можно заблокировать также, как и кредитную карту при утере.

Почитал errata на i.MX51 и слегка поплохело. Очень странно почему такой нет на Самсунги.

Но чтобы найти общий язык может поможет концепция защиты разработанная одной очень известной в узких кругах R&D конторой.
В аплоад/ЖСМ/док лежит документ под названием Изабелла.
Это плод войны хакеров и производителей субсидируемых дивайсов.
Там даже термин есть - лок субсидирования.
Надо сказать что лок субсидирования хоть и важная фича но не жизненно важная для корпораций. Он должен выдержать год или два.
В айфонах он не выдержал и месяца
Изабелла - это концепция защиты дешевой мобилы от хакеров. Предполагалось использовать в качестве хардварной платформы решения от TI применяемые нынче в OMAP-ах.
Можно увидеть что для реализации защиты нужно защищенное место храния ключей или/и их хешей. Во вторых есть достаточно длинная цепочка сертификатов, у нужны скрытые области оперативной памяти в проце.
Что еще понятно, весь софт подписать и зашифровать нельзя. Далее нужны программные демоны для защиты.
Я тут в релизе Chromium OS видел применение технологии описанной здесь http://tpm-emulator.berlios.de/documentation.html
Что-то в этом есть...

Насколько я знаю фрикерские технологии надеяться на то что BGA трудно отпаять, а JTAG трудно найти абсолютно нельзя.
Я гарантию даю, что в течении недели будет приобретен или изготовлен игольчатый адаптер для этой BGA и выведены на логические анализаторы все интересующие шины. Еще в течении 3-4 месяцев будут сделаны эмуляторы или перехватчики DDRAM и NAND для этой платформы.
Схему всего дивайса восстановят через неделю или две.
Обмен с далласовским SHA ключом сосканируют уже в первые несколько суток.
Если ключ нужен для расшифровки софта в том же дивайсе, то софт будет расшифрован тоже где-то за месяц-два.
Нет к вашему серверу клоны обращаться не будут, бедет сделан сервер клон!
И все это сделают при бюджете в несколько десятков тысяч баксов.

Быть может ВСЮ оперативную память, как и загрузочную Flash, сделать скытой? И, соответственно, ВЕСЬ софт шифрануть?

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

Разве есть успешный опыт расшифровки шифрованных разделов?

Из доки на S3C6410 косвенно можно сделать вывод что у них все таки сделано как у всех.
Есть те же eFuse и защищенный bootROM.
Вообщем судя по известиям со складов и от поставщиков лучшей альтернативы чем S3C6410X66 в следующем году не будет.
Об i.MX51 даже китайские стоки ничего не знают.
Надо делать на самсунгах.
В свои рабочие планы этот пункт практически вставил. А может есть готовый паттерн компонента под какую-нить EDA?

На первых порах наверно придется защищаться чисто программно. Как минимум надо будет сделать обфускацию физического формата записи на NAND.
Ни в коем случае не применять известные файловые системы типа JFFS2.
Сейчас, кстати, работаю над турбированием одного проприетарного FTL (Flash Translation Layer) для NAND.

Вопрос с защитой скорее надо ставить не в контексте расшифровки чего либо, а в контексте противодействия патчам и маскировки ключей.
Чесно не видел хакеров тупо брутфорсом ломающие шифровки, или ищущих слабости в криптоалгоритмах.
Усилия всегда концентрируются на подмене алгоритмов или патчах первичных, вторичных.. и т.д. загрузчиков либо на ломке инструментов для off-line апгрейда.

Мы все делаем в Altium-е, как будет сделан, скину

Аналогично.


А вот может не актуальный вопрос, но как делать будем распределение 2-х банков OneNAND?
Как один диск или как раздельные диски?
И будем ли вообще ставить второй OneNAND?

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

Кстати, Самсунг зажал свою технологию XSR под Линукс:
http://www.samsung.com/global/business/sem...rtingGuide.html
А под Win CE дают только в виде либ и то только под платформу на S3С6400

XSR это аналог FTL для самсунговских OneNAND.
А в данном приложении надежность дисков будет определять все.
Надо бы озаботиться выбиванием XSR

Дисков в любом случае придется делать несколько. Один как минимум для системы, второй для драйверов и приложений для различных ОС (MacOS, Windows, Linux), когда машинка при первом подключении прикидывается флэшкой.


И еще, было бы классно, если получится учесть особенности оборудования при использовании на uPC двух вариантов ОС: Windows Mobile и Linux. А может и Android...

Дело в том, что привлеченные спецы на месте не сидят, нарыли ряд интересных (пока на их взгляд) вариантов применения. Один из вариантов: Скайп-машинка с Wi-Fi на борту. Я пока не принял их доводы, почему стоит урезать возможности микрокомпьютера до одного приложения, но они еще не все сказали.

Это может оказаться сильно нерентабельно делать на самсунге.
У меня тут в двух шагах контора которая делает Wi-Fi и линукс в одном чипе AR2315. Правда там в качестве ядра MIPS
http://www.wiligear.com/?q=products/cpu-boards/wbd-500
Понятно, что идею со скайпфоном они сделают сильно дешевле. Да и два 32-х разрядных ядра одному USB уже не потянуть точно.

Зачем нужен WiFi если "донор" и так подключен к инету? С другой стороны, зачем подключать Скайп-фон к УСБ если у него свой WiFi? Опять таки скайп-фон с вай-фай уже не новость.

Разговор начинался со сценария подключения к чуждой среде где даже в USB с неохотой дают воткнуться, а уж интернет и свой Wi-Fi подавно могут не дать.

Тем более, зачем тогда свой вай-фай?

Вообще сценарий немного надуманный -- вы пришли в чуждую среду и приспичило по скайпу поговорить? Есть вообще обычный телефон, если срочно надо с кем-то связаться. Не говоря уже о мобилке.

Не зацикливайтесь на Wi-Fi и тогда может поймете.
Рядом можно принести и положить мост GSM-WiFI или WiMAX-WiFi.
А еще не надейтесь что тут вам прямо бизнес-идею и выложат.
Бизнес-идеи обсуждаются в другой ветке

А почему вы не смотрели в сторону TI OMAP3?
Это все таки более новое ядро чем у самсунга. И из cortex-a8 они насколько я понимаю первые реально появились. К тому же там есть DSP ядро что может быть полезно.
Только вот вроде у OMAP3530 нет TrustZone, но вот у телефонного варианта 3430 - есть.

Я что-то пропустил видимо, так как появился какой-то сервер, для которого будут делать клоны. Это что такое? Это система инициализации токена?

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

Тогда остается единственный путь – полное шифрование с пре-бут аутентификацией. Атака на алгоритм бессмысленна, если использовать открытые AES, «рыбы» или ГОСТ 28147—89 (последнее полезно при сертификации)

Отечественная открытая пре-бут шифровалка: http://diskcryptor.net/index.php/Main_Page
Зарубежный аналог: http://www.truecrypt.org/

Остается один тонкий момент: надежность ключа-пароля, которым шифруется ключ шифрования. Проблема в том, что этот пароль должен водиться пользователем, а значит, не может быть достаточно (да и вообще) надежным-сложным.
Таким образом, важным становится вопрос о предотвращении подбора ключа-пароля. То есть, есть разрешенное кол-во попыток ввода, после чего токен должен блокироваться. Вопрос: как? Уничтожением зашифрованного ключа?

Далее: будет ли предусмотрена возможность разблокировки? Если я понял правильно идею «сервера», то разблокировать токен можно будет «восстановлением» ключа на токене

Принципиально неразрешимая проблема в другом: пароль будет вводится через незащищённого "донора" там его простенькая программа "keylogger" и соберёт. Удачи.

Есть такое дело! Вопрос перехвата клавиатуры "токеном" реализуем?

Далее, существуют не только программные килогеры, но и аппаратные, борьба и обнаружение которых крайне проблематичная. Предлагаю рассмотреть вариант подключения клавиатуры напрямую в токену.
Это, в том числе, позволит реализовать требования, изложенные в FIPS 140-2 L3.

FIPS 140-2 это скорее стандарт механической защиты, а не программной.
Сами почитайте FIPS, в рамках простого USB дивайса адекватно можно говорить только об уровне L1

реализовать полностью требования FIPS, здесь, согласен, нереально.

В упомянутом выше стандарте есть прямое указание на то, что в том числе и данные аутентификации должны передаваться на устройство напрямую! Это одно из ключевых отличий L2 от L3

For Security Levels 3 and 4,

the physical port(s) used for the input and output of plaintext cryptographic key components, authentication data, and CSPs shall be physically separated from all other ports of the cryptographic module

or

the logical interfaces used for the input and output of plaintext cryptographic key components, authentication data, and CSPs shall be logically separated from all other interfaces using a trusted path,

and

plaintext cryptographic key components, authentication data, and other CSPs shall be directly entered into the cryptographic module (e.g., via a trusted path or directly attached cable). (See Section 4.7.4.)

И монитор тоже надо подключать к "токену" по тем-же соображениям.

Хорошо, есть идея как вводить пароли напрямую.
Ставим на дивайс маленький fingerprint сканер. И сканируем все свои 10-ть пальцев. По пальцу на каждую десятичную цифру.
Отпадает необходимость в клавиатуре.

А вывод информации на "небезопасный" монитор? Грош цена такой защите.

Защите чего?
Я привел идею для случая пароноидального юзера, для дополнительного подтверждения выполнения транзакций.
А так что может сделать "небезопасный монитор" если у него нет средств повлиять на выполнение пользовательского приложения в дивайсе?
Если юзер боится даже показывать что он делает то неча вообще подходить к чужому компьютеру.
А если USB дивайс применяется как мульти банковский код-генератор и одновременно выполняет приложение по управлению личными счетами, то юзеру в принципе до лампочки увидят там что он делает или нет.
Главное чтобы код-генератор не был взломан, но тут уж никакой монитор и никакая "небезопасная клава" вреда не наделает.

Еще как вариант подписи транзакций и источник сертификатов можно использовать личную ID-карту (то что в Евросоюзе дают вместо паспортов), а в дивайсе сделать считыватель ID-карт

Тогда в дивайсе нужно только предпринять меры против умышленных патчей

Ну-Ну. Всё это ломается на раз. Само-собой не "грубой силой". Я несколько раз пытался вам намекнуть что по защите информации вы не в ту сторону копаете... Вам что-нибудь говорят термины "зона первого/второго радиуса"?

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

Все и началось с того что все ломается. Обсуждается только цена и время взлома. Здесь прошу быть поточнее по возможности.

Это что-то из эпохи i386.. Глобальные/локальные дескрипторные таблицы (GDT/LDT) и пр.

Биометрию можно рассматривать в том случае, если модно надежно решить задачу хранения свертки пальца и выполнять проверку в защищенном режиме, так как это реализовано в match-on-card. Сканеры сейчас дешевые, но все равно это приведет к увеличению стоимости.

Вопрос ввода данных аутентификации можно решить виртуальной клавиатурой со случайным размещением кнопок



Можно поставить смарт-карту и таким образом решить все вопросы по аутентификации и хранения всех «секретов», генерации одноразовых паролей и т.д. С точки зрения надежности это будет максимум сегодняшнего дня. Здесь только один вопрос: криптография в них зарубежная. Банковские транзакции подписывать с использованием RSA «нельзя».

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

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

В этом же главное удобство! Вся ценность идеи. Мы не должны вечно помнить эту тьму паролей.

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


При утере такой штуки будет то-же что и при утере генератора и подсмотренном PIN коде, любой спокойно заберет ваши деньги как бы генератор не был защищен.





Нынче обычная практика вообще делать транзакции имея только кодовую карточку с напечатанными на ней всеми паролями!
Т.е. при таком механизме можно автоматизировать свой интернет-банк вообще с банками не заключая никаких договоров насчет применения таких устройств.
С другой стороны по европейским законам электронная подпись сгенерированная личной ID-картой должна приниматься всеми учреждениями так же как сделанная от руки. Т.е. банки ее принимать должны.

Это было предложение от реального потенциального клиента, речь шла о необходимости работы девайса с Интернетом, когда в Доноре нет сети. А в концепции изделия Донор используется только как интерфейс, код выполняется в девайсе.


У Samsung есть S5PC100, это тоже Cortex.

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

В случае применения POP, то есь три в одном корпусе (процессор, озу и флэш) нечего будет перехватывать.

Неа. + неделя на раскорпусировку =)

Если не сделать это все на одном кристалле.
Но это уже совсем другой уровень разработки.
хотя...надо же поддерживать отечественного производителя.
Интересно - есть ли возможность купить АРМ в бескорпусном варианте?

А кто сказал, что ее там нет? 3530 - тот же самый 3430.

Почему же, очень даже смотрели.

Но при внимательном рассмотрении это больше напоминает лохотрон.

Начнем конечно с того что корпус у OMAP3 гораздо менее технологичный чем у конкурентов.
Если вариант маленького корпуса OMAP3 с POP технологией то между шарами шаг 0.4 мм! В наших краях за репайринг такой вещи никто не возьмется
Если корпус без POP то его размер 16*16 мм, у самсунга для сравнения 13*13 мм

Далее цена. Она у OMAP3 чуть ли не в 3-и раза выше чем у Самсунгов.

Затем скорость. Разницы в скорости ядра Cortex-A8 и ARM11 почти никакой. У самсунга даже выше частота ядра.
Шина с DDR по скорости тоже такая же как у самсунгов.
У Cortex-A8 появился NEON сопроцессор и все в общем-то.
В скорости работы Линукса этот NEON пока никак не помогает. Смотрим бенчмарки опубликованные самим TI.

Насчет DSP. Вот тут начинается главная неприятность.
TI на самом деле не дает бесплатно сорсов никаких кодеков. Хотите пишите сами на DSP. Удачи!
Есть кодеки в объектных кодах и без всяких гарантий. Задвигалось у вас что-то на экране и радуйтесь.
Более того, закрыта и их технология DSPLink для организации нормального многозадачного общения с DSP.
Т.е. да, в объектных кодах качайте, но если что пеняйте на себя.
Для демонстраций нереальных возможностей OMAP хватает, но для бюджетного и конкурентоспособного проекта это не катит.
Умельцы без серьезных успехов пытаются использовать некую халявную технологию DSP-bridge.
Даже удалось использовать DSP для вычисления FFT. (серьезный успех ), но застопорились на патчах Линукса.

На самом деле рального софта для поддержки и тестирования железа OMAP-ов кот наплакал.
А тот что есть демонстрирует только как успешно можно кривыми драйверами убить производительность даже Cortex-A8.
Скажем из OneNAND (16-и битный интерфейс, до 100 МByte/s )скорость чтения у них получается всего 6 МByte/s при 100% загрузке проца!
Для сравнения в RTOS на i.MX27 (400 МГц ARM9) даже с устаревшей 25 МГц 4-bit SD карты скорость чтения с файловой системой более 12 МByte/s.
А именно OneNAND главная надежда при повышении скорости работы приложений с USB компьютере.

О том что в открытом проекте заюзать TrustZone в OMAP3 также нереально как в самсунгая я уже молчу.

Ну, Вы, батенька, махнули - нет разницы в производительности между ARM11 и Cortex-A8. По бенчмаркам BDTI Cortex почти в два раза быстрее ARM11.
По компиляторам - сейчас GCC уже подерживает векторные операции на NEON, так что его преимуществами можно пользоваться вовсю.

По DSP - да, исходников кодеков не дается. Вопрос - а оно Вам надо? Если все-таки надо, то есть два пути - либо купить, либо написать самим. Ядро там стандартное, С64х+, отладка в CCS + JTAG. Алгоритм можно грузить как через DSPLink, так и фреймворк верхнего уровня использовать (типа CodecEngine). Сам DSPLink открыт как минимум со стороны ARM, есть кит для портирования.

По тестированию железа - какой софт Вам нужен? Драйвера под Linux и WinCE - стандартные, если нужна ОСРВ - тоже пожалуйста - QNX, WindRiver, все данные по производительности Linux - драйверов на сайте TI можно посмотреть.
TrustZone - отдельная песня. Все зависит от объема производства. Если хотя бы 100К по году - уже можно разговаривать. Но нужно иметь в виду, что для использования TrustZone нужно получить лицензию госдепа США (впрочем, так же, как и для модуля криптования на iMX27).

Такое впечатление, что у Вас просто неудачный заход с ОМАП получился. Только за прошлый год 17000 биглбордов продали - это о чем-то говорит, народ просто так покупать не будет.

С OMAP-ами конечно дело имел.
Бенчмарк BDTI очень много вопросов оставляет, и мягко говоря авторитетом еще не является.
Тем более что мы запускаем Линукс, а не BDTI.

Про NEON обнадежили, тока покажите хоть один кусок открытого осмысленного кода под NEON в Линуксе.

В общем еще раз фиксирую ваше внимание на том что ключевым элементом успешной бюджетной разработки является наличие полного набора софта в компилируемых исходниках и желательно без обязательного программирования дополнительных архитектур.
Самсунги этим обеспечены по полной. Рекомендую взглянуть все таки что выложено под Самсунги.
Попробуйте вытребовать это у TI
OMAP-ы предлагают открытый софт выковыривать из патченного Линукса причем с крайне тормозными драйверами.
Вы сами трезво оцените скорости файловых операций Линукса на OMAP-ах, это курам насмех.
Можно конечно все переписать, но у кого есть лишнее время?
QNX под OMAP-ы тоже не открывает ключевых драйверов для OMAP.

Это здоровый минус варианта OMAP-ов, вернее это так поставлена сегментация рынка у TI.
Т.е. они нащупали такой слой разработчиков которых можно купить на дешевый "купон" и которые не критично оценивают трудозатраты и перспективы реальной разработки на этой платформе. А TI в свою очередь и не рассчитывает, что этот сегмент станет серьезным потребителем.
Поэтому относится к самостоятельным разработчикам крайне цинично. Типа а попробуйте-ка еще и DSP попрограмировать, а вот еще и NEON неизвестно на чем. Лишние архитектуры выставляя как преимущество хотя они на самом деле тормоза в разработке особенно в контексте данной темы.

И вообще я не про то, что OMAP-ы сами по себе плохие, а о том что разработка на Самсунгах будет легче, быстрее и дешевле.

17000 штук в россию? нифига себе!
Да и как то сравнивать S3C6410 и OMAP35xx кривовато, если сравнивать тогда уж с AM3517 (DDR2, шаг 0.65мм с 17х17мм корпусом)
Че их уговаривать, наше дело прокукарекать а там рассветай, не расЦветай
а идея немного старовата и появилась она после выхода как раз OMAP35xx и после недельного обдумывания понял что это очередная идея "высосана из пальца"
Но вы не слушайте меня и подобных как я, продолжайте делать и не обращайте внимания на всяких скептиков и обязательно пишите ваши мысли вслух.
Интересно как размышляют другие.
Хоть чужим успехам порадуемся ну или ехидно посмеемся.

ARM Cortex-A8 in OMAP3 is a high performance dual-issue applications processor which reaches a performance of 2.0 DMIPS/MHz (compared to ARM11 at 1.2 DMIPS/MHz).



Подозреваю что оно в ядре никогда и не поможет - какие Вы видите задачи в ядре для потоковых вычислений ? А вообще

Получив дев.кит на S3C6410, временно закрыл для себя вопрос выбора процессора, особенно смены производителя. Как получу какие-то полезные для обсуждения результаты, именно в контектсе патента, обязательно выложу. Переход от S3 скорее всего будет не к ОМАР, а к S5PC100 от того же Samsung.

Эти цифры берутся всегда в отрыве от реальности. С предположением что весь код выполняется из кэша и пишется если не на ассемблере то с использованием сверх эффективного компилятора С-и.

На самом деле ARM не доточил даже свой RealView до Cortex-A8 в чем честно и признается в каком-то из аппнотов.
От том что GCC и Линукс просто понизят всю производительность и Cortex-A8 и ARM11 ниже плинтуса где они сравняются можно видеть из бенчмарков TI.

Читая рекламу NEON-а я так предполагал, что он мог бы сильно ускорить алгоритмы сжатия для той же файловой системы JFFS2, ускорить создание хешированных индексов и сами алгоритмы поиска, ускорить алгоритмы проверки целостности данных и т.д.

Но реально мы видим что NEON программируют исключительно на ассемблере.
Да, обнаружились следы применения NEON-а в пакете FFMPEG.
Многокилобайтные ассемблерные файлы без единой строчки комментариев. Нам это сильно поможет
Косвенно можно понять, что NEON там делает DCT преобразование.

Юмор в том, что в OMAP-ах этим штатно должен заниматься DSP сопроцессор. Т.е. TI как бы не доверяют NEON-у либо не умеют его программировать.
Что уж тут говорить о более мелких разработчиках.
FFMPEG в свою очередь ничего не умеет делать в связке с DSP от TI. Они просто конкуренты.
И как можно ориентироваться на такую платформу (в смысле OMAP) разрываемую противоречиями?

Зато в S3C64xx тихо и мирно работает DSP не хуже чем у TI, для него дается микрокод firmware делающий тот же DCT, но не используя ресурсы ARM-а в отличии от NEON-а. Есть абсолютно прозрачные исходники применения этого DSP сопроцессора, комментированные и не привязанные к какой либо операционке.

хм.. поправте меня если что, на S5PC100, фулл спида точно хватит на мега девайс?
On-chip USB 2.0 OTG supporting high speed (480Mbps, on-chip transceiver)
On-chip USB 1.1 Host supporting full speed (12Mbps, on-chip transceiver)

Достаточно вспомнить историю - 133 МГц амдшная разогнанная четверка уделывала пентиумы по всем тестам, но длилось их призрачное счастье до появления компиляторов с поддержкой пентиумов а когда появились первенцы simd - расширение mmx - уже ниукого не было сомнений кто в доме хозяин Тем более с раширениями simd - одной поддержки компилятора мало - нужно перестраивать алгоритмы, не так быстро происходит переход.

Отлично, я и оценил времени в год.
Если за следующий год не получится сделать платформу на S3C6410,
то адназначна надо будет переходить на S5PC100 или i.MX51

Александр, Вас самого разрывают противоречия (не принимайте всерьез)
Вы сами ссылаетесь на тесты по производительности, сравнивая ARM11 и Cortex-A8, а потом говорите, что все эти тесты искуственны. Для чего тогда вообще на них смотреть? Объективность в том, что сама компания ARM считает Cortex более современным и производительным ядром.
Поддержка NEON зависит откомпилятора, но фишка в том, что TI ту ни при чем и если Вы перейдете на Cortex-A8 от Самсунг - проблемы поддержки NEON в Cortex Вы не избежите. Ну и я Вам уже писал, что GCC поддерживает операции с NEON, надо в опциях при компиляции включить оптимизацию. По крайней мере те проекты, которые сейчас делаются на OPEN Embedвed NEON используют.
Опять же не надо по одному апноту не надо всех уверять, что программируют NEON реально только на асме. Можно или опять же OPEN Embedded смотреть, либо официальный источник:
http://www.arm.com/products/DevTools/RVDSPro.html

И давайте мухи отдельно от котлет держать. NEON разрабатывался для поддержки векторных SIMD операций на ARM-ядре. В том числе для тех, кто хочет DCT выполнятьна ARM'е. И FFMPEG писАлся под ARM. А выполнять то же самое DCT на интегрированном DSP тоже никто не мешает - просто не на всех процессорах он есть. Там, где есть - там можно разгрузить ARM для выполнения других задач. Где нет - можно пользоваться ресурсами ARM'a.
Соответственно TI доверяет разработчику выбрать процессор, на котором он будет выполнять это DCT или еще что.

Про использование DSP на Самсунге - опять же, это firmware, которе прошито раз и навсегда. Соответственно, если понадобится сделать что-то отличное - это firmware будет абсолютно бесполезным. А DSP на TI можно программировать. И исходники для применения оже есть.
Можете, например, посмотреть здесь как работать с DSP на TI:
http://wiki.davincidsp.com/index.php/Category:BIOSLink

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

И еще - если Вы смотрите в сторону i.MX51 - что скажете по поводу вот этого:
http://focus.ti.com/docs/prod/folders/print/am3517.html

Для меня подобные споры разрешаются проще: для экмпериментов вналичии у меня есть i.MX51 и S3C6410, TI к сожалению, нет

Тут в поисках дешевого JTAG отладчика ядра Линукса наткнулся на реальных конкурентов по S3C6410

http://www.techor.com/product-282.html

Неплохой готовый OEM модуль для USB микрокомпьютера. При количестве от 100 шт. стоит 35 Евро
Кто-то у них круто заказал и они пока продавать не имеют права.
Но в начале 2010 собираются завалить этим рынок.

Если у Вас есть контакты с ними, узнайте, пожалуйста, когда конкретно в 2010 году они могут начать продажи.

гуглем случайно наткнулся на такой пдф www.industech.com.cn/Upload/image/20100206111003slt.pdf

с китайским у меня никак ))) однако дата 2010‐1‐19 и цены вроде распознаются (если учесть курс ~ 9,4 юаня за 1 евро):

100+ - 580RMB ~ 61.7 Eur
500+ - 520RMB ~ 55.35 Eur
1K+ - 480RMB ~ 51.09 Eur

т.е. цена почти вдвое превышает упомянутую выше... (((

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