Выбор процессора для u-PC, По мотивам "Патента для нового ..." Опции

[one_man_show]

Коллеги!

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

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

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

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

[KRS]

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

[AlexandrY]

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

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

Начнем конечно с того что корпус у 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 также нереально как в самсунгая я уже молчу.

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

[sasamy]

Разницы в скорости ядра Cortex-A8 и ARM11 почти никакой.

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).

В скорости работы Линукса этот NEON пока никак не помогает.

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

NEON is currently used by

* ffmpeg - libavcodec used by mplayer, omapfbplay, and many other linux applications
* libpixman - used by X.org and Mozilla & Webkit browsers to render text and graphics
* Bluez - official Linux Bluetooth stack

[AlexandrY]

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

На самом деле 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 сопроцессора, комментированные и не привязанные к какой либо операционке.

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).

[sasamy]

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

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