Погружение в YOCTO

[dlinyj]

Фермер не смог подобрать подходящего эпитета, чтобы охарактеризовать качество навоза.

Решил приобщиться к прекрасному, и разобраться с такой системой сборки как yocta. Много слышал, но никогда не работал. Раньше работал только с системами BuildRoot. В т.ч. и OpenWRT. К билдруту привык, прозрачен, понятен, лёгок, быстро компилируется.

А тут... 60 гигов н жёстком диске, просто титан, компилируется простейшая сборка минимум час, тащит всё откуда может. Жесть, как она есть. И, узнать о проблемах, можно спустя час компиляции, не всё прозрачно и понятно сразу. В общем, с непривычки очень странно. Не все баги грепаются, какой рецепт сломался. Прозрачность своеобразная.

Ладно, может я не прав. В целом, для проекта, который мучаю, альтернатив yocto нет, поэтому продолжаем жрать кактус. Решил начать с маленького: собрать простой проект для BeagleBone Black, что на фото выше. Типа начать с простого проекта, потом научится его обмазывать и т.п. Попробовал несколько мануалов, нифига не работает!!! То есть, собирает, но не грузит (боль, печаль и унижение). Обратите внимание, что в сути проба мануала занимает рабочий день, с учётом парочки перекомпиляций и перепрошивки!
В результате Нашёл неплохой видеомануал, который хоть как-то гарантирует, что всё будет работать.

Делаю всё согласно мануалу, разумеется делаю тот чекаут, с того тага...
Для удобства есть текстовый мануал к видео. Чуток исправил, потому что местами бредятина. Но смысл такой:

$ git clone git://git.yoctoproject.org/poky bgbl
$ cd bgbl
$ git fetch --tags 
$ git checkout tags/yocto-3.1 -b my-yocto-3.1
$ source oe-init-build-env

Редактирую файл conf/local.conf:

remove '#' MACHINE ?= "beaglebone-yocto"
add '#' #MACHINE ??= "qemux86-64" 
remove '#' comment following lines
DL_DIR ?= "${TOPDIR}/downloads"66 : SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
TMPDIR = "${TOPDIR}/tmp"
PACKAGE_CLASSES ?= "package_rpm package_ipk"

И дальше пускаю компиляцию:

$ bitbake core-image-minimal

Иииии, как вы думаете что? Мануал-то старый, ссылки все из гита не работают, и нифига не собирается...

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

Сейчас 6 раз пробую собрать уже с последнего тега...

Справедливости ради, могу сказать что проект OpenBMC для Aspeed 2500 у меня собрался почти с первого раза, и даже без проблем удалось его прошить в SPI-флешку и он успешно даже там запустился и работает. Но это готовый чужой проект, а хочется научится создавать свои проекты.

Aspeed 2500

Comments

[rbs-vader.livejournal.com]

Хмы, то есть, прошивка у BMC хранится в своем чипе с SPI. Надо покурить вдумчиво, как оно на X11DPH, поскольку супермикровский функционал...кхм...как бы не сматериться, оставляет желать лучшего.

[dlinyj.livejournal.com]

Меня супермикро никак не трогает. Это своё железо.

[rbs-vader.livejournal.com]

AST2500 просто у тот же, но вот как он прошивку хранит, пока хз. Буду пробовать. В любом случае полезно и спасибо, т.к. не знал что под него OpenBMC уже есть.

[nicka-startcev.livejournal.com]

бутлоадер, ядро, инитрд, девайс три — иногда приходится брать из такого рода жутких задниц (ну и хитроскрипт создания образа). но всё остальное можно и как-то более нормально брать чуть ли не из штатной репы дебиана.

[johnwarner.livejournal.com]

Вот за такие вот вещи я и не люблю пингвинов.

И да, сервера что я админил (вынужденно, и их было немного), все были на пингинах.

ЗЫ Десктоп у мну на форточке. Вебмин рулит.

[dlinyj.livejournal.com]

