Mounting rootfs in linux

Бездисковая загрузка по сети и жизнь после нее

История

Теория

По сути, для того, чтобы система загрузилась ей необходимо 3 компонента — ядро, начальное окружение initramfs и корневой каталог, в котором система будет работать.

Практика

Все действия проводятся на машине с ubuntu precise.

Для начала настроим PXE. Мануалов на эту тему уйма, поэтому я расскажу только самую суть.
Ставим ваш любимый dhcp сервер, например isc-dhcp-server, который будет раздавать машинкам ip адреса и указывать путь к файлу pxelinux.0, который будет отдавать tftp сервер (tftp-hpa или же atftp).

Пример конфига dhcp сервера. В примере pxe-сервер находится по адресу 10.0.0.1.

Запускаем tftp сервер (в ubuntu он имеет init-скрипт, но вполне вероятно, что вам придется запускать его и через inetd/xinetd).
Проверяем работоспособность. Кладем файл в каталог /var/lib/tftpboot и пробуем стянуть его tftp клиентом.

В принципе неважно, где вы возьмете файл pxelinux.0, так как он является просто начальным загрузчиком, в который мы передаем то, что надо грузить дальше.
Вы можете сделать красивую менюшку в загрузчике, но сейчас нам это не нужно, поэтому мой pxelinux.cfg/default выглядит так

rootfs

Образ rootfs собираем через debootstrap, чрутимся в него и ставим необходимые программы. Настраиваем сеть, hostname, фаервол и прочее, чем больше сделаем настроек, тем больше будет образ. Главное не забудьте сменить пароль на рута.

С нашим минимальным набором система получилась весом 200Мб.

Initramfs

В этом примере мы будем забирать образ корневой фс с веб-сервера, расположенного на нашем сервере сетевой загрузки, то есть на 10.0.0.1. Решение было таким просто потому, что в нашем initramfs была утилита wget. Чтобы не тянуть большой объем данных по сети, мы решили сжать образ. Это можно было бы сделать и обычным tar, но можно попробовать squashfs, тем более, что обычно в initramfs tar не встроен, с другой стороны, ничего не мешает его туда добавить.

Squashfs
Squashfs — это сжимающая файловая система, которая включена в ядро с версии 2.6.29. С ее помощью можно заархивировать каталог, примонтировать на loop устройство и читать с него, для записи же необходимо провести процедуру добавления файлов в архив. Так как при обращении к squashfs, вы читаете из архива, то это дает дополнительную нагрузку на cpu.

Для более эфферктивного сжатия вы можете использовать опцию -comp, чтобы установить тип сжатия, по умолчанию используется gzip.

Далее надо научить init из initramfs забирать образ корня и помещать его в оперативную память.

init в initramfs — это скрипт на sh, который производит разбор опций из cmdline, монтирует фс, делает switch_root и запускает гланый init-процесс системы.
Воспользуемся этим и допишем свои опции для cmdline. Напишем скрипт ram, который будет вызываться при значении опции boot=ram.

Через параметр rooturl можно указывать откуда качать образ корневой фс. Для работы со squashfs необходимо подгрузить ее модуль в ядро. Указываем в /etc/initramfs-tools/initramfs.conf BOOT=ram и пересобираем initramfs

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

В это примере, мы использовали squashfs просто для сжатия образа, но почему бы нам не попробовать примонтировать корневой раздел в squashfs и не посмотреть, что получится? Меняем наш скрипт, в функции do_rammount() оставляем только монтирование squashfs.

Пересобираем initramfs, запускаем, смотрим. Система загружается в режиме ro, но зато занимает в памяти всего около 180Мб.
В каких-то случаях монтирование в режиме ro это хорошо, но нас это не устраивает, но и просто так тратить оперативную память нам тоже не хочется. Выход же был найден при помощи Aufs.

Aufs
Aufs позволяет делать каскадно-объединённое монтирование файловых систем — одну в режиме только на чтение, а вторую в rw. Работает она в режиме copy-on-write, то есть все изменения записываются на rw систему и после этого чтение производится с нее же.
Опять переписываем наш скрипт.
В фукнцию mountroot() добавляем

А фукнцию do_rammount() приводим к следующему виду:

Пересобираем initramfs, запускаем, смотрим. Система занимает в памяти 181Мб, при этом мы можем менять ее, писать, читать. Все изменения хранятся отдельно в /mnt/rw, а сама система хранится в /mnt/ro.

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

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

Источник

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

Файловая подсистема — (rootfs) процесс монтирования корневой файловой системы 03

NO1.Загрузка ядра Linux + подробное объяснение процесса загрузки системы Android
https://blog.csdn.net/ahaochina/article/details/72533442

NO2. Конфигурация ядра, компиляция и анализ кода (1)
https://blog.csdn.net/kakasingle/article/details/12851963?utm_source=jiancool

Механизм initrd механизма initrd в NO3.linux и механизм initramfs
http://blog.chinaunix.net/uid-20279362-id-4924898.html
http://cukdd.blog.chinaunix.net/uid-29431466-id-4834509.html

NO4.android запускает процесс с файловой системой initrd
https://blog.csdn.net/wangcong02345/article/details/51659201

Поток обработки ядра NO5.initrd (ramdisk)
https://blog.csdn.net/yiyeguzhou100/article/details/78318100

Процесс монтирования файловой системы Linux и корневой файловой системы (rootfs)

Создание файловой системы .

Анализ процесса монтажа Rootfs

Корневой каталог по умолчанию смонтирован, а вот конкретная файловая система смонтирована.
linux/init

Разбираем разные типы креплений:

image-initrd & cpio-initrd описание процесса

Создание образа initrd

rest_init

Отвечает за загрузку файла initrd, расширение дерева VFS и создание базовой топологии каталогов файловой системы;
initrd — это временная файловая система, загружаемая в память при загрузке и содержащая основные исполняемые программы и драйверы. На начальном этапе инициализации Linux он предоставляет базовую операционную среду. Когда файловая система диска успешно загружена, система переключится на файловую систему диска и удалит initrd.

kernel_init

kernel_init_freeable

Завершите настройку корневого каталога здесь

do_basic_setup();

// Инициализируем драйвер устройства, загружаем статический модуль ядра; освобождаем Initramfs в rootfs
Вызов функции инициализации всех модулей, включая функцию инициализации populate_rootfs initramfs,

Здесь выполняется populate_rootfs, который определяет тип initrd и отправляет его в каталог.

do_initcalls();

• do_initcalls () извлечет начальные адреса этих функций инициализации в модуле драйвера, скомпилированном в ядро, в виде указателей на функции из раздела, начинающегося с __initcall_start и заканчивающегося __initcall_end, чтобы в свою очередь завершить соответствующую инициализацию. Эти функции инициализации получают инструкции от __define_initcall (level, fn), чтобы указать компилятору поместить значения начальных адресов этих функций инициализации в этом разделе в определенном порядке при компиляции

Введение в initcall

Linux определяет специальный сегмент initcall в сегменте кода, в котором хранятся указатели на функции; фаза инициализации linux вызывает do_initcalls () для выполнения функций этого сегмента по очереди. Для получения подробной информации об этом разделе, пожалуйста, обратитесь к скрипту ссылки vmlinux.lds.S.
https://www.cnblogs.com/downey-blog/p/10486653.html
https://blog.csdn.net/mcsbary/article/details/90644101

1. Проанализируйте определение макроса __define_initcall (level, fn).

2. Выполнение do_initcalls ()

do_initcall_level

do_initcalls

3. Вызов vmlinux.lds.h

4. INIT_CALLS vmlinux.lds.S

