Comments 16
Докер - лишний.
Buildrot не мусорит за пределами build folder, кроме buildroot-ccache и возможно dl (download) папки для исходников. Ccache обычно лежит в home, dl был под каталогом buildroot но вроде грозились менять.
Ад начнётся когда вы станете имплементировать свою плату, а не стандартную.
Для поддержки кастомного uboot и kernel есть стандартные механизмы для указания пути к ним (git) и commit id для ревизии, которую надо использовать - указывается в defconfig.
Для использования своих тестовых версий чего угодно есть файл local.mk позволяющий пареопределить источник исходников для любого (почти) компонента. Читайте доки.
А еще ад начнётся когда вы столкнетесь с необходимостью переопределить что угодно лежащие в самом buildroot (другую версию package) или ещё что - придётся клонировать его в свой git и править.
Buildroot не позволяет переопределять в отличии от yocto.
Так что использование своей версии стандартного софта вместо того, что указано в самом buildroot сопряжено с трудностями, иногда совершенно неоправданными.
Построить hello world любого уровня для стандартной платы просто, все остальное будет сопряжено с трудностями.
Нет стандартной поддержки secure boot.
Мимо, senior embedded dev.
Docker — лишний? Вы любитель мема "На моем компьютере все работает"? CI/CD тоже без контейнеризации заводить будете?
Этот цикл рассчитан на новичков в Buildroot, которые хотели бы начать его использовать, но не знают, как подступиться. Поэтому всё будет вводиться последовательно. С данным подходом переход от вводной части с базовыми определениями к интеграции новой для Buildroot платы будет выглядеть непоследовательно, не находите?
В целом, этот вопрос относится ко всему комметарию: не стоит просить на данном этапе чего то сложнее Hello World. Для этого банально рано
IMHO, именно для новичков использование docker даёт только усложнение. Buildroot нормально заводится на широком спектре дистрибутивов без танцев с бубном. Необходимые зависимости нормально ставятся из репозитория дистрибутива, А во время сборки сам билдрут не гадит по системе. Всегда можно удалить рабочую папку и начать заново.
P. S. У меня в CI/CD, который собирает buildroot нет докера
Для того, чтобы лишний раз не усложнять, минимально необходимая база команд Docker описана.
Зависимостей почти нет т.к. пока на системе один только Buildroot. Но когда начнется добавление своих пакетов, система так или иначе будет забиваться непонятно чем. Да и про воспроизводимость не будем забывать. Так что я считаю, что лучше всегда и всё оборачивать в Docker. Не сложно, но очень удобно
Всмысле система будет забиваться при добавлении своих пакетов? Это же просто добавление пары файлов в свой слой
Так что я считаю, что лучше всегда и всё оборачивать в Docker.
Полностью с вами не согласен и полностью согласен с вашим визави по этой ветке диалога.
Считаю категорически неверным везде где ни попадя, нужно или не нужно пихать докер...это какое-то на мой взгляд сумашествие на этой моде. Был период когда все с ума посходили на теме VMware. Ставили виртуализацию машин на каждое отдельное приложение сервиса (интересно нашелся ли кто, кто Postfix бы засандалил на каждый процесс, но не удивлюсь если такие найдутся)...так вот мода наконец-то прошла и теперь вроде как виртуализацию только с головой используют, теперь же мода пошла на этот докер (замечу пик уже прошел, но такие ребята как автор статьи все еще есть).
Для того, чтобы переделывать встроенные рецепты из buildroot в итоге поверх намутил систему, которая эти самые рецепты удаляет. Пока писал этот функционал, вспоминал добрым словом yocto в котором можно не просто переопределять всё, но и указывать для какой платы переопределяешь.
А что не так с secure boot в buildroot? Вроде образы для arm с tee нормально собираются.
Ой, это коммент к @BoldDwarf
Тоже пришлось писать свои костыли для переопределения.
Secure boot тут это цифровые подписи для загрузчика и ниже.
В yocto часто есть стандартное решение от вендора, в buildroot это надо вкостыливать.
При осмотре предлагаемых вендорами решений практически всегда будет поддержка yocto.
Потому что там легко все переопределить через свои рецепты.
ИМХО Buildroot проще на старте но yocto значительно лучше на дистанции...
Всё ещё лучшая статья про buildroot была написана @heavyC1oud
Благодарим вас за труд. Ждём продолжения.)
На счет переопределения переменной BR2_EXTERNAL, мне кажется лучше использовать стандартный флаг make buildroot'а (п.9.2 оф.доккументации).
Там ещё пара полезных переменных вводиться и в menгconfig меньше руками надо делать.
Embedded Linux для начинающих — Часть 2