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

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

К сожалению пока вопрос именно такой - «как запихать в…»

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

Комплект ПО и тулчейнов у меня уже намоленый и оттестированный. Именно поэтому я не готов перетрясать весь этот комплект чтобы он стал более похожий на то, что из коробки предоставляет buildroot или yocto (или что-то еще). В будущем, да, было бы неплохо все это привести к единым версиям всех компонентов и инструментарий должен этому способствовать. Но это следующий этап.

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

Использовать или нет дело каждого. Лишь бы палки в колёса не совали.

Это

Мне нужно все это аккуратно перенести из самопальной системы сборки в «стандартную».

и это

Комплект ПО и тулчейнов у меня уже намоленый и оттестированный.

Уже конфликтуют.

У buildroot уже проверенный временем SDK. Который обновляется от версии к версии.

buildroot – это простой инструмент для запуска минимального образа на устройстве. Он часто используется для запуска платы. Ему не надо кеширование сборки пакетов, т.к. образ маленький и его собрать не долго. Для СУЩЕСТВЕННОГО ускорения сборки, у него есть возможно предварительной сборки SDK.

Используя buildroot + BR2_EXTERNAL получаешь очень аккуратный способ описания сборки 150 прошивок в едином стиле с «наследованием».

Пытаться поменять компиляторы и базовые библиотеки в buildroot? Такого не видел. Видел закостянелые форки, которые можно собрать только в виртуалке с ОС 20-летней давности.

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

Хотеть можно многого. У Yocto аналогичное делается через sstate.

Но надо понимать что такое yocto.

Сейчас это три репы

• bitbake – система сборки.
• openembedded-core – минимальные слои для сборки.
• meta-yocto – слои с дистрибутивом от yoctoproject.

На первых двух реально собрать мини-образ, без компонентов от yocto. И так некоторые делают.

Теоретически можно написать свой meta вместо openembedded-core и meta-yocto. Но это такой объём работы, что и года может не хватить.

чтобы не бежать марафон по граблям с самого начала.

Найдите версии buildroot или yocto/oe которые содержат близкие версии пакетов к вашим SDK. Ну не с нуля же они были сделаны.

Только надо понимать, что для сборки старых компиляторов, нужны старые версии ОС. Причём на столько старые, что только в VirtualBox их и можно запустить.

А опиши, если не сложно, как выглядит работа для обычных разработчиков через сгенерированные SDK у вас. Я про ёкту.

• Для образа вызываешь задачу populate_sdk.
  • В полученном SDK и компиляторы, и библиотеки есть.
  • Из нюансов: приходилось пару dev пакетов добавлять в TOOLCHAIN_TARGET_TASK
• Полученный файл устанавливается у разработчика.
• А далее что-то в таком роде:

source /opt/poky-.../environment-setup-...
cmake ...

Есть два принципиальных подхода:

• Сборщик всего мира, а-ля buildroot и yocto: соберёт сначала компилятор+libc (тулчейн), затем ядро/загрузчик/обвязку, затем юзерспейс, всё из исходников, затем всё это выдаст в виде образа в необходимом формате, и вы получаете «дистрибутив» в изначальном смысле слова;
• Сборщик образов существующего дистрибутива в определённом формате, ничего не компилирует: mkosi, packer, bootc

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

Второе — если вам принципиально подходит пакетная база какого-то из существующих дистрибутивов (arm/risc-v/mips/whatever типичное ходовое, устраивают их сборочные флаги готовых библиотек) и вам нужно сфокусироваться на запуске вашего ПО — это экономит время и ресурсы на обновления и отслеживания уязвимостей, а ядро, загрузчик и своё ПО вы можете собрать отдельно и использовать как артефакт при сборке образа.

Я обычно всем рекомендую пакетную базу, пакетный менеджер и систему сборки пакетов Debian/Ubuntu, потому что она позволяет чрезвычайно легко кросс-компилировать на любой архитектуре под любую другую архитектуру, устанавливая пакеты и заголовочные файлы неродной архитектуры прямо из репозиториев, штатным образом (позволяет смешивать какое угодно количество архитектур на хосте, и готовые тулчейны подо всё), и не задумываться о настройке сборочной системы вообще, благодаря встроенным автоматизирующим врапперам для autoconf, cmake, qmake, meson, ninja, ant, perl/python, maven, gradle, bmake, golang, и наверняка другим системам.

Я у себя использую двустадийный mkosi: сначала собирается builder-образ на основе Debian, в котором кросс-компилируется необходимое ПО и выдаётся в виде .deb’ов, а затем собирается image-образ нужной архитектуры, в который устанавливается базовый комплект ОС и собственное ПО из .deb’ов, и выдаётся в виде готового образа (mkosi штатно поддерживает кучу разных output’ов).

mkosi поддерживает слои, но относительно простенькие. Ускоряет начальный bootstrap базового образа.

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

Наверное, вам скорее нужна система дистрибьюции?

Обновления решаются специальным ПО, сделанным для обновления embedded-систем:

• https://swupdate.org/
• https://mender.io/
• https://rauc.io/
• https://memfault.com/ota-firmware-updates/

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

Часть их них чисто для «обновлений прошивки» с кучей удобных функций, чтобы ненароком не установить несовместимую версию для другого девайса, и т.п., а часть поддерживают также обновление ПО, т.е. разделяют «слой ОС» и «слой софта». Типа OSTree, который уже упоминали, но не всегда именно с подходом OSTree.

Отвечу тут сразу на оба поста (пионер должен быть вежливым):

У меня первый случай (нужно контролировать всё). Обоснование я уже тут в ветке тонким слоем разложил.

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

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