• Пользователи могут легко регистрировать указатели функций в коде Linux, используя макросы initcall с разными приоритетами; сохранять эти указатели функций в соответствующем разделе initcall; наконец, do_initcalls () выполняет функции в разделе в порядке, соответствующем приоритету.

5. Примеры механизма initcall

populate_rootfs

rootfs_initcall(populate_rootfs)
populate_rootfs в основном завершает обнаружение Initrd и проверяет, является ли это CPIO Initrd или Initramfs или Image-Initrd

• Один из них — это initramfs, интегрированный с ядром. При компиляции ядра сохраните его в области от __initramfs_start до __initramfs_end с помощью сценария связывания и напрямую вызовите unpack_to_rootfs, чтобы передать его в корневой каталог. Если его нет в этой форме, то есть значения __initramfs_start и __initramfs_end равны, а длина равна нулю. Не буду ничего делать

А. Проверьте, существует ли файловая система формата initram, и если она существует, она будет перенесена непосредственно в исходный каталог rootfs «/».
б. Проверьте, является ли это cpio-initrd или image-initrd, и рассмотрите их отдельно.
c. Если это cpio-init, отпустите его непосредственно в каталог «/», в противном случае сохраните image-initrd в initrd.image.
г. Завершите шаг c и освободите место в памяти, занимаемое Initrd.

unpack_to_rootfs(char *buf, unsigned long len)

Если initramfs не существует, значения __initramfs_start и __initramfs_end равны, то есть параметр len = 0, unpack_to_rootfs ничего не сделает.

• Он обращается к файлу XXX.cpio.gz через указатель __initramfs_start и указатель __initramfs_end,
  вызвать функцию unpack_to_rootfs, чтобы извлечь исходный файл в rootfs

root_dev_setup

root используется для указания устройства хранения, на котором расположена корневая файловая система, и сохранения имени устройства в статической переменной saved_root_name
__setup («root =», root_dev_setup); механизм

static char __initdata saved_root_name[64];
static int __init root_dev_setup(char *line)
<
strlcpy(saved_root_name, line, sizeof(saved_root_name));
return 1;
>
__setup(“root=”, root_dev_setup);

fs_names_setup

rootfstype указывает тип файловой системы и сохраняет тип файловой системы в статической переменной root_fs_names.
static char * __initdata root_fs_names;
static int __init fs_names_setup(char *str)
<
root_fs_names = str;
return 1;
>
__setup(“rootfstype=”, fs_names_setup);

// Поскольку я ранее переключался в корневой каталог новой файловой системы, шаги в теге out в основном должны следовать за новым корневым каталогом файловой системы
Замените rootfs, чтобы сделать его корневым каталогом Linux vfs.
// Процесс без использования initrd, устройство файловой системы смонтировано и заменено rootfs, чтобы стать корнем vfs,
Остальные задачи оставлены программе / sbin / init в корневой файловой системе.

prepare_namespace();

• Если тип cpio initrd не используется, ядро ​​выполнит prepare_namespace ()

Путь к функции: kernel / kernel4.14 / init / do_mounts.c

• ** Смонтируйте фактическую корневую файловую систему **

a. Для image-initrd существует два устройства монтирования, одно — root = / dev / mtdblockxx, а другое — root = / dev / ram device

Во-первых, пользователь может использовать root = для указания корневой файловой системы. Его значение хранится в файле saved_root_name. Если пользователь указывает строку, начинающуюся с mtd в качестве корневой файловой системы. Он будет монтироваться напрямую. Этот файл является файлом устройства mtdblock, в противном случае файл узла устройства будет преобразован в ROOT_DEV, который является номером узла устройства. Затем перейдите к initrd_load (), чтобы выполнить предварительную обработку initrd, а затем смонтируйте определенную корневую файловую систему. В конце функции будет вызвана sys_mount (), чтобы переместить текущую точку монтирования файловой системы в каталог «/», а затем переключить корневой каталог в текущий каталог. Точка монтирования корневой файловой системы становится тем, что мы видим в пространстве пользователя. «/».

