Представлены (https://radix.pro) первые выпуски новой системы сборки программного обеспечения Radix.pro (https://radix.pro), которая представляет основу для разработки различных дистрибутивов для встраиваемых систем. Система сборки (https://radix.pro/build-system/overview) включает набор Make-файлов и скриптов, написанных на языках Bash и Perl, которые предоставляют средства для работы с архивами исходных текстов входящих в состав дистрибутива компонентов, сборки дистрибутива, управления пакетами и установки. В рамках проекта также развивается дистрибутив Linux (https://radix.pro/platform/), создаваемый в среде Radix.pro. Периодические сборки дистрибутива доступны (ftp://ftp.radix.pro/radix/platform/releases/1.0.334/) для устройств на базе архитектуры ARM (Cubieboard, Cubietrack, OMAP5 uEVM), MIPS (Creator CI20) и x86/x86_64.
Особенности системы сборки:
- Позволяет создавать проекты, удовлетворяющие современным требованиям управления конфигурациями (CM) и непрерывной интеграции (CI);- Система ориентирована на одновременную, многопоточную сборку конечного продукта для нескольких целевых устройств с различной архитектурой;
- Позволяет создавать как встроенное ПО для микроконтроллеров, так и дистрибутивы общего назначения.
- Предоставляются механизмы управления межпакетными зависимостями и управления пакетами, как на стадии сборки продукта, так и во время работы на целевой машине.
- В систему сборки встроены инструменты управления пакетами, которые позволяют автоматизировать создание временной целевой файловой системы во время процесса сборки, что можно использовать для тестирования создаваемого дистрибутива.
- Компоненты системы сборки размещаются в одном каталоге, который монтируется в исходное дерево разрабатываемого продукта.
Код системы сборки открыт (http://svn.radix.pro/wsvn/build-system), но лицензия не определена - ведется работа над текстом открытой лицензии, которая в своей основе будет похожа на лицензию Apache-2.0. В открытом репозитории (http://git.radix.pro/) можно найти примеры подготовки сборок для собственных применений.
URL: https://radix.pro
Новость: http://www.opennet.me/opennews/art.shtml?num=43956
>написанных на языках Bash и PerlСпасибо, не нужно. На дворе 21 век уже давно.
И что, теперь билдсистему на node.js писать?
Тише! Вдруг хабрахипстеры услышат!
С разморозкой, товарищ.
node.js сам без Python даже не соберётся.
> node.js сам без Python даже не соберётся.Сейчас вообще все собирается, как в этом английском стихотворении (в переводе С. Маршака):
https://www.google.ru/search?q=дом+который+построил+джек
>Сейчас вообще все собирается, как в этом английском стихотворении (в переводе С. Маршака):Как сейчас модно говорить: Вы таки не умеете в рекурсию?
> И что, теперь билдсистему на node.js писать?Debootstrap'нуть систему на основе убунты или дебиана из готовых пакетов как-то проще. В соседней новости про pi читаем, просвещаемся.
Если не "Bash и Perl", то что?
Perl умер, учите Python
>Perl умер, учите PythonPython умер, учите Perl!
Звучит как - я ниалсил Perl.
Кому он нужен, чтобы его учить?
> Perl умер, учите PythonОсобой разницы нет. Мне лично Python не по душе лишь тем, что патчить его код надо без опции -b, иначе, из-за отсутствия отступов, расстроится ЛОГИКА.
> Особой разницы нет. Мне лично Python не по душе лишь тем, что
> патчить его код надо без опции -b, иначе, из-за отсутствия отступов,
> расстроится ЛОГИКА.--backup_-то каким боком к пробелам? Наверное, -l / --ignore-whitespace.
diff(1)
-b
Игнорировать хвостовые пробелы (символы пробела и табуляции) и считать любые строки из пробелов совпадающими.
Пожалуйста пример, в каком случае вообще нужен этот параметр
А всё, допёр, вы не про нативные фичи питона, а про утилиты patch/diff. Я уже забыл, когда ими пользовался. Есть же нормальные системы контроля версий и их хватает выше крыши
С одного на другое переползается легко и непринуждённо при необходимости.
>Perl умер, учите PythonПри всем уважении к обоим языкам, учить надо сишку.
>>Perl умер, учите Python
> При всем уважении к обоим языкам, учить надо сишку.Сишка - для хардкора. Python - для студентов-научников. Perl - для альтернативно мыслящих.
> Python - для студентов-научников.Это школота так себя называет: "студенты-научники"? Забавно.
> Perl умер, учите PythonВи таки слишком читали Брюсова? Ви - неправы!
Не читал Брюсова, но очевидно же что Perl, Basic (включая VBS), Pascal (и его вариация в Delphi) - всё это умерло. Есть конечно "последние программисты", которые "так привыкли" и могут на коленке очень быстро написать на них одноразовый костыль, но это ничего не решает, кроме них такой софт никто не будет сопровождать, да и ни к чему. Чем исправлять такое - быстрее заново написать на чём-то вменяемом, что многие и делают
Что-нибудь вменяемое - надо полагать, С#, dot.net, Power Shell и т.п.? Или язык HTML, Java Script, Flash? Тогда не договоримся, увы...
Абсолютно с Вами согласен. Я вообще стал замечать, что новые языки "программирования" создаются по принципу: "я не понимаю как это работает, напишу ка я лучше свой язык".
Python гораздо старше выше названных дотнетов и флешей, он практически ровесник Perl.
Pascal и Basic - это такой анахронизм из времён, когда люди не знали, что им придётся писать софт сложнее тупого калькулятора и что исходники должны быть читаемыми. Этот первый блин был явно комом. Вы ещё повозмущайтесь, почему всё не пишут на фортране
C# это не часть .NET? VB вообще-то входит в .NET, но это его нифига не спасает.
HTML и JS если для гуя или веба ещё куда ни шло, но системный софт и автоматизация и вообще в контексте сабжа - даже не смешно.
Flash? Это вечно падающее тормозящее решето вообще на что-то способно?
Вы шутник
> Что-нибудь вменяемое - надо полагать, С#, dot.net, Power Shell и т.п.? Или
> язык HTML, Java Script, Flash? Тогда не договоримся, увы...программеры на html такие программеры ....
> Не читал Брюсова, (.. и далее по тексту...)А Ви почитайте, почитайте. В частности, http://www.stihi-rus.ru/1/Bryusov/208.htm . Слово "поэт", правда, замените (мысленно) на "программист".
И, да, это - ирония.
> Perl умер, учите PythonСтранно слышать такое после релиза Perl6, в котором реализована, внимание, *полная* поддержка кода Perl5.
Вообще, что Python, что Perl - какая разница? Расплодили технологий на любой вкус и цвет, наизобретали клонов модулей на разных языках программирования; но самого главного так и не поняли: что все мы пользуемся не фреймфорками, не языками, не синтаксисом - мы пользуемся программами, и плевать, на каком языке они написаны, если выполняют свои задачи.
Мне что, выкидывать программу, если она написана на Lisp или Ocaml? Почему? Только потому, что они типа "устаревшие"?
Большинство программ, составляющих базу систем Linux, BSD, Hurd и т.д. написаны вообще на сях. А сям уже сто лет в обед. Вас и это смущает? Вам надо обязательно bash на Java переписать просто, чтоб было? И обязательно заменить нормальный работающий sysvinit, чтобы вместо init-а у нас был мега-бинарь, на который жёстко завязаны все системные сервисы, и который системный администратор, который в общем-то не обязан быть также программистом, не может внести изменения, если что-то не работает?
--
А Perl у них, смотрите-ка, умер. Как же.
Окей, давайте рассмотрим открытую Bugzilla и проприетарную Jira. Bugzilla написан на Си и Perl. Jira - на Java. Bugzilla имеет вменяемую базу данных и обвязки поверх для работы с ней. Вся логика - в базе. Если что-то нужно, нужно, что не предоставляет интерфейс, милости просим, один запрос к базе, и всё прекрасно. В Jira вся логика сосредоточена в приложении, а база - одна большая помойка, в которой хрен разберёшься без реверс-инжиниринга устройства системы посредством анализа запросов браузера.
Это так, что ли, умер Perl? В таком случае я согласен быть некромантом!
И это при том, что я на Perl не писал уже очень, очень-очень давно.--
Простите, сегодня что-то у меня всякого накипело.
Абсолютно с вами согласен. Вот, например, взяли и перескочили на PHP, а ведь надо было просто понять что такое https://en.wikipedia.org/wiki/Mason_%28Perl%29
и использовать.
Пожалуй, что нет, этот пример не к месту совершенно. Mason появился всего 5 лет назад, а PHP5 уже 12 лет как на рынке.
Python, Lua
bourne shell и perl
"набор Make-файлов и скриптов, написанных на языках Bash и Perl" - как-то подозрительно много всего, почему не использовать один современный инстурмент, вместо кучи костылей. на bash можно очень плохо писать, make - голову сломаешь, perl - только чтобы писать, а не читать.
Сам удивляюсь.
Ведь если отбросить предвзятость, то перл может все, что может баш. Это даже из текста новости явно следует. А вот наоборот - увы. Ну и зачем тогда плодить зоопарк ЯП? Ради "чтобы було"? Непонятно.
> Сам удивляюсь.
> Ведь если отбросить предвзятость, то перл может все, что может баш. Это
> даже из текста новости явно следует. А вот наоборот - увы.
> Ну и зачем тогда плодить зоопарк ЯП? Ради "чтобы було"? Непонятно.Зоопарк нужен лишь тогда, когда на целевой машине нет Perl интерпретатора, а делать что-то надо. Вот тогда нужен shell. На машине разработчика для работы с древовидными конструкциями использовать shell не удобно.
>Зоопарк нужен лишь тогда, когда на целевой машине нет Perl интерпретатора, а делать что-то надо. Вот тогда нужен shell. На машине разработчика для работы с древовидными конструкциями использовать shell не удобно.а что делать, когда на целевой машине нет шела?)
ну без него нельзя, соберите хотябы sash (http://linuxcommand.org/man_pages/sash8.html)
> "набор Make-файлов и скриптов, написанных на языках Bash и Perl" - как-то
> подозрительно много всего, почему не использовать один современный инстурмент, вместо
> кучи костылей. на bash можно очень плохо писать, make - голову
> сломаешь, perl - только чтобы писать, а не читать.Make - довольно простой язык. Все пакеты собираются именно с использованием Make. Bash и Perl читать никто не заставляет, просто можно пользоваться функциями, написанными на них, ну или не пользоваться.
Да ладно, Perl норм, но Bash - да, для гурманов...
интересна штука !!! на до попробывать
Они опять изобрели buildroot, только хуже.
Ну почему сразу BuildRoot, Openembedded, Yocto и иже с ними. Здесь никто не заставляет пользователя учить новые языки описания сценариев сборки и не ограничивает пользователя набором: распоковать, сконфигурировать, инсталлировать. Все на родном GNU Make.
>Все на родном GNU Make.Зачем тогда вот так делать?
>ведется работа над текстом открытой лицензии, которая в своей основе будет похожа на лицензию Apache-2.0
Просто по тому, что нет еще лицензии на русском языке, текст которой соответствует ГК РФ. И еще потому, что GPL лицензия не дает полной свободы пользователям.А GNU Make - всего лишь средство не имеющее никакого отношения к лицензированию.
Вам надо было ознакомиться с buildroot - вот он как раз на родном GNU Make, не ограничен "набором: распоковать, сконфигурировать, инсталлировать" и предоставляет кучу готовых протестированных средств для написания новых/кастомизации существующих сценариев сбоорки. Добавьте к этому огромное комьюнити включаещее опытных разработчиков и постоянно обновляющих базу до актуального состояния, непрерывное тестирование на своей сборочной ферме да и просто всемирную известность которая гарантирует проекту актуальность.
Знаю. Но в вашей фразе слишком много противоречий. Например, как вы собираетесь владеть продуктом и поддерживать его для своих заказчиков, если вы собрали его из кусков, которые вытянули из сети? Вы, что, в случае рекламаций будете отсылать заказчика к сообществу?
Как вы собираетесь обеспечивать линейки продуктов на buildRoot? Как решать вопросы многопоточной, одновременной сборки собственных прошивок сразу на серию собственных железяк?Словом, пожалуйста не путайте студента, которому надо собрать Ubuntu под Cubietrack и коллектив разработчиков, который пишет софт для серии железяк, которые уже проданы и находятся в "полях" милионными тиражами.
Главное понимать разницу между словами "владеть" и "пользоваться". BuildRoot предлагает пользоваться результатами труда сообщества для собственных единичных нужд, а Radix.pro предлагает владеть собственными продуктами, используя простое средство.
> Вам надо было ознакомиться с buildroot - вот он как раз на
> родном GNU Make, не ограничен "набором: распоковать, сконфигурировать, инсталлировать"
> и предоставляет кучу готовых протестированных средств для написания новых/кастомизации
> существующих сценариев сбоорки. Добавьте к этому огромное комьюнити включаещее опытных
> разработчиков и постоянно обновляющих базу до актуального состояния, непрерывное тестирование
> на своей сборочной ферме да и просто всемирную известность которая гарантирует
> проекту актуальность.
> Например, как вы собираетесь владеть продуктом и поддерживать его для своих заказчиков, если вы собрали его из кусков, которые вытянули из сети?это просто бугага ^ 2. Вы хотите сказать вы не пользуютесь кусками вытянутыми по сети ? Тогда что вы собираете - "все свое все с огорода" ?
> коллектив разработчиков, который пишет софт для серии железяк
и что вы написали кроме небольшой части кастомизации для OMAP5 ?
> Radix.pro предлагает владеть собственными продуктами
ну вранье же - он ни капли не добавит прав собственности по сравнению с любой другой сборочной средой, потому что львиная часть кода написана не вами и вам не принадлежит
> это просто бугага ^ 2. Вы хотите сказать вы не пользуютесь кусками
> вытянутыми по сети ? Тогда что вы собираете - "все свое
> все с огорода" ?Производители железа предоставляют патчи на ядро, u-boot, драйвера графики ... это и берется из сети.
> и что вы написали кроме небольшой части кастомизации для OMAP5 ?
я не писал кастомизацию под OMAP5, TI поставляет HAL. Я писал систему сборки и сценарии сборки пакетов для платформы. Все это вы можете посмотреть в репозиториях svn.radix.pro и решить самостоятельно, что и кому там принадлежит.
> ну вранье же - он ни капли не добавит прав собственности по
> сравнению с любой другой сборочной средой, потому что львиная часть кода
> написана не вами и вам не принадлежитНаверное не надо путать права собственности, с инженерным владением тем, продуктом, который вы создаете. Я говорю о том, что если вы поставляете ПО, то, наверное, вы должны понимать как оно собрано и как работает? Или вы считаете, что можно слепить и продать что попало? Если да, то после продажи лучше всего скрыться, ведь рано или позно заказчик поймет, что надо заниматься обновлением продукта и устранением ошибок.
> Производители железа предоставляют патчи на ядро, u-boot, драйвера графики ... это и берется из сети.т.е. ВСЁ берете из сети
> Я писал систему сборки и сценарии сборки пакетов для платформы
т.е. ничего что дает право собсвенности
> Я говорю о том, что если вы поставляете ПО, то, наверное, вы должны понимать как оно собрано и как работает?
я его пишу и знаю что даже если код под GPL копирайты что-то означают и тот кто собирает никакого отношения к этому коду не имеет - ни права собственности ни проава инженерного владения (что это за бред вообще) потому что элементарно не знает техничеких деталей
> Или вы считаете, что можно слепить и продать что попало?
это как раз то чем вы занимаетесь
> после продажи лучше всего скрыться, ведь рано или позно заказчик поймет, что надо заниматься обновлением продукта и устранением ошибок
вам - очеаидно да, мне наоборот - лучше пропиариться на своих опенсорсных проектах чтобы иметь заказы на коммерческую разработку
>> Или вы считаете, что можно слепить и продать что попало?
> это как раз то чем вы занимаетесьНу понятно. Знаете, а ведь переход на личные оскорбления означает, что аргументы разумные давно закончились. Что же вас так сильно выбивает из колеи? Помошь нужна?
> Что же вас так сильно выбивает из колеи?беспросветная тупость импортозамещателей и их покровителей
>> Что же вас так сильно выбивает из колеи?
> беспросветная тупость импортозамещателей и их покровителейТак не читайте по утрам Советских Газет (хотя, ваша обеспокоенность вполне понятна).
> ведется работа над адаптированным к ГК РФ текстом открытой лицензии, которая в своей основе будет похожа на лицензию Apache 2.0
> Debian на MIPS II серверах, а работать заставляют на новых ядрах от Imagination
> инженерное владение
> ваша обеспокоенность вполне понятнапонятно что понятна - что тут вообще может быть неопнятного
А на счет тестирования на собственной ферме, наверное стоит добавить пример Debian-а Для MIPS Creator CI20. Так вот в поставке Debian полно бинарей вообще для x86 архитектуры, более того, собирают Debian на MIPS II серверах, а работать заставляют на новых ядрах от Imagination. Мне лично такое тестирование "помойки" не по душе.> Вам надо было ознакомиться с buildroot - вот он как раз на
> родном GNU Make, не ограничен "набором: распоковать, сконфигурировать, инсталлировать"
> и предоставляет кучу готовых протестированных средств для написания новых/кастомизации
> существующих сценариев сбоорки. Добавьте к этому огромное комьюнити включаещее опытных
> разработчиков и постоянно обновляющих базу до актуального состояния, непрерывное тестирование
> на своей сборочной ферме да и просто всемирную известность которая гарантирует
> проекту актуальность.
Оставлю это велосипедистам для ознакомления: https://wiki.gentoo.org/wiki/Banana_Pi_the_Gentoo_Way в статье рассказывается как собрать образ системы используя кластер DistCC и кроскомпиляцию. Всё собирается стандартными средствами gentoo: emerge используя стандартный репозиторий portage.
Все знают, что Gentoo - это "канпелять"™. Но ни у одной сволочи из знающих про "канпелять"™ не доходит прочитать определение слова "метадистрибутив". Слишком это сложно, проще свой велосипед поизобретать.
Каким образом предлагается получить crooss-toolchain для таргет платы ? Использовать crosstool-ng, buildroot, crossdev, etc ?
Toolchain можно получить тремя способами:
- взять готовый из набора ftp://ftp.radix.pro/toolchains/x86_64/ (загружаются автоматически см. https://radix.pro/build-system/practice/#getting_toolchains);
- собрать собственны, что вообще не трудно (см. http://svn.radix.pro/wsvn/toolchains/trunk/);
- подключить любой по инструкции https://radix.pro/build-system/overview/#toolchain_connectionТакие средства как crosstool-ng, buildroot, сначала собирают toolchain, а затем софт. Мы придерживаемся другого принципа. Toolchain - это отдельный продукт над которым должны трудиться специалисты более близкие к архитектуре железа, да и каждый раз пересобирать toolchain не выгодно.
Еще несколько слов о тулчейнах. Лучше всего их готовить самостоятельно, так как использование сторонних тулчейнов может тормозить развитие вашего продукта. Поясню.
Допустим вы используете чужой тулчейн, который в своем составе содержит старую GLibc, а вам надо делать свой продукт на новой версии GLibc (а вы для своей rootfs брали GLibc из тулчейна). Тогда вам придется ждать когда поставщик тулчейна сделает новый или всетаки самому сделать нужный тулчейн (https://radix.pro/build-system/overview/#toolchains).> Toolchain можно получить тремя способами:
> - взять готовый из набора ftp://ftp.radix.pro/toolchains/x86_64/ (загружаются автоматически
> см. https://radix.pro/build-system/practice/#getting_toolchains);
> - собрать собственны, что вообще не трудно (см. http://svn.radix.pro/wsvn/toolchains/trunk/);
> - подключить любой по инструкции https://radix.pro/build-system/overview/#toolchain_connection
> Такие средства как crosstool-ng, buildroot, сначала собирают toolchain, а затем софт. Мы
> придерживаемся другого принципа. Toolchain - это отдельный продукт над которым должны
> трудиться специалисты более близкие к архитектуре железа, да и каждый раз
> пересобирать toolchain не выгодно.
https://radix.pro/build-system/overview/#toolchainsOMAP543X_EGLIBC_ARCH = arm-omap543x-linux-gnueabihf
...
OMAP543X_EGLIBC_ARCH_FLAGS = -march=armv7-a -mtune=cortex-a15 \
-mfloat-abi=softfp -mfpu=neon-vfpv4 \
-mabi=aapcs-linux -fomit-frame-pointer
бгг, использовать кросскомпилятор с ABI hard-float а в параметрах указывать softf-loat. И эти люди с высоких трибун вещают о помойке в дебиане.
Спасибо за сообщение об опечатке на страничках сайта.
Аноним, я с трудом нащупал два ваших раздражитеся: импортозамещение и Debian. Вы скажите сразу, о чем еще нельзя говорить в Вашем присутствии. Огласите весь список пожалуйста.
> о чем еще нельзя говорить в Вашем присутствииВам вообще не надо было заикаться что буилдруты, ёкты и дебианы - это все фуфло для школьников. Потому что реально дело обстоит так что все наоборот - это поймет любой человек который хоть немного в теме. Тот же буилдрут примерно на порядок круче - по количеству поддерживаемых архитектур, кросскомпиляторов, выбору libc, систем инициализации, готовых пакгажей - их качеству и уровню тестирования. Ёкта уже на пару порядков будет круче для дистрибютеров - там система опакечивания есть и готовых пакетов прорва хоть и кастомизацией более геморная. Дебиан конечно немного не в тему для встраиваемых устройств.
> Вам вообще не надо было заикаться что буилдруты, ёкты и дебианы
> - это все фуфло для школьников. Потому что реально дело обстоит
> так что все наоборот - это поймет любой человек который хоть
> немного в теме. Тот же буилдрут примерно на порядок круче -
> по количеству поддерживаемых архитектур, кросскомпиляторов, выбору libc, систем инициализации,
> готовых пакгажей - их качеству и уровню тестирования. Ёкта уже на
> пару порядков будет круче для дистрибютеров - там система опакечивания есть
> и готовых пакетов прорва хоть и кастомизацией более геморная. Дебиан конечно
> немного не в тему для встраиваемых устройств.Все эти умные слова я слышал, все чем может гордится Yocto как система сборки, а не как набор готовых слоев (если вы понимаете разницу), давно реализовано в build-system от Radix.pro. А слои ваши никому не нужны если речь идет о собственной железяке, это изобилие приводит к тому, что особо ленивые запихивают в at91sam7s uCLinux, или собирают полный Debian для роутера.
Расскажите лучше о Ваших проектах, на которых вы себе PR делаете.
> все чем может гордится Yocto как система сборки, а не как набор готовых слоев (если вы понимаете разницу), давно реализовано в build-system от Radix.proпохоже вы не очень понимаете что актуально а что нет. Просто иметь систему которая что-то собирает - это никому не интересно и бесполезно, нужны как раз готовые сценарии - слои с набором пакетов и патчей под разные архитектуры, слои адаптации под процессор в ёкте уже есть для всех популярных. Бар-метал для динозавра arm7 - это я вообще не знаю даже кому понадобился :) Вы например попробуйте собрать без OBS в своей системе Nemo Mobile или там Tizen или Openwrt - испытаете попа-боли.
и перестаньте злиться, жить надо весело и спокойно
Кстати. История этой опечатки довольно поучительная. Как только появились эти платы, TI поставлял бинарный стек поддержки SGX54XX собранный именно под softfp. И на первых порах приходилось все собирать именоо без поддержки hard-float (хотя CPU продвинутый), чтобы ускоритель задействовать.Когда я попросил инженеров TI собрать user-space драйвера SGX54xx графики нормальным тулчейном, они сказали что в их репозиториях такая каша и подключение другого тулчейна в принципе невозможна, я перешел на другие железяки, будет время сделаю DRA7...
Теперь TI вообще забросил omap5uevm и кинулся на DRA7...
Это еще один пример того, какая грамотная поддержка разработчиков осуществляется такими светилами человечества как Texas Instruments.
> поддержка разработчиков осуществляется такими светилами человечества как Texas Instruments.там у них все печально с omap с тех пор как MS перекупил ноклу - она была основным покупателем их процессоров. Впрочем сколько я для ядругих линеек процессоров видел TI SDK - это полное г..но. Зря вы на них решили равняться :)
>> поддержка разработчиков осуществляется такими светилами человечества как Texas Instruments.
> там у них все печально с omap с тех пор как MS
> перекупил ноклу - она была основным покупателем их процессоров. Впрочем сколько
> я для ядругих линеек процессоров видел TI SDK - это полное
> г..но. Зря вы на них решили равняться :)Я сейчас смотрю в сторону Imagination у них поддержка нормальная. По крайней мере по моей просьбе выдали (положили на Вики eLinux) все бинари для SGX на MIPS Creator ci20. Да и вообще стараюсь выбирать открытые железяки, для которых доступен стек драйверов.
> По крайней мере по моей просьбе выдали (положили на Вики eLinux) все бинари для SGX на MIPS Creator ci20.да уж - крутизна :) они должны их давать без просьбы - иначе кому их кремниевый хлам нужен ? исходники и доки - вот это было бы открыто, но такого не предвидится, хотя приятные подвижки есть c отреверсированными и переписанными драйверами для Vivante
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
https://github.com/austriancoder?tab=repositories
Вот спасибо за ссылки. Я до Vivante еще не добрался (борды нет) только тулчейн для IMX6. Но наверное скоро доведется.А вот Intel наверное их скоро всех обскачет с открытым кодом для своих ускорителей, хотя, даст ли он возможность в собственные SoCs втыкать графику - вопрос.
> А вот Intel наверное их скоро всех обскачет с открытым кодом для своих ускорителейпомоему он просто на месте подпрыгивает :) кстати открытый иксовый драйвер для виванта тут, если интересно
http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/
Интересно. Спасибо.