Buildroot что это

Встраиваемые системы на базе Linux

Buildroot это набор файлов сборки и корректировок, которые позволяют просто сгенерировать под разные платформы, полный набор инструментальных средств и корневую файловую систему Вашей целевой Linux системы. Инструментарий кросс-компиляции использует uClibc, небольшую стандартную C библиотеку.

Buildroot, в основном, используется людьми, работающими с маленькими или встроенными системами. Встроенные системы часто предназначаются не для распространенных x86 процессоров. Это могут быть PowerPC процессоры, MIPS процессоры, ARM процессоры и так далее.

Инструментарий компиляции это набор инструментов, которые позволяют скомпилировать код для системы. Этот инструментарий состоит из компилятора (в нашем случае, gcc), бинарных утилит, таких как ассемблер и компоновщик и стандартной C библиотеки. В системе, установленной на станцию разработки, конечно уже есть инструментарий компиляции такой, что можете компилировать приложение, которое выполняется на системе. Если использовать PC платформу, инструментарий компиляции выполняется на некотором x86 процессоре и генерирует код для x86 процессора. Под большинством Linux систем, инструментарий компиляции использует GNU libc, как стандартную C библиотеку. Этот инструментарий компиляции называется «host compilation toolchain» (главный инструментарий компиляции), и в более общем случае, система, на которой он выполняется, называется «host (главная) система». инструментарий компиляции предоставляется посредством дистрибутива, который Вы используете, и Buildroot ничего не может в нем нарушить.

Как было сказано выше, инструментарий компиляции, который поставляется с системой, выполняется и генерирует код для процессора Вашей host (главной) системы. Так как встроенная система, может иметь другой процессор, необходим инструментарий кросс-компиляции: это инструментарий компиляции, который выполняется на Вашей host (главной) системе, но, который генерирует код для целевой системы (и целевого процессора). Например, если главная система использует x86, и целевая система использует ARM, обычный инструментарий компиляции главной системы выполняется на x86 и генерирует код для x86, в то время, как кросс-компиляции инструментарий выполняется на x86 и генерирует код для ARM.

Даже если встроенная система использует x86 процессор, может быть интересен Buildroot, по двум причинам:

· инструментарий компиляции Главной системы несомненно использует GNU Libc, которая является полной, но огромной стандартной C библиотекой. Взамен использования GNU Libc на target системе, можно использовать uClibc, которая является небольшой стандартной C библиотекой. Если использовать эту C библиотеку, будет необходим инструментарий компиляции для генерации бинарных кодов, скомпонованных с ней. Buildroot может сделать это.

· Buildroot автоматизирует построение root filesystem со всеми необходимыми инструментами, например, как busybox. Так гораздо легче, чем собирать все вручную.

Зачем такие инструменты необходимы, когда можно скомпилировать gcc, binutils, uClibc и все инструменты вручную. Конечно, сделать так возможно. Но иметь дело со всеми конфигурационными параметрами, со всеми проблемами каждой gcc или binutils версии это очень затратно по времени и неинтересно. Buildroot автоматизирует этот процесс посредством использования Makefiles (сборочных файлов), и имеет коллекцию исправлений для каждой gcc и binutils версии так, чтобы сборки могли работать на большинстве архитектур. /4/

OpenWrt

OpenWrt — производная Buildroot, прошивка, основанная на Linux, для домашних маршрутизаторов (роутеров). Изначально поддержка ограничивалась серией Linksys WRT54G, но сейчас расширилась и включает в себя чипсеты других производителей, в том числе и x86. Наиболее популярными является серия Linksys WRT54G и Asus WL500G. OpenWrt в основном использует интерфейс командной строки, но одной из опций является веб-интерфейс. Техническая поддержка осуществляется с помощью форума и IRC канала.

Разработка OpenWrt стала возможной благодаря использованию производителем программного обеспечения лицензии GNU General Public License (GNU GPL), которая требует от разработчиков публиковать все производные продукты под той же лицензией.

Одна из трех самых популярных альтернативных прошивок для WiFi роутеров.

Главное в OpenWrt — это полная поддержка файловой системы JFFS2( структурированная файловая система, используемая в устройствах флеш-памяти), которая позволяет использовать для управления пакетами менеджер пакетов ipkg. Всё это делает OpenWrt легко настраиваемой и адаптируемой системой для каждого конкретного случая.

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

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

