buildroot что это такое

Buildroot — часть 1. Общие сведения, сборка минимальной системы, настройка через меню

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

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

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.

Где взять и как начать

Сайт проекта — buildroot.org. Здесь можно скачать актуальную версию и прочитать руководство. Там же можно обратиться к сообществу, есть багтрекер, mail-lists и irc-канал.

Buildroot оперирует defconfig’aми для целевой платы сборки. Defconfig — это конфигурационный файл, хранящий в себе только опции, не имеющими значения по умолчанию. Именно он определяет, что и как будет собрано. При этом можно отдельно настроить конфиги busybox, linux-kernel, uClibc, загрузчиков u-boot и barebox, но все они будут привязаны к целевой плате.
После распаковки скачанного архива или клонировании из git получаем готовый к работе buildroot. Подробно о структуре каталогов можно прочитать в руководстве, расскажу о самых важных:

board — каталог с файлами, специфичными для каждой платы. Это могут быть скрипты формирования образов системы(iso, sdcart, cpio и прочие), каталог overlay, конфиг ядер и прочее
configs — собственно defconfig платы. Defconfig — это неполная конфигурация платы. В нем хранится только отличные от дефолтных настроек параметры
dl — каталог со скачанными исходными кодами/файлами для сборки
output/target — собранная файловая система полученной ОС. В дальнейшем из нее создаются образы для загрузки/установки
output/host — host-утилиты для сборки
output/build — собранные пакеты

Конфигурирование сборки осуществляется через KConfig. Эта же система используется для сборки ядра linux. Список самых часто используемых команд (выполнять в каталоге buildroot):

Важные замечания и полезные советы

Buildroot не пересобирает уже собранные пакеты! Поэтому может создаться ситуация, когда потребуется полная пересборка.

Можно пересобрать отдельный пакет командой make packagename-rebuild. Например, можно пересобрать ядро linux:

Следовательно, можно пересобрать root-fs и образы без пересборки пакетов:

Полезные переменные

В buildroot есть набор переменных для удобного конфигурирования

Визуализация

В buildroot есть возможность по визуализации.Можно построить схему зависимостей, график времени сборки, график размера пакетов в итоговой системе. Результаты в виде pdf файлов( на выбор есть svn,png) в каталоге output/graph.

Примеры команд визуализации:

Полезные скрипты

В каталоге buildroot есть подкаталог utils c полезными скриптами. Например, там есть скрипт, проверяющий корректность описания пакетов. Это может быть полезно при добавлении своих пакетов (я это сделаю позже). В файле utils/readme.txt есть описание этих скриптов.

Соберем cтоковый дистрибутив

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

Смотрим список конфигураций:

Переключаемся на конфиг qemu_x86_64_defconfig

И запускаем сборку

Сборка завершается успешно, смотрим на результаты:

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

Результат — запущенная в qemu система:

Создание конфигурации собственной платы

Добавление файлов платы

Смотрим список конфигураций:

В списке видим pc_x86_64_bios_defconfig. Мы создадим свою плату, скопировав её с конфигурации:

Сразу же создадим каталог платы для хранения своих скриптов, rootfs-overlay и прочих нужных файлов:

Переключаемся на этот defconfig:

Скопируем конфигурацию linux-kernel (пригодится в дальнейшем):

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

Откроется окно KConfig. Есть возможность конфигурировать с графическим интерфейсом (make nconfig, make xconfig, make gconfig):

Входим в первый раздел Target Options. Здесь можно выбрать целевую архитектуру, под которую будет вестись сборка.

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

Toolchain – здесь настраивается сам инструментарий сборки. О нем подробнее.

Toolchain type – тип используемого тулчейна. Это может быть встроенный в buildroot или внешний тулчейн (можно указать каталог с уже собранным или url для скачивания). Для разных архитектур есть дополнительные опции. Например, для arm можно просто выбрать версию внешнего тулчейна Linaro.

C library – выбор библиотеки С. От этого зависит работа всей системы. Обычно используется glibc, поддерживающая весь возможный функционал. Но она может оказаться слишком большой для встроенной системы, поэтому часто выбирают uClibc или musl. Мы выберем glibc (в дальнейшем это потребуется для использования systemd).

