Что такое mtd устройства
Русские Блоги
Linux mtd system
Linux mtd system
MTD (Memory Technology Device), устройство с технологией памяти, является подсистемой устройств хранения Linux. Целью разработки этой системы является предоставление уровня абстракции и интерфейса для запоминающих устройств, так что разработчикам драйверов аппаратного обеспечения необходимо предоставить только простейшую функцию чтения / записи / стирания базового аппаратного устройства. Да, вам не нужно заботиться о том, как данные представляются верхним пользователям, потому что подсистема устройства хранения MTD сделала это за вас.
Рамки 1.MTD
Устройство Linux MTD находится в каталоге drivers / mtd /, здесь приведен только приблизительный анализ его структуры каталогов. Если вы хотите узнать конкретные детали, вы можете проверитьблог Крифана, Есть много ссылок и статей для справки, и анализ очень тщательный. Содержимое файла MTD выглядит следующим образом:
Оборудование MTD обычно можно разделить на четыре уровня
Сверху вниз находятся: узел устройства, уровень устройства MTD, уровень исходного устройства MTD и уровень драйвера оборудования.
1.cmdlinepart.c
Когда таблица разделов mtd переносится из u-boot в linux через параметры cmd, ядру linux не нужно регистрироваться и добавлять mtdparts, просто включите параметр разделения командной строки в MTD. Используя этот метод, u-boot должен поддерживать MTD, а передаваемые параметры раздела mtd должны соответствовать требованиям формата.
Папка 2.devices
Папка 3.chips / nand / onenand
Флеш-драйвер nand находится в папке nand;
Flash-драйвер onenand находится в папке onenand;
И флэш не сложнее, там будут все следующие файлы:
4. Основные файлы
mtdchar.c: реализация интерфейса с символьным устройством MTD, номер устройства 31;
mtdblock.c: реализация, связанная с интерфейсом блочного устройства MTD, номер устройства 90;
mtdcore.c: реализация, связанная с оригинальным интерфейсом устройства MTD;
mtdpart.c: реализация интерфейса раздела MTD.
5.ubi
2. Реализация таблицы разделов MTD
Во время процесса загрузки вы часто можете увидеть информацию, похожую на следующую из консоли,
Это наиболее интуитивное представление, которое дает нам MTD, показывающее нам структуру разделов каждого модуля в памяти, но как эти разделы реализованы? Существует несколько способов реализации таблицы разделов, которые описаны ниже:
Примечание. Обязательным условием реализации таблицы разделов является успешное выполнение драйвера устройства MTD, в противном случае раздел не будет создан даже в случае сбоя драйвера.
1. Добавлено в ядро
Поскольку наш драйвер MTD завершен, при совпадении устройства и драйвера будет вызвана функция интерфейса датчика в драйвере, и нам нужно вызвать его в функции датчика add_mtd_partitions(s3c_mtd, sets->partitions, sets->nr_partitions); Реализуйте добавление таблицы разделов.
2.u-boot параметры передачи
Под u-boot вы можете добавить информацию mtdparts в bootargs.После запуска u-boot информация из bootargs будет передаваться ядру, и ядро будет анализировать часть bootargs mtdparts при запуске. Вот пример:
mtdparts=nand.0:1M(Bootloader)ro,31M(Kernel)ro,16M(User),96M(File System) Более конкретный формат mtdparts можно найти в соответствующей информации.
При добавлении таблицы разделов в ядро мы добавляем информацию mtd_partition на устройство платформы. Передача параметров через u-boot здесь отменяет информацию о разделах в устройстве платформы, а затем, как нам нужно проанализировать mtdparts, переданные u-boot.
После того, как u-boot передаст параметры, эти параметры будут проанализированы в cmdlinepart.c и сохранены внутри LIST_HEAD(part_parsers) В связанном списке мы затем в функции зонда драйвера, вызывая mtd_device_parse_register(mtd, probe_types,&ppdata, NULL, 0); функция.
mtd_device_parse_register() Функция находится в drivers / mtd / mtdcore.c, и ее содержимое выглядит следующим образом:
Вы можете видеть, что функция будет выполнена первой parse_mtd_partitions(mtd, types, &real_parts, parser_data); Функция, позже через add_mtd_partitions() Функция для реализации добавления таблицы разделов.
parse_mtd_partitions() Функция находится в drivers / mtd / mtdpart.c, и ее содержимое выглядит следующим образом:
войти parse_mtd_partitions() Функция сначала определит тип типа, и если он будет пустым, он даст значение по умолчанию. Обычно существует два типа типов:
Передача параметров 3.dts
В версии Linux после Linux3.14 добавлено новое знание DTS (Дерево устройств). Фактически, DTS решает избыточный код в ARM Linux. В Linux2.6 версии arch / arm / plat.xxx и arch / Файл Arm / mach.xxx заполнен большим количеством мусорного кода. После принятия дерева устройств многие детали аппаратного обеспечения могут напрямую передаваться в Linux через Linux вместо большого количества избыточного кодирования в ядре. Вы можете обращаться к dts самостоятельно. данные.
Принцип передачи параметров dts фактически тот же, что и для u-boot, разница в том, что u-boot использует файл cmdlinepart.c для записи информации о разделах. LIST_HEAD(part_parsers) Связанный список, dts использует файл ofpart.c для записи информации о разделах. LIST_HEAD(part_parsers) Связанный список, поэтому следует также открыть макрос файла ofpart.c и mtd_device_parse_register(mtd, probe_types,&ppdata, NULL, 0); Тип функции должен быть установлен на ofpart.
Если вы сравните версию для Linux 2.6 и версию для Linux 3.14, вы обнаружите, что файлы drivers / mtd / ofpart.c и drivers / mtd / mtdpart.c отличаются. Версия Linux 3.8 включает дерево устройств. Те, кто заинтересован, могут вникать в это самостоятельно.
Анализ системы Linux Mtd здесь, и она будет обновляться, когда у вас есть чувства.
Примечание. Приведенное выше содержание является частью моего опыта, накопленного в процессе обучения. Это неизбежно, что я буду ссылаться на некоторые знания других статей. Если есть какие-либо нарушения, пожалуйста, сообщите мне вовремя. Я буду удалять или отмечать источник контента в срок. Пожалуйста, укажите, обсудите и изучите. Эта статья является лишь руководством. Для подробного анализа данных, пожалуйста, ознакомьтесь с руководствами по Linux. Спасибо за чтение.
Мобильные устройства изнутри. Разметка памяти, структура файлов описания и разметки памяти
1. Введение
Как оказалось, разметка физической памяти мобильных устройств (МУ) это малоописанный раздел знаний, необходимых разработчику. Т.к. память существует во всех устройствах, созданных на основе микропроцессоров или микроконтроллеров, а их уже миллиарды, то это еще и очень-очень востребованный раздел знаний.
Эта статья посвящена аспектам разметки памяти только МУ, т.к. именно здесь существует тесно свитый разными производителями клубок из файлов описания разметки при почти полном отсутствии теоретических данных о структуре самих этих файлов.
Разметка физической памяти МУ формируется на основании таблиц или списков описаний параметров разделов памяти. Практически каждая фирма-производитель МУ имеет свою форму (структуру) этих таблиц. Тем не менее, все описания параметров разделов имеют много общего, что позволяет рассматривать их в едином контексте.
На основе таблиц описаний затем формируются файлы разметки памяти, которые в виде образов разделов прошиваются непосредственно в память МУ.
2. Что такое разметка памяти?
Подробнее, что представляет собой разметка памяти МУ и для чего это нужно, можно посмотреть, например, в [1]. Вот еще одна публикация, в которой доступно объясняется устройство памяти и ее разметка [2].
Если кратко, то разметка памяти, как процесс, выполняет распределение всего объема внутренней физической памяти МУ на отдельные разделы, которые могут иметь разное функциональное назначение, вплоть до разных файловых систем, и разные права доступа. Это позволяет выделить в памяти отдельно области для хранения данных и работы пользователя, отдельно для работы операционной системы, шифровать или форматировать разделы при необходимости и независимо друг от друга и т.д.
При выполнении разметки разработчик МУ должен придерживаться некоторых правил, которые называются схемами разметки памяти. Схема разметки описывает размещение всех разделов физической памяти: их очередность, смещение и название, т.е. метку или имя раздела. Могут указываться и другие параметры: его размер, тип, регион, флаги и т.п.
Для выполнения разметки памяти используют файлы двух видов: текстовые и бинарные (двоичные RAW-файлы).
Текстовый файл представляет собой перечень (список) всех разделов памяти, каждая запись которого содержит описание основных параметров этих разделов. Он используется при выполнении нескольких операций:
Процесс создания разметки памяти можно описать следующим алгоритмом:
3. Схемы разметки памяти
Чаще всего применяются две схемы разметки памяти: Mbr и Gpt.
При любой схеме разметки памяти первым по порядку разделом в пользовательском регионе МУ всегда должен быть раздел разметки (Mbr, Gpt, Parameter).
3.1.Mbr-схема разметки памяти
Согласно Mbr-схеме память МУ представляется как последовательность разделов, дополненная главной загрузочной записью или Mbr (Master Boot Record), содержащей таблицу описания разделов. Mbr физически располагается в первом (нулевом) секторе памяти МУ:
рис.1. Главная загрузочная запись.
Mbr содержит сигнатуру, т.е. признак Mbr, и непосредственно саму таблицу описания разделов.
Внутреннее строение Mbr [3] позволяет разместить в ней только 4 записи о разделах, что является в современных условиях существенным недостатком. Если требуется разбить память на большее количество разделов, то используется дополнительная (расширенная) загрузочная запись Extended Boot Record (Ebr). При этом в Mbr вместо записи об одном из разделов помещается запись о дополнительном (extended) разделе, содержащем только Ebr.
Сама Ebr устроена аналогично Mbr, и использовать ее нужно точно также. Т.е., если при заполнении таблицы Ebr опять не хватает места под записи о разделах, то создается следующая Ebr-таблица и т.д.
Mbr и все Ebr могут помещаться в отдельные файлы-образы, которые размещаются и прошиваются в соответствующих отдельных разделах памяти. При этом все файлы, содержащие Ebr, имеют имена нумерованные последовательно: Ebr1, Ebr2,…
При другом варианте Ebr помещаются в один файл-образ последовательно, тогда этот образ, соответственно, размещается в одном Ebr-разделе памяти.
3.2. Gpt-схема разметки памяти
Gpt-схема разметки (GUID Partition Table) является частью EFI (Extensible Firmware Interface) — стандарта, используемого вместо BIOS для разметки памяти и загрузки ее разделов. Переход на другой формат описания разделов позволил устранить самый существенный недостаток Mbr-схемы — малое число разделов, т.к. в таблице описания разделов Gpt можно разместить до 128 разделов. Структуру самих таблиц можно посмотреть в [4].
Согласно Gpt-схеме память МУ тоже представляет собой последовательность разделов, необходимых для работы МУ, дополненную спереди Gpt-таблицей описания разделов, называемой основной. При этом после всех разделов размещается дополнительная Gpt-таблица, называемая резервной. Такое расположение таблиц, теоретически, повышает надежность разметки, т.к. при сбое или порче основной Gpt-таблицы ОС может использовать для работы, или восстановления основной, резервную.
4. Таблицы описания разделов памяти
Таблицы описания разделов памяти МУ содержат информацию о всех разделах, необходимую для создания разметки памяти. Каждая строка (запись) таблицы описывает один раздел и содержит, как правило, следующие параметры:
4.1. Parameter-файл
Прошивка МУ на чипе RK содержит текстовый файл PARAMETER, который предназначен для описания построения (настройки и загрузки) физической памяти блочного типа. Причем использовался он и на ОС LINUX.
Оригинальный вид содержимого файла PARAMETER для МУ Cube u30gt-M приведен ниже:
FIRMWARE_VER:4.0.4
MACHINE_MODEL:U30GT-M
MACHINE_ID:007
MANUFACTURER:RK30SDK
MAGIC:0x5041524D
ATAG:0x60000800
MACHINE:3066
CHECK_MASK:0xFF
KERNEL_IMG:0x60408000
RECOVERY_KEY:0,4,C,6,0
COMBINATION_KEY:0,4,C,6,0
CMDLINE: console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000( boot),0x00008000@0x00010000(recovery),0x000C0000@0x00018000(backup),0x00040000@0x000D8000(cache),0x00200000@0x00118000(userdata),0x00002000@0x00318000(kpanic),0x00120000@0x0031A000(system),-@0x0043A000(user)
4.1.1. Описание параметров файла PARAMETER
Файл PARAMETER может содержать следующие параметры:
4.1.2. Параметр CMDLINE и его возможности
Формат командной строки, т.е. CMDLINE, имеет следующий вид:
CMDLINE: ключ1=значение1 [ключ2=значение2], где
mtddef — описание разметки памяти устройства блочного типа (БУ). Если МУ содержит несколько БУ, то может содержать и несколько описаний, которые располагаются последовательно без промежутка и разделяются символом «точка с запятой».
Описание разметки памяти каждого БУ имеет следующее строение:
Параметр part_size описывает размер раздела в блоках, выраженный в hex-системе счисления. Если вместо размера указан символ «минус» («-«), это означает максимально возможный размер, т.е. до физического конца памяти.
Параметр part_offset представляет смещение раздела в блоках, выраженный в hex-системе счисления. Смещение всегда выравнивается на границу в 0х1000.
Параметр label (имя раздела) это строковый идентификатор раздела, заключенный в круглые скобки, например, (boot).
Параметр flag (флаг) может принимать только одно значение — «ro«, означающее, что раздел предназначен только для чтения. Отсутствие флага означает, что раздел доступен для чтения и записи.
Несколько очень важных замечаний:
4.2. Rawprogram0-файл
Файл rawprogram0.xml предназначен для описания разметки памяти МУ на основе чипов Qualcomm и имеет следующее строение:
Рис.3. Вид файла rawprogram0.xml от Lenovo s90a
Он содержит таблицу описания параметров разделов в виде xml-элементов типа program. Все разделы перечисляются строго в порядке их размещения в памяти МУ.
Каждый xml-элемент может содержать следующие xml-атрибуты:
4.3. Ota-файл
Это единственный файл описаний, который описывает строение файла прошивки, а не разметку памяти.
Например, файл ota-обновления МУ на чипе МТ6582 фирмы MTK, имеет следующий вид:
Он содержит описание тех разделов, чьи образы присутствуют в файле прошивки для ota-обновления, каждое из которых имеет следующее строение:
label part_offset, где
4.4. Scatter-файл
Файл scatter содержит описание разметки памяти МУ, построенных на основе чипов МТК. Существует три версии структуры этого файла, что связано с историческим развитием возможностей как самих чипов памяти, так и чипов процессоров фирмы MTK.
4.4.1. Версия 1
Файл описаний разметки первой версии содержит список описаний каждого раздела памяти, и имеет следующий вид:
Рис.5. Scatter-файл первой версии
Каждый раздел памяти описывается следующей структурой:
Такое описание разделов памяти предполагает, что:
4.4.2. Версия 2
Scatter-файл описаний разметки памяти второй версии содержит заголовок и непосредственно таблицу описаний каждого раздела памяти. Он имеет следующий вид:
Рис.6. Scatter-файл второй версии
Заголовок содержит параметры прошивки целиком и содержит следующие поля:
Для чипов МТ6572-МТ6577 в качестве значения Begin Address флешером используется значение поля linear_start_addr, отражающее истинное смещение раздела в памяти (представляющей один сплошной регион), т.к. чипы не умеют работать с регионами, а используемая память имела только один регион для размещения разделов. При этом значение поля «physical_start_addr» всегда равно нулю.
Чипы МТ6582 уже умеют работать с регионами, но используемая память еще имеет только один регион. Поэтому в качестве значения Begin Address флешером уже используется значение поля physical_start_addr, отражающее смещение раздела в пределах регионов, создаваемых в памяти программно, а поле linear_start_addr содержит значения смещения от начала чипа памяти.
В связи с тем, что, начиная с чипа МТ6592, МУ от МТК используют полноценную работу с регионами памяти, то для чипов МТ6592 и выше флешером в качестве значения Begin Address используется значение поля physical_start_addr.
Значение поля Format Length флешер всегда получает из поля partition_size.
5.Файлы разметки памяти.
Файлы разметки памяти содержат образ раздела разметки памяти МУ. Их структура зависит от схемы разметки (Gpt или Mbr) и от назначения, например, резервные файлы разметки Pmt или Gpt.
Встречаются следующие виды файлов разметки:
5.1. Mbr-файл
Mbr-файл представляет собой образ раздела разметки памяти по Mbr-схеме, имеющий размер 1 сектор, т.е. 512 байт.
В МУ применяется так называемая классическая структура Mbr-файла [5]:
Рис.7. Классическая структура Mbr-файла
Каждая запись параметров раздела содержит следующие поля, значения которых отличается от принятых в классической структуре Mbr:
Поле IsBoot имеет размер 1 байт и используется для обозначения активности раздела, старший бит которого указывает на загрузочный раздел:
Поле Type имеет размер 1 байт и используется производителями МУ для обозначения типа описываемого раздела. Обозначение типа раздела у разных производителей могут отличаться, но есть некоторые общепринятые значения:
Поле Offset имеет размер 4 байта и содержит значение смещения раздела, выраженное в секторах.
Поле Size имеет размер 4 байта и содержит значение размера раздела, выраженное тоже в секторах.
По адресу 0x01FE расположена сигнатура Mbr-файла, имеющая значение 0xAA55.
5.2. Ebr-файл
Ebr-файл представляет собой образ расширенного раздела разметки памяти, выполненной по Mbr-схеме. Он имеет такое же строение и размер, как и Mbr-файл:
Рис.8. Классическая структура Ebr-файла
Отличия заключаются в том, что в Ebr-файле признак активности всегда установлен в 0, да и этих файлов, при необходимости, может быть уже не один, а 63. Соответственно, для их размещения тоже понадобится создавать до 63 разделов, что приводит к расточительному расходованию памяти МУ.
Если разделов памяти относительно немного, например, как в МУ Star Z2, то используются отдельные файлы Ebr1 и Ebr2, размещаемые в отдельных разделах. Но, если разделов много, например,, то все файлы Ebr можно сложить в один и разместить общий файл в одном разделе памяти.
5.3. Gpt-файл
Gpt-файл содержит образ разметки памяти по Gpt-схеме. Чаще всего МУ имеют стандартную структуру Gpt-схемы, поэтому, фактически, в прошивке имеется два Gpt-файла: основной, называемый pgpt (primary) или gpt_main, и вторичный (резервный), называемый sgpt (secondary) или gpt_backup.
Основной Gpt-файл располагается в памяти МУ, начиная с нулевого сектора, занимает 34 сектора и имеет следующее строение:
5.4. Parameter-файл
Parameter-файл, т.е. образ раздела, содержащего разметку памяти, содержит только сам текстовый файл PARAMETER, причем независимо от размеров этого раздела. Вот как Parameter-файл выглядит, например, внутри прошивки для устройства U30GT-H фирмы RK [6]:
Рис.9. Parameter-файл от U30GT-H на процессоре RK3066
5.5. Pmt-файл
Pmt-файл представляет собой образ резервного раздела разметки памяти, используемой разработчиками МУ фирмы МТК, и имеет размер 4096 байт.
Образ раздела PMT состоит из двух таблиц описания разделов памяти. В начале расположена базовая, а следом за ней резервная или зеркальная (mirror) таблица описания разделов.
Каждая из таблиц состоит из:
Для резервной таблицы эта строка имеет вид «‘MPT1’\х01\х00\х03\х01»:
Рис.13.Сигнатура конца резервной таблицы
Структура каждой записи имеет размер 0х58 (88) байт состоит из 4 полей и имеет следующий вид:
5.6. Pit-файл
Pit-файл (Partition Information Table) представляет собой образ раздела разметки памяти, используемой разработчиками МУ фирмы Samsung, и имеет размер 4096 байт. Информация по строению образа взята из [7, 8].
Pit-файл состоит из заголовка и таблицы описаний параметров разделов.
Заголовок имеет размер 28 байт и содержит следующие поля:
Следом располагается таблица описаний параметров разделов, состоящая из записей о разделах. Признак конца таблицы — пустая запись. Каждая запись содержит следующие поля:
Поле binary содержит тип операционной системы. Допустимы следующие значения:
Поле device содержит тип устройства. Допустимы следующие значения:
Поле id содержит порядковый номер раздела в прошивке.
Поле flags содержит флаги раздела. Может принимать значения:
Поле update содержит флаги раздела при обновлении. Может принимать значения:
Поле part_off содержит смещение раздела в памяти, выраженное в блоках.
Поле part_len содержит размер раздела в памяти, выраженный в блоках.
Поле offset содержит смещение файла-образа в прошивке, выраженное в блоках.
Поле file_size содержит размер файла-образа, выраженный в блоках.
Поле label имеет длину 32 байта и содержит метку раздела памяти, завершенную нулем (0х00).
Поле file_name содержит имя файла-образа раздела прошивки, завершенное нулем (0х00).
Поле fota_name содержит имя файла-образа раздела прошивки FOTA-обновления, завершенное нулем (0х00).
Записки Линуксоида
Я вижу Мир, Мир видит меня
Memory Technology Device (MTD) support
Memory Technology Device (MTD) support
Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option will provide the generic support for MTD drivers to register themselves with the kernel and for potential users of MTD devices to enumerate the devices which are present and obtain a handle on them. It will also allow you to select individual drivers for particular hardware and users of MTD devices. If unsure, say N.
Устройства памяти — это флэш-память, оперативная память и аналогичные микросхемы, которые часто используются для создания твердотельных файловых систем на встроенных устройствах. Эта опция обеспечит общую поддержку для драйверов MTD для регистрации себя в ядре и для потенциальных пользователей устройств MTD для перечисления имеющихся устройств и получения указателя на них. Это также позволит вам выбрать отдельные драйверы для конкретного оборудования и пользователей устройств MTD.
Если не уверены, скажите N.
This turns on low-level debugging for the entire MTD sub-system. Normally, you should say N.
Включает низкоуровневую отладку для всей подсистемы MTD.
Обычно вы должны сказать N.
MTD concatenating support
Поддержка объединения нескольких устройств MTD в одно (виртуальное). Это позволяет вам иметь, например, файловую систему JFFS (2), охватывающую несколько физических флеш-чипов.
Если не уверены, скажите Y.
MTD partitioning support
If you have a device which needs to divide its flash chip(s) up into multiple ‘partitions’, each of which appears to the user as a separate MTD device, you require this option to be enabled. If unsure, say ‘Y’.
Note, however, that you don’t need this option for the DiskOnChip devices. Partitioning on NFTL ‘devices’ is a different — that’s the ‘normal’ form of partitioning used on a block device.
Если у вас есть устройство, которому необходимо разделить свои флеш-чип(ы) на несколько «разделов», каждый из которых представляется пользователю как отдельное устройство MTD, вам необходимо включить эту опцию. Если вы не уверены, скажите «Y».
Обратите внимание, что вам не нужна эта опция для устройств DiskOnChip. Разбиение на «устройствах» в NFTL отличается — это «нормальная» форма разбиения, используемая на блочных устройствах.
Direct char device access to MTD devices
This provides a character device for each MTD device present in the system, allowing the user to read and write directly to the memory chips, and also use ioctl() to obtain information about the device, or to erase parts of it.
Предоставляет символьное устройство для каждого устройства MTD, присутствующего в системе, позволяя пользователю читать и записывать данные непосредственно в микросхемы памяти, а также использовать ioctl () для получения информации об устройстве или для его удаления.
Caching block device access to MTD devices
Although most flash chips have an erase size too large to be useful as block devices, it is possible to use MTD devices which are based on RAM chips in this manner. This block device is a user of MTD devices performing that function.
At the moment, it is also required for the Journalling Flash File System(s) to obtain a handle on the MTD device when it’s mounted (although JFFS and JFFS2 don’t actually use any of the functionality of the mtdblock device).
Later, it may be extended to perform read/erase/modify/write cycles on flash chips to emulate a smaller block size. Needless to say, this is very unsafe, but could be useful for file systems which are almost never written to.
You do not need this option for use with the DiskOnChip devices. For those, enable NFTL support (CONFIG_NFTL) instead.
Хотя большинство флэш-чипов имеют слишком большой размер стирания, чтобы их можно было использовать в качестве блочных устройств, таким образом можно использовать устройства MTD, основанные на чипах ОЗУ. Это блочное устройство является пользователем устройств MTD, выполняющих эту функцию.
В настоящий момент также требуется, чтобы Journalling Flash файловая система(ы) получала дескриптор устройства MTD при его монтировании (хотя JFFS и JFFS2 фактически не используют никаких функций устройства mtdblock).
Позже он может быть расширен для выполнения циклов чтения/стирания/изменения/записи на чипах флэш-памяти, чтобы эмулировать меньший размер блока. Излишне говорить, что это очень небезопасно, но может быть полезно для файловых систем, в которые почти никогда не записываются данные.
Вам не нужна эта опция для использования с устройствами DiskOnChip. Для них включите поддержку NFTL (CONFIG_NFTL).