Пока не понимаю, при чём здесь пингвины и сборочная система.

Ну раз виндузятник, собери мне виндоус с нужным функционалом под ARM? Точнее под Aspeed 2500, буду рад увидеть муки творчества.

[johnwarner.livejournal.com]

В том-то и дело, что это не очень возможно.

Я смысл поста ничуть не оспариваю.

[dlinyj.livejournal.com]

А к чему тогда этот комментарий? Windows тоже кто-то собирает, и там проблем не меньше, точно. Особенно если в первый раз этим заниматься.

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

[johnwarner.livejournal.com]

К тому, что начинаются поиски того, что на форточках обычно даже в голову не приходит.

Вы, наверное, не поняли, я вообще-то вам искренне сочувствую.

[dlinyj.livejournal.com]

Разработка таких сложных систем никак не связана с тем, форточки это ли что-то ещё. Везде будут сложности, и винда не исключение. Я разработку веду в Windows, внезапно :).

[Николай Замотаев (from livejournal.com)]

Так проблема Yocto в том, что это мета-дистрибутив — исходники компонентов вообще сторонние, и гарантий в том, что их не удалили в процессе очередной реорганизации сайта — никакой.

Плавали, пилили, знаем.

[Николай Замотаев (from livejournal.com)]

Если конфиг ядра совпадёт по опциям ну и с некоторыми оговорками.

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

PS. Если что — yocto и производное от debian собрать может, просто рецепты писать долго (он же на выходе и репозиторий пакетов даёт и в rpm/ipk/deb умеет.

[Николай Замотаев (from livejournal.com)]

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

Ну а что вы предлагаете-то? yocto — это набор инструкций "как собирать", инструкции зависят от внешних репозиториев или исходников. Если кто-то удалил проект.... или подвинул его в другую точку в процессе реорганизации сайта — тут не yocto виновато, к сожалению. Или предлагается регулярно проверять все рецепты?
Как вариант предотвращения — мы делили сборку на фазы — сначала качать исходники, потом уже собирать. Делается через bitbake -c fetchall <таргет>
Кроме того — в конце процесса — пишет какие именно рецепты сдохли и там есть полные логи — что сдохло.

А тут... 60 гигов н жёстком диске, просто титан, компилируется простейшая сборка минимум час, тащит всё откуда может. Жесть, как она есть.

У yocto есть опция rm_work — она ценой некоторого удлинения сборки урежет занимаемое место на диске.
Добавляем в локальный конфиг:
INHERIT += "rm_work"
И занимаемого места будет меньше.
Тащит — один раз, загрузки кэшируются.

компилируется простейшая сборка минимум час

Ну так это ПОЛНАЯ сборка всего — от toolchain-а для сборки дистрибутива до самого дистрибутива.

Кстати если ограничить package_classes одним форматом — собирать будет быстрее

[dlinyj.livejournal.com]

>>Кстати если ограничить package_classes одним форматом — собирать будет быстрее

За это спасибо. Вообще за все советы спасибо!

[Николай Замотаев (from livejournal.com)]

Пожалуйста.
Я некоторое время занимался поддержкой сборки и обновления демо-образа boot2qt для одного проекта, в числе прочего. (там не совсем boot2qt, но на его базе).

Отсюда и все раскопки.
Bitbake, на самом деле довольно умная система и умеет сохранять промежуточные результаты сборки (SSTATE cache). Так что — инкрементальная сборка, если менялось небольшое число компонентов будет довольно быстрой.
У нас полная с "чистого листа" шла примерно 8 часов (основное время — qt webengine), инкрементальная по 2-3 компонентам — минут 15-20, в зависимости от (это собрать именно образ, готовый к заливке на систему. там основное время было сжатие этого образа в архив).

Мы ещё докручивали сборку с распараллеливанием на icecc, но это было... не очень стабильно (часть пакетов нельзя было собирать с ним, приходилось писать исключения для них) + создавало SDK с поддержкой этого же icecc, что было не всегда удобно.