Знания для анализа

_setup извлекать save_root_name

initrd_load

а. Вызовите create_dev, чтобы создать узел устройства / dev / ram
б. Вызовите rd_load_image, чтобы освободить initrd.image для / dev / ram0, и определите, указал ли пользователь окончательное имя устройства корневого файла.
c. Если это не Root_ram0, который не указан, он будет передан в функцию handle_initrd для обработки.

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

rd_load_image

А. Откройте (узел устройства / dev / ram0, созданный initrd_load в rootfs) и (образ ramdisk («initrd.image»)) соответственно.
b. nblocks = identify_ramdisk_image(in_fd, rd_image_start, &decompressor);?
c. Вызовите crd_load, чтобы загрузить содержимое initrd.image в узел устройства / dev / ram0.

handle_initrd()

Если ROOT_DEV! = Root_RAM0, вызовите handle_init, чтобы запустить пользовательский режим через linuxrc. (То есть initrd = 0Xxxx, но root = / dev / metdblock2 вызван противоречием)

mount_root()

mount_block_root

do_mount_root () для монтирования корневой файловой системы

do_mount_root

В основном монтировать корневую файловую систему
Подключите устройство, содержащее корневую файловую систему, в корневой каталог / rootfs.

Источник

Zynq 7000. Собираем Linux и RootFS при помощи Buildroot

Продолжаем изучение SoC Zynq 7000 и разбираемся с тем, как организовать подготовку, сборку Linux для нашей отладочной платы QMTech. В прошлой статье я рассмотрел процедуру быстрой сборки (без кастомизации) основных компонентов встраиваемой системы Linux и шаг за шагом прошли путь до приглашения к вводу в работающей ОС. Согласитесь, что если вы новичок — то работа была выполнена колоссальная! К счастью, всю эту работу можно автоматизировать! И в этой статье я хотел бы уделить внимание этому вопросу и рассказать как это сделать с помощью Buildroot. Эту статью можно считать логическим продолжением общего повествования о начале работы с Linux на Zynq.

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

Всем интересующимся — добро пожаловать под кат!

Важно! Перед началом повествования, хотелось бы заранее оговориться, что основная цель, которую я преследую при написании этой статьи — рассказать о своем опыте, с чего можно начать, при изучении отладочных плат на базе Zynq. Я не являюсь профессиональным разработчиком под ПЛИС и SoC Zynq, не являюсь системным программистом под Linux и могу допускать какие-либо ошибки в использовании терминологии, использовать не самые оптимальные пути решения задач, etc. Но отмечу, что любая конструктивная и аргументированная критика только приветствуется. Что ж, поехали…

Рекомендуемые источники для более глубокого изучения

Перед началом повествования хотелось бы отдельно отметить источники информации, которые помогли мне при подготовке этого материала:

Книга Криса Симмондса Встраиваемые системы на основе Linux.

Стрим ребят из команды FPGA-Systems.ru по сборке Linux: https://www.youtube.com/watch?v=339hpNuRZDo

Что такое Buildroot и зачем он нужен?

В предыдущей статье мы полностью в ручном режиме собрали всё необходимое для работы операционной системы. Учитывая объем проделанной работы и количество затраченного времени — ручная сборка не выглядит чем-то эффективным и быстрым.

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

В результате реализации этой идеи на свет появился Buildroot! Это система автоматизированной сборки на основе GNU Make и Kconfig.

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

Самое удобное и полезное в этой ситуации то, что всё необходимое собирается из исходного кода. В этом случае у нас есть уверенность, что мы можем пересобрать код в любое время и без лишнего гемороя с внешними зависимостями. Также мы можем быть уверенными в том, что используется самые последние версии программ со всеми патчами и исправлениями.

Общая последовательность шагов которые выполняются при работе с системами сборки мне видится таковой:

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

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

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

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

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

В дополнение к этому, есть еще ряд плюшек которые предоставляются системой сборки:

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

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

Очень удобно использовать при создании автономного SDK и распространения его среди других разработчиков.

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

Наличие удобного интерфейса для взаимодействия с пользователем.

Наверняка, пытливый пользователь может спросить “А ведь есть же PetaLinux который базируется на Yocto. Зачем нужен buildroot?”. И я немного разобравшись в вопросе смело могу заявить, что это абсолютно две разные системы которые подходят к решению задачи сборки довольно таки разных по сложности и преследуют совершенно разные цели.

Основная цель Buildroot — это сборка именно образа корневой файловой системы, хоть она и умеет собирать загрузчик, DTS, и образ ядра.

А что касается Yocto — это полноценная система подготовки дистрибутива Linux. Это более общая система в том, смысле что позволяет описать целевое устройство и способна собирать полновесные дистрибутивы для весьма сложных устройств. Каждый компонент в Yocto генерируется в виде пакетов RPM, DPKK или IPK и после этого все пакеты собираются в цельный образ файловой системы.

Возможно когда-нибудь в будущем я попробую разобраться и с Yocto, но точно не в этой статье. Едем дальше…

Переходим от разговоров к делу!

Сразу отмечу основные моменты касающиеся с источниками полезной информации. Сайт проекта buildroot находится по адресу http://buildroot.org. На сайте находится очень подробная документация https://buildroot.org/downloads/manual/manual.html. По большинству вопросов и для углубленного изучения — можно обращаться к ней.

Что касается используемых версий. Разработчики Buildroot выпускают стабильные версии четыре раза в год: в феврале, мае, августе и ноябре. В этой связи в Git-репозитории им соответствуют метки вида . . Обычно при начале работы с buildroot имеет смысл взять последнюю стабильную версию, но они редко обновляются после выпуска. Рекомендую все время использовать последнюю стабильные версии по мере их выхода.

Перейдем к установке

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

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

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

Основная сущность, которой оперирует buildroot — это файлы defconfig, которые относятся к той или иной целевой плате. В этом файле хранятся все настройки которые отличаются от тех, что заданы по умолчанию.

Давайте посмотрим, что находится рабочем каталоге buildroot:

board — каталог с файлами, которые относятся к конкретным платам. Тут могут быть скрипты, каталог rootfs_overlay, конфигурацию ядер;

configs — в этой папке находятся те самые файлы defconfig;

dl — каталог со скачанными файлами исходного кода;

Всё, что будет скомпилировано будет положено в папку output, либо в папку указанную в параметрах компиляции с ключом O= , в которой появятся два основных каталога:

host — папка с утилитами для сборки на хосте;

build — папка с собранными пакетами;

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

Создадим файл, запуская который у нас будет открываться меню конфигурации:

Запишем в него следующее:

После этого можно запустить этот файл и если все необходимые зависимости установлены — будет открыто меню конфигурации buildroot:

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

Первым пунктом заходим в меню Target options и выбираем архитектуру ARM (little endian) и выбираем вариант архитектуры Cortex-A9, что собственно соответствует тому, что мы имеем на плате. Устанавливаем также опции связанные с Hard Floating Point. После проведения правильной конфигурации окно примет следующий вид:

Переходим обратно в главное меню и заходим в меню Build options. Для ускорения процедуры сборки можно поставить опцию Number of jobs to run simultaneously в соответствии с количеством ядер CPU. Остальные опции оставляем по умолчанию.

Переходим к настройке Toolchain.

В нашем случае мы воспользуемся toolchain встроенным в Buildroot. Оставляем без изменений пункт Toolchain type.

Меняем используемую C library на glibc.

В пункте Kernel Headers выбираем Custom Git Repository и в меню URL of custom repository указываем путь, к cклонированному в прошлом занятии, ядру Linux. Либо клонируем репозиторий в папку /home:

После в поле Custom repository version необходимо указать хэш текущего указателя на master-ветку в репозитории:

