Rootfs linux что это

Обновлено: 06.07.2024

Mount namespaces изолируют ресурсы файловых систем. Это по большей части включает всё, что имеет отношение к файлам в системе. Среди охватываемых ресурсов есть файл, содержащий список точек монтирования, которые видны процессу, и, как мы намекали во вступительном посте, изолирование может обеспечить такое поведение, что изменение списка (или любого другого файла) в пределах некоторого mount namespace инстанса M не будет влиять на этот список в другом инстансе (так что только процессы в M увидят изменения)

Точки монтирования

Вам может быть интересно, почему мы так сфокусировались на кажущимся произвольно выбранном файле, содержащим в себе список точек монтрирования. Что в нём такого особенного? Список точек монтирования даёт процессу полное описание доступных файловых систем в системе и, поскольку мы пребываем на территории Linux с мантрой всё есть файл, видимость почти каждого ресурса диктуется этим описанием: от фактических файлов и устройств до информации о том, какие другие процессы также запущены в системе. Таким образом, это даёт огромный выигрыш в безопасности для isolate , позволяющий точно указывать о каких именно частях системы будут в курсе команды, которые мы хотим выполнить. Пространства имён mount в сочетании с точками монтирования являются очень мощным инструментом, который позволит нам этого достичь.

Мы можем видеть точки монтирования, видимые для процесса с id $pid посредством файла /proc/$pid/mounts — его содержимое одинаково для всех процессов, принадлежащих к тому же mount namespace, что и $pid :

В списке, полученном на моей системе, видно устройство /dev/sda1 , смонтированное в / (ваше может быть другим). Это дисковое устройство, на котором размещена корневая файловая система, которая содержит всё что нужно для запуска и правильной работы системы, поэтому было бы здорово, если бы isolate запускала команды без ведома о таких файловых системах.

Давайте начнём с запуска терминала в его собственном mount namespace:

Строго говоря, нам не понадобится доступ уровня суперпользователя для работы с новыми пространствами имён mount, поскольку мы добавим процедуры настройки user namespace из предыдущего поста. В результате в этом посте мы предполагаем, что только команды unshare в терминале выполняются от суперпользователя. Для isolate в таком предположении необходимости нет.

Хммм, мы всё еще можем видеть тот же самый список, что и в корневом mount namespace. Особенно после того, как в предыдущем посте стало ясно, что новый user namepace начинается с чистого листа, может показаться, что флаг -m , который мы передали unshare , не дал никакого эффекта.
Процесс шелла фактически выполняется в другом mount namespace (мы можем убедиться в этом, сравнив файл симлинка ls -l /proc/$$/mnt с файлом другой копии шелла, работающей в корневом mount namespace). Причина, по которой мы все еще видим тот же список, заключается в том, что всякий раз, когда мы создаем новый mount namespace (дочерний), в качестве дочернего списка используется копия точек монтирования mount namespace, в котором происходило создание (родительского). Теперь любые изменения, которые мы вносим в этот файл (например, путём монтирования файловой системы), будут невидимы для всех других процессов.
Однако изменение практически любого другого файла на этом этапе будет влиять на другие процессы, поскольку мы всё ещё ссылаемся на те же самые файлы (Linux только делает копии особых файлов, таких как список точек монтирования). Это означает, что сейчас у нас минимальная изолированность. Если мы хотим ограничить то, что будет видеть наш командный процесс, мы должны сами обновить этот список.

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

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

Хорошо, в теории это звучит хорошо и для реализации этого мы сделаем следующее:

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

Корневые файловые системы

Уже на шаге 1 возникает вопрос: какие системные файлы нужны команде, которую мы хотим запустить? Мы могли бы порыться в нашей собственной корневой файловой системе и, задаваясь этим вопросом по каждому файлу, с которым мы столкнемся, брать только те, на которые ответ положительный, но это выглядит больно и излишне. Кроме того, какую команду будет выполнять isolate , мы изначально не знаем.

Вот если бы только у людей уже была такая же проблема и они собрали набор системных файлов, в целом достаточный, чтобы служить базой прямо из коробки для большинства программ? К счастью, есть много проектов, что реализовали это! Одним из них является проект Alpine Linux (его основное предназначение, это когда вы начинаете свой Dockerfile с FROM alpine:xxx ). Alpine предоставляет корневые файловые системы, которые мы можем использовать для наших целей. Если вы последуете инструкциями, то сможете получить копию их минимальной корневой файловой системы ( MINI ROOT FILESYSTEM ) для x86_64 здесь. Последней версией на момент написания поста и которую мы будем использовать, является v3.10.1 .

В каталоге rootfs есть знакомые файлы, прям как в нашей собственной корневой файловой системе в / , но убедитесь, насколько он минимален — многие из этих каталогов пусты:

Отлично! Мы можем дать команду, которая запустится в копии этого окружения, и она может быть даже sudo rm -rf / , но нас это не будет волновать, а никто другой не пострадает.

Pivot root

Имея наш новый mount namespace и копию системных файлов, мы хотели бы смонтировать эти файлы в корневом каталоге нового mount namespace не выбивая землю из под наших ног. Linux предлагает нам системный вызов pivot_root (есть соответствующая команда), который позволяет нам контролировать то, что именно процессы видят как корневую файловую систему.
Команда принимает два аргумента: pivot_root new_root put_old , где new_root — это путь к файловой системе, будущей вскоре корневой файловой системой, а put_old — путь к каталогу. Это работает так:

Монтирование корневой файловой системы вызывающего процесса в put_old .
Монтирование new_root в качестве корневой файловой системы в / .

Давайте посмотрим на это в действии. В нашем новом mount namespace мы начинаем с создания файловой системы из наших файлов alpine:

Затем мы делаем pivot root:

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

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

Реализация

Мы можем повторить в коде то, что делали выше, заменив команду pivot_root соответствующим системным вызовом. Сначала мы создаем наш команды процесс в новом mount namespace, добавляя флаг CLONE_NEWNS для clone .

Затем мы создаём функцию prepare_mntns которая, получив путь до каталога, содержащего системные файлы ( rootfs ), настраивает текущий mount namespace посредством pivoting'а корневого каталога текущего процесса на rootfs , что мы создали ранее.

Нам нужно вызвать эту функцию из нашего кода и это должно быть выполнено нашим командным процессом в cmd_exec (поскольку он работает в новом mount namespace) до фактического начала выполнения команды.

Давайте попробуем это:

Этот вывод показывает что-то странное: мы не можем проверить список монтирования, за который так тяжело боролись, и ps говорит нам, что нет процессов, запущенных в системе (нет даже текущего процесса или самого ps ?). Более вероятно, что мы что-то сломали при настройке mount namespace.

PID Namespaces

Мы уже несколько раз упоминали каталог /proc в этой серии постов, и если вы были знакомы с ним, то, вероятно, не будете удивлены тому, что вывод ps оказался пустым, поскольку мы видели ранее, что каталог был пуст в этом mount namespace (когда мы получили его из корневой файловой системы alpine).

Каталог /proc в Linux обычно используется для доступа к специальной файловой системе (называемой файловой системой proc), которой управляет сам Linux. Linux использует его для предоставления информации обо всех процессах, запущенных в системе, а также другой системной информации, касающейся устройств, прерываний и так далее. Всякий раз, когда мы запускаем такую команду, как ps , выдающую сведения о процессах в системе, она обращается к этой файловой системе для получения информации.
Другими словами, нам нужно завести файловую систему proc . К счастью, в основном для это потребуется лишь сообщить Linux, что она нам нужна, причем желательно смонтированная в /proc. Но пока мы не можем этого сделать, поскольку наш командный процесс всё ещё зависит от той же файловой системы proc , что и isolate и любой другой обычный процесс в системе. Чтобы избавиться от этой зависимости, нам нужно запустить его внутри собственного PID namespace.

