Доступны новые выпуски платформ Yocto 1.6 (http://www.yoctoproject.org/) и Linaro 14.04 (http://www.linaro.org/), нацеленных на предоставление средств для создания встраиваемых систем на базе Linux.Yocto
Организация Linux Foundation представила (https://lists.yoctoproject.org/pipermail/yocto-announce/2014...) релиз проекта Yocto 1.6 (http://www.yoctoproject.org/), который предоставляет набор компонентов для создания собственных дистрибутивов для встраиваемых продуктов на базе различных аппаратных архитектур, в том числе ARM, PPC, MIPS, x86 и x86-64. Yocto не является отдельным дистрибутивом, а предоставляет разработчикам встраиваемых систем полный спектр решений на базе существующих готовых компонентов, позволяя минимизировать затраты на разработку прототипа системы и сфокусировать усилия на процессе разработки и создании специфичных для продукта возможностей. Предлагается несколько наборов для поддержки аппаратных платформ (Board Support Package, BSP) для встраиваемых платформ компаний Intel, Freescale, TI, Ubiquiti и д.р.
В состав платформы входит инструментарий разработчика, система сборки, набор программных интерфейсов и коллекция мета-пакетов (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/?h=denzil). Набор метаданных и компонентов сборки поддерживается совместно с проектом OpenEmbedded. В качестве базового набора компиляторов задействован GCC 4.8, поддерживается создание GUI-приложений с использованием библиотек Qt, Clutter и GTK+. В состав проекта также входит пакет Cross-Prelink (http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/), позволяющий существенно ускорить загрузку программ, связанных с большим количеством библиотек. Для упрощения разработки приложений для платформ на базе Yocto подготовлено два плагина - для среды разработки Eclipse (http://yoctoproject.org/projects/eclipse) и для Anjuta IDE (http://yoctoproject.org/projects/anjuta), которые поддерживают развёртывание проектов на удалённых системах, отладку, анализ кода, кросс-компиляцию и использование эмулятора QEMU.
Для сборки задействована система Poky (http://www.pokylinux.org/), являющаяся ответвлением от OpenEmbedded Build System и позволяющая объединить в рамках дистрибутива разрозненные приложения. Пакеты распространяются в формате RPM5. Для контроля за инфраструктурой сборки используется ПО Swabber (http://git.yoctoproject.org/cgit/cgit.cgi/swabber/), для выполнения привилегированных операций задействован Pseudo (http://github.com/wrpseudo/pseudo), для организации автоматизированного тестирования используются технологии Shoeleather Lab. Предусмотрена возможность генерации (http://yoctoproject.org/projects/sdk-generator) SDK, оптимизированного для продуктов, построенных на базе Yocto.
Основные новшества (http://downloads.yoctoproject.org/releases/yocto/yocto-1.6/R...) Yocto 1.6:
- Обновлены версии базовых компонентов: ядро Linux 3.14 и 3.10 LTSI, eglibc 2.19, gcc 4.8.2;
- Поддержка сборки Python 3;
- Интерфейс пользователя для изучения вывода в процессе сборки;
- Специальный клиент для передачи информации об ошибках в центральный web-интерфейс;
- Новые эталонные BSP-наборы для BeagleBone (замена для beagleboard) и Edgerouter (замена для routerstationpro);
- Переход на SHA512 для хэширования паролей и упрощение процесса установки пользовательских паролей;
- Задействование по возможности жестких ссылок вместо операций копирования для сокращения расходования дискового пространства;
- Поддержка загрузки на системах UEFI с использованием загрузчика gummiboot;
- Код для создания образов и SDK переписан с Shell на Python;
- Поддержка параллельной сборки пакетов rpm, deb и ipk;
- Улучшена поддержка systemd;
- Добавлена поддержка ptest для различных пакетов. Включена сборка по умолчанию тестового пакета ptest. Возможность запуска тестов вне процесса сборки. Поддержка piglit для тестирования OpenGL.Linaro
Консорциум Linaro, созданный компаниями ARM, Freescale, IBM, Samsung, ST-Ericsson и Texas Instruments, представил (http://www.linaro.org/blog/linaro-14-04-release-now-availabl.../) релиз программной платформы Linaro 14.04 (https://wiki.linaro.org/Cycles/1404/Release), нацеленной на развитие поддержки архитектуры ARM в Linux и различных открытых проектах, а также на оптимизацию их кода с целью повышения эффективности работы на различных ARM SoC. Работа консорциума сфокусирована на обеспечении совместимости программных решений с устройствами на базе различных ARM-совместимых систем от разных поставщиков, что позволяет производителям программных решений и Linux-дистрибутивам сэкономить инженерные ресурсы за счет задействования унифицированного низкоуровневого программного обеспечения.Платформа Linaro представляет собой коллекцию типовых улучшений и дополнений, предназначенных для работы в уже существующих дистрибутивах, таких как Ubuntu, Android, LiMo, Tizen, Debian и webOS. В качестве эталонных систем, на базе которых формируются готовые к использованию установочные сборки, используются Ubuntu, OpenEmbedded и Android. Дополнительно поставляются обновлённые инструменты кросс-компиляции и создания рабочих образов, которые оформлены в виде пакетов для различных версий Ubuntu. Все создаваемые консорциумом Linaro наработки поставляются в исходных текстах под открытыми лицензиями и рекомендуются для интеграции в основные проекты (upstream).
В рамках проекта Linaro поддерживаются (https://wiki.linaro.org/Cycles/1404/Release#Getting_Started) модифицированные версии набора компиляторов GCC 4.5-4.8, отладчика GDB 7.6.1, набора утилит Binutils, эмулятора QEMU 1.7, графических компонентов, таких как Compiz и Unity, различных библиотек (alsa-lib, libpng, libjpeg-turbo). Для ядра Linux подготовлены специальные наборы патчей, значительно расширяющих спектр поддерживаемых ARM-устройств, понижающих потребление энергии и повышающих производительность за счет использования специальных оптимизаций. Работа программных компонентов, оптимизированных для архитектуры ARM, проверена на различных ARM-совместимых SoC от разных производителей, что гарантирует работоспособность всех базовых программ на различном спектре устройств.
Новая версия примечательна обновлением набора компонентов для построения готовых решений для различных встраиваемых ARM-платформ, таких как Versatile Express (QEMU), Galaxy Nexus, Arndale, PandaBoard, Highbank и Midway. Компоненты на базе платформы Android обновлены до выпуска Android 4.4.2, OpenEmbedded до выпуска 2014.04, а Ubuntu до 14.04 LTS. Для сборок на базе Android добавлена поддержка GCC 4.8, ARMv8, настроек для Nexus 7 и Nexus 10. Набор развиваемых проектом патчей адаптирован для ядра Linux 3.14. В патчи для ядра Linux 3.10.37 включены многочисленные улучшения для ARMv8, в том числе средства для регулирования частоты CPU и управления спящим режимом. Добавлена поддержка многоядерных ARM-систем с архитектурой big.LITTLE.
URL: http://www.linaro.org/blog/linaro-14-04-release-now-availabl.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=39651
embedded... systemd...[сообщение отредактировано модератором]
>сраньгасподня, embedded... systemd...Для тех кто использует openembedded(OE) это то что нужно,
не знаю почему это вас удивляет.Раньше в OE по умолчанию шла обычная /etc/init.d с кучей скриптов,
все это грузилось мягко говоря не быстро, что критично для
некоторых embedded систем, и приходилось дорабатывать
ручками для нормальной скорости загрузки.
Теперь по умолчанию с systemd все грузиться примерно за тоже время,
плюс всякие фишки для запуска основного приложения, начиная
от того что можно одной строчкой отсрочить его запуск до появления
какого-нибудь открытого domain socket закачивая watchdog для приложения (не путать с HW watchdog).
>шла обычная /etc/init.d с кучей скриптовс большой-прибольшой кучей.
Неужели написать свой инит скрипт для embeded разработчика непосильная задача? У меня лично ноутбук загружается за 8 секунд и занимает 23Mb памяти (kernel/drivers/x.org/dwm/st/mc/conky). Естественно без systemd/pulseaudio/dbus/etc.
Действительно, на?ер нужны такие ембедщики, которые не могут несколько своих сервисов запустить простым скриптом.
> Действительно, на?ер нужны такие ембедщики, которые не могут несколько своих сервисов запустить
> простым скриптом.Как говорится напиши сначала этот простой скрипт.
Представьте себе, что вам естественно нужно смонтировать ФС, а если что-то пошло не так, то проверить ее с помощью fsck, если fsck не справилась то смонтировать в RO, и в этом режиме некоторые сервисы не запускать. Потом подмонтировать всякие procfs, sysfs, devpts, создать устройства и /dev и позаботиться о создании новых при подключении скажем флешки для сброса телиметрии.
Что каждый запущенный сервис нужно не просто запустить, но в случае падения перезапустить.
Нужно учесть все зависимости, чтобы запускать параллельно, т.к. чем быстрее устройство заработает от момента включения питания тем лучше. Плюс правильно отработать выключение, с учетом того, что после убийства процесса он автоматически перезапускается.В итоге куча мелочей и "простым" скриптом софт реального изделия ты не запустишь.
Еще надо учесть что на все нестандартные скрипты нужна документация.А тут бац, и в systemd все что нужно есть плюс документация.
Нахрена изобретать собственный велосипед?
> Представьте себе, что вам естественно нужно смонтировать ФС, а если что-то пошло не так, то проверить ее с помощью fsck, если fsck не справилась то смонтировать в RO, и в этом режиме некоторые сервисы не запускать.Если fsck не может исправить ошибки, то монтирование в RO ничего не даст - устройство не будет работать адекватно. Это либо аппаратная ошибка, либо баг fsck. В любом случае должно появится предложение обновить прошивку или обратится в СЦ, пытаться продолжать работу в таком состоянии - только портить репутацию фирмы производителя.
> Потом подмонтировать всякие procfs, sysfs, devpts, создать устройства и /dev и позаботиться о создании новых при подключении скажем флешки для сброса телиметрии.
devtmpfs + mdev отлично с этим справятся.
> Что каждый запущенный сервис нужно не просто запустить, но в случае падения перезапустить.
(while true; имя_часто_падучего_сервиса; sleep 10; done) &
> Нужно учесть все зависимости, чтобы запускать параллельно, т.к. чем быстрее устройство заработает от момента включения питания тем лучше. Плюс правильно отработать выключение, с учетом того, что после убийства процесса он автоматически перезапускается.
Ненужно переусложнять и не будет подобных проблем.
> Нужно учесть все зависимости, чтобы запускать параллельно, т.к. чем быстрее устройство
> заработает от момента включения питания тем лучше.Прям-таки на тех CPU и флэшах переключение контекстов и убивание readahead дало выигрыш?
> В итоге куча мелочей и "простым" скриптом софт реального изделия ты не запустишь.
А расскажите-ка, что это за реальные изделия делаете и как давно. Бо сомнения берут.
Так понимаю всю эту х;:?ню ты придумал почитав поттеринга? Ну раньше у большинства всё было нормально, но пришёл лёня и написал текст: смонтировать, запустить, при ошибке перезапустить, простые юниты, может даже обезьяна, етц. Ага, подумал меганоним и взяв текст лёньчика выкинул из него упоминание ситемд и всунул слова - надо для ембедед. Классно подогнана задача под решение.
>Неужели написать свой инит скрипт для embeded разработчика непосильная задача?Нет конечно, и если вы читали мой пост, то узнали что я это и так сделал.
Но теперь этого делать не нужно. Ведь не считаете же вы, что моей задачей является писать скрипты для загрузки? Мне нужно чтобы изделие делало то, что прописано в ТЗ, и если мне часть функциональности не нужно писать самому и отлаживать я только рад.PS
>У меня лично ноутбук загружается за 8 секунд
А теперь представьте, что у вас в ноутбуке процессор 200Mhz и не жесткий диск или SSD,
а nand работающий на 50Mhz, я думаю загрузка уже будет 8 * 10, что очень много для моего изделия.
> Но теперь этого делать не нужно. Ведь не считаете же вы, что моей задачей является писать скрипты для загрузки? Мне нужно чтобы изделие делало то, что прописано в ТЗ, и если мне часть функциональности не нужно писать самому и отлаживать я только рад.Согласен, но каков будет перерасход памяти от systemd и всего что он за собой притянет?
> А теперь представьте, что у вас в ноутбуке процессор 200Mhz и не жесткий диск или SSD, а nand работающий на 50Mhz, я думаю загрузка уже будет 8 * 10, что очень много для моего изделия.
Ноутбуку пять лет, на десктопе (в четыре раза мощнее ноутбука) стоит такая же система и грузится примерно столько же, так как все упирается не в cpu и не в io, а в задержки при инициализации железа.
Да и как сложная система инициализации, выполняющая кучу ненужных проверок, может быть быстрее чем хорошо продуманный скрипт?
>Согласен, но каков будет перерасход памяти от systemd и всего что он за собой притянет?Мы все-таки говорим об embedded linux системе. Это значит мы имеем несколько мегабайт оперативки, потому что в ином случае проще взять какую-нибудь мини ОС типа eCos, FreeRTOS и подобные, чем упихивать linux скажем в 128K SRAM оперативки и 256K nor flash.
В этих условиях расходы на systemd просто смехатворны, сколько-то там килобайт.
Естественно в openembedded systemd собирается без преферанса и картинок и там на это можно влиять - есть некий аналог USE флагов в Gentoo.Пример, во время разработки изделия плата шла с 64МБ SDRAM (столько было на отладочной плате к процессору, и не было никаких требований чтобы это поменять).
При выходе в серию изделие оснастили 128МБ, т.к. микросхема была в том же корпусе, стоила столько же, а 64МБ то ли прекратили выпускать, то ли купить было сложно.В итоге, на этом фоне, что systemd жрет сколько-то килобайт и зависит от одной не системной либы (libdbus [возможно пока не системной]) абсолютно пофиг.
>в задержки при инициализации железа
в embedded на это обычно пофиг, т.к. свое железо знаешь и нивелировать эти задержки легко,
основные задержки это как раз IO и CPU.
> В этих условиях расходы на systemd просто смехатворны, сколько-то там килобайт.
> Естественно в openembedded systemd собирается без преферанса и картинок и там на это можно влиять - есть некий аналог USE флагов в Gentoo.Было бы интересно узнать сколько (вместе с udev) конкретно?
> в embedded на это обычно пофиг, т.к. свое железо знаешь и нивелировать эти задержки легко, основные задержки это как раз IO и CPU.
Так я и говорю, что время загрузки увеличится не в десять раз, а может наоборот даже быстрее будет, так как не надо ждать пока винты и прочее инициализируется.
> Мы все-таки говорим об embedded linux системе. Это значит мы имеем несколько
> мегабайт оперативки, потому что в ином случае проще взять какую-нибудь мини
> ОС типа eCos, FreeRTOS и подобные, чем упихивать linux скажем в
> 128K SRAM оперативки и 256K nor flash.
> В этих условиях расходы на systemd просто смехатворны, сколько-то там килобайт.И как, давно упихивали линукс в 128k или systemd в килобайты?
Хочу себе такую же серебряную пулю, чтоб за восемь секунд грузилась. Давай раскладывай, что да как. Как говорится: - "рецепт в студию"
> Хочу себе такую же серебряную пулю, чтоб за восемь секунд грузилась. Давай
> раскладывай, что да как. Как говорится: - "рецепт в студию"Сильно измененный LFS:
glibc -> eglibc (в будущем хочу попробовать musl)
gnu* -> busybox
udev -> mdev
Управление пакетами - paco + собственная система сборки.
Ядро без модулей (все необходимое в ядре, лишнее отключено), без initrd.Инициализация до старта иксов идет в последовательно - все эксперименты с параллельным исполнением на этой стадии ничего кроме усложнения не дали. Далее исполняется два скрипта: в одном последовательный запуск x.org и после его старта st/mc/conky/dwm, в другом параллельной запуск настройки сети, звука, энергосбережения.
Короче, серебряной пули не получилось :) Ежели слону отрезать ноги...Я то думал, а тут вон оно как... Дык и на Убунте можно поотрубать всё и оставить голый Busybox, тока зачем оно надо? Я по молодости тоже отрубал всё в Дебьяне и гордился собой, потом прошло. Теперь сижу на кедах, да ещё и с почтой и календарями и пр. в Kontact и жду когда комп загрузится. И делает он это всё ме-е-едленно. Зато всё что надо работает. По любому, главная головная боль это жручие браузеры с флэшами. Тут уж ничто не поможет.
достаточно просто купить ссд.
Почему ты думаешь, что systemd сожрет больше памяти, чем куча инстансов баша?
Для скриптов я использую ash из busybox. Суммарный Pss (включая locale-archive, libc-2.19.so, ld-2.19.so) - 132k. В описанной мной системе инициализации нужно два инстанса.
>Мне нужно чтобы изделие делало то, что прописано в ТЗ, и если мне часть функциональности не нужно писать самому и отлаживать я только рад.Это замечательно. Особенно если это поддерживать ваш продукт кому-то другому.
Который будет выслушивать маты от заказчика, у которого оно будет падать с невнятными сообщениями об ошибках, а то и совсем без них, и ездить-летать в те далекие места где оно у заказчика работает, чтобы выяснить какой именно затык в systemd на этот раз.
> А теперь представьте, что у вас в ноутбуке процессор 200Mhz и не жесткий диск или SSD,а nand работающий на 50Mhz, я думаю загрузка уже будет 8 * 10, что очень много для моего изделия.
На процессоре 200Mhz ваш любимый systemd будет полчаса гонять туда-сюда сотню сообщений через dbus, только чтобы запустить какой-нибудь сервис, который как правило в embeded системах запускается скриптом из 5 строчек.
А уж про килобайты памяти для systemd может написать разве что совсем невменяемый человек.
В libdbus то хоть заглядывали?
> На процессоре 200Mhz ваш любимый systemd будет полчаса гонять туда-сюда сотню сообщений через dbusПроц там может требоваться, разве что, на сериализацию/десериализацию (ну не на запись/чтение из сокета же), и займет ли это больше ресурсов, чем интерпретация кода на shell - это еще большой вопрос.
> А уж про килобайты памяти для systemd может написать разве что совсем невменяемый человек.
systemd на десктопе жрет RES меньше, чем один login-инстанс баша.
> В libdbus то хоть заглядывали?
Ты апеллируешь к footprint-у библиотеки, но забываешь, что потребление памяти shell-интерпретатора не сводится только к размеру кода его бинарника. Кстати, ты сам-то в исходники какого-нибудь шелла в его шапшеподобным кодом FSM заглядывал?
належность работы - для Embedded systems - куда важнее, скорости загрузки/старта.
равно как и консистентность.
или управляемость.
или отсутствие анальных зондов от ЦРУ.
> належность работы - для Embedded systems - куда важнее, скорости загрузки/старта.
> равно как и консистентность.
> или управляемость.
> или отсутствие анальных зондов от ЦРУ.Чушь. Вы назвали несколько параметров:
- скорости загрузки/старта
- належность
- управляемость
- отсутствие анальных зондов от ЦРУКак вы можете сказать, что для сферического embedded устройства какой-то из параметров
может быть важнее другого?Для гражданского embedded всем насрать на зонды от ЦРУ, если
это скажется на скорости разработки или еще на каких-то параметрах
мешающих коммерческому успеху.
В военных embedded, естественно наличие/отсутствие параметра "анальные зонды от ЦРУ" имеет один из высших приоритетов.
И так для каждого из параметров.
Кому скажем нужен телефон/рация которая включается 10 минут,
если мы говорим о бытовой электронике?
Или скажем всем насрать, если ПО для какой-нибудь железке
на производстве грузиться 50 минут, если она потом по технологии не выключается годами.и т.д. и т.п.
Каждый параметр может быть важен и не важен в embedded находится в зависимости от того для чего embedded железка нужна.
> Чушь.Поскольку федорофанбои не поняли, пришлось наглую назойливую рекламу стереть -- этой чушью уже все уши прожужжали, а только слаще она от того не стала.
нисвисти... без зондов - им никто не заплатит :)
> приходилось дорабатывать ручками для нормальной скорости загрузки.
> Теперь по умолчанию с systemd все грузиться примерно за тоже времяЗначит ручки из ж..ы растут. busybox init на скриптах (!) которые у вас так тормозят у меня работает ~3 раза быстрей чем то же самое на systemd. Доработанная система (скорость в основном упирается в инит модулей ядра) загружается меньше секунды.
ext4 B / ?????
> Edgerouter (замена для routerstationpro);Не понял юмора автора этой мысли. В каком месте оно замена?
это не замена, а скорее алычные мечты неосиляторов-проприерастов, увы.
Эх, то же самое бы для rockchip, allwiner, amlogjc ;d
Архитекрута armhfСовсем наркоман?
Я не понял, можно подробнее?
rpm для встройки? На 4-х метрах ipk некуда распаковывать. Для малых обьемов может и прокатит - но qnx по прежнему интереснее.