Русские Блоги
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
Когда у нас есть устройство spi flash и нам нужно использовать mtd для управления, мы обычно помещаем его в папку устройств, например, m25p80.c в папке устройств — это типичное устройство spi flash.
Папка 3.chips / nand / onenand
Флеш-драйвер nand находится в папке nand;
Flash-драйвер onenand находится в папке onenand;
И флэш не сложнее, там будут все следующие файлы:
- фишки: универсальный драйвер интерфейса cfi / jedec
- устройства: ни флэш нижний драйвер (spi flash)
- карты: ни функции, связанные с отображением флэш-карт
4. Основные файлы
mtdchar.c: реализация интерфейса с символьным устройством MTD, номер устройства 31;
mtdblock.c: реализация, связанная с интерфейсом блочного устройства MTD, номер устройства 90;
mtdcore.c: реализация, связанная с оригинальным интерфейсом устройства MTD;
mtdpart.c: реализация интерфейса раздела MTD.
5.ubi
Слой поддержки файла ubifs. При использовании файловой системы ubifs необходимо выбрать «Включить UBI» в разделе «Драйверы устройств» -> «Поддержка устройств с технологией памяти (MTD)» -> UBI — Несортированный образ блока.
Выберите поддержку файловой системы UBIFS в Файловые системы -> Другие файловые системы.
2. Реализация таблицы разделов MTD
Во время процесса загрузки вы часто можете увидеть информацию, похожую на следующую из консоли,
Это наиболее интуитивное представление, которое дает нам MTD, показывающее нам структуру разделов каждого модуля в памяти, но как эти разделы реализованы? Существует несколько способов реализации таблицы разделов, которые описаны ниже:
Примечание. Обязательным условием реализации таблицы разделов является успешное выполнение драйвера устройства MTD, в противном случае раздел не будет создан даже в случае сбоя драйвера.
1. Добавлено в ядро
Добавление этого в ядро является более часто используемым методом. Он должен быть доступен в любой книге о трансплантации драйверов. Главное — добавить mtd_partition к устройству платформы и добавить информацию, подобную следующей. Я не буду описывать ее здесь.
Поскольку наш драйвер 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 можно найти в соответствующей информации.
Чтобы ядро могло анализировать информацию mtdparts, нам нужно включить опцию «Драйверы устройств -> Поддержка устройств с памятью (MTD)» -> «Разбор таблицы разделов командной строки» в ядре, как было упомянуто выше.
При добавлении таблицы разделов в ядро мы добавляем информацию 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() Функция сначала определит тип типа, и если он будет пустым, он даст значение по умолчанию. Обычно существует два типа типов:
Первый «cmdlinepart» — это способ передачи параметров в u-boot, а второй «ofpart» — это способ передачи параметров с использованием dts, как указано ниже. После оценки типа pass get_partition_parser Разобрать part_parsers Данные в связанном списке завершат анализ параметров загрузки.
Передача параметров 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. Спасибо за чтение.
4.2 MTD — Технологическое Устройство Памяти
MTD означает Memory Technology Device, Технологическое Устройство Памяти, и является подсистемой, используемой для управления устройствами хранения данных, находящихся на плате. Является ли MTD отдельным классом набора драйверов, как символьные или блочные? Простой ответ: нет. Тогда в чём заключается работа MTD и когда и как устройства флеш-памяти включаются в подсистему MTD? Как на MTD устройство будут помещаться файловые системы? На эти вопросы отвечают следующие подразделы.
General MTD documentation
MTD subsystem (stands for Memory Technology Devices) provides an abstraction layer for raw flash devices. It makes it possible to use the same API when working with different flash types and technologies, e.g. NAND, OneNAND, NOR, AG-AND, ECC’d NOR, etc.
MTD subsystem does not deal with block devices like MMC, eMMC, SD, CompactFlash, etc. These devices are not raw flashes but they have a Flash Translation layer inside, which makes them look like block devices. These devices are the subject of the Linux block subsystem, not MTD. Please, refer to this FAQ section for a short list of the main differences between block and MTD devices. And the raw flash vs. FTL devices UBIFS section discusses this in more details.
MTD subsystem has the following interfaces.
- MTD character devices — usually referred to as /dev/mtd0 , /dev/mtd1 , and so on. These character devices provide I/O access to the raw flash. They support a number of ioctl calls for erasing eraseblocks, marking them as bad or checking if an eraseblock is bad, getting information about MTD devices, etc.
- The sysfs interface is relatively newer and it provides full information about each MTD device in the system. This interface is easily extensible and developers are encouraged to use the sysfs interface instead of older ioctl or /proc/mtd interfaces, when possible. The sysfs interface for the mtd subsystem is documentated in the kernel, and currently can be found at Documentation/ABI/testing/sysfs-class-mtd .
- The /proc/mtd proc file system file provides general MTD information. This is a legacy interface and the sysfs interface provides more information.
MTD subsystem supports bare NAND flashes with software and hardware ECC, OneNAND flashes, CFI (Common Flash Interface) NOR flashes, and other flash types.
Additionally, MTD supports legacy FTL/NFTL «translation layers», M-Systems’ DiskOnChip 2000 and Millennium chips, and PCMCIA flashes ( pcmciamtd driver). But the corresponding drivers are very old and not maintained very much.
MTD API
The MTD subsystem API is defined in include/linux/mtd/mtd.h . The methods and data structures in this file are used by higher layer kernel code such as flash file systems to access and control the mtd devices, and also by device driver authors to interface their device to the mtd subsystem. The various methods by which a driver provides access to the device are defined within struct mtd_info . Prior to kernel version 3.4, higher layers called the driver methods directly by way of a pointer to struct mtd_info . As of kernel 3.4, these methods are implemented within the mtd subsystem core code, which then calls the corresponding driver methods. Users of kernel 3.4 and later should not call the driver methods directly, but instead use those prototyped in mtd.h outside of struct mtd_info . These methods include mtd_read() , mtd_write() , etc.
Absent an error, the API methods will return zero, with two notable exceptions. mtd_read() and mtd_read_oob() may return -EUCLEAN in some circumstances. This return code is applicable mainly to NAND flash devices, and is used to indicate that some bit errors were corrected by the device’s ECC facility. Prior to kernel version 3.4, -EUCLEAN was returned if one or more bit errors were corrected during the read operation. As of kernel 3.4, the meaning is more nuanced, and can be broadly interpreted to mean «a dangerously high number of bit errors were corrected». The -EUCLEAN return code is intended to help higher layers detect degradation of erase blocks. The conditions by which mtd_read() and mtd_read_oob() return -EUCLEAN can be tuned using the bitflip_threshold element of the sysfs interface. Please see the kernel documentation for the MTD sysfs interface (referenced above) before adjusting this value.
MTD tests
The mtd-utils include a set of test programs which you may run to verify your flash hardware and drivers. The programs have only been recently ported to user space and are also available as kernel modules.
In contrast to the modules, the user space tests also offer more fine grained options for controling their behaviour, such as only using specific erase blocks or pages.
The user space tests are compiled automatically when compiling mtd-utils, but are not installed by default. To install the tests through make install , the configure option —enable-install-tests has to be set.
The kernel module tests are available in the mainline kernels starting from kernel version 2.6.29 and they live in the drivers/mtd/tests directory of the linux kernel source codes. You may compile the tests as kernel modules by enabling them in the kernel configuration menu by marking: «Device Drivers» -> «Memory Technology Device (MTD) support» -> «MTD tests support» (or the MTD_TESTS symbol in the .config file).
If you have a pre- 2.6.29 kernel, you may find the tests here:
The MTD test-suite contains the following tests:
- nandbiterrs: relevant only for NAND flashes, introduces bit errors and tests for multi-bit error recovery on a NAND page. This mostly tests the ECC controller / driver. The kernel module version is called mtd_nandbiterrs.
- flash_speed: measures and reports read/write/erase speed of the MTD device. The kernel module version is called mtd_speedtest.
- flash_stress: performs random read/write/erase operations and validates the MTD device I/O capabilities. The kernel module version is called mtd_stresstest.
- flash_readtest: this tests reads from an MTD device, one NAND page at a time including OOB (or 512 bytes at a time in case of flashes like NOR) and checks that reading works properly. The kernel module version is called mtd_readtest.
- nandpagetest: relevant only for NAND flashes, tests NAND page writing and reading in different sizes and order; this test was originally developed for testing the OneNAND driver, so it might be a little OneNAND-oriented, but must work on any NAND flash. The kernel module version is called mtd_pagetest.
- mtd_oobtest: currently only exists as a kernel module. Relevant only for NAND flashes, tests that the OOB area I/O works properly by writing data to different offsets and verifying it.
- nandsubpagetest: relevant only for NAND flashes, tests sub-page I/O. The kernel module version is called mtd_subpagetest.
- flash_torture: this test is designed to wear out flash eraseblocks. It repeatedly writes and erases the same group of eraseblocks until an I/O error happens, so be careful! It may be very god idea to run this test for some time and validate your flash driver and HW, providing you have a spare device. For example, we caught rather rare and nasty DMA issues on an OMAP2 board with OneNAND flash, just by running this tests for few hours. The kernel module version is called mtd_torturetest and also supports a number of options (see modinfo mtd_torturetest ).
- mtd_nandecctest: a simple test that checks correctness of the built-in software ECC for 256 and 512-byte buffers; this test is not driver-specific but tests general NAND support code. This tests only exists as a kernel module, as it tests the internal software ECC implementation.
The mtdblock driver
The mtdblock driver available in the MTD is an archaic tool which emulates block devices on top of MTD devices. It does not even have bad eraseblock handling, so it is not really usable with NAND flashes. And it works by caching a whole flash erase block in RAM, modifying it as requested, then erasing the whole block and writing back the modified. This means that mtdblock does not try to do any optimizations, and that you will lose lots of data in case of power cuts. And last, but not least, mtdblock does not do any wear-leveling or bit-flips handling.
Often people consider mtdblock as general FTL layer and try to use block-based file systems on top of bare flashes using mtdblock . This is wrong in most cases. In other words, please, do not use mtdblock unless you know exactly what you are doing.
There is also a read-only version of this driver, mainly for use with uCLinux where the extra RAM requirement was considered too large. However, just like the R/W version of the driver, there is no wear-levelling and bit-flips handling.
Instead of using this old driver, you may check the R/O block device emulation provided by UBI useful. Please refer to the UBI section for more details.
Old MTD documentation
Old MTD web site and old MTD documentation is available here. Old NAND flash interface description is available here.
Основы безопасности операционной системы Android. Native user space, ч.1
В этой статье я попробую рассмотреть безопасность чуть-чуть повыше ядра, а именно: как работает безопасность в Native user space. Мы коснемся темы процесса загрузки операционной системы и рассмотрим структуру файловой системы Android. Как я уже говорил, я не очень силен в Linux, поэтому если заметите неточности, то исправляйте — меня научите и статью улучшите. Так как эта тема довольно обширная, я решил разбить её на две части. В первой части мы рассмотрим процесс загрузки операционной системы и особенности файловой системы. Всем кому интересно, добро пожаловать!
Список статей
Что подразумевается под Native user space
Под Native user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik Virtual Machine, и которые не являются частью Linux kernel.
Файловая система Android
Для начала давайте рассмотрим структуру файловой системы Android. Хотя Android и базируется на Linux kernel, привычную нашему глазу структуру файловой системы мы здесь не увидим. Давайте запустим эмулятор и посмотрим, что у нас есть. Для этого выполним комманду:
В моем терминале для эмулятора на Android 4.2 я вижу следующий результат:
Я отмечу здесь только главные директории и те, которые нам пригодятся в будущем. В Интернете можно найти описание и предназаначение других директорий. Можно заметить, что некоторые директории такие же, как и в Linux, например, /dev, /proc, /sys, /mnt, /etc И их предназначение в основном такое же, как и в Linux. Кстати, отметьте, что мы не видим /bin и /lib директорий. Где они скрылись, я расскажу чуть позже.
C другой стороны можно заметить директории, которых в Linux вообще нет. Среди них нас интересуют /data, /system, /cache, /init, /init.rc Давайте рассмотрим их назначение поподробнее.
/system Это главная директория, где хранятся неизменяемые компоненты Android системы. Если проводить аналогию, то эта папка похожа на папку C:\windows\, доступную только для чтения. Т.е. изменять данные в этой директории мы не можем. Как раз здесь можно найти директории /bin и /lib, где хранятся различные исполняемые файлы и shared libraries. Кроме того, здесь же лежат системные приложения, которые встроены в операционку и которые, по умолчанию, нельзя удалить. Содержимое этой директории формируется во время компиляции операционной системы.
/data Т.к. /system у нас доступна только для чтения, то должна быть директория где хранятся изменяемые данные. /data как раз ею и является. Например, в эту директорию в /data/app сохраняются apk файлы устанавливаемых приложений, а в /data/data хранятся их данные (эту директорию мы подробно рассматривали в прошлой статье).
/cache Это просто временное хранилище. Также в эту директорию сохраняются, а потом из неё запускаются системные обновления.
Чтобы понять, что такое /init файл и для чего нужны непонятные файлы с расширением *.rc, рассмотрим процесс загрузки системы.
Процесс загрузки Android
Давайте рассмотрим несколько шагов процесса загрузки операционной системы Android. Эта картинка взята из книги «Embedded Android», там же можно найти и более детальное описание. Хотя в целом я и понимаю процесс, но для меня это больше магия 🙂
CPU. Когда вы нажимаете на кнопку включения, на процессор вашего устройства начинает подаваться напряжение. Так как до этого момента процессор был выключен, и так как он не способен сохранять свое состояние без подачи напряжения, то сразу после старта он находится в некотором неинициализированном состоянии. В данном случае процессор считывает из своего специального регистра некоторый жестко зашитый адрес и начинает выполнять инструкции начиная с него. Чаще всего, этот адрес указывает на чип, в который зашит bootloader (загрузчик).
Bootloader. Bootloader инициализирует RAM и загружает в неё Linux kernel. Кроме того Bootloader создает RAMdisk.
Linux kernel. Ядро инициализирует различные подсистемы, встроенные драйвера и монтирует root filesystem (корневую файловую систему). После этого ядро может запускать первую программу.
На этом магия заканчивается и дальше всё становится более-менее понятно.
Первой программой в случае Android является init. Исполняемый файл находится в корневой директории (/init). Именно эту программу стартует ядро после своей загрузки. Её исходники находятся в папке system/core/init/ Давайте в них слегка покопаемся. Нас интересует system/core/init/init.c:
Вначале мы создаем и монтируем некоторые необходимые для работы директории, а потом парсим файл /init.rc и выполняем то, что распарсили. Формат /init.rc файла очень хорошо описан в readme, там же можно найти и пример. Если кратко, то этот файл представляет собой набор actions (секций — именнованная последовательность комманд). Каждая последовательность команд срабатывает по определенному trigger (триггеру). Например, следующая последовательно — это action, в которой trigger — это fs, а последовательность команд — это набор mount команд:
Исходный файл /init.rc находится в system/core/rootdir/init.rc Давайте рассмотрим некоторые основные его части, хотя я вам очень советую просмотреть его полность. После этого многие вещи вам должны стать понятны. Итак, начинается наш файл следующими строками:
Они означают, что кроме init.rc файла нужно также импортировать настройки из файлов init.usb.rc, init.trace.rc и из файла с непонятным именем init.$
После этого происходит инициализация переменных, необходимых для работы устройства. Если вас заинтересует эта тема, то вы легко найдете информацию о той или иной комманде. Давайте подробно рассмотрим следующий блок (который я уже приводил в этой статье):
MTD — Memory Technology Devices. Если в общих чертах, то MTD — это специальный чип с энергонезависимой (т.е. данные на этом чипе сохраняются после перезагрузки или выключения) flash-памятью (типа NOR или NAND), на который сохраняются образы дисков. В этой статье более подробно рассказывается об этом типе устройств, а также об ограничениях. Специально для этих разновидностей flash-памяти были разработаны специальные файловые системы, например, YAFFS. Одно из самых важных ограничений этих типов памяти заключается в том, что для того чтобы записать данные в сектор, куда уже записаны какие-то данные, вам надо полностью сначала стереть весь сектор. Поэтому производители стали переходить на новый тип блочной flash-памяти (eMMC), на которые можно поставить обычную ext4 файловую систему и избавиться от указанного ограничения. Т.к. я показываю пример init.rc файла для эмулятора, где вся работа эмулируется, то в нем по умолчанию используется файловая система YAFFS2 (думаю, что это пережитки прошлого, т.к. YAFFS2 использовалась для всех устройств до Android 2.2). В реальном устройстве (это как раз один из примеров, когда необходимо использовать init.rc файл для определенного железа) эти комманды будут перезаписаны. Например, в случае устройства herring (Google Nexus S), в файле init.herring.rc эта секция выглядит следующим образом:
Где fstab.herring — это файл, содержимое которого выглядит следующим образом:
Как вы могли заметить, /system, /data, /cache — это просто mounting points (точки монтирования файловой системы), которые указывают либо на MTD устройства (в случае эмулятора), либо на блочные устройства (в случае настоящего устройства), куда записаны соответствующие дисковые образы (system.img, userdata.img и cache.img). Я не уверен, но думаю, что внутри смартфона находится один единственный чип с flash-памятью, разделенный на partitions (тома), в каждый из которых записан соответствующий образ. Этот чип с flash-памятью — то, что мы знаем под именем Internal storage (внутренняя память), объем которой — один из основных параметров смартфона.
Следует заметить, что /system смонтирован read-only (только для чтения). Это означает, что содержимое данного раздела не изменяется в процессе работы устройства, а только когда вы, например, обновляете систему на вашем устройстве (используя системные обновления).