Основные достоинства в пользовании OpenWrt :

1) Он Бесплатный и с открытым исходным кодом. Проект является полностью бесплатным, под лицензией GPL. Он намерено всегда будет размещен в легком доступе, с полным легкодоступным исходным кодом и легким в построении.

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

3) Поддержка общества. Речь идет не о «нас», говорят — «вы», речь идет о всех кто соберется вместе, чтобы работать и сотрудничать для достижения общей цели. /6/

OpenWrt Buildroot – Использование

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

Приступите к установке OpenWrt

Скачивание исходных кодов

Скачайте исходные коды: Свежая версия (trunk)

git clone https://github.com/openwrt/openwrt.git

(Последний) релиз Chaos Calmer 15.05.1

git clone https://github.com/openwrt/openwrt.git -b v15.05.1

Последняя версия в ветке Chaos Calmer

git clone https://github.com/openwrt/openwrt.git -b chaos_calmer

Обновление исходных кодов

Обновите исходные коды :

git pull

Исходные коды OpenWrt часто изменяются. Рекомендуется использовать исходные коды последней редакции.

Обновление репозитория

./scripts/feeds update -a

“Установите” загруженные пакеты (не обязательно, но требуется, если вы хотите , к примеру, собрать прошивку с LuCI).
Эта процедура создаст символьные ссылки на подкаталоги пакетов в основном “дереве” исходных текстов.

Для установки индивидуальных пакетов:

./scripts/feeds install

Чтобы собрать всё дерево пакетов:

./scripts/feeds install -a

ПРЕДУПРЕЖДЕНИЕ Это может занять много времени и не требуется, если вы не планируете развертывание репозитория пакетов для своей сборки.

Последовательность действий

Типичные действия по сборке:

выполняем make menuconfig , настраиваем платформу (Target System, Subtarget, Target Profile) и сохраняем конфигурацию в файл .config;

выполняем make defconfig (применяем стандартные параметры для профиля);
выполняем make menuconfig , модифицируем набор пакетов и сохраняем конфигурацию (в файл .config);

выполняем scripts/diffconfig.sh >mydiffconfig (сохраняем свои изменения конфигурации в файл mydiffconfig на будущее);

выполняем make либо make V=w либо make V=s .

Настройка параметров сборки

Запустите OpenWrt Buildroot’s ncurses — текстовый интерфейс настройки:

make menuconfig

Когда вы сохраняете конфигурацию создается файл ~/openwrt/trunk/.config содержащий параметры сборки.

Это меню позволяет выбрать платформу, версию набора инструментов (toolchain), которую вы хотите использовать для сборки и пакеты, которые вы хотите включить в образ прошивки.

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

Defconfig

make defconfig

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

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

Общая настройка

Menuconfig имеет ТПИ, который предназначен для выбора платформы, пакетов для компиляции, пакетов для включения в файл прошивки, некоторые параметры ядра и т.д.

make menuconfig

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

С самого начала было намерение разработать ‘menuconfig’, чтобы создать простую, но мощную среду для конфигурирования индивидуальных образов OpenWrt. Menuconfig более или менее понятен, поэтому даже самые специфические задачи конфигурирования могут быть решены с его помощью. В зависимости от конкретной платформы, необходимых пакетов и модулей ядра стандартный процесс конфигурирования будет включать в себя изменение следующих пунктов:

Платформа системы
Выбор пакетов
Настройки системы сборки
Модули ядра

Платформа выбирается из обширного списка поддерживаемых платформ с многочисленными профилями — начиная от конкретных устройств и заканчивая общими профилями, все зависит от имеющегося устройства. Выбор пакетов имеет несколько вариантов: либо выбрать все пакеты (‘selecting all package’), которые могут быть просто не практичны в конкретной ситуации, либо будет достаточно использовать стандартный набор пакетов, либо сделать индивидуальную подборку. Здесь необходимо отметить, что некоторые комбинации пакетов могут нарушить процесс сборки, так что возможно понадобится поэкспериментировать, прежде чем ожидаемый результат будет достигнут. В дополнение к этому, сами разработчики OpenWrt поддерживают лишь небольшой набор пакетов — который включает в себя все стандартные пакеты — но скрипт репозитория позволяет очень просто обработать локальный поддерживаемый набор пакетов и интегрировать их в процессе сборке.

