Выпьем за упокоение души …

Что я уже видел-гуглил.

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

Поправил за тебя. Не корябь названия.

buildroot

Удобен для запуска платы с самым минимальным корневым разделом. Например, для правки ядра Linux и u-boot.

Yocto

«Удобен» для коллективной работы над несколькими проектами одновременно. Но нужен тот, кто это всё разбатает по полной. В отличии от buildroot ориентирован на повторяемую сборку каждого компонента (рецепта) с мощной системой кеширования артефактов.

Рекомендую на команду разработчиков сразу разобраться с такими компонентами:

• единая система кеширования исходников, масштабируемая на несколько компьютеров в сети.
• единая система кеширования артефактов сборки, масштабируемая на несколько компьютеров в сети.
• локальный сервис эквивалентности хэша артефактов.
• локальный сервис ревизий сборки.
• CI/CD на сборку. Yocto использует buildbot

Для управления слоями и целями сборки использую KAS.

Всё остальное в документации.

З.Ы.: Надо уметь использовать оба инструмента. А после них, разве что, OpenWRT идёт.

то это всё разбатает по полной

не смог распарсить

Для управления слоями и целями сборки использую KAS.

что за зверь?

единая система кеширования исходников, масштабируемая на несколько компьютеров в сети.

единая система кеширования артефактов сборки, масштабируемая на несколько компьютеров в сети.

локальный сервис эквивалентности хэша артефактов.

локальный сервис ревизий сборки.

CI/CD на сборку. Yocto использует buildbot

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

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

А что в мире уже придумали на такой случай?

У вас по описанию получился buildroot. Я с ним активно работаю, так что могу ответить на какие-то конкретные вопросы.

Там система примерно следующая:

Сам buildroot изначально собирает только rootfs. Но в конфигурации buildroot можно указать, что нужно собирать u-boot и kernel, у последних двух свои конфиги. Для всего этого дела качаются исходные коды (далее пакеты) со всего интернета (или из архива buildroot) в виде архива. При этом есть просто пакеты, а есть host-пакеты, это всякие компиляторы, макропроцессоры и пр. подобное, что необходимо для сборки.

Следующим этапом это всё поочереди распаковывается в build/ и собирается. Сначала host-программы, затем u-boot, kernel и rootfs. При это, мне недавно было тестировать два разных ядра, из двух разных коммитов и, в итоге, получалось что есть build/linux-<commit1> и build/linux-<commit2>. В итоге, просто поменяв в конфиге хэш коммита, у меня в финальный образ нужное мне ядро без пересборки.

Потом при необходимости корректируешь конфиги u-boot, kernel, rootfs пересобираешь и хорошо (хотя некоторые тонкости там есть). А потом просто берёшь и сохраняешь make savedefconfig, а дальше этот конфиг можно использовать (опять же, тут есть тонкость, что конфиги u-boot и kernel отдельно сохранять и в конфиге прописать путь до них).

Там система примерно следующая:

есть мнение, что вы невнимательно ознакомились с моими основными требованиями.

есть ли у buildroot слой куда попадает собранное ПО в виде бинарных пакетов, из которых позже можно собрать уже прошивку?

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

Не только линукса. Тот же FreeRTOS под MIT тоже опенсорсный и много всякого узкого специфичного. Вообще открой для себя мир ОС реального времени (из жирненького к ним относится Google Fuchsia, да та на которую хотели андрюшку менять). Задача на самом деле несколько шире:

Нужен универсальный инструмент сборки всего подо всё и какой-то общепринятый стандарт конфигурации всего этого дерьма (CI/CD и разные костыли к гитхабу как раз этим занимаются, а ещё те костыли что ты тут описал, но это костыли потому что они к линупсам прибиты). Но нет, этого никогда не будет, потому что для этого придётся переписывать много всякого и системы сборки вроде cmake работают совершенно иначе от тех, которые тянут библиотеки откуда-то из сети. А ещё авторы того же cargo и иже с ними не учли интересов проприетарщиков и делали всё с учётом что оно опенсорсное должно быть. Так что нет, будет куча подпорок и костылей.

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

есть мнение, что вы невнимательно ознакомились с моими основными требованиями.

Есть мнение, что мнение выше справедливо.

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

Хм… Конкретно этой частью я мало интересовался. Вообще, всё собранное остаётся в build/ с исходниками, а потом вся бинарная часть отправляется в target/.

В теории, я вижу два способа как это дело можно реализовать, но в одном случае много работы выходит, а во втором случае ещё больше. :^)

А вы хотите собирать свои пакеты или чужие? Если заниматься своими пакетами, можно просто заранее в *.mk файлах прописать, что брать готовые бинарники если есть, иначе собирать и сохранять в каком-нибудь хранилище. Если брать пакеты, которые buildroot предоставляет из коробки, то переписывать все *.mk файлы – такое себе.

Не только линукса.

наверно я был не точен и надо было сказать, что «у меня есть много приборов (больше полутора сотен) где…»

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

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

охож на знакомый конфигуратор ядр

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

Для управления слоями и целями сборки использую KAS.

что за зверь?

https://kas.readthedocs.io/en/1.0/userguide.html

Подготовка:

• В своём слое meta_FOOBAR размещаешь kas-файлы с описанием слоёв и итоговой цели сборки.

Использование:

• Клонируешь meta_FOOBAR
• Вызываешь утилиту kas для сборки.

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

Локально с.м.:

• DL_DIR
• SSTATE_DIR

Для коллективной работы с.м.:

• BB_GENERATE_MIRROR_TARBALLS
• PREMIRRORS
• SSTATE_MIRRORS
• BB_HASHSERVE
• PRSERV_HOST

Ну и видео/статьи по ускорению сборки в Yocto.

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

Да. Но нужно выбрать инструмент для обновления прошивок. Мне зашёл swupdate.

Кроме этого есть:

• Встроенный devtool для правки исходников и рецепта в рабочем проекте yocto. С возможностью залить изменённый компонент на устройство, без полной перепрошивки. https://docs.yoctoproject.org/dev/ref-manual/devtool-reference.html
• Возможность создать SDK и программировать локально, закидывая и дебажа по ssh. Можно найти примеры в плоть до настрой qtcreator-а.

З.Ы.: Но ещё раз это всё надо разботать по полной. И займёт это не один день, и даже не одну неделю.

Ты это в одного суркова это будешь делать?

А по твоей проблеме мысли простые. Либо делаешь под узкий круг задач так как делал раньше, либо как все остальные страдаешь с Yocto. Никто ведь не готов что-то там новое разрабатывать или делать Yocto более удобной для вхождения, тем более для такой сложной задачи. Будут ждать когда можно будет свалить эту задачу на ИИ агентов.

З.Ы.: Но ещё раз это всё надо разботать по полной. И займёт это не один день, и даже не одну неделю.

напугал ежа голой жопой )))

Я под такое планирую цельный отдел погромистов.

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

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

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

Но первый этап Buildroot.

Цель: минимальная фс + ядро + загрузчик под устройство.

Для ускорения сборки:

• кеш загрузки
• готовые SDK

Второй этап: локальная сборка в Yocto

И только потом: отдел программистов

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

Ну, тогда yocto.

У меня уже есть система сборки аналогичная buildroot, но этого уже мало.

Локально ставить yocto для постепенного внедрения приемлемо. Но хочется видеть куда делать следующий шаг. А вот это пока смутно.

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

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

И когда все уже отладилось, оттестилось, просто обновляешь строчку в конфиге и вот у тебя обновление прошивки.

Yocto - это инструмент для создания дистрибутива. Сделать можно многое. Только единого готового рецепта нет. Пару примеров, а остальное в закромах знающих. Тоже обновление кто как делает.

Поддержка RO корня в Yocto есть одним из параметров образа, но он не даст использовать пакеты.

С другой стороны можно использовать A/B обновление и отдельные образы для прода и разработки.

Еще вопрос. Как я понял у yocto есть куча своих целей и слоев. Но фактически, мне нужны мои цели и слои. Как решается вопрос конфликтов при обновлении? Если я например все их слои по-удаляю. При обновлении мне они обратно будут прилетать?

Базовые слои минимальны, остальные слои добавляются по мере необходимости. Свои слои, как правило, зависят от базовых, производителей микропроцессоров (meta-sunxi и т.п.) или ПО (meta-qt и.т.п).

Есть механизм обновления рецептов. Например, в своём слое определяешь патчи для ядра определённого в нижележащем слое (базовом или от вендора).

но он не даст использовать пакеты.

В общем случае пакеты и не нужны. Прошивка всегда с rootfs RO.

Но для удобства разработки (тут все для этого) хочется иметь такую возможность.

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

Для массовки, +1 за Yocto

Может тебе в гитлабе пучок пайплайнов напилить и прикрутить какое-нибудь s3-like хранилище для хранения артефактов?

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

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

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

OpenWrt – как партия скажет, так внутри и будет. Свой стек сервисов для работы на очень слабом железе. Методы расширения образа есть. Китайский Allwinner выпускает свою Tina Linux на базе старого-старого порта OpenWrt.

PTXdist – не смотрел и смысла не вижу. По «популярным» buildroot и Yocto не так и много учебного материала и людей работавших с ними, с остальными на порядки меньше.

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

наверно это ускользнуло из моего поста.

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

OpenWrt – как партия скажет, так внутри и будет

Что ты конкретно имеешь в виду, ибо сторонние репки в feeds никто не запрещает подключать, точно также как и конфигурировать под свои хотелки?

ибо сторонние репки в feeds никто не запрещает подключать

Ну я и сказал

Методы РАСШИРЕНИЯ образа есть.

Только в OpenWrt всё вертится вокруг своего стека базовых сервисов, кастомного dbus, своего подхода к конфигурации и обновления системы.

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

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

Надо всё же отделять базовый дистрибутив и прикладное ПО.

Если ты хочешь поменять в buildroot, yocto или т.п. базовые компоненты на свои версии. То это тупиковый, писец как трудозатратный метод. Можно, но не то, что надо.

На себя брать отслеживание CVE? В текущее время ИИ шторма?

То что есть в дистрибутиве, берётся из дистрибутива. Остальное добавляется.

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

наверно это ускользнуло из моего поста.

Понятие слабого железа слишком растянуто. Если у тебя 32 МБ оперативки одно. На 128 МБ с двумя 32-битными ядрами уже многое за глаза.

Но для малых серий, дешевле взять 1000 шт. хороших SoM-ов, чем пердолиться со старым говном на SPI флешачках.

SoM-ов, чем пердолиться со старым говном на SPI флешачках

А еще есть поддержка уже отгруженного и там ограничения в полный рост и по флешу и по рам и по процессору.

но вообще «Свой стек сервисов для работы на очень слабом железе» это не цель.

То что есть в дистрибутиве, берётся из дистрибутива. Остальное добавляется.

я конечно готов брать если версии которые мне нужны там есть.

базовые компоненты на свои версии.

что такое базовые компоненты?

На себя брать отслеживание CVE?

В моем случае это крайне специфичное железо, которое всегда внутри защищенного контура.

Всегда есть не нулевой шанс внезапно выйти на «потребительский» рынок, но там, я надеюсь, все будет из максимально стандартных компонентов.

То это тупиковый, писец как трудозатратный метод. Можно, но не то, что надо.

К сожалению нужно сохранять преемственность. Есть готовая прошивка, которая оттестирована и работает. Первым шагом я бы хотел ее максимально повторить на базе yocto. А потом уже заменять компоненты на те, которые предоставляет сама yocto. За несколько итераций прийти к готовым рецептам.

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

Ещё добавлю, что у многих производителей оборудования есть официальные «слои» для йокто. Это упрощает сборку прошивки для них. Для билдлута тоже встречается, но гораздо реже.

В целом билдрут это больше для каких-то наколенных поделок, а йокто для «сурьёзного энтерпрайза».

Ну и ещё есть опция - собирать всё самому, своими скриптами. Или вообще взять какой-нибудь debian и его водрузить на плату.

mkosi может? сам не пользовал, но комрады что-то собирали

https://github.com/rosalinux/image-builder/tree/main/device

Пакеты и конфиги в rpm.

Или вообще взять какой-нибудь debian и его водрузить на плату.

Отчасти плюсую - загрузчик и ядро собираем сами потому что они критически зависят от палаты, а вот зачем изобретать свой дистрибутив для userspace - непонятно. Берём какой-нибудь (debian/alpine/по вкусу) и используем его в том количестве в котором удобно. Можно его init использовать, можно свой прописать в параметры ядра. Библиотеки специфичные для железки + свой софт опакечиваем в формат под выбранный дистрибутив. Стандартные библиотеки используем из дистрибутива. Чтоб собственно их поставить - используем или qemu под архитектуру (НЕ под конкретную плату) или разбираемся как менеджер пакетов этого листрибутива работает с foreign-arch-префиксом

Берём какой-нибудь (debian/alpine/по вкусу

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

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

Наколенные скрипты себя уже исчерпали.