Смотрим версию ядра, склонированную в репозитории linux-xlnx:

Будет выведено окно настройки конфигурации ядра для последующего компилирования и в заголовке будет указана версия:

Выбираем версию ядра 5.10.х в опции Custom kernel headers series.

Устанавливаем опцию Install glibc utilities.

Выбираем версию компилятора gcc. В моем случае это gcc 9.x. Установим его в поле GCC compiler Version.

Установим поддержку C++ в поле Enable C++ support.

Далее выбираем опции Enable compiler link-time-optimization support.

Ставим поддержку мультипроцессорного режима работы программ с использованием OpenMP в поле Enable compiler OpenMP support.

Переходим в меню System configuration и тут по желанию можно написать имя целевой системы и приветственное лого. Я указал в поле System hostname — Z7020, а в System banner — Welcome to QMtech Zynq Linux!. Остальные пункты меню оставляю по умолчанию.

Переходим в меню Kernel. Если вы хотите, чтобы вместе с rootfs было так же собрано ядро Linux — включите опцию Linux kernel.

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

Таким же образом указываем Custom Git repository с указанием пути до репозитория и хэша.

Указываем что корневой файл конфигурации будем использовать из in-tree источника: Kernel configuration (Using an in-tree defconfig file).

Файл defconfig указываем тот, что использовали по умолчанию при компиляции ядра в прошлом уроке: записываем в поле Defconfig name xiinx_zynq без постфикса “_defconfig”.

Выбираем опцию Kernel binary format и ставим uImage и тип компрессии gzip

Устанавливаем адрес загрузки Load address в 0x8000.

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

Переходим в меню Target options. В этом меню мы можем выбрать весь набор необходимых программ которые будут включены в состав будущего образа.

Miscelaneous — haveged, который является базовым демоном для генерации случайных чисел;

Networking — dhcpd, демон для работы с сетью и получения сетевых реквизитов по протоколу DHCP;

Networking — dropbear, демон для организации SSH-сервера;

Networking — ifupdown scripts, для работы с сетевыми интерфейсами;

Networking — iperf, iperf3, для проведения бенчмарка пропускной способности по сети (по желанию);

Переходим в меню Filesystem images. Выбираем интересующие нас образы, я выбираю только cpio и метод сжатия lzma.

Поскольку у нас будет использоваться свой кастомный загрузчик — пункт меню Bootladers пропускаем.

В меню Host Utilites ставим опции:

host dosfstools

host genimage

host mtools

Все настройки завершены, записываем их путем нажатия клавиши F6 сохраняем файл с именем .config.

На этом мы можем считать, что предварительная настройка Linux закончена. Можно запускать компиляцию. Для этого я сделал скрипт br-build и записал в него следующее:

После этого необходимо присвоить ему права на исполнение и запустить:

Если все указано и настроено верно — начнется процедура скачивания исходных кодов и компиляция. Этот процесс может затянуться на многие десятки минут.

После окончания компиляции в папке images/ появятся необходимые образы:

Для того, чтобы можно было воспользоваться образом rootfs — необходимо сделать подпись для загрузки его через U-Boot. Для этого нам понадобится пакет U-Boot-tools:

После этого можно попробовать загрузить то, что у нас получилось. Копируем на загрузочную microSD файлы uImage и uramdisk.image.gz и файл devicetree.dtb который у нас был сделан в прошлом занятии.

Проверим, что получилось

Запускаем плату и попадаем в меню U-Boot. В этом меню вводим команды:

Если все получилось верно — у нас загрузится ядро, все программы которые мы указали при старте уже будут в составе ОС. И все будет готово к работе.

В целом основная задача выполнена и достигнутое можно считать хорошей заготовкой для дальнейшей кастомизации используемого образа Linux. Можно пробовать добавлять свои скрипты и проводить более углубленное изучение buildroot, например, осуществить сборку Device Tree через buildroot.

Источник