PID namespace изолирует ID процессов в системе. Одним из следствий тут является то, что выполняющиеся в разных пространствах имён PID процессы могут иметь одинаковые идентификаторы процесса, не конфликтуя друг с другом. Допусти, мы изолируем это пространство имён потому, что мы хотим обеспечить как можно большую изолированность нашей запущенной команде. Однако более интересная причина, по которой мы рассматриваем это здесь, заключается в том, что монтирование файловой системы proc требует привилегий пользователя root, а текущий PID namespace принадлежит пользователю root, где у нас нет достаточных привилегий (если вы помните из предыдущего поста, root у командного процесса на самом деле не root). Итак, мы должны работать в PID namespace, владельцем которого является пользователь пространства имён, которое считает наш командный процесс запущенным от root.

Мы можем создать новый PID namespace, передав CLONE_NEWPID для clone :

Затем мы добавляем функцию prepare_procfs , которая настраивает файловую систему proc, монтируя её в текущих пространствах имён mount и pid.

Наконец, мы вызываем функцию прямо перед размонтированием put_old в нашей функции prepare_mntns , после того, как мы настроили mount namespace и перешли в корневой каталог.

Мы можем воспользоваться isolate для очередного запуска:

Это выглядит намного лучше! Шелл считает себя единственным процессом, запущенным в системе и работающем с PID 1(поскольку это был первый процесс, запущенный в этом новом PID namespace)

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

В этой статье следует записать процесс использования buildroot для создания rootfs на платформе rockchip-rk3288.

1. Подготовка

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

2. Конфигурация платформы

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

Выше представлен интерфейс живой конфигурации Buildroot.

2.1 Конфигурация целевых параметров

Ниже приведена информация о конфигурации платформы rockchip-rk3288:

2.2 Настройка цепочки инструментов

Toolchain в основном включает в себя настройку кросс-компилятора, существует два способа:

Buildroot toolchain
External toolchain

Buildroot toolchain - это кросс-компилятор, официально предоставляемый buildroot, а External toolchain - это кросс-компилятор, предоставляемый третьей стороной. Здесь мы подробно объясняем внешний набор инструментов.

Для внешнего набора инструментов buildroot предоставляет три метода конфигурации:

Здесь мы выбираем метод конфигурации Custom toolchain. Конкретные параметры конфигурации следующие:

Здесь необходимо получить информацию, такую как версия gcc и серия заголовков ядра. Для версии gcc мы можем просмотреть ее с помощью команды arm-linux-gnueabihf-gcc -v, например:

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

2.3 System configuration

Настройте имя хоста системы и системный баннер как информацию, относящуюся к платформе. Настройте систему Init как Busybox. Обратите внимание, что управление / dev настроено как динамическое с использованием devtmpfs + mdev, а system / device_table.txt настроено на атрибут «Путь к таблицам разрешений». Мы можем использовать «Enable root login with password», чтобы установить пароль для входа в систему.

Наконец, настройте систему на вход в терминал. Ее конфигурацию необходимо настроить в соответствии с конкретным последовательным портом отладки платы разработки. Например: последовательный порт отладки - ttyS0, а скорость передачи - 115200.

2.4 Filesystem images

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

2.4 Target packages

Целевые пакеты включают в себя большое количество сторонних библиотек.Мы можем скомпилировать необходимые инструменты в корневую файловую систему в соответствии с конкретными требованиями проекта.

3. Компилировать

Переключитесь в главный каталог buildroot, выполните команду make или выполните make O = / path / to / store / build / file (укажите место, где хранятся результаты компиляции), и buildroot автоматически загрузит и установит пакеты программного обеспечения, необходимые для создания rootfs. После завершения компиляции содержимое, связанное с rootfs, будет сгенерировано в buildroot / output. Функции каждого файла следующие:

target: эта папка содержит все файлы rootfs, которые мы используем для отладки проблемы rootfs на плате разработки.
image: эта папка содержит все различные типы файловых систем, мы выбираем соответствующий тип и загружаем его на плату разработки, если есть проблема, вы можете обратиться к цели для отладки.
build: эта папка содержит исходные файлы пакетов, необходимых для rootfs.
host: эта папка содержит инструменты и файлы конфигурации, необходимые в процессе компиляции rootfs.
Makefile: Управляет процессом компиляции всей файловой системы.

