Система для сборки прошивок для встройки

У меня свой дистр. И именно его мне надо опакечивать и собирать из них образы.

Вот именно что легаси. На ARM нормально приготовленные дистры 4-5 секунд стартуют.

Ну так и сделай слойку из контейнеров, потом в genimage их. Меняешь базовый образ, меняются все образы при пересборке. А если оставить плейсхолдеры на FROM, то ещё проще всё.

Ну то есть фактически «закат солнца в ручную».

Ну тоже вариант.

Хотя мне бы хотелось иметь вариант когда выкачал из репы все зависимости (какой лбраз из чего должен собираться), дальше одной командой build all. Выкачались все исходники нужных версий. Собрался весь тулинг, собрались все бинарные пакеты сложились в репу. Потом из этих бинарей собрались образы. И при повторном запуске собиралось и пересобиралось только то что прилетело по зависимостям.

Мне нужеа именно такая система. Я пишу правила, а она всё это компиляет и собирает. Без эталонных дистров и дублирования.

Yocto пока ближе всего как мне кажется, хотя и придется poky выкинуть.

фактически «закат солнца в ручную».

в каком именно месте он «в ручную», хотелось бы полюбопытствовать?

компоненты собираются в сиае своих проектов, финальные образы - в release engineering пайплайнах.

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

Да, у нас разные каналы поставок и не всё идет в виде прошивок. Что-то ставится на деб-подобные дистры просто апт-ом.

Хотя мне бы хотелось иметь вариант когда выкачал из репы все зависимости (какой лбраз из чего должен собираться), дальше одной командой build all. Выкачались все исходники нужных версий. Собрался весь тулинг, собрались все бинарные пакеты сложились в репу.

Ну, кхе, это сиай называется. Кнопку «сделать всё за2.7бись» каждый пилит себе сам.

Без эталонных дистров

Не понимаю, о чем это. Мы собираем в целевых системах. Что-то кроссом, что-то нативно, так как не каждый вендор предоставляет кросс-компилятор, увы.

Мне нравится pbuilder, но тут скорее всего не подойдет, задача немного другая. Может взять pbuilder за основу и написать свой велосипед для задачи как вариант. Но конечно сначала следует изучить как обычно решаются такие задачи для конкретного стака и железок, потому уже смотреть.

Эммм а зачем выкачивать все из репы? Сборкой пусть специально обученые сервера занимаются (и всяким build all). И даже выкачивать образы не обязательно, пусть сразу на железку заливаются (ну а чо).

Чего вы такие буквальные?

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

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

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

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

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

Есть ли возможность локально писать код, собирать и быстро проверять создавая прошивку и загружать ее в железо?

Да, там (в екте) есть воркспейсы для этого

При этом не копируя на локалхост миллиард файлов системы сборки.

Тут тебя ждёт ад)

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

Buildroot же портянка из плохо читаемых мейкфайлов.

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

Можно не извиняться. Мы тут идеи фонтанируем, а не пытаемся всем понравится.

Можно в 2-х словах, почему пример из yocto - poky for x86 занимает на диске 300гб?

Результат сохранения всего хлама от сборки SDK.

Если были настроены DL_DIR и SSTATE_DIR, то можно снести директорию build и повторить сборку. Если небыли настроены, то перенести эти две директории вне build, настроить и повторить.

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

По этому общая рекомендация:

• Настроил DL_DIR и SSTATE_DIR.
• Собрал первый раз.
• Снёс директорию сборки.
• Собрал второй раз.
• Пошёл работать над образом.

Когда иногда возвращаюсь к старым железка с билдрутом - плачу от счастья, насколько же раньше все было просто, понятно, разумно

А почему бы тогда не продолжать использовать buildroot?

А почему бы тогда не продолжать использовать buildroot?

Если бы я решал – рак бы и было. Но у нас тут культ «прогрессивности», тащат любую хрень про которую есть мода что она прогрессивная, почти всегда это создает проблем больше чем решает, в результате тут одни газотурбинные двигатели и сверхпроводники в задачах где десятилетиями справлялись дизеля и вилка в розетку. Причем современные и прогрессивные справлются хуже, от части функций, которые всегда были, пришлось отказаться, зато все убер-соременное внедрено. Понатащили овер9000 сложности и теперь натурально на ровном месте постоянно имеют с этого проблемы и екта одно из таких решений

Если бы я решал – рак бы и было.

Не сразу понял, что опечатка.

культ «прогрессивности»

Хороший термин, утащу себе.

Тогда буду дальше на buildroot сидеть. :^)

Buildroot же портянка из плохо читаемых мейкфайлов

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

то есть мало прочитать рецепт, надо еще провести расследование что нигде не лежит дополнение к этому рецепту, а поискать тут есть где…

А пробовали системы сборки openwrt

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

Меньше всего мне хочется пердолится в самодельные велосипеды с квадратными колесами

тогда yocto. Но пусть в меня бросит камень тот, кто считает что там не придется пердолиться с чужими велосипедами с квадратными колесами :)

Теперь все тоже самое только для рутфс размером в 30мб

тогда, боюсь, у тебя екта не взлетит. Я точно не знаю че там у нее с минималками, но по ощущениям ей даже на минимуме потребуется в 10 раз больше. Но, повторюсь, я такое не пробовал, это – мои фантазии на тему

То есть требования такие, чтобы можно было тонко настраивать под свои нужды

в екте можно что угодно настраивать, но ее сильная сторона – это набор готовых слоев, которые поддерживаются и обновляются. Ты можешь все это делать и сам, но тогда какой прок от екты? Я охотнее поверю в очень кастомный дебиан на 30 мегабайтах, чем в полностью самодельный дистрибутив на екте

Полез почитал, оказалось давно отфоркнулись

Мне казалось, что buildroot – форк от openwrt. Если правильно всё понял, OpenIPC раньше собиралось через OpenWRT, сейчас перешли на buildroot.

Мне нужен именно, что инструмент для создания своих слоев, зависимостей и т.д.

Как я понял, у всех кроме инструментов еще и готовые монструозные библиотеки пакетов и дистрибутивов. И все этим кичаться. Тут один регистрант посоветовал еще https://www.kdab.com/using-nix-as-a-yocto-alternative/ - 80тыс пакетов! Я весь дрожу от нетерпения все их скомпелять!

А мне бы на первом шаге хотелось бы собрать kernel+uClibc+dropbear под arm. Сделать для этой связки правила, чтобы все опакечивалось и потом из них собирался образ. И чтобы в qemu можно было запустить.

«Ужасно не хочется разобраться в монструозной системе, чтобы понять, что она не подходит. Причем когда разберешься, будет соблазн ее применить. И потом по инерции тянуть всю эту сложность и вовлекать в нее других людей. А рядом может оказаться решение на плейн-тексте и башскриптах в пару сотен строк. В которых даже школьник разберется»

А мне бы на первом шаге хотелось бы собрать kernel+uClibc+dropbear под arm. Сделать для этой связки правила, чтобы все опакечивалось и потом из них собирался образ. И чтобы в qemu можно было запустить

Тогда точно сначала реализуй на билдруте. Если уж тебе только свое - то не вижу причин почему нет. Даже если покажется мало, и потянет попробовать на екте, то на начальную реализацию на билдруте ты потратишь несколько вечеров, а в екте будешь потом полгода разбираться и до тебя только через полгода масштаб этого действа доходить начнет: там столько всего, просто открой список переменных доступных из рецепта и прочти. А ведь чтобы эффективно этим пользоваться, их надо не просто знать, а прям проработать, знать ньансы. Этим надо полный день заниматься и только этим, полгода, по завершению авторов, а если не полный день, то никогда не осилишь, по ому что они обновят я быстрее, чем ты в них разберёшься. Ну и Нафиг это все, если за это время сам руками десять раз все напишешь и для тебя там никаких таин не будет. Единственное, что я признаю как ценное - это библиотека софта на поддержке под ембед, если тебе оно не надо - то только проблем с ней хапнешь а пользы ноль

Посмотри на ту же самую openwrt: там десятки поддерживаемых тулчейнов, сотни поддерживаемых тергет платформ, самые любые конфигурации самого любого софта – и все это весит мегабайты и ты скачиваешь, делаешь тривиальные make menuconfig; make и все, вот она лежит прошивка. Екта тебе будет часами что-то качать, часами что-то собирать, сожрет какие сотни гигабайт места, вместо ошибки покажет какой-то дамп питоновского стека и ты в итоге собрал ядро+убут+бизибокс без грепа. Я искренне не понимаю людей которые добровольно этим пользуются, когда их не заставляют. Все ее охринительные разрекламированные фишки я на мейке реализую в 10 строчек каждую.

Идея екты в чем? В слоях. Это хорошая штука, признаю, но она хороша как конструктор одного своего дистрибутива, типа берем базовый слой просто линукса, поверх если надо накатываем слой браузера и еще сверху слой своих каких-то сервисов и все круто. Но вот тебе оказывается нужны разные тулчейны – поперли «ифдефы» в рецепты. А вот тебе не нужны всякие излишние программы из базового слоя, ты думаешь ты редактируешь рецепт? Нет, ты делаешь аддон к реепту, в котором выпиливааешь то что было впилено в основном. А у тебя разные платформы? Ты делаешь много эддонов ко многим рецептами раскладываешь их по папкам в зависимости от платформы. В некоторых рецептах зафиксированна ветка или тег или хеш коммита из которого этот рецепт скачает исходники и соберет какой-нибудь, не знаю lua. А в некоторых – не зафиксированно, это значит что когда ты в след раз будешь собирать что-то по этим же рецептам – ты соберешь уже не совсем то же самое, ведь туда могли что-то закоммитить. А как обеспечить воспроизводимость сборки – это прямо отдельная задача! А как сделать чтоб оно генерировало прошивку – ну тут тоже надо немного доделать, как я понимаю, авторами yocto задумывалась как генератор SDK+toolchain, вот так да, отличная штука, а как полноценная система сборки, это скорее некоторая основа для творчества, у всех по-разному, по крайней мере у нас – очень плохо

И никакой целый отдел программистов тут не нужен, тут достаточно одного человека и то не на фулл тайм, я вообще ничего такого не вижу в твоем описании что не было бы в той или иной мере реализовано у нас на билдруте/самописе: дай эту задачу целой команде с ектой и мне одному с билдрутом и посмотрим кто лучше справится! :)

и мне одному с билдрутом и посмотрим кто лучше справится! :)

А можно меня в помощники? На четверть ставки. :^)

Берёшь buildroot, добавляешь в него свои проекты модулями. Можно сборку из исходников, можно wget готовых бинарников, можно выбиралку нужной версии сделать (а потом git checkout нужного тега или wget нужного бинаря). Затем включаешь нужные галочки в конфиге и сохраняешь. И модули, и конфиги для разных устройств коммитишь в git. Затем хоть разработчик на своей машине, хоть CI/CD может собрать образы.

Если лень писать модули buildroot, то в 2026 году можно делегировать это нейронке. Они хорошо пишут конфиги.

Как насчет промежуточного хранения бинарных артефактов? С автоматическим использованием того, что есть и автоматическим развертыванием того чего нет? Причем хочется, чтобы был отдельный пайплайн для пополнения бинарного хранилища. И отдельный пайплайн для сборки из него уже готовой прошивки.

Причем в пределе сборка должны выглядеть так: затянул из гита все правила и зависимости и на локалхосте собрал прошивку состоящую из 99 готовых бинарных пакетов (стянутых по сети) и одного кастомного, который ты прям сейчас редактируешь в «блокноте» (указав конечно, откуда взять этот кастомный). Причем добавление этого кастома в готовую цель должно быть интуитивно понятно рядовому разрабу (с учетом прочитки минимального ридми).

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

Я точно не знаю че там у нее с минималками, но по ощущениям ей даже на минимуме потребуется в 10 раз больше. Но, повторюсь, я такое не пробовал, это – мои фантазии на тему

Я охотнее поверю в очень кастомный дебиан на 30 мегабайтах, чем в полностью самодельный дистрибутив на екте

Надо не верить или гадать. А проверять. И понимать из каких кубиков собирать.

Сейчас Yocto предлагает три примера дистрибутивов.

Вот результат сборки примера образа core-image-minimal (минимального образа с рабочей сетью и типовыми утилитами). Привожу размер распакованного rootfs.

Дистрибутив poky-tiny (на базе musl, и простых систем инициализации и обработки устройств). Сам образ упаковывается в 800 КБ spio.gz

❯ dust -n 20 -b
8.0K     ┌── lib
 32K   ┌─┴ var
 12K   │ ┌── mdev
 12K   │ ├── skel
 16K   │ ├── services
 20K   │ ├── init.d
172K   ├─┴ etc
 68K   │ ┌── busybox.suid
644K   │ ├── busybox.nosuid
716K   ├─┴ bin
 12K   │ ┌── bin
8.0K   │ │ ┌── udhcpc
 28K   │ ├─┴ share
 68K   │ │ ┌── ttyrun
 72K   │ ├─┴ sbin
644K   │ │ ┌── libc.so
860K   │ │ │ ┌── alternatives
864K   │ │ ├─┴ opkg
1.5M   │ ├─┴ lib
1.6M   ├─┴ usr
2.6M ┌─┴ .

Дистрибутив poky без модификаций. glibc, udev, initd. Дефолтно ext4 на 20МБ

❯ dust -n 20 -b
408K   ┌── etc
592K   │ ┌── tar.tar
644K   │ ├── busybox.nosuid
1.5M   ├─┴ bin
388K   │ ┌── udevd
780K   │ ├── ldconfig
1.6M   ├─┴ sbin
260K   │ ┌── libmvec.so.1
452K   │ ├── libblkid.so.1.1.0
708K   │ ├── libm.so.6
1.2M   │ ├── udev
1.6M   │ ├── libc.so.6
5.2M   ├─┴ lib
388K   │   ┌── udevadm
740K   │ ┌─┴ bin
800K   │ │   ┌── alternatives
804K   │ │ ┌─┴ opkg
5.5M   │ │ ├── libcrypto.so.3
6.9M   │ ├─┴ lib
7.8M   ├─┴ usr
 16M ┌─┴ .

Дистрибутив poky-altcfg использует systemd и пачку доп. утилит (которые могли бы и убрать).

❯ dust -n 20 -b
 22M     ┌── Image-6.18.39-yocto-standard
 22M   ┌─┴ boot
4.0M   │ ┌── sbin
2.4M   │ │     ┌── freedesktop.org.xml
2.4M   │ │   ┌─┴ packages
6.4M   │ │ ┌─┴ mime
9.2M   │ ├─┴ share
9.6M   │ ├── bin
2.4M   │ │ ┌── libstdc++.so.6.0.34
4.5M   │ │ ├── security
5.5M   │ │ ├── libcrypto.so.3
4.4M   │ │ │ ┌── libsystemd-shared-259.so
 14M   │ │ ├─┴ systemd
2.9M   │ │ │   ┌── 20-OUI.hwdb
3.9M   │ │ │   ├── 20-pci-vendor-model.hwdb
9.0M   │ │ │ ┌─┴ hwdb.d
 10M   │ │ │ ├── hwdb.bin
 20M   │ │ ├─┴ udev
 72M   │ ├─┴ lib
 95M   ├─┴ usr
118M ┌─┴ .

Ну тут /usr/lib/ и /usr/share отъели больше 80 МБ. И явно есть что почистить. Но пусть будет так. Хотя на практике systemd отъедает мегабайт 10 оперативы, с учётом shared библиотеки с C++ рантаймом.

На практике же делают свой дистрибутив и свой образ.

Берёшь buildroot, добавляешь в него свои проекты модулями. Можно сборку из исходников, можно wget готовых бинарников, можно выбиралку нужной версии сделать (а потом git checkout нужного тега или wget нужного бинаря). Затем включаешь нужные галочки в конфиге и сохраняешь. И модули, и конфиги для разных устройств коммитишь в git. Затем хоть разработчик на своей машине, хоть CI/CD может собрать образы.

зис. Не понимаю что людей тут не устраивает.

А мне бы на первом шаге хотелось бы собрать kernel+uClibc+dropbear под arm.

Как уже сказали, это на buildroot типовой шаблон.

Как насчет промежуточного хранения бинарных артефактов? С автоматическим использованием того, что есть и автоматическим развертыванием того чего нет?

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

Можно сделать. У нас примерно так и сделано: ты для каждого пакета билдрута пишешь мейкфайл, а он, когда система сборки его зовет, проверяет есть ли такой пакет ( нас по имени-версии ) уже готовый в хранилище, если есть – тащит, если нет у нас собирает из исходников, но ты можешь сделать чтоб дернул сборку в хранилище.

Причем в пределе сборка должны выглядеть так: затянул из гита все правила и зависимости и на локалхосте собрал прошивку состоящую из 99 готовых бинарных пакетов (стянутых по сети) и одного кастомного, который ты прям сейчас редактируешь в «блокноте» (указав конечно, откуда взять этот кастомный). Причем добавление этого кастома в готовую цель должно быть интуитивно понятно рядовому разрабу (с учетом прочитки минимального ридми).