Kernel Headers и Custom Kernel Headers series – должно совпадать с версией ядра, которое будет в собираемой системе. Для kernel headers можно так же указать путь к тарболу или git-репозиторий.

GCC COMPILER VERSIONS – выбор версии компилятора, которая будет использована для сборки
Enable C++ support – выберем для сборки с поддержкой библиотек c++ в системе. В дальнейшем нам это пригодится.

Additional gcc options – можно задать дополнительные опции компилятора. Нам без надобности пока что.

System configuration позволяет задать будущие параметры созданной системы:

Большинство пунктов понятны из названия. Обратим внимание на следующие пункты:
Path to the users tables — таблица с создаваемыми пользователями (https://buildroot.org/downloads/manual/manual.html#makeuser-syntax).

Пример файла. Будет создан пользователь user с паролем admin, автоматически gid/uid, /bin/sh шеллом, группой по-умолчанию user, член группы root, комментарием Foo user

Root filesystem overlay directories — каталог, накладываемый поверх собранной target-fs. Добавляет новые файлы и заменяет имеющиеся.

Custom scripts to run before creating filesystem images — Скрипты, выполняемые непосредственно перед сворачиванием файловой системы в образы. Сам скрипт пока оставим пустым

Перейдём в раздел Kernel

Здесь задаются настройки ядра. Само ядро конфигурируется через make linux-menuconfig.
Задать версию ядра можно по-разному: выбрать из предложенных, ввести версию вручную, указать репозиторий или готовый tarball.

Kernel configuration — путь к конфигу ядра. Можно выбрать конфигурацию по-умолчанию для выбранной архитектуры или defocnfig из Linux. В исходниках Linux есть набор defconfig’ов для разных целевых систем. НАйти нужный можно, глянув напрямую в исходники здесь. Например, для платы beagle bone black можно выбрать конфиг.

Раздел Target packages позволяет выбрать, какие пакеты будут установлены в собираемую систему. Пока оставим без изменений. Позже мы добавим свои пакеты в этот список.
Filesystem images — список образов файловых систем, которые будут собраны. Добавим iso-образ

Bootloaders — выбор собираемых загрузчиков. Выберем isolinix

Конфигурирование Systemd

Systemd становится одним из столбов linux, наравне с kernel и glibc. Поэтому вынес его настройку в отдельный пункт.

Настраивается через make menuconfig, далее Target packages → System tools → systemd. Здесь можно указать, какие службы systemd будут установлены и запущены при старте системы.

Сохранение конфигурации системы

Сохраняем этот конфиг через KConfig.

После чего сохраним наш defconfig:

Конфигурирование ядра Linux

Конфигурирование ядра linux вызывается следующей командой:

Добавим поддержку видеокарты Virtualbox

Добавим Virtualbox Guest integration support

Сохраняем и выходим. ВАЖНО: конфигурация сохранится в output/build/linux-$version/config, но не в board/my_x86_board/linux.config

Поэтому нужно вручную скопировать конфиг в место хранения:

Этой командой я копирую ПОЛНЫЙ конфиг ядра, что нужно не всегда. Более правильный путь — сохранять defconfig ядра:

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

По завершении сборки запускаем VirtualBox(проверялось на версии 5.2 и 6.0) с загрузкой с cd-диска.Параметры системы:

Источник

Русские Блоги

Введение в использование buildroot

buildrootЭто структура для создания встроенной системы Linux на платформе Linux. Весь Buildroot состоит из скриптов Makefile и файлов конфигурации Kconfig. Вы можете скомпилировать ядро ​​Linux с помощью конфигурации buildroot и модификации menuconfig, чтобы скомпилировать полное системное программное обеспечение Linux (включая загрузку, ядро, rootfs и различные библиотеки и приложения в rootfs), которое можно напрямую записать на машину для запуска.

Используйте buildroot для создания виртуальной платформы разработки на основе qemu, см. «Создайте виртуальную среду разработки ARM-Linux с помощью buildroot + qemu》。

1. Начало работы с buildroot

Во-первых, как использовать buildroot: 1. Выберите defconfig; 2. Настройте buildroot по мере необходимости; 3. Скомпилируйте buildroot; 4. Запустите систему, созданную buildroot, на qemu или целевой плате.

1.1 Введение в каталог buildroot

1.2 конфигурация buildroot

Используйте make xxx_defconfig, чтобы выбрать defconfig, этот файл находится в каталоге config.

Затем настройте его через make menuconfig.

1.3 Использование команды make

С помощью make help вы можете увидеть детали использования make в buildroot, включая конфигурацию пакета, uclibc, busybox, linux и генерацию документов.

2. Фреймворк buildroot

Buildroot предоставляет структуру функций и структуру переменных команд (подробности будут представлены в следующей статье). Сценарий автоматической сборки в формате Makefile app_pkg.mk, написанный его структурой, будет расширен основным сценарием package / pkg-generic. mk Заполните его в Makefile в главном каталоге buildroot.

Наконец, make all выполнит Makefile в домашнем каталоге Buildroot, чтобы сгенерировать нужный образ. Вызывая файлы pkg-download.mk и pkg-utils.mk в одном каталоге в package / pkg-generic.mk, автоматически реализовывалась серия механизированных процессов, таких как загрузка, распаковка, загрузка и компиляция зависимых пакетов для ты.

Вам нужно только написать нижний колонтитул Makefile app_pkg.mk в соответствии с форматом, заполнить адрес загрузки, связать имя зависимой библиотеки и другие конкретные детали конструкции. В целом, Buildroot обеспечивает основу для процесса сборки.Разработчики пишут сценарии в соответствии с форматом, предоставляют необходимые сведения о сборке, настраивают всю систему и, наконец, автоматически создают вашу систему.

Конфигурация buildroot подключается последовательно через Config.in, а начальная точка находится в корневом каталоге Config.in.

3. Настройте ядро ​​Linux.

Конфигурация ядра Linux состоит из двух частей: войдите в ядро ​​через make menuconfig, чтобы выбрать ядро, и настройте внутреннее ядро ​​через make linux-menuconfig.

3.1 Выберите версию ядра Linux

Как показано ниже: «Версия ядра» выбирает версию ядра, «Defconfig name» выбирает файл конфигурации ядра, «Двоичный формат ядра» выбирает формат ядра, «Имена исходных файлов дерева устройств» выбирает файл DT,

В «Linux Kernel Tools» выберите инструменты, которые поставляются с ядром, например perf.

Вы можете выбрать «Пользовательский репозиторий Git», чтобы указать собственный репозиторий Git, и указать имя ветки в «Версия пользовательского репозитория».

Выберите «Использование файла defconfig в дереве», введите имя defconfig в поле «Имя Defconfig» и обратите внимание, что конец _defconfig не требуется.

3.1.1 Kernel binary format

Вы можете выбрать vmlinux или uImage.

Исходный файл ядра elf, скомпилированный vmlinux, без сжатия.

Разница между выбором vmlinux и uImage заключается в следующем:

Если это vmlinux, то в конце это vmlinux. К

3.2 Настроить ядро

Внутренние детали ядра можно настроить с помощью make linux-menuconfig.

Пусть в ядре Linux есть таблица символов:

# CONFIG_COMPILE_TEST is not set

4. Настройте приложение файловой системы.

Конфигурация содержимого файловой системы целевой платы в основном выполняется путем ввода целевых пакетов через make menuconfig.

Настройте формат, используемый файловой системой, и укажите, следует ли использовать RAM fs в образах файловой системы.

4.1 ramfs

Если вы выберете «начальная файловая система RAM, связанная с ядром Linux», файловая система будет интегрирована в vmlinux.

Если этот флажок не установлен, в vmlinux будет включено только ядро, а файловая система будет предоставлена ​​в других формах, таких как rootfs.cpio.

Если BR2_TARGET_ROOTFS_INITRAMFS определен, ядро ​​необходимо перекомпилировать в конце компиляции, а rootfs.cpio добавляется в vmlinux.

В fs / initramfs / initramfs.mk:

Включив initramfs, перекомпилируйте rootfs.cpio в ядро ​​vmlinxu.

Затем скопируйте файлы, такие как uImage, в BINARIES_DIR.

5. Добавьте собственное приложение.

Чтобы добавить собственное локальное приложение, сначала добавьте Config.in, указывающий на новый каталог APP в package / Config.in;

Затем добавьте в пакет каталог helloworld и добавьте в него Config.in и helloworld.mk;

Наконец, добавьте соответствующий каталог helloworld.

5.1 Добавление записи package / Config.in

Система может найти соответствующий APP Config.in при создании menuconfig.

Если в make menuconfig выбран helloworld, он будет открыт в make savedefconfig. BR2_PACKAGE_HELLOWORLD=y 。

5.2 Настройте файлы Config.in и mk, соответствующие приложению

helloworld / Config.in файл helloworld можно выбрать через make menuconfig.

Только когда BR2_PACKAGE_HELLOWORLD = y, helloworld.mk будет вызываться для компиляции.

Также необходимо начало следующего HELLOWORLD.

Если исходный код находится на git, требуются следующие настройки:

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

_INSTALL_TARGET_CMDS Переменная в конце автоматически устанавливается и выполняется после завершения компиляции.Как правило, buildroot копирует скомпилированный bin или lib в указанный каталог.

5.3 Написание исходного кода приложения

Просто напишите файл helloworld.c:

Затем напишите файл Makefile:

5.4 Выберите приложение через make menuconfig

Затем сделайте savedefconfig, конфигурация helloworld будет сохранена в qemu_arm_vexpress_defconfig.

5.5 Компиляция приложения

Приложение можно скомпилировать вместе со всей платформой или make helloworld можно скомпилировать отдельно.

Эти два файла будут скопированы в папку output / build / helloworld-1.0.0 после выбора этого приложения.

Затем скопируйте сгенерированный файл bin в output / target / bin / helloworld, и этот файл будет упакован в файловую систему.

Если вам нужно очистить соответствующие исходные файлы, используйте make helloworld-dirclean.

5.6 Запустить приложение

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

Работа по добавлению APP завершена.

6. Конфигурация uboot

Использование uboot в качестве загрузчика требует некоторой настройки.

После выбора U-boot в качестве загрузчика появится ряд связанных конфигураций.

«U-Boot board name» конфигурирует имя defconfig для конфигураций.

«Версия U-Boot» выберите Пользовательский репозиторий Git, затем выберите свой собственный адрес git в «URL-адресе пользовательского репозитория» и выберите ветку git в «Пользовательской версии репозитория».

Выберите формат изображения, который вы хотите вывести в «двоичном формате U-Boot», например u-boot.img или u-image.bin.

Вы также можете выбрать «Бинарный образ Intall U-Boot SPL», чтобы выбрать соответствующий SPL.

7. Finalizing target

В конце компиляции buildroot необходимо выполнить некоторые проверки или другие операции с результатами компиляции.

Buildroot резервирует два интерфейса:

7.1 FS Overlay

Содержимое в заданном каталоге перезапишет output / target.

Соответствующая обработка в Makefile выглядит следующим образом:

7.2 post build

В дополнение к наложению fs buildroot также предоставляет сценарий для более сложной обработки.

Вы можете удалять файлы, переименовывать их и даже удалять из файлов отладочную информацию.

Пример post_build.sh, удаление и разделение ряда файлов:

7.2 post image

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

Ниже приведен пример упаковки файла изображений.

8. Производительность компиляции Buildroot.

Buildroot также предоставляет некоторые команды для анализа трудоемкости, зависимости, размера файловой системы и т. Д. Во время процесса компиляции buildroot.

Найдите связанные команды с помощью make help:

8.1 Компиляция требует много времени

Выполнение make graph-build сгенерирует следующие файлы:

Среди них наиболее значимым является файл build.hist-duration.pdf, который упорядочен по убыванию трудоемкости.

По этому рисунку вы можете понять, на что тратится все время процесса компиляции, а целенаправленный анализ и оптимизация помогут повысить эффективность компиляции.

8.2 Зависимости компиляции

Сгенерируйте graph-depends.pdf, вы можете увидеть зависимости между различными скомпилированными модулями.

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

8.3 Анализ размера результатов компиляции

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

Кроме того, файлы file-size-stats.csv и package-size-stats.csv более полезны для справки.

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

Источник

Собираем и устанавливаем свою Linux-систему на микроконтроллер STM32MP1

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

В этой статье мы автоматизируем процесс сборки и установки Linux-системы на микроконтроллер STM32MP157-DK2. ОС будет обладать минимальной функциональностью, но зато мы соберём из исходников собственную систему. А поможет нам в этом Buildroot — система сборки Linux-дистрибутивов.

Что такое Buildroot?

Некоторые из этих дистрибутивов поддерживают архитектуру ARMv7. Основное преимущество этого решения в том, что оно простое: эти бинарные дистрибутивы знакомы большинству пользователей Linux-систем, они имеют красивую и простую в использовании систему управления пакетами, все пакеты предварительно скомпилированы, поэтому нашей цели можно достичь очень быстро. Однако собранные таким образом системы обычно сложно кастомизировать (компоненты уже созданы, поэтому вы не можете легко изменить их конфигурацию в соответствии с вашими потребностями) и сложно оптимизировать (с точки зрения объёма занимаемой памяти или времени загрузки).

Они позволяют собрать Linux-систему непосредственно из исходного кода. А это означает, что систему будет легко оптимизировать и кастомизировать под свои нужды. Конечно же, этот способ намного сложнее, а на компиляцию кода придётся потратить немало процессорного времени.

Мы выбираем второй способ. В этой статье используем Buildroot, потому что с этой системой сборки достаточно просто разобраться и она подходит для embedded-платформ.

Buildroot — это набор make-файлов и скриптов, которые автоматизируют загрузку исходного кода различных компонентов, их извлечение, настройку, сборку и установку. В конечном итоге он генерирует образ системы, готовый к прошивке и обычно содержащий загрузчик, файл-образ ядра Linux и корневую файловую систему.

Важно отметить, что Buildroot не поставляется с исходными кодами Linux, с U-Boot или с другими компонентами. Он всего лишь содержит набор скриптов и инструкций, описывающих, какой исходный код загружать и какие настройки использовать при сборке.

Как собрать Linux-систему с Buildroot?

Начнём с установки самой системы Buildroot, а потом перейдём к её настройке:

Обычно настройка Buildroot делается с помощью команды make menuconfig, которая позволяет указать необходимые опции для вашей системы. Но мы вместо этого используем свою конфигурацию, которую мы создали заранее — специально для STM32MP157-DK2. Она находится в моём репозитории.

Мы могли бы сразу приступить к сборке, так как эта конфигурация работает нормально. Но здесь я хочу показать, как можно изменить конфигурацию и ускорить сборку. Мы изменим всего один параметр. Для этого запустим утилиту menuconfig (она встроена в Buildroot). Если кто-то из вас уже настраивал ядро ​​Linux, этот инструмент должен быть вам интуитивно понятен, поскольку это просто утилита для настройки.

Если команда не сможет работать из-за отсутствия библиотеки ncurses, установите пакет libncurses-dev или ncurses-devel (точное название пакета будет зависеть от версии Linux ОС, на которой вы запускаете Buildroot). Библиотека ncurses предназначена для управления вводом-выводом на терминал.

Выходим из menuconfig и сохраняем изменения. Теперь пришло время поработать с командой make. Я люблю всё логировать, поэтому она будет выглядеть вот так:

На этом этапе система сборки Buildroot проверит наличие всех необходимых пакетов. Если чего-то не обнаружит, то выполнение команды прервётся. Если это произойдёт, на сайте Buildroot посмотрите раздел System requirements > Mandatory packages и установите все необходимые зависимости. После этого можно запускать команду заново.

На моей машине команда make работала 10 минут. После сборки появится набор каталогов и файлов (самое интересное лежит в output/images):

Прошивка и тестирование системы

Запишем sdcard.img на карту microSD:

Не забудьте проверить, что в вашей системе карта microSD определяется как /dev/mmcblk0 (и на всякий случай предупреждаю: после того, вы запишете туда образ, вся информация на этой карточке будет затёрта)!

Подключите карту к микроконтроллеру.

Соедините USB-кабелем ваш компьютер и micro-USB разъём с надписью ST-LINK CN11 на плате. Ваша машина должна распознать устройство с именем /dev/ttyACM0, через которое вы сможете получить доступ к последовательному порту платы. Установите на свой компьютер и запустите программу для общения с последовательным портом. Лично мне очень нравится picocom:

Он подходит для embedded-систем, так как занимает минимальный объём памяти (менее 20 КБ) и имеет подробную документацию.

Наконец, включите плату, воткнув кабель USB-C в разъём PWR_IN CN6. Затем на последовательный порт начнут приходить сообщения. Нам важно, что в конце появится приглашение залогиниться в системе Buildroot. Можно войти в систему с пользователем root, пароль вводить не нужно.

Этапы загрузки системы и вход

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

Это сообщение от загрузчика первой стадии: код, содержащимся в файле u-boot-spl.stm32 скомпилирован как часть загрузчика U-Boot. Его непосредственно загружает STM32MP157. Загрузчик первой стадии должен быть достаточно маленьким, чтобы поместиться во внутреннюю память STM32MP157.

Это сообщение от загрузчика второй стадии, который был выгружен из внутренней памяти устройства во внешнюю память загрузчиком первой стадии. Загрузчик второй стадии — это файл u-boot.img, который также является частью загрузчика U-Boot.

Эти сообщения печатает загрузчик второй стадии: мы видим, что он загрузил образ ядра Linux (файл zImage) и блоб дерева устройств (файл stm32mp157c-dk2.dtb), описывающий нашу аппаратную платформу. Хорошо, U-Boot загрузил оба файла в память: теперь он готов к запуску ядра Linux.

И сразу появляются первые сообщения ядра Linux, показывающие версию Linux и дату/время сборки. Далее идут другие, не слишком интересные сообщения… Нам нужно дождаться вот этого:

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

И вот, наконец, появляется то самое сообщение от Buildroot с просьбой залогиниться.

После входа в систему вы получите доступ к командной оболочке Linux. Введя команду ps, можно посмотреть список процессов, команда ls/ покажет содержимое корневой файловой системы и так далее.

Также можно немного поиграться с платой — например, включить и выключить один из светодиодов:

Как сделать это «с нуля»?

Углубляемся в основы конфигурирования Buildroot

В начале статьи мы говорили про настройку и оптимизацию конфигурации Buildroot. По идее, для этого нужно сначала изучить основы конфигурирования в этой системе. Поэтому вернёмся в прошлое к команде make menuconfig.

В меню Target options выбрана архитектура ARM Little Endian, а в Target Architecture Variant указан Cortex-A7. На этом процессоре как раз построен наш микроконтроллер.

В меню Build options используем все значения по умолчанию.

В меню System configuration мы произвели следующие изменения:

В меню Filesystem images активировали ext2/3/4root filesystem и выбрали ext4. Эта файловая система отлично подходит для SD-карт.

Теперь в меню Bootloaders активируем U-Boot, для которого выполняем следующий набор действий:

Углубляемся в процесс сборки Buildroot

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

Какие конкретно указания даны в этом скрипте:

Файл extlinux.conf находится внутри оверлей-каталога нашей файловой системы (board/stmicroelectronics/stm32mp157-dk/overlay/boot/extlinux/extlinux.conf), в корневой файловой системе он будет определяться как /boot/extlinux/extlinux.conf и U-Boot легко найдёт его.

Вот что внутри этого файла:

Таким образом мы говорим U-Boot, чтобы он загружал образ ядра из /boot/zImage, дерево устройств — из /boot/stm32mp157c-dk2.dtb. А строка root=/dev/mmcblk0p4 rootwait должна быть передана ядру Linux во время загрузки. Именно в этом выражении (root=/dev/mmcblk0p4) хранится информация о том, где находится корневая файловая система.

Итак, сформулируем этапы загрузки собранной Linux-системы на нашей аппаратной платформе — с учётом новых подробностей:

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Источник