Интеллектуальная рекомендация

Краткое описание общих функций MPI

содержание 1, основная функция MPI 2, точка-точка функция связи 3, коллективная функция связи 1, основная функция MPI MPI_Init(&argc, &argv) Информировать системы MPI для выполнения всех необх.

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

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

Анализ процесса монтажа 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

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 (), чтобы переместить текущую точку монтирования файловой системы в каталог «/», а затем переключить корневой каталог в текущий каталог. Точка монтирования корневой файловой системы становится тем, что мы видим в пространстве пользователя. "/".

initrd_load создает узел устройства / dev / ram0 типа Root_RAM0 (то есть узел устройства ramdisk)
Вызовите rd_load_image, чтобы загрузить файл /initrd.image в / dev / ram0, а затем удалите файл initrd.image.
Затем вызовите handle_initrd, чтобы смонтировать узел ramdisk / dev / ram0 в корневой каталог /, введите каталог / root, смонтируйте текущий каталог как корневой каталог,
Наконец, переключите текущий каталог в положение корневого каталога, на которое ссылается выполнение программы.

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

_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.

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

jff2 - это файловая система, разработанная специально для Norflash. Эта файловая система хранится непосредственно на флэш-памяти и не будет потеряна после сбоя питания. В отличие от initramfs, можно также использовать небольшую страницу Nandflash, но это неэффективно. Вот Norflash и
Простое отличие Nandflash1。

2.1 VFS

Все мы знаем, что Linux более совместим, потому что встроенное оборудование будет защищать базовое оборудование, требуя хорошей совместимости и высокой переносимости. Пользователям не нужно знать конкретную реализацию этих базовых файловых систем, что в основном связано с VFS (виртуальная файловая система). VFS имеет следующие характеристики:

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

2.2 Подготовка исходного кода инструмента - трансплантация mtd-utils

Создать рабочий путь

Подготовка библиотеки

1. Скомпилируйте библиотеку lzo и создайте статическую библиотеку.

2. Скомпилируйте библиотеку zlib.

3. Скомпилируйте библиотеку e2fsprogs (libuuid)

4. Скомпилируйте mtd-utils и установите mkfs.jffs2 и mkfs.ubifs.

5. Производство средств корневой файловой системы.

3.1 Изготовление зеркал

Его можно изменить прямо в дереве файловой системы, созданном в прошлый раз.

3.2 Конфигурация и компиляция ядра

1.General setup
Уменьшите размер ядра и отмените раздел подкачки Nandflash.

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

2.File systems
Отменена ненужная поддержка файловой системы, также можно отключить привод компакт-дисков. Компакт-диски не нужны.

3.Native language support
Параметры языка более произвольны, просто выберите китайские символы, и все остальные можно отменить.

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

По настроенной в ядре информации настроим параметры u-boot

Интерпретация параметров：
Корневая файловая система jffs2 отличается от файловой системы initramfs. jiff2 - это корневая файловая система, построенная на Nandflash. Плата разработки не теряется при отключении питания, и, в отличие от initramfs и ядра, ей требуется Запишите отдельно ядро и корневую файловую систему.
Общий опыт

Программный адрес u-boot должен быть 0, а размер не должен превышать 1 МБ. Этот раздел соответствует / dev / mtdblock0 в таблице разделов ядра Linux;
Программный адрес ядра Linux должен быть 0x100000 (со смещением 1M), а размер не должен превышать 15M. Этот раздел соответствует Linux
/ dev / mtdblock1 таблицы разделов ядра;
Адрес записи образа корневой файловой системы должен быть 0x1000000 (со смещением 16M), а размер не должен превышать 40M. Этот раздел соответствует / dev / mtdblock2 в таблице разделов ядра Linux;

4.1 Запись ядра

4.2 Записать корневую файловую систему

После того, как u-boot будет записан, мы можем напрямую перезапустить плату разработки или использовать команду загрузки.

Корневой файл действительно смонтирован в файловой системе jffs2, и вы можете проверить состояние раздела.

Читайте также: