[one_man_show 0]

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

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

[Petka 0]

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

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

[masterofnature 0]

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

Если не сделать это все на одном кристалле.

Но это уже совсем другой уровень разработки.

хотя...надо же поддерживать отечественного производителя.

Интересно - есть ли возможность купить АРМ в бескорпусном варианте?

[el_chapo 0]

А почему вы не смотрели в сторону TI OMAP3?

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

Только вот вроде у OMAP3530 нет TrustZone, но вот у телефонного варианта 3430 - есть.

 

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

[AlexandrY 3]

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

 

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

 

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

[el_chapo 0]

...

Ну, Вы, батенька, махнули - нет разницы в производительности между 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 биглбордов продали - это о чем-то говорит, народ просто так покупать не будет.

[AlexandrY 3]

С OMAP-ами конечно дело имел.

Бенчмарк BDTI очень много вопросов оставляет, и мягко говоря авторитетом еще не является.

Тем более что мы запускаем Линукс, а не BDTI.

 

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

 

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

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

Попробуйте вытребовать это у TI

OMAP-ы предлагают открытый софт выковыривать из патченного Линукса причем с крайне тормозными драйверами.

Вы сами трезво оцените скорости файловых операций Линукса на OMAP-ах, это курам насмех.

Можно конечно все переписать, но у кого есть лишнее время?

QNX под OMAP-ы тоже не открывает ключевых драйверов для OMAP.

 

Это здоровый минус варианта OMAP-ов, вернее это так поставлена сегментация рынка у TI.

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

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

 

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

 

 

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

[walsv 0]

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

 

17000 штук в россию? нифига себе!

Да и как то сравнивать S3C6410 и OMAP35xx кривовато, если сравнивать тогда уж с AM3517 (DDR2, шаг 0.65мм с 17х17мм корпусом)

Че их уговаривать, наше дело прокукарекать а там рассветай, не расЦветай

а идея немного старовата и появилась она после выхода как раз OMAP35xx и после недельного обдумывания понял что это очередная идея "высосана из пальца"

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

Интересно как размышляют другие.

Хоть чужим успехам порадуемся ну или ехидно посмеемся.

Изменено 4 декабря, 2009 пользователем wangan

[sasamy 0]

Разницы в скорости ядра 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

[one_man_show 0]

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

[AlexandrY 3]

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

 

На самом деле 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).

[walsv 0]

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

хм.. поправте меня если что, на 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)

[sasamy 0]

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

 

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

[AlexandrY 3]

Отлично, я и оценил времени в год.

Если за следующий год не получится сделать платформу на S3C6410,

то адназначна надо будет переходить на S5PC100 или i.MX51

 

.... но длилось их призрачное счастье до появления компиляторов с поддержкой ....

[el_chapo 0]

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

 

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

Александр, Вас самого разрывают противоречия :) (не принимайте всерьез)

Вы сами ссылаетесь на тесты по производительности, сравнивая 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