MTD: Memory Technology Device
This article introduces the MTD (Memory Technology Devices).
Brief Introduction
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 (FTL) inside, which makes them look like block devices. These devices are the subject of the Linux block subsystem, not MTD. 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 Architecture
The following figure shows the MTD architecture under Linux system:
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 include/linux/mtd/mtd.h outside of struct mtd_info . These methods include mtd_read(), mtd_write(), etc. The member flags in struct mtd_info takes the following values, refer to include/uapi/mtd/mtd-abi.h:
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 subsystem includes a set of tests which you may run to verify your flash hardware and drivers. The 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 git://git.infradead.org/users/ahunter/nand-tests.git
The MTD test-suite contains the following tests:
- mtd_speedtest: measures and reports read/write/erase speed of the MTD device.
- mtd_stresstest: performs random read/write/erase operations and validates the MTD device I/O capabilities.
- mtd_readtest: this tests reads whole 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.
- mtd_pagetest: 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.
- mtd_oobtest: relevant only for NAND flashes, tests that the OOB area I/O works properly by writing data to different offsets and verifying it.
- mtd_subpagetest: relevant only for NAND flashes, tests sub-page I/O.
- mtd_torturetest: 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! The test supports a number of options (see modinfo mtd_torturetest) which allow you to set the amount of eraseblocks to torture and how the torturing is done. You may limit the amount of torturing cycles using the cycles_count module parameter. 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.
- 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.
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.
mtd-utils
The MTD Utilities are a collection of tools that allow the user to interact with the MTD subsystem in the kernel to perform operations on Flash devices. The most commonly used utilities are:
| mtd-utils | Description |
|---|---|
| mtd_debug | Debug MTD |
| flash_info | Displays information about Flash devices |
| flashcp | Copies data into NOR flash |
| flash_erase | Erases an erase block of flash |
| flash_eraseall | Erases the entire flash device |
| flash_lock | Lock flash pages to prevent writing |
| flash_unlock | Unlock flash pages to allow writing |
| mkfs.jffs2 | Create a JFFS2 file system image from an existing file system |
| nandwrite | Write an input file (i.e. JFFS2 or YAFFS2 image) to the NAND Flash device |
These utilities are often used to write file system images to the Flash device on an embedded system.
Устройства Mtd в ноутбуке что это такое
В этой статье показано, как разработчики ядра и приложений (на C) могут использовать устройства MTD в Linux.
MTD (Memory Technology Devices) – это микросхемы флэш-памяти на основе NAND/NOR, которые используются для хранения энергонезависимых данных, таких как загрузочные образы и конфигурации. Предупреждаем читателей, чтобы их не путали с USB-накопителями, SD-картами и т. д., которые также называются флэш-устройствами, но не являются устройствами MTD. Последние обычно находятся на макетных платах, используются для хранения загрузчиков, ОС и т. д.
Несмотря на то, что устройства MTD предназначены для хранения данных, они отличаются от жестких дисков и оперативной памяти в нескольких аспектах. Самая большая разница заключается в том, что в то время как сектора жесткого диска являются перезаписываемыми, секторы устройства MTD должны быть стерты перед перезаписью, поэтому их чаще называют стирающими блоками. Во-вторых, сектора жесткого диска можно перезаписывать несколько раз, не изнашивая аппаратное обеспечение, но секторы устройства MTD имеют ограниченный срок службы и не могут быть использованы примерно после 10^3-10^5 операций стирания. Изношенные блоки стирания называются поврежденными блоками, и программное обеспечение должно следить за тем, чтобы такие блоки не использовались.
Как и жесткие диски, устройства MTD могут быть разбиты на разделы и, следовательно, могут работать как независимые устройства. В системе с одним или несколькими устройствами MTD информацию об устройствах и разделах можно получить из файла /proc/mtd. Типичный файл /proc/mtd выглядит следующим образом:
Разделенное устройство MTD можно изобразить, как показано на рисунке 1, на котором показано соотношение между устройством MTD, разделом и сектором.
Рисунок 1: Устройство MTD
Как уже было сказано, операции записи MTD отличаются от обычных устройств хранения. Поэтому, прежде чем двигаться дальше, давайте разберемся, как происходят операции записи на устройствах MTD. На рис. 2 показан типичный случай записи.
Рисунок 2: Операция записи MTD
Самая левая часть показывает сектор, в конце которого есть данные. Остальная часть сектора не записывалась с момента последнего стирания. Пользователь хочет записать «новые данные 1» в этот сектор по смещению 0. Поскольку эта часть сектора уже стерта, она готова к записи, поэтому «новые данные 1» могут быть записаны непосредственно в сектор. Позже пользователь может захотеть записать «новые данные 2» снова по смещению 0. Для этого сектор необходимо стереть. Так как сектор нужно стереть целиком, «старые данные» необходимо сохранить во временном буфере. После стирания всего сектора «новые данные 2» и «старые данные» должны быть записаны с соответствующими смещениями.
Эта процедура является причиной того, что существуют специальные файловые системы для устройств MTD, такие как JFFS2 и YAFFFS, и уровни флэш-трансляции (FTL), такие как NFTL, INFTL и т. д. Эти FTL и файловые системы уделяют особое внимание свойствам устройства MTD, чтобы скрыть сложность от пользователя.
В первом следующем разделе мы рассмотрим, как получать доступ, читать/записывать и стирать устройства MTD из приложений Linux. Второй раздел описывает то же самое в пространстве ядра, так что эта статья может быть полезна как разработчикам приложений, так и разработчикам ядра.
Доступ к MTD из приложений
Пользователь должен знать раздел устройства для работы, который можно найти в /proc/mtd, как показано ранее. Если пользователи хотят работать с разделом userdata, они должны использовать устройство /dev/mtd5.
Первое, что нужно сделать, это получить информацию об устройстве МПД. Используйте команду MEMGETINFO ioctl следующим образом:
Для краткости обработка ошибок опущена. Структура mtd_info_t используется с командой MEMGETINFO. Тип MTD может быть MTD_ABSENT, MTD_RAM, MTD_ROM, MTD_NAND, MTD_NOR и т. д., которые определены в заголовочном файле mtd/mtd-abi.h. mtd_info.size указывает размер всего устройства (т. е. раздела в данном случае). Наконец, mtd_info.erasesize указывает размер сектора. Во время операции стирания это минимальный размер, который можно стереть, как мы увидим позже.
Чтение устройств MTD аналогично обычным устройствам:
Операция записи может быть выполнена таким же образом, при условии, что сектор был предварительно стерт. Наконец, мы подошли к операции стирания. Вот пример стирания раздела по секторам:
После этой операции стирания все сектора устройства доступны для записи. Обратите внимание на использование MEMUNLOCK перед MEMERASE, что необходимо для разрешения операции стирания.
Доступ к MTD из пространства ядра
В этом разделе будут повторяться функции, описанные в предыдущем разделе, но в пространстве ядра.Для этого нужен отдельный раздел, так как операция стирания здесь более сложная — операция стирания может приостановить работу, и поэтому программист ядра должен дождаться завершения операции. Это относится и к приложениям, но о спящем режиме прозрачно заботится планировщик.
Как объяснялось ранее, первой информацией MTD является структура mtd_info. Это получается путем перебора всех зарегистрированных устройств MTD:
Приведенный выше модуль ядра ищет раздел «userdata». Функция get_mtd_device() при вызове с первым аргументом NULL возвращает устройство MTD, связанное с младшим номером, указанным во втором аргументе. При успешном поиске увеличивается счетчик ссылок устройства. Вот почему перед выходом необходимо вызвать функцию put_mtd_device() для сброса (уменьшения) счетчика ссылок.
Кроме того, модуль использует флаг MTD_ABSENT (который также доступен для приложений). Эта проверка необходима для правильной работы с некоторыми драйверами зондирующих устройств, используемыми для выделения замещающих устройств MTD в системах с сокетами или съемными носителями.
После извлечения структуры mtd_info чтение становится относительно простым:
Второй аргумент функции чтения указывает смещение чтения, а третий — длину для чтения. Обратите внимание, что операция чтения тоже может заснуть, и поэтому ее нельзя выполнять в контексте прерывания. Операция записи может быть выполнена следующим образом (при условии, что сектор был предварительно стерт):
Как упоминалось ранее, операции чтения, записи и стирания могут приостанавливаться. Поэтому код ядра должен дождаться завершения операции. Вот пример стирания раздела и ожидания завершения операции:
Функция erase_partition() выполняет итерацию по всем секторам и стирает их с помощью erase_sector() . В основе Erase_sector() лежит вызов mtd_info->erase, который (как упоминалось ранее) может спать. Таким образом, erase_sector() подготавливает очередь ожидания и заголовок очереди ожидания.
После вызова mtd_info->erase функция готовится освободить ЦП (предполагая, что mtd_info->erase перейдет в спящий режим), изменив состояние задачи на TASK_UNINTERRUPTIBLE и добавив себя в начало очереди ожидания. Перед освобождением ЦП он проверяет, выполнено ли стирание с помощью флага ei.state. Если стирание выполнено успешно, этот флаг будет установлен на MTD_ERASE_DONE .
Если операция стирания не завершена, задача освобождает ЦП, вызывая schedule() . Позже, когда операция стирания завершена, драйвер вызывает функцию обратного вызова, предоставленную в ei.callback. Здесь задача пробуждается сама по себе, затем удаляется из очереди ожидания, меняет состояние задачи на TASK_RUNNING и, наконец, возвращается функция erase_sector().
Устройства MTD имеют гораздо больше функций, которые могут использоваться разработчиками приложений. ECC (коды исправления ошибок) и OOB (внеполосные) данные являются одними из них. Фреймворк MTD интегрирован в ядро Linux — поэтому он очень упрощает работу с устройствами MTD, как мы видели в этой статье.
Недавно я имел удовольствие участвовать в вебинаре с Микелем Драгичи, главным инженером Zimperium, и Дж. Т. Китингом, нашим старшим вице-президентом по маркетингу, на котором мы говорили о различиях между защитой от мобильных угроз (MTD) и управлением мобильными устройствами. (МДМ).
Веб-семинар «Другая половина уравнения: почему агентства, заботящиеся о безопасности, объединяют UEM и MTD» на самом деле возник из-за путаницы, которую я наблюдал у некоторых организаций в государственном секторе относительно ролей и различий между MDM и MTD.
Чтобы просмотреть вебинар полностью, нажмите здесь .
На протяжении многих лет мы наблюдали равенство между тем, как используются ноутбуки/настольные компьютеры и мобильные устройства, и содержащейся в них информацией/данными. Однако в то время как подавляющее большинство ноутбуков и настольных компьютеров защищены предприятиями (вы бы вышли из офиса без какой-либо защиты на своем ноутбуке), этого нельзя сказать о мобильных устройствах.
Подобно диспетчеру конфигурации для ноутбуков и настольных компьютеров, предприятия могут использовать MDM для централизованного управления мобильными устройствами.
MDM — это инструмент управления. Он позволяет совместимым устройствам получать доступ к корпоративной электронной почте, приложениям через корпоративный магазин приложений и данным, а также защищает передачу данных между мобильным устройством и корпоративной сетью.
Решения MTD обнаруживают и предотвращают атаки на мобильные устройства, сети, фишинг и вредоносные приложения. В качестве примера этих типов угроз мы наблюдаем увеличение и всплеск мобильных взломов и взломов во время COVID. И мы не одиноки:
- Только за последнюю неделю Google ежедневно отслеживал более 18 миллионов вредоносных программ и фишинговых писем, связанных с мошенничеством в связи с COVID-19. Это помимо более чем 240 миллионов спам-сообщений, которые он видит ежедневно, связанных с новым коронавирусом; и
- Wall Street Journal предупредил о значительном росте числа схем фишинга, робоколлинга и «смишинга» (мошенничества с текстовыми сообщениями, отправляемыми на ваш телефон), включая проверки стимулов, возмещение расходов авиакомпаниями, благотворительность, штрафы за нарушение правил социального дистанцирования, «обязательные» действия. Тесты на готовность к COVID-19, недоказанные методы лечения и продажа востребованных товаров, таких как маски или термометры.
Управление MDM; МПД предотвращают и обнаруживают.
И Gartner, и Национальный институт стандартов и технологий (NIST) признают важность MTD для защиты конечных точек.
Вместе лучше
MITRE ATT&CK – это общедоступная база знаний о тактике и методах противников, основанная на реальных наблюдениях. База знаний ATT&CK используется в качестве основы для разработки конкретных моделей угроз и методологий в частном секторе, в правительстве, а также в сообществе продуктов и услуг кибербезопасности.
Сами по себе MDM не учитывают эти тактики и методы (опять же, MDM не предназначены для этого).
Вместе с МПД это гораздо лучшая защитная поза.
Подробнее
Чтобы просмотреть вебинар полностью, нажмите здесь . Если вы хотите узнать больше о реальных мобильных атаках и о том, что предприятия и агентства могут сделать, чтобы защитить себя, загрузите наш технический документ «Анатомия мобильных атак» . Чтобы узнать больше, свяжитесь с нами. Мы здесь, чтобы помочь.
Автор: Джим Ковач
Вице-президент по государственному сектору с более чем 20-летним опытом поддержки государственного сектора, включая министерство обороны федерального правительства, гражданские и разведывательные агентства, а также государственные и местные органы власти. Вне офиса я гуляю со своими щенками, наслаждаюсь активным отдыхом, раздражаю своих взрослых детей и провожу слишком много времени в магазине Lowe’s, занимаясь своими делами.
20 декабря 2021 г. Android
Защита ваших бизнес-данных — это не только защита ваших офисных компьютеров и сетей. Особенно сейчас, когда внедрение удаленных и гибридных рабочих сред имеет решающее значение для выживания бизнеса, вам необходимо установить цифровые барьеры вокруг мобильных устройств вашей компании, чтобы блокировать вредоносное ПО и другие угрозы. Вот как это сделать с помощью инструментов обнаружения мобильных угроз (MTD).
MTD и обнаружение вредоносных программ
Решения для обнаружения мобильных угроз предотвращают сетевые атаки и заражение вредоносным ПО на мобильных устройствах, таких как смартфоны, планшеты и ноутбуки. Поскольку большинство вредоносных программ искусно маскируются под легитимные приложения, ключом к их обнаружению и защите от них является распознавание нестандартных моделей поведения пользователей и функций устройств — в этом инструменты MTD превосходно справляются.
Применительно к бизнес-сетям решения MTD могут отслеживать сетевой трафик на наличие подозрительной активности, такой как недействительные или поддельные сертификаты, чтобы остановить атаки посредника. Это позволяет им реагировать на угрозы в режиме реального времени, предоставляя информацию об уровне риска для всех устройств, подключенных к сети.
MTD и машинное обучение
Все инструменты MTD поддерживаются механизмом машинного обучения, который позволяет им распознавать шаблоны использования и помечать любые отклонения в поведении. Решения MTD также очень масштабируемы и могут одновременно контролировать десятки мобильных устройств Android. Когда одно из этих устройств начинает работать не так, как остальные, машинное обучение помогает инструменту MTD регистрировать аномалии и уведомлять ИТ-администраторов.
Внедрение решения MTD
Интеграция решения MTD в вашу стратегию безопасности мобильных устройств требует тщательной оценки различных критических факторов, включая отраслевые нормы и конфиденциальность данных, которые хранятся и/или передаются на ваших мобильных устройствах. В идеале ваше решение MTD должно быть частью более широкой стратегии безопасности, позволяющей блокировать вредоносный сетевой трафик и укреплять общую кибербезопасность бизнеса.
Разработка надежной защиты для мобильных устройств быстро становится важным компонентом стратегий кибербезопасности многих компаний. И хотя обнаружение угроз для мобильных устройств остается несовершенным средством обнаружения вредоносных программ, оно гораздо более эффективно, чем традиционные решения для защиты от вредоносных программ.
Другие преимущества использования инструментов MTD
Развертывание решения MTD дает ряд преимуществ, необходимых для современных удаленных или гибридных рабочих сред. Во-первых, это дает компании уверенность в реализации политики использования собственных устройств.Мало того, что решение MTD способно предотвращать кибератаки до того, как они станут серьезными проблемами, оно также дает ИТ-администраторам критическое представление об уровне риска мобильных сотрудников компании. Более того, развертывание решений MTD упрощает соблюдение нормативных требований, поскольку гарантирует безопасность конфиденциальных данных организации независимо от того, где они хранятся.
Таким компаниям, как ваша, нужны комплексные решения для защиты от кибератак, будь то компьютеры, ноутбуки или смартфоны. Чтобы получить экспертные рекомендации по ИТ-безопасности, позвоните нашим специалистам сегодня.
pstore block (pstore/blk) – это регистратор ошибок/паники, который записывает свои журналы на блочное и неблоковое устройство до того, как произойдет сбой системы. Вы можете получить эти файлы журнала, смонтировав файловую систему pstore, например:
концепции блоков pstore¶
pstore/blk обеспечивает эффективный метод настройки pstore/blk, который делит все конфигурации на две части: конфигурации для пользователя и конфигурации для драйвера.
Конфигурации пользователя определяют, как работает pstore/blk, например pmsg_size, kmsg_size и т. д. Все они поддерживают как Kconfig, так и параметры модуля, но параметры модуля имеют приоритет над Kconfig.
Конфигурации драйвера касаются блочного и неблочного устройства, например общего размера блочного устройства и операций чтения/записи.
Конфигурации для пользователя¶
Все эти конфигурации поддерживают как параметры Kconfig, так и параметры модуля, но параметры модуля имеют приоритет над Kconfig.
Вот пример параметров модуля:
Подробности каждой конфигурации могут вас заинтересовать.
blkdev¶
Используемое блочное устройство. В большинстве случаев это раздел блочного устройства. Это необходимо для pstore/blk. Он также используется для устройства MTD.
Когда pstore/blk собирается как модуль, «blkdev» принимает следующие варианты:
/dev/ представляет номер устройства диска
/dev/ представляет номер устройства раздела — номер устройства диска плюс номер раздела
/dev/ p — то же, что и выше; эта форма используется, когда имя диска с разделами заканчивается цифрой.
Когда pstore/blk встроен в ядро, «blkdev» принимает следующие варианты:
номер устройства в шестнадцатеричном представлении без ведущего 0x, например, b302.
PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF представляет собой уникальный идентификатор раздела, если он указан в таблице разделов. UUID может быть UUID EFI/GPT или относиться к разделу MSDOS в формате SSSSSSSS-PP, где SSSSSSSS — это шестнадцатеричное представление 32-битной «подписи диска NT», заполненное нулями, а PP — это нулевое заполненное шестнадцатеричное представление номера раздела, основанного на 1.
PARTUUID= /PARTNROFF= для выбора раздела по отношению к разделу с известным уникальным идентификатором.
: старший и младший номер устройства, разделенные двоеточием.
Он принимает следующие варианты для устройства MTD:
Имя устройства MTD. рекомендуется «pstore».
Номер устройства MTD.
kmsg_size¶
Размер фрагмента в КБ для пользовательского интерфейса oops/panic. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал oops/panic.
Существует несколько фрагментов интерфейса oops/panic в зависимости от оставшегося места, за исключением других интерфейсов pstore.
pstore/blk будет записывать фрагменты oops/panic один за другим и всегда перезаписывать самый старый фрагмент, если больше нет свободного фрагмента.
pmsg_size¶
Размер фрагмента в КБ для внешнего интерфейса pmsg. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал pmsg.
В отличие от внешнего интерфейса oops/panic, для внешнего интерфейса pmsg существует только один фрагмент.
Pmsg — это объект pstore, доступный в пользовательском пространстве. Записи в /dev/pmsg0 добавляются к чанку. После перезагрузки содержимое доступно в /sys/fs/pstore/pmsg-pstore-blk-0.
размер_консоли¶
Размер фрагмента в КБ для внешнего интерфейса консоли. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал консоли.
Как и в интерфейсе pmsg, для интерфейса консоли существует только один фрагмент.
Все журналы консоли будут добавлены к чанку. После перезагрузки содержимое доступно в /sys/fs/pstore/console-pstore-blk-0.
ftrace_size¶
Размер фрагмента в КБ для внешнего интерфейса ftrace. Оно ДОЛЖНО быть кратно 4. Это необязательно, если вам не важен журнал консоли.
Как и в интерфейсе oops, интерфейс ftrace состоит из нескольких фрагментов в зависимости от количества процессоров. Размер каждого фрагмента равен ftrace_size/processors_count.
Все журналы ftrace будут добавлены к чанку. При перезагрузке содержимое объединяется и становится доступным в /sys/fs/pstore/ftrace-pstore-blk-0.
Постоянная трассировка функций может быть полезна для отладки программных или аппаратных зависаний. Вот пример использования:
max_reason¶
Ограничением того, какие типы дампов kmsg сохраняются, можно управлять с помощью значения max_reason, как определено в перечислении kmsg_dump_reason include/linux/kmsg_dump.h. Например, чтобы хранить и ошибки, и панику, для параметра max_reason должно быть установлено значение 2 (KMSG_DUMP_OOPS), для хранения только сообщений паники значение max_reason должно быть равно 1 (KMSG_DUMP_PANIC). Установка этого параметра в 0 (KMSG_DUMP_UNDEF) означает, что фильтрация причин будет контролироваться загрузочным параметром printk.always_kmsg_dump: если он не установлен, это будет KMSG_DUMP_OOPS, иначе KMSG_DUMP_MAX.
Конфигурации драйвера¶
Драйвер устройства использует register_pstore_device со структурой pstore_device_info для регистрации в pstore/blk.
int register_pstore_device ( struct pstore_device_info *dev ) ¶
зарегистрировать неблокируемое устройство в pstore/blk
структура pstore_device_info *dev
неблокировать информацию об устройстве
отменить регистрацию неблокирующего устройства в pstore/blk
структура pstore_device_info *dev
неблокировать информацию об устройстве
Сжатие и заголовок¶
Блочное устройство достаточно большое для несжатых данных oops. На самом деле мы не рекомендуем сжатие данных, потому что pstore/blk вставит некоторую информацию в первую строку данных oops/panic. Например:
Это означает, что это OOPS|Panic в 16-й раз с момента первой загрузки. Иногда количество появлений oops|panic с момента первой загрузки важно для оценки стабильности системы.
Следующая строка вставляется файловой системой pstore. Например:
Это означает, что это OOPS во второй раз при последней загрузке.
Чтение данных¶
Данные дампа можно прочитать из файловой системы pstore. Формат этих файлов: dmesg-pstore-blk-[N] для интерфейса oops/panic, pmsg-pstore-blk-0 для интерфейса pmsg и так далее. Временная метка файла дампа записывает время срабатывания. Чтобы удалить сохраненную запись с блочного устройства, просто отсоедините соответствующий файл pstore.
Внимание в API чтения/записи паники¶
В случае паники ядро не будет работать намного дольше, задачи не будут запланированы, и большая часть ресурсов ядра не будет работать. Это похоже на однопоточную программу, работающую на одноядерном компьютере.
Следующие моменты требуют особого внимания при работе с API чтения/записи при панике:
Нельзя выделять память. Если вам нужна память, просто выделите ее во время инициализации драйвера блока, а не дожидаясь паники.
Должен быть опрошен, а НЕ управляем прерыванием. Расписания задач больше нет. Драйвер блока должен задержаться, чтобы гарантировать успешную запись, но НЕ переходить в спящий режим.
Нельзя взять любой замок. Нет ни другой задачи, ни общего ресурса; вы можете сломать все замки.
Просто используйте ЦП для передачи. Не используйте DMA для передачи, если вы не уверены, что DMA не сохранит блокировку.
Регистры управления напрямую. Пожалуйста, управляйте регистрами напрямую, а не используйте ресурсы ядра Linux. Сопоставьте ввод-вывод во время инициализации, а не ждите, пока не произойдет паника.
При необходимости перезагрузите блочное устройство и контроллер. Если вы не уверены в состоянии вашего блочного устройства и контроллера при возникновении паники, вы можете безопасно остановить и сбросить их.
pstore/blk поддерживает функцию psblk_blkdev_info(), определенную в linux/pstore_blk.h, для получения информации об использовании блочного устройства, такой как номер устройства, количество секторов и начальный сектор всего диск.
Внутреннее устройство блока pstore¶
Для разработчиков здесь приведены все важные структуры и API:
заголовок зоны для сброса в хранилище
подпись для указания заголовка (значение типа PSZ_SIG xor PSZONE)
длина данных в данных
смещение в данные, где начинается начало сохраненных байтов
Заголовок дампа kmsg для сброса в хранилище
магическое число для заголовка дампа kmsg
время срабатывания дампа kmsg
счетчик дампа kmsg
причина дампа kmsg (например, oops, паника и т. д.)
указатель на данные журнала
Это подзаголовок дампа kmsg после psz_buffer .
один сохраненный буфер
смещение зоны хранилища
имя внешнего интерфейса для этой зоны
тип внешнего интерфейса для этой зоны
указатель на буфер данных, управляемый этой зоной
указатель на старый буфер данных
байт в буфере->данные
должна ли эта зона восстанавливаться из хранилища
являются ли данные в буфере грязными
структура зоны в памяти.
все о рабочем состоянии pstore/zone
зоны хранения дампа kmsg
зона хранения pmsg
зона хранения консоли
зоны хранения ftrace
максимальное количество kpsz
счетчик общего количества прочитанных дампов kmsg
счетчик общего количества записей дампа kmsg
счетчик общего количества прочитанных pmsg зоны
счетчик общего количества прочитанных зон консоли
максимальное количество кадров в секунду
счетчик максимальной зоны чтения ftrace
счетчик дампов oops
счетчик панических дампов
не закончилось ли восстановление данных из хранилища
происходит ли паника
привязать к pstore_zone_info
информация из бэкенда
режим сброса для psz_zone_write()
не сбрасывать в хранилище, а обновлять данные в памяти
просто сбросить часть данных, включая метаданные, в хранилище
просто сбросьте метаданные зоны в хранилище
очистить всю зону
int psz_recovery ( struct psz_context *cxt ) ¶
восстановить данные из хранилища
структура psz_context *cxt
восстановление означает чтение данных из хранилища после перезагрузки
0 в случае успеха, остальные в случае неудачи.
Структура внутреннего драйвера pstore/zone
Модуль, отвечающий за этот внутренний драйвер.
Имя внутреннего драйвера.
Общий размер в байтах, который может использовать pstore/zone. Оно должно быть больше 4096 и быть кратным 4096.
Размер зоны паники. Ноль означает отключено, в противном случае он должен быть кратен SECTOR_SIZE (512 байт).
Максимальная причина сохранения дампа kmsg.
Размер зоны pmsg совпадает с kmsg_size.
Размер зоны консоли, который совпадает с kmsg_size.
Размер зоны ftrace равен kmsg_size.
Общая операция чтения. Оба параметра функции, размер и смещение, относятся к объему хранилища. В случае успеха должно быть возвращено количество байтов, остальные означают ошибку.
То же, что и чтение, но со следующим номером ошибки: -EBUSY означает попытку записи позже. -ENOMSG означает попробовать следующую зону.
Общая операция стирания для устройства со специальным заданием удаления. Оба параметра функции, размер и смещение, относятся к объему хранилища. Возвращает 0 в случае успеха и другие значения в случае неудачи.
Операция записи используется только в случае паники. Это необязательно, если вас не волнует журнал паники. Параметры имеют относительное значение для хранилища. В случае успеха должно быть возвращено количество байтов, другие, за исключением -ENOMSG, означают ошибку. -ENOMSG означает попробовать следующую зону.
что такое mtd устройства в ноутбуке
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).
Создание политики соответствия для устройств Mobile Threat Defense (MTD) в Intune
Intune с MTD помогает обнаруживать угрозы и оценивать риск на мобильных устройствах. Можно создать правило Intune для политики соответствия требованиям, которое будет оценивать риски для определения соответствия устройства. Затем можно использовать политику условного доступа, чтобы запретить доступ к службам в зависимости от соответствия устройства требованиям.
Эти сведения относятся ко всем партнерам Mobile Threat Defense.
Подготовка к работе
В рамках настройки MTD в партнерской консоли MTD вы создали политику, которая разделяет различные угрозы по уровням (высокий, средний, низкий). В политике соответствия устройств Intune затем задайте уровень Mobile Threat Defense.
Необходимые условия для политики соответствия устройств с MTD:
Создание политики соответствия устройств MTD
Выберите Безопасность конечной точки > Соответствие устройства > Создать политику.
Выберите Платформа, а затем — Создать.
В разделе Базовые укажите имя и описание для политики соответствия устройств (необязательно). Нажмите кнопку Далее, чтобы продолжить.
В разделе Параметры соответствия разверните и настройте параметр Работоспособность устройств. Выберите уровень угрозы для мобильного устройства в раскрывающемся списке в разделе Требовать уровень угрозы на устройстве не больше указанного.
Защищено. Этот уровень обеспечивает максимальную защиту. Устройство не может осуществлять доступ к ресурсам компании при наличии каких-либо угроз. При обнаружении любых угроз устройство переходит в состояние несоответствия.
Низкий. Если все обнаруженные на устройстве угрозы имеют низкий уровень, считается, что устройство соответствует требованиям. Любая угроза с уровнем выше низкого переводит устройство в состояние несоответствия.
Средняя. Если обнаруженные на устройстве угрозы имеют низкий или средний уровень, считается, что устройство соответствует требованиям. Если на устройстве найдены угрозы высокого уровня, устройство переходит в состояние несоответствия.
Высокая. Это наименее безопасный уровень угрозы, допускающий все уровни угроз, а Mobile Threat Defense используется только для отчетов. На устройствах приложение MTD должно быть активировано с этим параметром.
Выберите Далее, чтобы перейти к разделу Назначения. Выберите группы, которые получат этот профиль. Дополнительные сведения о назначении профилей см. в статье Назначение профилей пользователей и устройств.
Выберите Далее.
На странице Проверка и создание после завершения нажмите Создать. Выбрав тип политики для созданного профиля, вы увидите новый профиль в списке.
При создании политик условного доступа для Microsoft 365 и других служб такая оценка соответствия устройства принимается во внимание и доступ несоответствующих устройств к ресурсам организации блокируется до устранения угрозы на устройстве и передаче сведений о ней в Intune через выбранного поставщика MTD.
Назначение политики соответствия устройств MTD
Чтобы назначить или изменить назначение политики соответствия устройств пользователям, выполните следующие действия:
Выберите Безопасность конечной точки > Соответствие устройства.
Выберите политику, которую необходимо назначить пользователям, и щелкните Свойства.
Выберите Изменить в разделе «Назначения», а затем используйте доступные параметры для включения и исключения групп, чтобы получить эту политику.
Выберите Просмотреть и сохранить, чтобы завершить назначение. При сохранении назначения политика развертывается для выбранных пользователей, и их устройства оцениваются на соответствие.
Mtd устройства в ноутбуке что это
A Memory Technology Device (MTD) is a type of device file in Linux for interacting with flash memory. The MTD subsystem was created to provide an abstraction layer between the hardware-specific device drivers and higher-level applications. Although character and block device files already existed, their semantics don’t map well to the way that flash memory devices operate.
USB sticks, MMCs, SDs, CompactFlashes and other popular removable devices should not be confused with MTDs. Although they contain flash memory, this is h >[1]
When using an MTD, the use of an MTD aware file system such as JFFS2 or YAFFS is recommended. The MTD subsystem exports block devices as well, which allows the use of common filesystem like ext4. However, using an MTD this way is not recommended since there is neither detection of bad blocks nor any kind of wear leveling.
Одна из частых проблем при подключении Android телефона или планшета к компьютеру или ноутбуку по USB — сообщение об ошибке при установке драйвера: Возникла проблема в процессе установки программного обеспечения для этого устройства. Система Windows обнаружила драйверы для этого устройства, но при попытке установки этих драйверов произошла ошибка — Неправильная секция установки службы в этом INF-файле.
В этой инструкции — подробно о том, как исправить эту ошибку, установить необходимый драйвер MTP и сделать так, чтобы телефон был виден по USB в Windows 10, 8 и Windows 7.
Основная причина ошибки «Неправильная секция установки службы в этом INF-файле» при подключении телефона (планшета) и как её исправить
Чаще всего причиной того, что при установке драйвера MTP возникает ошибка является то, что среди имеющихся в Windows драйверов (а в системе может присутствовать несколько совместимых драйверов) автоматически выбирается не тот, что нужен.
Это очень просто исправить, шаги будут следующими
Драйвер должен будет установиться без проблем (в большинстве случаев) а сообщение о неправильной секции установки в этом INF-файле не должно будет вас побеспокоить. Не забудьте, что на самом телефоне или планшете должен быть включен режим подключения «Медиаустройство (MTP)», который переключается при нажатии по уведомлению о USB-подключении в области уведомлений.
В редких случаях вашему устройству может быть нужен какой-то специфичный драйвер MTP (который Windows не может найти сама), тогда, как правило, его достаточно скачать с официального сайта производителя устройства и установить примерно тем же способом, что описан выше, но на 3-м шаге указать путь к папке с распакованными файлами драйвера и нажать «Далее».
Intune с MTD помогает обнаруживать угрозы и оценивать риск на мобильных устройствах. Intune with MTD helps you detect threats and assess risk on mobile devices. Можно создать правило Intune для политики соответствия требованиям, которое будет оценивать риски для определения соответствия устройства. You can create an Intune device compliance policy rule that assesses risk to determine if the device is compliant or not. Затем можно использовать политику условного доступа, чтобы запретить доступ к службам в зависимости от соответствия устройства требованиям. You can then use a Conditional Access policy to block access to services based on device compliance.
Эти сведения относятся ко всем партнерам Mobile Threat Defense. This information applies to all Mobile Threat Defense partners.
Подготовка к работе Before you begin
В рамках настройки MTD в партнерской консоли MTD вы создали политику, которая разделяет различные угрозы по уровням (высокий, средний, низкий). As part of the MTD setup, in the MTD partner console, you created a policy that classifies various threats as high, medium, and low. В политике соответствия устройств Intune нужно задать уровень Mobile Threat Defense. You now need to set the Mobile Threat Defense level in the Intune device compliance policy.
Необходимые условия для политики соответствия устройств с MTD: Prerequisites for device compliance policy with MTD:
Создание политики соответствия устройств MTD To create an MTD device compliance policy
Щелкните Устройство > Политики соответствия > Создать политику. Select Device > Compliance policies > Create policy.
Укажите для политики соответствия устройств имя, описание, выберите платформуи щелкните Настроить в разделе Параметры. Specify a device compliance policy Name, Description, select the Platform, then select Configure under the Settings section.
На панели Политика соответствия выберите Работоспособность устройств. On the compliance policy pane, choose Device Health.
На панели Работоспособность устройств выберите уровень угрозы для мобильного устройства в раскрывающемся списке в разделе Требовать уровень угрозы на устройстве не больше указанного. On the Device Health pane, choose the Mobile Threat Level from the drop-down list for Require the device to be at or under the Device Threat Level.
Защищено. Этот уровень обеспечивает максимальную защиту. Secured: This level is the most secure. Устройство не может осуществлять доступ к ресурсам компании при наличии каких-либо угроз. The device cannot have any threats present and still access company resources. При обнаружении любых угроз устройство переходит в состояние несоответствия. If any threats are found, the device is evaluated as noncompliant.
Низкий. Если все обнаруженные на устройстве угрозы имеют низкий уровень, считается, что устройство соответствует требованиям. Low: The device is compliant if only low-level threats are present. Любая угроза с уровнем выше низкого переводит устройство в состояние несоответствия. Anything higher puts the device in a noncompliant status.
Средний. Если обнаруженные на устройстве угрозы имеют низкий или средний уровень, считается, что устройство соответствует требованиям. Medium: The device is compliant if the threats found on the device are low or medium level. Если на устройстве найдены угрозы высокого уровня, устройство переходит в состояние несоответствия. If high-level threats are detected, the device is determined as noncompliant.
Высокий. Этот уровень наименее безопасный. High: This level is the least secure. При нем допустимы все уровни угроз, а Mobile Threat Defense используется только для отчетов. This allows all threat levels, and uses Mobile Threat Defense for reporting purposes only. На устройствах приложение MTD должно быть активировано с этим параметром. Devices are required to have the MTD app activated with this setting.
Щелкните ОК дважды, а затем выберите Создать, чтобы создать политику. Select OK twice, then select Create to create the policy.
При создании политик условного доступа для Office 365 и других служб такая оценка соответствия устройства принимается во внимание, и доступ несоответствующих устройств к ресурсам организации блокируется до устранения угрозы на устройстве. If you create Conditional Access policies for Office 365 or other services, the device compliance evaluation is assessed and noncompliant devices are blocked from accessing corporate resources until the threat is resolved in the device.
Назначение политики соответствия устройств MTD To assign an MTD device compliance policy
Чтобы назначить политику соответствия устройств пользователям, сделайте следующее: To assign a device compliance policy to users:
Щелкните Устройства > Политики соответствия. Select Device > Compliance policies.
Выберите политику, которую необходимо назначить пользователям, и щелкните Назначения. Select the policy you want to assign to users, and then select Assignments. Используйте доступные параметры для включения и исключения групп, чтобы получить эту политику. Use the available options to Include and Exclude groups to receive this policy.
Щелкните «Сохранить», чтобы завершить назначение. Select Save to complete the assignment. При сохранении назначения политика развертывается для выбранных пользователей, и их устройства оцениваются на соответствие. When you save the assignment, the policy deploys to your selected users and their devices are evaluated for compliance.
4.2 MTD — Технологическое Устройство Памяти
MTD означает Memory Technology Device, Технологическое Устройство Памяти, и является подсистемой, используемой для управления устройствами хранения данных, находящихся на плате. Является ли MTD отдельным классом набора драйверов, как символьные или блочные? Простой ответ: нет. Тогда в чём заключается работа MTD и когда и как устройства флеш-памяти включаются в подсистему MTD? Как на MTD устройство будут помещаться файловые системы? На эти вопросы отвечают следующие подразделы.
61 Разработка и внедрение системы на встраиваемом Linux
4.2.1 Модель MTD
Хотя устройства флеш-памяти являются устройствами хранения, похожими на жёсткие диски, между ними существуют некоторые фундаментальные различия.
Обычно жёсткие диски имеют сектор, который делится по размерам страницы (обычно 4096 байт). Стандартным значением является 512 байт. Модель файловой системы Linux, особенно буфер кэша (кэш памяти между файловой системой и уровнем блочного устройства), основана на этом предположении. Микросхемы флеш-памяти, с другой стороны, имеют большие размеры сектора; стандартный размер составляет 64 Кб.
Секторы флеш-памяти обычно перед записью в них должны быть стёрты; операции записи и стирания могут быть независимыми, что зависит от программного обеспечения, использующего флэш-память.
Микросхемы флеш-памяти имеют ограниченный срок службы, который определяется в терминах числа раз стирания сектора. Так что если какой-то сектор становится записываемым очень часто, его срок службы уменьшается. Чтобы предотвратить это, записи на флеш-память должны быть распределены по всем секторам. Это называется выравниванием износа и не поддерживается блочными устройствами.
Обычные файловые системы не могут быть использованы поверх флеш-памяти, потому что это проходит через буферный кэш. Обычный дисковый ввод-вывод медленный; чтобы ускорить его, используется кэш в памяти, называемой кэш-буфером, который хранит данные для ввода-вывода на диск. Пока эти данные не записаны обратно на диск, файловая система находится в неустойчивом состоянии. (Это и является причиной, почему вы должны выключать ОС на ПК перед выключением его питания.) Тем не менее, встроенные системы могут быть выключены без надлежащего завершения работы и всё же иметь непротиворечивые данные; так что обычные файловые системы и модель блочного устройства не очень подходят для встраиваемых систем.
Традиционным методом, используемым для доступа к флеш-памяти, является FTL, то есть Flash Translation Layer, Уровень Трансляции Флеш-памяти. Этот уровень эмулирует на флеш-памяти поведение блочного устройства, чтобы обеспечить на них работу обычных файловых систем. Однако, создание новой файловой системы или нового драйвера флешпамяти, работающего с FTL, является сложной задачей и это является причиной изобретения подсистемы MTD. (Владельцем подсистемы MTD является Дэвид Вудхаус, а разработки, связанные с MTD, можно получить на веб-сайте http://www.linuxmtd.infradead.org/ . Подсистема MTD была создана как часть основного ядра версии 2.4.) Решение MTD вышеуказанных проблем простое: рассматривать устройства памяти как устройства памяти, а не как диски. Поэтому вместо изменения низкоуровневых драйверов или введения уровня трансляции, измените приложение, чтобы использовать устройства памяти такими, как они есть. MTD очень привязано к приложениям; подсистема MTD состоит из двух частей: драйверы и приложения.
Подсистема MTD не реализует новый вид драйвера, но скорее она связывает любое устройство с драйверами символьных и блочных устройств. Когда драйвер зарегистрирован в подсистеме MTD, она экспортирует такое устройство в оба этих вида драйверов. Почему это делается именно так? Символьное устройство может позволить непосредственный доступ к устройству памяти с использованием стандартных вызовов open/read/write/ ioctl . Но в случае, если вы захотите смонтировать обычную файловую систему на такое устройство памяти с помощью традиционного метода, вы сможете также смонтировать её используя блочный драйвер.
Глава 4, Хранение данных во встраиваемых системах
Мы разберёмся с каждым уровнем на Рисунке 4.1, но перед этим давайте разберёмся с двумя устройствами, которые в настоящее время поддерживаются MTD: микросхемы флешпамяти и флеш-диски.
4.2.2 Микросхемы флеш-памяти
Рассмотрим различные микросхемы флеш-памяти, поддерживаемые подсистемой MTD. Устройства флеш-памяти поставляются в двух вариантах: NAND и NOR флеш-память. Хотя оба варианта созданы примерно в одно время (NOR была представлена Intel, а NAND — Toshiba в конце 1980 года), NOR быстрее вошла в мир встраиваемых устройств, поскольку она проще в использовании. Однако, когда встраиваемые системы эволюционировали к необходимости иметь больше места для хранения (например, медиаплееры и цифровые камеры), для приложений хранения данных стала популярной NAND Flash. Уровень MTD также первоначально развивался вокруг NOR Flash, а поддержка NAND была добавлена позднее. Таблица 4.1 сравнивает два этих типа флеш-памяти.