Существуют 3 значения:

< >исходный код не будет обрабатываться

исходный код пакета будет кросс-скомпилирован в бинарный файл и opkg пакет будет собран и помещен в /buildsystem/bla/bla/bla , но ImageGenerator не включит его в образ прошивки!

пакет будет включен в прошивку (в SqashFS раздел)

Последний шаг перед началом компиляции образа(ов) — выход из ‘menuconfig’ — здесь можно сохранить определенную конфигурацию или загрузить уже существующую и предварительно настроенную.

Выйти из ТПИ и выбрать save — сохранить ваши настройки.

Настройка ядра

Обычно это не требуется, но вы можете это сделать:

make kernel_menuconfig

Обратите внимание, что make kernel_menuconfig изменяет конфигурационные шаблоны ядра дерева сборки и очистка build_dir не вернет их. Изменения могут быть просмотрены с помощью команды svn diff target/linux/ и отменены командой svn revert -R target/linux/ .

Зеркала источников

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

Локальное зеркало для источника пакетов
Каталог загрузки

В первом случае можно просто ввести полный URL -адрес на WEB или FTP -сервер, на котором размещается источник пакетов. Каталог загрузки — такой же путь, только к локальному каталогу системы сборки (или сети). Если у вас есть WEB/ FTP -сервер c архивами, система сборки OpenWrt проверит их перед тем как скачать с адресов, указанных в Make-файлах. Также и локальный каталог загрузки, размещенный в системе сборки будет проверен.

Опция ‘модули ядра’ нужна если требуются специфические (не стандартные) драйвера и т.д. – это, как правило, могут быть такие вещи, как модули для USB или драйвера конкретного сетевого интерфейса и т.д.

Пользовательские файлы

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

/files/

Например, предположим что вы хотите собрать образ с предварительно настроенным /etc/config/firewall , тогда поместите ваш измененный конфигурационный файл firewall сюда:

/files/etc/config/

Сборка образа

Теперь все готово для сборки образа(ов), которая осуществляется с помощью одной команды:

make

или (то же самое)

make world

Эта простая команда вызовет последовательность событий. Как уже говорилось, произойдет:

компиляция набора инструментов (toolchain)
потом кросс-компиляция исходных кодов с этим инструментарием
создание opkg-пакетов
создание образа прошивки, готового к прошивке.

Последовательность работы make

Команда make world сама выполняет следующую последовательность команд:
make target/compile
make package/cleanup
make package/compile
make package/install
make package/preconfig
make target/install
make package/index

Вы можете выполнить каждую из них отдельно. Например, если процесс компиляции какого-либо пакета прервался с ошибкой, после устранения ошибки можно продолжить сборку (без удаления уже сделанного):
make package/compile
make package/install
make package/preconfig
make target/install
make package/index

Параметры Make

Отладка

Параметр V=xx указывает уровень выдачи сообщений в процессе сборки.

Значением V можно указать:

1 или w — выводить путь к каталогу при входе в него и после выхода из него;

99 или s — выводить полную информацию о сборке, обычные сообщения жёлтым, ошибки красным, отладочные чёрным.

make V=w

Трассировка каталогов (путей).

make V=s

make V=99

Трассировка с полной информацией о сборке.

make V=sw

Тоже полная трассировка. (Если указать два значения, работает более полный вывод.)

Сборка на многоядерном процессоре

Процесс сборки можно ускорить запустив несколько параллельных задания с использованием параметра -j :

make -j 3

Используйте стандартную формулу
Если это приводит к случайным ошибкам сборки запустите компиляцию еще раз, но без параметра -j

Фоновая сборка

Если вы собираетесь использовать вашу систему во время процесса сборки, вы можете выполнять сборку используя только простой ввода/вывода и мощности процессора, например так (двухъядерный процессор):

ionice -c 3 nice -n 20 make -j 2

Сборка одиночных пакетов

При разработке или создании пакетов для OpenWrt удобно иметь возможность сборки только нужного пакета (пример с пакетом cups ):

make package/cups/compile V=99

Обнаружение ошибок сборки

Если по какой-то причине сборка не удается, то самый простой способ определить ошибки это:

make V=99 2>&1 | tee build.log | grep -i error

Команда сохраняет полную подробную копию вывода сборки (с stdout переданный в stderr) в /openwrt/trunk/build.log и показывает на экране только ошибки.

ionice -c 3 nice -n 20 make -j 2 V=99 CONFIG_DEBUG_SECTION_MISMATCH=y 2>&1 | tee build.log | egrep -i '(warn|error)'

somthing something screen

Команда сохраняет полную подробную копию вывода сборки (с stdout переданный в stderr) в build.log и показывает только предупреждения и ошибки в процессе сборки используя только фоновые ресурсы двухъядерного процессора.

Включение звуковых уведомлений

В зависимости от вашего процессора этот процесс займет некоторое время или дольше. Если вы хотите включить звуковые уведомления можете использовать echo -e ‘\a ‘:

make V=99 ; echo -e '\a'

Размещение образов

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

Например, если ваш это /openwrt/trunk, файлы находятся в /openwrt/trunk/bin/ar71xx.

Очистка

Время от времени вам может понадобиться очистить среду сборки. Следующие параметры make подходят для этой цели:

Clean

make clean

удаляет содержимое каталогов bin и build_dir .

Dirclean

make dirclean

удаляет содержимое каталогов /bin и /build_dir , а также дополнительно /staging_dir и /toolchain (инструментарий кросс-компиляции). ‘Dirclean’ — основная команда для полной очистки.

Distclean

make distclean

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

ВНИМАНИЕ : Кроме всего прочего будет стерта ваша конфигурация сборки (.config), ваш набор инструментов (toolchain) и все прочие исходные коды. Используйте с осторожностью!

Есть множество других функций в системе сборки OpenWrt, но выше рассмотрены некоторые из основных.

Примеры

Устранение неполадок

В начале получите больше информации о проблеме используя параметр make — “make V=99”.

Missing source code file, due to download problems.

Сначала проверьте, если URL -путь в make-файле содержит обратный слэш, то поэкспериментируйте с его удаленем (помогло несколько раз). В противном случае попробуйте загрузить исходный код вручную и поместить его в каталог “dl”

Compilation errors.
Не забудьте установить все необходимые пакеты для сборки:

В процессе компиляции возможно будет не доставать какого-то пакета. Ищите в выводе (make V=s) строку типа:

bash: неизвестная команда hg #например

Решение (ubuntu 12.04LTS): Вводим в теминале команду hg (например). Вывод терминала:

Программа 'hg' на данный момент не установлена. Вы можете установить её, выполнив: sudo apt-get install mercurial

Выполняем что просят: sudo apt-get install mercurial

Запускаем сборку (make) снова.

Проблема со сборкой cmus:

checking for header . no configure failed

Решение (ubuntu 12.04LTS):

#от root cd /usr/include ln -s linux/soundcard.h #возможно это лишнее mkdir sys cd sys ln -s ../linux/soundcard.h

Попробуйте обновить основной исходный код и все репозитории (Внимание! Может привести к другим проблемам). Поищите похожие ошибки в (TRAC), используйте фильтры, чтобы найти их. В противном случае сообщите об этой проблеме там, указав пакет, выходные данные (процессор, образ и т.п.) и код ревизии (main & package). Компиляция с make -j . иногда дает случайные ошибки. Попробуйте компиляцию без -j прежде чем сообщать об ошибке.

Bad environment variables.
GREP_OPTIONS не должен иметь —initial-tab или другие параметры, влияющие на его вывод

SED не должен быть установлен. Если это так, запустите `unset SED` перед компиляцией. (Смотрите Ticket 10612.)

Примечания

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website. OK More information about cookies

Last modified: 2021/10/15 05:06
by bobafetthotmail

Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.

Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International

Buildroot на BBB.

Buildroot – это набор make файлов, патчей, дистрибутивов, которые позволяют просто сгенерировать загрузчик, toolchain, linux и корневую файловую систему, а так же множество библиотек и программ для целевой платформы и хоста. Buildroot, в основном, используется людьми, работающими с embedded системами. Встраиваемые системы часто предназначаются не для распространенных x86 процессоров, а для ARM, PowerPC, MIPS и других CPU.

Процедура подготовки образа buildroot