Есть. Опять же, идешь просто в конкретный мейкфайл конкретного пакета и в шапке ему в специальную переменную раскоменчиваешь что вот этот конкретный в любом случае собирай из исходников на локалхосте. Потом подправил исходники в блокноте, запустил make packagename-rebuild и у тебя есть готовый бинарь. Можно сделать еще каждому пакету цель packagename-deploy чтоб оно тебе складывало на борду поглядеть. Мы так и работаем.

Может я хочу слишком много

Вполне разумного хочешь: все так и делают

Надо не верить или гадать. А проверять

ну я ж предупреждал что не знаю :)

круто, впечатляет

А как обеспечить воспроизводимость сборки

С каких пор воспроизводимость сборки является проблемой для yocto? Это что-то совсем надо странное наделать.

А вот тебе не нужны всякие излишние программы из базового слоя, ты думаешь ты редактируешь рецепт? Нет, ты делаешь аддон к реепту, в котором выпиливааешь то что было впилено в основном. А у тебя разные платформы? Ты делаешь много эддонов ко многим рецептами раскладываешь их по папкам в зависимости от платформы. В некоторых рецептах зафиксированна ветка или тег или хеш коммита из которого этот рецепт скачает исходники и соберет какой-нибудь, не знаю lua. А в некоторых – не зафиксированно, это значит что когда ты в след раз будешь собирать что-то по этим же рецептам – ты соберешь уже не совсем то же самое, ведь туда могли что-то закоммитить.

Эм…. Есть же параметры от дистрибутива, платформы и образа для решения этой задачи красиво. Да пишутся .bbappend, но если ты держишь их в одном своём слое, то проблем нет. В том их смысл, что бы изменять параметры сборки без форка.

Да и в buildroot есть BR2_EXTERNAL, что бы не делать форк.

Эм…. Есть же параметры от дистрибутива, платформы и образа для решения этой задачи красиво. Да пишутся .bbappend, но если ты держишь их в одном своём слое, то проблем нет. В том их смысл, что бы изменять параметры сборки без форка.

Да, все так. Наверное, если этим занимается один человек, то можно сделать красиво, вот так как в теории. Но у нас международная команда, несколько проектов, легаси, там люди с десятилетним ёкто-опытом, только этим и заняты и не один и не два, и ТАКОГО нагорожено – ты бы видел. Там вокруг екты – мейкфайл, чтоб по разному ее запускать, а вокруг мейкфайла – питоновский скрипт, я так и не понял зачем, а внутри – своя систем тегохранения чтоб все сабмодули чекаутить куда надо и все равно все это работает ужесно, постоянно ломается, и чтоб одну строчку закоммитить надо потом еще два раза хеш коммита закоммитить.

Напоминает передачу что где когда :)

У нас всё это удалось редуцировать до одной meta репы на пачку проектов и kas-файлов для сборки. Для управления слоями kas оказался лучшим решением. И дошли до этого не с первого шага.

Теперь для повторения сборки:

git clone .../meta-XXX
kas build meta-XXX/kas/YYY.yaml

Все остальные слои сами будут подтянуты, чекаутны и подключены. Переменные настроены. Больше и не надо.

У нас сам Yocto правят только несколько человек. Остальная толпа тупо разрабатывает софт, или собирая через SDK, или из CI/CD забирает прошивки.

Был опыт работы с заказом платы у сторонней организации с запускам минимального образа. Им отдали meta шаблон с тестами, они добавили минимальные правки (dts и пару патчей ядра).

При этом ладно что есть проекты на Qt, так ещё есть проекты на golang, rust и nodejs. Видите ли web-морда нынче нужна всем, а пишут её кто на чём. И это, в том числе, и под слабенькие 32 битные армы.

А с таким раздутым SDK пилить костыли для buildroot, создавая сложные pipeline совсем не хочется. Поэтому Yocto. Лучше потерпеть, что первая сборка занимает часы пока все эти llvm-native, rust-native, nodejs-native, … соберутся. Но как только они попали sstate всё летает. И не надо говорить, что nodejs, go и т.п. можно собрать вне buildroot. Это приводит к такому графу сборки, что мама не горюй. В итоге вместо простых типовых рецептов для Yocto пишутся CI/CD с костылями размазанных по нескольким слоям (makefile проекта, makefile в buildroot, цепочка в CI/CD, ещё и с хранением артефактов в разных местах).

Бесят жёсткие обновления мажорных версий. Пока сидим на 5.0 Scarthgap. Ибо в 6.0 дошли до очередной перетасовки bitbake, openembedded и yocto. [режим ворчуна] Нафига было вводить этот bitbake-setup и т.п. Это ещё один уровень абстракции, да ещё и на входе в систему.[/режим ворчуна]

Так что согласен, Yocto требует постоянной работы хотя бы одного члена команды. И порог входа у него совсем не тривиальный и растянут на месяца. Но один такой человек, способен существенно упростить работу остальным.

Вполне разумного хочешь: все так и делают

Продолжаем пытошную.

• Как насчет параллельного хранения нескольких архитектур? Когда один и тот же исходник собираем под несколько архитектур.

• Возможности поддержки нескольких тулчейнов (для разных целей)?

• Можно ли делать какое-то наследование? Бывает так, что есть две одинаковых железки, но у одной кнопка в вебе должна быть синяя, а у другой фиолетовая. В остальном все идентично. Ну кроме шильдика. Можно ли отнаследоваться от листа и добавить изменение только для этой кнопки?

Несмотря на большое количество конечных целей. Все они укладываются в тройку архитектур. И в каждой еще по 2-3-4 процессора. И все это на 3-х версиях ядра и загрузчика. Остальная разница только в составе функционального софта (там различий богато и все это выливается в те десятки конечных целей). И вот ваще не улыбается для каждой конечной цели держать полный набор конфигов. Хочу как в DTS. Базовый набор для всех. Инклюд базы и несколько инклюдов кастома. А если еще поверх можно оверлеев намазать (для всяких экспериментов, отладки, костылей и т.д.)

Для управления слоями kas оказался лучшим решением. И дошли до этого не с первого шага.

не знаю че за kas, но выглядит будто не из состава екты. А сообщение назад ты удивлялся что у кого-то проблемы с воспроизводимостью сборки

толпа тупо разрабатывает софт, или собирая через SDK

Эх, хорошо вам :)

Ибо в 6.0 дошли до очередной перетасовки bitbake, openembedded и yocto

Это - отдельная боль

Как насчет параллельного хранения нескольких архитектур? Когда один и тот же исходник собираем под несколько архитектур.

Ну это же само собой. Просто собирай разными тулчейнами. Ну кое-где ифдефы в коде есть, хидеры бывают немного разные. Но это точно поддерживается: у нас так

Возможности поддержки нескольких тулчейнов (для разных целей)?

Есть. Тулчейн – такой же параметр конфига борды как, например, номер версии сборки: какой укажешь ( можно указать путь к тулчейну ) такой и будет работать. У нас так

Можно ли делать какое-то наследование?

И это есть. Есть механизм external tree. Правда, сразу оговорюсь что я его не применял в смысле многослойного использования, но слыхал что так можно. Это такое дерево файлов, которые накладываются поверх дерева файлов буилдрута и как бы патчат что там уже есть. ТАким образом ты можешь держать один конфиг для базовой платы и внешние external tree для как бы наследников этой платы, где будут прописаны только изменения относительно базовой конфигурации. Я все мечтаю с этим поиграть, но вместо этого разглагольствую на ЛОРе

по третьему пункту еще подумалось: есть же еще дифы конфигов, я забыл как называется. Части конфигов или фрагменты, как-то так. Но суть в том что ты хранишь некоторый базовый конфиг и некоторый диф к нему, где ты можешь его дополнить или переопределить. И после того как ты переключился на конфиг конкретной платы ( это такой один из главных шагов в BR ) ты к нему еще отдельной командой применяешь эту дельту, а потому уже собираешь. Через это – наследование.

Я только не понял, объявлен ли этот механизм устаревшим и взамен ему ввели экстернал три или в дополнение – тут уже надо углубляться че они там планируют. Но это работает и, вроде как, то что ты ищешь

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

https://buildroot.org/downloads/manual/manual.html#outside-br-custom

Есть Example layout в конце параграфа. Но только относительно похожее нашёл.

Просто патчи поверх дерева файлов:

|- patches/linux/0001-some-change.patch
|- patches/linux/0002-some-other-change.patch
|- patches/busybox/0001-fix-something.patch

Есть provides/ которые позволяют «впихнуть» в основное дерево buildroot:

|- provides/jpeg.in
|     |config BR2_PACKAGE_MY_JPEG
|     |    bool "my-jpeg"
|     `----
|- package/my-jpeg/Config.in
|     |config BR2_PACKAGE_PROVIDES_JPEG
|     |    default "my-jpeg" if BR2_PACKAGE_MY_JPEG
|     `----
|- package/my-jpeg/my-jpeg.mk
|     |# This is a normal package .mk file
|     |MY_JPEG_VERSION = 1.2.3
|     |MY_JPEG_SITE = https://example.net/some/place
|     |MY_JPEG_PROVIDES = jpeg
|     |$(eval $(autotools-package))
|     `----

Target packages  --->
    Libraries  --->
        Graphics  --->
            [*] jpeg support
                jpeg variant ()  --->
                    ( ) jpeg
                    ( ) jpeg-turbo
                        *** jpeg from: Example br2-external tree ***
                    (X) my-jpeg
                        *** jpeg from: FOO_27 ***
                    ( ) another-jpeg

Но как-то всё немного не то.

не знаю че за kas, но выглядит будто не из состава екты.

Утилита внешняя. Несколько раз мелькала на конференциях и подкастах по Yocto. Что это такое спокойно ищется по yocto kas, в том числе и доклады и видео.

Учитывая мизерное число видеоматериалов по теме, она попасть в поле зрения могла бы.

Yocto (точнее bitbake) на протяжении многих и многих лет пытается ввести инструменты для управления слоями. Но что-то получается невразумительное. Вот в 6-ом опять что-то не доделали.

А сообщение назад ты удивлялся что у кого-то проблемы с воспроизводимостью сборки

Если они связаны с версиями и составом слоёв. То вариантов решения же много, главное хоть какой-то зафиксировать. Кто-то на repo сидит, кто-то на git submodle, кто-то на скриптах.

толпа тупо разрабатывает софт, или собирая через SDK

Эх, хорошо вам :)

Баба с возу — кобыле легче

Продолжаем пытошную.

При этом ты упорно пытаешься скрестить ежа с ужом.

По всем трёх пунктам ответ: да. Иначе, как бы оно работало?

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

• Какова поддержка железа в mainline Linux и U-Boot?
  Часто производители микропроцессоров выкинут недотулчейн и всё (аля Allwinner или Rockchip)
  Или ведут свою ветку, с редким отправлением патчей (аля TI).
  Или проц из эры до dts.
• Насколько реально привести использование ядра Linux и U-Boot на всех платах к одной актуальной версии?
  Оба проекта рекомендуют использовать их актуальные версии ядра.
  Хоть и заложена возможность использования сторонних.
• Есть ли проц в примерах buildroot?
  Это сразу решит 100500 вопросов. \
• Насколько сложно портировать софт на версии библиотек из buildroot и yocto?
  При таком числе устройств надо не систему сборки вкорячивать в имеющееся.
  А приводить имеющееся к стандартным инструментам.
  Внедряя плановые обновления зависимостей.

От этого и строить план.

• Подготовить buildroot для всех устройств
  • Минимальный образ.
  • Одна версия актуальных U-Boot и ядра Linux.
  • Отделение патчей и dts.
  • Цель: иметь единый инструмент для запуска новых устройств с последующей интеграцией в единую систему сборки.
• Разделение устройств на собираемых в buildroot или yocto (или в чём-то другом).
  • Для всей мелочи, намного проще оставаться в buildroot. На начальном этапе точно. Т.к. в buildroot дистрибутив уже заточен на сборку микро образов.
  • А вот при наличии больших библиотек и разнородных компиляторов, уже лучше собирать в Yocto.
• Портирование софта на библиотеки и компиляторы из buildroot/yocto.
• …

не знаю че за kas, но выглядит будто не из состава екты.

Посмотрел (послушал) что говорят разработчики про bitbake-setup. Им, понимаете ли, не нравиться, что KAS принадлежит не связанной с ними компании. Поэтому решили сделать ещё одну утилиту для управления слоями.

При этом:

• Запихнули фрагменты для build-setup в основные репы.
• Перестали поддерживать poky.git разбив его части.
• Переделали bitbake.git и openembedded-core.git.
• Запихали bitbake-setup в bitbake.git.
• Добавили в bitbake разбор файлов сгенерированных bitbake-setup в вышестоящих директориях.
• …

Но: «Вы можете и дальше использовать KAS или другие инструменты для управления слоями»

Вы можете и дальше использовать KAS

Ключевой вопрос на такое утверждение: «А можно не использовать?»