git clone https://github.com/buildroot/buildroot.git
make beaglebone_defconfig (или beaglebone_qt5_defconfig с Qt5)
Процесс сборки занимает много времени, поэтому нужно набраться терпения.

vfat(boot.vfat): adding file 'MLO' as 'MLO' . vfat(boot.vfat): adding file 'u-boot.img' as 'u-boot.img' . vfat(boot.vfat): adding file 'zImage' as 'zImage' . vfat(boot.vfat): adding file 'uEnv.txt' as 'uEnv.txt' . vfat(boot.vfat): adding file 'am335x-evm.dtb' as 'am335x-evm.dtb' . vfat(boot.vfat): adding file 'am335x-evmsk.dtb' as 'am335x-evmsk.dtb' . vfat(boot.vfat): adding file 'am335x-bone.dtb' as 'am335x-bone.dtb' . vfat(boot.vfat): adding file 'am335x-boneblack.dtb' as 'am335x-boneblack.dtb' . hdimage(sdcard.img): adding partition 'u-boot' (in MBR) from 'boot.vfat' . hdimage(sdcard.img): adding partition 'rootfs' (in MBR) from 'rootfs.ext4' . hdimage(sdcard.img): writing MBR

После сборки платформы перейдите в output/images/

output/images/
├── am335x-boneblack.dtb
├── am335x-bone.dtb
├── am335x-evm.dtb
├── am335x-evmsk.dtb
├── boot.vfat
├── MLO
├── rootfs.ext2
├── rootfs.tar
├── sdcard.img
├── u-boot.img
├── uEnv.txt
└── zImage

В этом каталоге будет находится образ, который нужно записать на sd карту.

user@ws-273 ~ dmesg | tail -20 | grep sd [256680.121513] sd 7:0:0:0: Attached scsi generic sg3 type 0 [256680.122050] sd 7:0:0:1: Attached scsi generic sg4 type 0 [256680.122199] sd 7:0:0:2: Attached scsi generic sg5 type 0 [256680.122316] sd 7:0:0:3: Attached scsi generic sg6 type 0 [256680.125426] sd 7:0:0:0: [sdd] Attached SCSI removable disk [256680.126850] sd 7:0:0:1: [sde] Attached SCSI removable disk [256680.127318] sd 7:0:0:2: [sdf] Attached SCSI removable disk [256680.127807] sd 7:0:0:3: [sdg] Attached SCSI removable disk [256694.710493] sd 7:0:0:0: [sdd] 15728640 512-byte logical blocks: (8.05 GB/7.50 GiB) [256694.713723] sdd: sdd1 sdd2

Поиск недавно подключенной sd карты.

user@ws-273 ~ cd buildroot/output/images user@ws-273 ~/buildroot/output/images ls am335x-boneblack.dtb am335x-bone.dtb am335x-evm.dtb am335x-evmsk.dtb boot.vfat MLO rootfs.ext2 rootfs.ext4 rootfs.tar sdcard.img u-boot.img u-boot-spl.bin uEnv.txt zImage

Далее записываем образ на sd карту.
dd if=output/images/sdcard.img of=/dev/XXX (где XXX – это наша sd карта, sdX), данная запись осуществляется из директории buildroot.

. [ 4.710726] davinci_evm sound: ASoC: CODEC DAI hdmi-hifi not registered [ 4.736613] davinci_evm sound: snd_soc_register_card failed (-517) [ 4.994177] usbcore: registered new interface driver usbfs [ 5.038600] usbcore: registered new interface driver hub [ 5.073588] usbcore: registered new device driver usb [ 5.207866] davinci_evm sound: ASoC: CODEC DAI hdmi-hifi not registered [ 5.214817] davinci_evm sound: snd_soc_register_card failed (-517) [ 5.238471] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver [ 5.245458] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1 [ 5.288769] davinci_evm sound: ASoC: CODEC DAI hdmi-hifi not registered [ 5.295718] davinci_evm sound: snd_soc_register_card failed (-517) [ 5.328988] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 5.336104] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 5.380767] usb usb1: Product: MUSB HDRC host driver [ 5.385983] usb usb1: Manufacturer: Linux 4.1.6 musb-hcd [ 5.396713] usb usb1: SerialNumber: musb-hdrc.1.auto [ 5.413880] hub 1-0:1.0: USB hub found [ 5.419261] hub 1-0:1.0: 1 port detected [ 5.430838] davinci_evm sound: ASoC: CODEC DAI hdmi-hifi not registered [ 5.440256] davinci_evm sound: snd_soc_register_card failed (-517) [ 5.449635] davinci_evm sound: ASoC: CODEC DAI hdmi-hifi not registered [ 5.456576] davinci_evm sound: snd_soc_register_card failed (-517) [ 5.478657] davinci_evm sound: ASoC: CODEC DAI hdmi-hifi not registered [ 5.485644] davinci_evm sound: snd_soc_register_card failed (-517) done Initializing random number generator. done. Starting network: OK Initializing SGX graphics driver OK Welcome to Buildroot buildroot login:

Первый шаг на пути к buildroot сделан.

Buildroot: свой образ Linux для Raspberry Pi

Недавно я откопал у себя в столе Raspberry Pi Model B (Broadcom BCM2835 SoC). В качестве эксперимента я решил свой образ операционной системы Linux со своим набором тестового программного обеспечения. Сборку я производил при помощи Yocto Project (YP) (побробности можно почитать здесь).

Однако я столкнулся с тем что «из коробки» я не могу получить требуемый мне набор програмного обеспечения.

Неоходимые мне пакеты:

Python 3
- RPi.GPIO (нужен дотуп к GPIO)
- rpi-ws281x (хочу управлять LED панелькой)
- npm (необходимо устанавливать модули)
Поскольку я собираю образ Linux для встраиваемой системы (англ. embedded system), то тут есть один существенный момент, набор и версии програмного обеспечения фиксирован. В большей степени данное замечание касается Python, дополнительные модули командой pip install доустановить не получится (те которые требуют компиляции). К сожалению, в используемых мной слоях Yocto не оказалось рецепта для сборки модуля rpi-ws281x , это вполне поправимая ситуация, существует множество хороших инструкций по добавлению модудей Python в проекты Yocto.

Но самая большая проблема это нежелание Node.js собираться под платформу raspberrypi , причем как в релизной ветке dunfell так и в ветке master . Я попытался исправить рецепт сборки, но пара попыток оказались неудачными. Так у меня возникло желание попробовать собрать все «из коробки» в Buildroot.

Подготовка к сборке

Создаю рабочий каталог и перехожу в него
```
mkdir buildroot && cd buildroot
```
Загружаю и распаковываю стабильный релиз
```
wget https://buildroot.org/downloads/buildroot-2020.08.1.tar.bz2 tar -xf buildroot-2020.08.1.tar.bz2
```
Создаю каталог для сборки (мне так удобнее) и перехожу в него
```
mkdir rpi && cd rpi
```
Сборка системы для запуска Raspberry Pi

Инициализирую сборку применяя стандартный конфигурационный файл для Raspberry Pi
```
make -C ../buildroot-2020.08.1/ O=$PWD raspberrypi_defconfig
```
Для того чтобы внести изменения в стандартный конфиг запускаю графическую оболочку
```
make menuconfig
```
Вношу следующие изменения:
- Toolchain
  - C library — выбираю (glibc)
  - Root password — указываю свой пароль
  - Install timezone info — отмечаю для установки
  - Custom scripts to run before creating filesystem images — добавляю перед уазанным скриптом $(TOPDIR)/
  - Custom scripts to run after creating filesystem images — добавляю перед уазанным скриптом $(TOPDIR)/
  - Interpreter languages and scripting
  - nodejs
  - NPM for the target
  - python3
  - External python modules
    - python-pip
    - python-rpi-gpio
    - python-rpi-ws281x
    - exact size — указываю 250М
    Выхожу из конфигурационной оболочки с сохранением изменений.
```
make
```
    Запись образа на карту памяти
    
    Полученный после сборки образ системы записываю на карту памяти
```
sudo dd if=images/sdcard.img of=/dev/mmcblk0 status=progress
```
    Заключение
    
    В данной заметке я не пытаюсь сравнивать две системы сборки Yocto и Buildroot. Просто в конкретной ситуации собрать прошивку оказалось быстрее и проще с помощью Buildroot. В реальной жизни, под конкретную аппаратную платформу и набор программного обеспечения, скорее всего, придется писать свои правила и рецепты сборки, но это уже совсем другая история.
    Похожие публикации: