Как проверить emmc на ошибки

CNXSoft: Это пост от гостей Марселя Зисвилера (Marcel Ziswiler), менеджер платформы Embedded Linux, Toradex и Леонардо Грабоски Вейга (Leonardo Graboski Veiga), инженера по техническому маркетингу, Toradex, связанные с предстоящим докладом Марселя на тему «Оценка износа устройств с флэш-памятью eMMC» на конференции Embedded Linux 2019 года позже этот месяц.

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

Рисунок 1. от флэш-накопителей и SD-карт до SSD и интегральных микросхем, флэш-память является частью нашей повседневной жизни.

Как показано на рисунке 1, флеш-память везде в нашей повседневной жизни — от устройств, специально предназначенных для хранения данных, таких как флэш-накопители, SD-карты и жесткие диски SSD, до бытовой электроники, в которой используется флэш-память внутри, например смартфоны, модемы Wi-Fi и умные лампочки.

Знаковым противоположным примером является первая модель iPod, выпущенная в 2001 году. В ней использовался вращающийся жесткий диск для обеспечения высокой емкости хранения (для его времени — 5 или 10 ГБ). Однако, исследование показало, что частота отказов моделей с жестким диском была больше 20%, для сравнения, у моделей, оснащенных флэш-памятью она менее 10%. Из-за чувствительных движущихся частей, которые они содержат, вращающиеся диски не очень хорошо справляются с механическими ударами. Это играет значительную роль в частоте отказов портативных устройств, оснащенных магнитным накопителем.

Рисунок 2: Оригинальный iPod, выпущенный в 2001 году, является редким примером мобильного устройства с магнитным накопителем.

Когда речь идет о встраиваемых системах, флэш-память является предпочтительной энергонезависимой памятью. Во встраиваемых системах Linux распространенной практикой является использование интегральных микросхем (IC) в системах-на-модуле (SoM) и одноплатных компьютерах (SBC), поскольку они более устойчивы к повреждению данных, чем некоторые модели карт MicroSD. Они также более устойчивы, когда вибрация окружающей среды является решающим фактором. К примерам SoM, использующим встраиваемую флэш-память, относятся семейства Apalis и Colibri от Toradex. На рисунке 3 представлено увеличенное изображение модуля Colibri iMX8X, оснащенного eMMC от Micron:

Рисунок 3: Colibri iMX8X оснащен флэш-памятью eMMC от Micron.

Цель этой статьи — представить обзор того, как проектировать более надежные встраиваемые системы, используя преимущества как открытого, так и закрытого программного обеспечения для измерения и оценки износа eMMC. Это обусловлено (например) постоянно растущей потребностью в IoT-шлюзах и регистраторах данных, а также желанием хранить избыточные данные локально для повышения надежности или прерывистого соединения.  Из практических деталей реализации, SoM Toradex, оснащенные eMMC Micron, используются для иллюстрации того, как инструмент Flash Analytics — решение для мониторинга и оценки износа — может быть воплощен в жизнь.

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

Обзор технологии

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

В этой статье представлены только основы понимания износа, в Интернете доступно большое количество литературы по флэш-памяти. Например, у Toradex есть блог, архив вебинаров и ряд статей на веб-сайте разработчиков. Статья Википедии о флэш-памяти также содержит более ста ссылок на другие ресурсы.

NOR и NAND

Флэш-память — это широкий термин, и существует несколько комбинаций технологий, которые вместе образуют конечные флэш-продукты с определенными характеристиками. Первоначальное различие кроется в разделении флэш-памяти на два типа: NOR и NAND. Они названы по имени технологий, работающих на уровне транзисторов для хранения битов, напоминающих логические элементы NOR и NAND.

NOR имеет более простые принципы работы и более высокую надежность, но часто требуется более высокое число выводов и имеется более низкая плотность хранения на единицу площади кремния, чем NAND, что влияет на размер и стоимость. По этим причинам NOR часто используется только в определенных приложениях, которые считаются критическими даже для высоконадежных встраиваемых систем промышленного уровня. Вы можете узнать больше об этой теме в NOR | / NAND Flash Guide от Micron (PDF). На рисунке 4, взятом из руководства, упомянутого в этом параграфе, представлена сводка технологий NOR и NAND в контексте плотности и емкости хранилища:

Рисунок 4: Предложения NOR и NAND по плотности и емкости. (источник: Micron NOR / NAND Flash Guide)

Как видите, Micron eMMC — это исключительно устройства NAND в диапазонах MLC и TLC, которые мы обсудим более подробно. Поскольку SoM Toradex используют eMMC в диапазоне от 4 ГБ до 16 ГБ, мы можем сделать вывод, что они используют устройства MLC. Это также будет рассмотрено далее в этой статье.

Структура NAND

Флэш-устройство raw NAND можно разбить на три отдельные части.

  • Ячейка : самый маленький объект. Ячейка хранит данные на уровне битов и не может быть напрямую адресуемым устройством, управляющим хранилищем NAND.
  • Страница : Наименьший массив ячеек, которые можно адресовать для операций чтения и программирования. Программная операция состоит из «переворачивания» битов от значения 1 до значения 0. Размеры страниц находятся в диапазоне килобайт; например, 4 КБ.
  • Блок : наименьший массив страниц, который можно адресовать для операций удаления. Блок также известен как стираемый блок в некоторых контекстах, таких как стек MTD Linux. Операция удаления состоит из возврата битов со значения от 0 до значения 1. Размеры блоков находятся в мегабайтах; например, 4 МБ. Операции стирания выполняются намного медленнее, чем операции программирования или чтения, выполняемые на страницах.
    • Операции удаления стирают флэш-память с течением времени.
    • Когда блок больше не может использоваться для хранения данных, он помечается как плохой .

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

Рисунок 5: Диаграмма высокого уровня raw NAND флэш-кристалла.

NAND SLC и MLC

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

  • SLC : одноуровневая ячейка, хранит 1 бит на ячейку
    • pSLC : MLC, работающий в режиме SLC, сохраняет 1 бит на ячейку
  • MLC : многоуровневая ячейка, хранит 2 бита на ячейку
  • TLC : трехуровневая ячейка, хранит 3 бита на ячейку
  • QLC : четырехъярусная ячейка, хранит 4 бита на ячейку

Существует компромисс между плотностью и стоимостью в сравнении с надежностью и сроком службы, как показано в таблице 1.

NAND Cell Technology

Плотность (бит на ячейку)

Стоимость

Надежность

Срок жизни

SLC

1

Наибольший

Наибольший

Наибольший

pSLC

1

Средний

Высоко

Высоко

MLC

2

Средний

Высоко

Средний

ТСХ

3

Низкий

Низкий

Низкий

QLC

4

низший

низший

низший

Таблица 1: Сравнение клеточных технологий NAND

Рисунок 6 помогает визуализировать, как SLC и MLC хранят биты:

Рисунок 6: Пороги напряжения SLC и MLC

PSLC («pseudo-SLC») повышает скорость работы и срок службы устройства MLC за счет уменьшения его емкости вдвое. Срок службы не соответствует настоящему SLC, но он значительно увеличен. Pseudo-SLC не следует путать с быстрым режимом, который ускоряет работу устройства MLC, но не увеличивает его срок службы:

Рисунок 7: Pseudo-SLC и быстрый режим

Понимание того, настроены ли блоки как MLC или pSLC, важно для определения срока службы устройства, так как мы собираем количество поврежденных блоков с течением времени.

Для eMMC, в котором используется технология MLC, в зависимости от ширины трассировки кремния, блок длится в среднем от 3000 до 10000 циклов стирания. Время жизни для pSLC увеличивается более чем в 2 раза по сравнению с MLC; поэтому pSLC предпочтительнее быстрого режима или избыточного выделения ресурсов (т. е. использование флэш-памяти с удвоенной емкостью, чтобы она работала вдвое дольше). Может быть трудно найти количество циклов стирания и значения ширины трассировки в общедоступной документации производителей, поэтому бенчмаркинг самих устройств может быть решением.

ECC

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

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

Усиление Записи

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

Выравнивание износа и сбор мусора

Если всегда использовать одни и те же физические страницы и блоки, например, при обновлении файла, эти блоки будут преждевременно изнашиваться. В худшем случае система может даже перестать работать задолго до окончания срока службы флэш-памяти (EOL), если контроллер NAND не перемещает данные, поскольку эти блоки становятся неисправными.

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

  • Динамический : перемещаются только данные, которые являются динамическими (то есть обновляются с течением времени). Статические данные хранятся в блоках, в которые они были первоначально записаны. Этот алгоритм проще, но не использует всю емкость устройства хранения. Лучше всего использовать, когда только небольшой процент флэш-памяти содержит статические данные.
  • Статический : Этот алгоритм целенаправленно перемещает статические данные, равномерно распределяя все блоки флэш-памяти. Это более сложный алгоритм, но он продлевает срок службы устройства хранения, используя всю доступную флэш-память.

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

На рисунке 8 показано, как алгоритмы управления raw NAND вместе можно рассматривать как контроллер, который отображает физические блоки стирания (PEB) в логические блоки стирания (LEB) и абстрагирует специфичные для NAND операции в простые операции «чтения» и «записи»:

Рисунок 8. Операции raw NAND абстрагируются через контроллер.

Когда чип raw NAND подключен к системе, которая пытается реализовать «dumb» контроллер для простого преобразования операций программы NAND, чтения и стирания в операции чтения и записи, подобные жесткому диску, это серьезно влияет на производительность и срок службы флэш-памяти. Это одна из причин, по которой подсистема MTD Linux почти всегда используется файловыми системами, которые осведомлены о особенностях raw NAND — и, возможно, промежуточным слоем, в случае UBI и UBIFS — вместо файловых систем, которые обращаются к блочным устройствам.

Если вы хотите узнать больше о выравнивании износа, ознакомьтесь с документом Micron TN-29-42: Методы выравнивания износа и износа в устройствах NAND Flash (PDF) и статьей в Википедии «Выравнивание износа»  (а также с ее ссылками, включая некоторые статьи LWN.net). Для получения информации о сборке мусора прочтите «Micron TN-2960: Сборка мусора в одноуровневой ячейке NAND Flash Memory» (PDF).

Чтобы лучше понять полную реализацию уровней абстракции между устройством raw NAND и программой в деталях, вы можете прочитать исчерпывающую документацию по MTD , UBI и UBIFS. Конечно, чтобы узнать особенности реализации, вы также можете взглянуть на исходный код ядра Linux.

Несмотря на всю сложность операций raw NAND, которые мы, тем не менее, должны знать в некоторой степени для создания моделей оценки износа, простой способ абстрагироваться от этой сложности — купить устройство NAND со встроенным контроллером, также называемое управляемым NAND. Что касается интегральных схем, распространенные типы включают в себя встроенный USB, eMMC и UFS. Здесь мы сосредоточимся на eMMC.

Детальный взгляд на eMMC Flash

Одной из самых популярных высокопроизводительных флэш-технологий, используемых во встраиваемых промышленных системах, является eMMC ( Embedded MultiMediaCard), которая состоит из матрицы NAND, обычно MLC или TLC, и сопровождающего ее контроллера NAND. Он абстрагирует большую часть стека управляющего программного обеспечения от базовой операционной системы. Стандарт eMMC поддерживается JEDEC, и его база доступна бесплатно после регистрации. Последним стандартом, опубликованным до написания этой статьи, является Embedded MultiMedia Card Electrical Standard 5.1 (можно скачать PDF-файл после регистрации)

Поскольку контроллер обеспечивает высококачественный уровень абстракции (при условии, что он исходит от надежного производителя), можно безопасно использовать файловую систему, которая осведомлена о работе блочных устройств, если принять некоторые меры предосторожности. В BSP Toradex Embedded Linux используется файловая система EXT4 по умолчанию для компьютеров на модулях с флэш-памятью eMMC. Рисунок 9 суммирует различия между raw NAND и управляемым NAND относительно контроллера:

Рисунок 9: Raw NAND и контроллер eMMC.

В примерах, приведенных в этой статье, мы рассматриваем 4 ГБ MLC eMMC с 1024 блоками, которые в реальном мире могут быть (например, Micron MTFC4GACAJCN-1M-WT, использовавшимися в последней редакции Apalis iMX6Q 1 ГБ SoM). Мы также предполагаем, что средняя продолжительность жизни блока составляет 3000 циклов стирания, что является лишь обоснованным предположением. Оно не был взято из таблицы данных вышеупомянутого номера детали.

Проблемы использования eMMC заключаются в сборе сведений о реализации контроллера и сроке службы модуля, которые могут быть или не быть общедоступными. Кроме того, кто-то может предпочесть выбрать производителя, который предоставляет хороший собственный отчет о состоянии работоспособности. Стандарт eMMC резервирует некоторые регистры для этой цели, но их использование не является обязательным. У eMMC, выбранной для данного примера, есть подробный отчет о работоспособности, а подробную информацию о нем можно получить из TN-FC-32 Micron: Отчет о работоспособности устройства e.MMC, доступный после регистрации, в разделе программного обеспечения e.MMC на веб-сайте Micron. В этом разделе веб-сайта Micron вы также можете найти инструмент emmcparm, который будет использоваться позже в этой статье, и полезную TN-FC-25: Общие сведения о поддержке драйверов Linux для e.MMC.

Команды и регистры

Стандарт eMMC определяет работу через шину, которая содержит линии электропитания, линии CMD, DAT0-7 и CLK.

CMD — это последовательный канал, и разные значения CMD представляют разные операции. После отправки команды с хоста на карту выдается ответ с карты на хост по той же последовательной линии. Связанные данные доступны через линии DAT.  На рисунке 10 представлена иллюстрация операции чтения из нескольких блоков. К счастью, все инструменты, которые мы будем использовать, уже реализуют и абстрагируют коммуникацию eMMC для нас.

Рисунок 10. Многоблочная операция чтения. (Источник: Стандарт JEDEC № 84-B51, раздел 5.3.1, стр. 9)

Стандарт eMMC также определяет регистры с различными наборами информации, которые, в свою очередь, доступны через определенные команды CMD. В таблице 2 представлены регистры eMMC:

Название

Ширина (байты)

Описание

Реализация

CID

16

Идентификационный номер устройства, индивидуальный номер для идентификации

Обязательный

RCA

2

Относительный адрес устройства, это системный адрес устройства, назначаемый хостом во время инициализации.

Обязательный

DSR

2

Driver Stage Register, для настройки выходных драйверов устройства.

Необязательный

CSD

16

Специфичные данные устройства, информация об условиях работы устройства.

Обязательный

OCR

4

Регистр условий эксплуатации. Используется специальной широковещательной командой для определения типа напряжения устройства.

Обязательный

EXT_CSD

512

Расширенные данные, специфичные для устройства. Содержит информацию о возможностях устройства и выбранных режимах. Введено в стандарт v4.0

Обязательный

Таблица 2 : Регистры e.MMC (источник: Стандарт JEDEC № 84-B51, глава 5.3, стр. 8)

Расширенные данные конкретного устройства, ранее называемые расширенными данными карты — это то место, где доступны отчеты о работоспособности. Содержат:

  • собственный отчет о работоспособности разработчика, длина 32 байта
  • оценка срока службы устройства тип A, обеспечивающая состояние работоспособности с шагом 10%
    • относится к блокам SLC в нашей eMMC.
  • оценка срок службы устройства тип B, обеспечивающая состояние работоспособности с шагом 10%
    • относится к блокам MLC в нашей eMMC.
  • pre-EOL info, отражающая срок службы устройства по средним зарезервированным блокам
    • возвращает значения normal, warning (80% зарезервированных блоков использовано) и urgent (90% зарезервированных блоков использовано)

Уместный вопрос: если эта информация легко доступна, почему бы просто не использовать данные из стандарта JEDEC?

  • Одной из причин является тот факт, что отчет о работоспособности был представлен только в версии 5.0 стандарта JEDEC.
  • Другим является низкое разрешение значений (с шагом 10%), что плохо для бенчмаркинга программ, которые записывают небольшие объемы данных. Для получения полезной информации потребуется очень много времени.
  • Кроме того, инструмент оценки износа флэш-памяти, который предоставляет методы, независимые от конкретных технологий (т. е. также работает для карт SD или необработанной флэш-памяти поверх MTD), является более гибким.

Собственный отчет Micron о работоспособности

По этой теме мы (почти) не подпадаем под действие стандарта JEDEC. Единственная информация, которую нам нужно понять, это как получить доступ к этим данным. Нам нужно только знать, что мы должны использовать General Command, а именно GEN_CMD или CMD56, как входную дверь для получения этих данных из кремния. Раздел «Специфичные для программ команды» в спецификации eMMC содержит более подробную информацию.

Следующая информация, которая нам нужна, — реализация отчета о работоспособности разработчика. В нашем случае он содержится в отчете Micron TN-FC-32: Отчет о работоспособности устройства e.MMC, доступный в области программного обеспечения e.MMC.

Могут быть получены следующие данные:

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

Чтобы получить доступ к каждому из них, CMD56 должен быть с конкретным параметром.

Примечание о поддержке eMMC в течение срока службы SoM

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

Зачастую жизненный цикл отдельных компонентов короче, чем у SoM в целом. Таким образом, со временем выпускаются новые версии оборудования и рассылаются уведомления об изменении продукта (PCN). Это одно из главных преимуществ использования SoM — абстрагированность от сложности редизайнов.

С другой стороны, вы можете предложить аппаратное обеспечение с (например) eMMC, которое не соответствует последним стандартам. Это еще один практический сценарий, когда вы хотите иметь решение для оценки износа, каким-то образом отделенное от конкретных технологий или стандартов.

Работоспособность флэш-памяти

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

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

Где:

  • E — выносливость, выраженная числом циклов стирания (вверху) или байтов (внизу)
  • B — количество блоков
  • Lavg — это средняя продолжительность жизни блока, выраженная как количество стереть блок
  • S — размер блока в байтах

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

В приведенном выше примере, после того, как 1 536 000 стираний были равномерно переданы блокам или примерно 6 ТБ данных было записано на устройство, оно достигло 50% срока службы.

Мониторинг состояния Флэш-памяти в Linux

Для мониторинга параметров работоспособности флэш-памяти, которые обсуждались в предыдущих разделах, Linux необходимо программное обеспечение, которое извлекает значимую информацию из устройства eMMC. Инструмент с открытым исходным кодом, который можно использовать для этой цели — mmc-utils. Он реализует большую часть протокола eMMC, включая чтение данных из регистра расширенных данных, специфичных для карты (EXT_CSD), и отображение его в удобочитаемом формате. Он включает срок службы устройства, как это определено в стандарте JEDEC eMMC 5.0 и далее. Давайте кратко рассмотрим его, запустив программу без каких-либо параметров, которая выводит справку: 

root@colibriimx6:~# mmc

Usage:

mmc extcsd read <device>

Print extcsd data from <device>.

mmc extcsd dump <device>

Print raw extcsd data from <device>.

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

root@colibriimx605097264:/app# mmc extcsd read /dev/mmcblk1

=============================================

   Extended CSD rev 1.7 (MMC 5.0)

=============================================

Это подтверждает, что у нас есть eMMC, которая соответствует стандарту JEDEC 5.0. Затем мы можем отфильтровать выходные данные, чтобы получить состояние работоспособности, как определено JEDEC:

root@colibriimx6:~# mmc extcsd read /dev/mmcblk1 | grep LIFE

Device life time estimation type B [DEVICE_LIFE_TIME_EST_TYP_B: 0x01]

Device life time estimation type A [DEVICE_LIFE_TIME_EST_TYP_A: 0x01]

eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01

eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x01

root@colibriimx605097264:~# mmc extcsd read /dev/mmcblk1 | grep EOL

Pre EOL information [PRE_EOL_INFO: 0x01]

eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01

В приведенном выше примере мы видим, что состояние работоспособности оценивается от 0% до 10% срока службы устройства с нормальным состоянием до EOL. Следовательно, это новое устройство. Если мы попытаемся получить собственный отчет о работоспособности разработчика, мы обнаружим, что он недоступен в исходной версии mmc-utils. Даже ChromiumOS, представленный ниже , отображает только нули: 

root@colibriimx6:~# mmc-cos extcsd read /dev/mmcblk1 | grep -i health

Vendor proprietary health report:

[VENDOR_PROPRIETARY_HEALTH_REPORT[301]]: 0x00

[VENDOR_PROPRIETARY_HEALTH_REPORT[300]]: 0x00

[VENDOR_PROPRIETARY_HEALTH_REPORT[299]]: 0x00

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

/ Retrieve the erase count for each block

// A two-step approach is needed (read number of tables and then read tables)

int do_block_erase_info(int nargs, char **argv)

{

ret = CMD56_data_in(fd, cmd56_how_many_tables, data_in);

printf(«Block erase count\n»);

printf(«Block\tErase\n»);

for(table_idx = 0; table_idx < how_many_tables; table_idx++){

ret = CMD56_data_in(fd, (table_idx * 256) + cmd56_retrieve_base, data_in);

for(physical_block = 0; physical_block < 128; physical_block++){

printf(«%d\t%d\n»,

         (256*data_in[0+2*physical_block]) + data_in[1+2*physical_block],

         (256*data_in[256+2*physical_block]) + data_in[257+2*physical_block]);

}

}

}

У вас может быть приложение, которое извлекает следующие данные из флэш-памяти Micron: 

int do_bad_block_count(int nargs, char **argv);

int do_bad_block_info(int nargs, char **argv);

int do_block_erase_count(int nargs, char **argv);

int do_block_erase_info(int nargs, char **argv);

int do_block_addr_type_info(int nargs, char **argv);

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

На момент написания статьи (август 2019 г.) emmcparm периодически обновлялся с версии 2.6.0, выпущенной 27 мая 2016 г. (возможно, более старые версии больше не доступны в Micron) до версии 4.4.0, выпущенной 5 июня 2019 г. У инструмента есть несколько функций, из которых оценка работоспособности является одной из множеств: 

root@colibriimx6:~# emmcparm_arm

spare_block

bad_block

erase_count

sect_count


Отслеживание ввода/вывода

Отслеживание ввода/вывода может быть полезным индикатором того, что флэш-память будет быстро изнашиваться, а также индикатором отладки, показывающим, какие приложения записывают слишком много данных. Отслеживание ввода/вывода генерирует входные данные для модели оценки износа, которая не зависит от стандартов JEDEC или отчетов о работоспособности разработчика eMMC. Следовательно, это средство достижения идеи гибкого инструмента, который можно распространить на различные технологии, все из которых используют raw NAND в качестве технологии хранения.

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

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

Затем ядро ​​Linux работает с этим вводом / выводом через то, что обычно называют стеком ввода / вывода или стеком хранения. На последнем этапе он отправляет данные на устройство через низкоуровневый драйвер устройства, который в случае eMMC должен соответствовать стандарту JEDEC. На максимально возможном уровне на рисунке 11 показаны стеки для устройств raw NAND и eMMC.

Рисунок 11: Стек ввода / вывода для eMMC и raw NAND

Мы можем пройтись по стеку ядра сверху вниз:

Рисунок 12. Упрощенный обзор структуры ядра Linux. (Источник: Википедия )
  • Виртуальная файловая система — это уровень абстракции для пользовательского API.
  • Файловая система сама реализует определенную структуру для определения концепций, связанных с файлами.
  • Уровень общего блока, который часто включает в себя планировщик ввода-вывода, является местом в стеке, которое обрабатывает все блочные операции ввода-вывода (BIO) и, таким образом, среди других аспектов, абстрагирует блочные устройства для файловой системы.
  • Планировщик ввода-вывода принимает очередь запросов ввода-вывода и отправляет их драйверу блочного устройства в соответствии с определенным алгоритмом. Он пытается максимизировать производительность блочного ввода-вывода, и выбор планировщика может повлиять на задержку, пропускную способность и использование флэш-памяти.

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

Как показано на рисунке 13, ядро ​​Linux представляет собой сложную систему, которая реализует слои кэша через свой стек для предотвращения ненужного доступа к диску. Это вызывает беспокойство, потому что дисковые операции всегда были медленными; даже с появлением флэш-памяти и ее гораздо более быстрой работы теперь необходимо продлить срок службы устройства хранения, и кэши и очереди помогают в этом:

Рисунок 13: Кэши, буферы, очереди и синхронизации.

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

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

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

Измерение ввода / вывода при записи

Проблема становится более определенной с точки зрения мониторинга и учета всех записей, которые фактически достигают флэш-памяти:

  • Где в стеке Linux мы можем измерить записи, которые фактически достигают флэш-памяти?
  • Как мы измеряем это? (Какие инструменты мы можем использовать?)

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

Рисунок 14: Инструменты наблюдения производительности Linux. (Источник: Брендан Грег)

В ходе нашего исследования мы натолкнулись на iotop для отслеживания операций в пользовательском пространстве и blktrace / blkparse для точного отслеживания операций ввода-вывода на уровне блоков и того, что на самом деле достигает флэш-памяти. Поскольку мы не хакеры, и у нас еще есть много возможностей для исследований по этой теме, мы ни в коем случае не намекаем, что это лучшие или наиболее оптимизированные инструменты для работы. (Например, perf trace и eBPF также находятся в нашем перечне). Есть интересная статья на тему, под называнием трассировкой ввода-вывода Linux , а также многие другие ресурсы в Интернете, включая саму документацию ядра Linux. 

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

Давайте кратко рассмотрим на практике, как мы можем использовать iotop и blktrace.

У iotop есть несколько удобных опций, которые помогают с этой задачей, и очень легко собирать и анализировать метки времени, счетчики записи и процессы, ответственные за эти записи: 

root @ colibri imx6 : ~ # iotop –help

Options :

   o ,   only             only  show  processes  or   threads  actually  doing   I / O

   b ,   batch             non interactive  mode

   a ,   accumulated      show  accumulated   I / O   instead  of  bandwidth

   k ,   kilobytes        use   kilobytes  instead  of   a   human  friendly  unit

   t ,   time              add   a   timestamp  on  each   line   ( implies   batch )

   q ,   quiet            suppress  some  lines  of  header   ( implies   batch )

Вы можете увидеть пример ниже: 

root@colibriimx6:~# dd if=/dev/urandom bs=4k count=100000 | pv -L 25k > testfile

root@colibriimx6:~# iotop —only —batch —accumulated —kilobytes —time –quiet

TIME       TID         PRIO    USER       DISK READ  DISK WRITE  SWAPIN      IO    COMMAND

20190802 03:11:19    50 be/4 root          0.00 K     24.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:20    50 be/4 root          0.00 K     52.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:21    50 be/4 root          0.00 K     80.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:22    50 be/4 root          0.00 K    104.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:23    50 be/4 root          0.00 K    128.00 K 0.00 % 0.00 % pv L 25k

Когда дело доходит до blktrace, все немного сложнее. Пора обратиться к документации. Запуск его в режиме реального времени без фильтров может привести к огромному количеству вывода: 

oot@colibriimx6:~# blktrace -o — /dev/mmcblk1 | blkparse -i —

179,0    0       26     0.000114661   304  A  WS 4509800 + 8 < (179,2) 4468840

179,0    0       27     0.000117328   304  Q  WS 4509800 + 8 [jbd2/mmcblk1p2]

179,0    0       28     0.000119661   304  M  WS 4509800 + 8 [jbd2/mmcblk1p2]

179,0    0       29     0.000127328   304  U   N [jbd2/mmcblk1p2] 1

179,0    0       30     0.000131661   304  I  WS 4509736 + 72 [jbd2/mmcblk1p2]

179,0    0       31     0.008860277   279  D  WS 4509736 + 72 [kworker/0:3H]

179,0    0       32     0.012586780   279  C  WS 4509736 + 72 [0]

К счастью, как в blktrace, так и в blkparse, реализованы фильтры, облегчающий. В таблица 3, коротко перечислены описания:

barrier атрибут barrier 
complete завершенный драйвером
fs FS запросы
issue обращение к драйверам
pc

команды пакетной обработки

queue операции с очередями
read чтение следа
requeue операции запроса
sync атрибут synchronous
write запись следа
notify сообщения, уведомляющие о трассировке

Таблица 3: Маски фильтра (источник: руководство по blktrace)

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

  • C — завершено: ранее выданный запрос был выполнен. Вывод детализирует сектор и размер этого запроса, а также его успех или неудачу.
  • I — вставлено: запрос отправляется в планировщик ввода-вывода для добавления во внутреннюю очередь и последующего обслуживания драйвером. Запрос полностью сформирован на данный момент.

Оценка продолжительности жизни

Регистрируя отслеживание ввода-вывода и состояние флэш-памяти, можно определить две корреляции:

  • Флэш-память работоспособна с течением времени
  • Флэш-память работоспособна относительно скорости записи

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

Данная выносливость измеряется в циклах стирания:

Заданная выносливость в байтах или кратных:

Где:

  • L — продолжительность жизни в секундах
  • E — выносливость, выраженная числом циклов стирания (вверху) или байтов (внизу)
  • Cavg — это среднее глобальное количество блоков стирания; т. е. сумма счетчиков стирания блоков, деленная на количество блоков в секунду
  • Wavg — это скорректированная средняя скорость записи в байтах в секунду

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

Температура влияет на срок службы флэш-памяти. Вы должны принять во внимание использование режима pSLC, если доступно, использование статического и динамического выравнивания износа, наличие плохих блоков, что происходит, когда устройство находится рядом с EOL, и наличие запасных блоков, среди других возможностей.

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

Инструмент Flash Analytics, который в настоящее время разрабатывается в Toradex Labs, представляет собой инструмент, разработанный для того, чтобы абстрагироваться от всей сложности оценки износа устройств eMMC самостоятельно. Мы представили принципы, предостережения, краеугольные случаи и сложность этой задачи в этой статье. Надеемся, что становится понятно, почему это сложная задача, которую разработчики программ скорее всего будут избегать.

Рисунок 15. Функции Flash Analytics Tool.

Как показано на Рисунке 15, представленном выше, инструмент предназначен для оказания всесторонней помощи, а не только для оценки продолжительности жизни. Он предназначен для использования среды выполнения контейнера Docker с платформы Torizon, которая будет доступна в виде модульного решения, где вы выбираете, что использовать поверх базового модуля BSP.

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

На рисунке выше представлен пользовательский интерфейс. Предлагаем вам протестировать его из первых рук и рассказать нам, что вы об этом думаете.

Заключение

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

Рисунок 16: Оценка и прогнозирование продолжительности жизни raw NAND .

Комплексный подход предлагает некоторые преимущества по сравнению с более простым расчетом. В дополнение к более точному результату, это также предоставляет вам возможности мониторинга и возможность запуска сигналов тревоги для более прогнозирующего обслуживания. В конце концов, ряд низкоуровневых и высокоуровневых инструментов, в том числе emmcparm, mmc-utils от Micron и Toradex Flash Analytics Tool, могут облегчить ваши усилия по созданию надежных решений. Мы надеемся, что вы хорошо провели время, читая этот пост.

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

Оригинал статьи вы можете прочитать здесь.

Накопитель Kingston eMMC на фоне черного корпуса системы.

Процессы, обрабатываемые шиной NAND

Флэш-память NAND — это не просто носитель для чтения и записи данных. Для надежного использования следует реализовать несколько алгоритмов: управление блоками NAND, очистка памяти от ненужных данных, контроль ошибок и выравнивание износа. Современная флэш-память NAND управляется с помощью алгоритмов на устройстве хранения, не реализованных в процессоре хост-системы. Это выгодно пользователям, поскольку делает управление NAND менее сложным для хост-системы и упрощает поддержку продукта и поддержание его работоспособности.

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

Количество циклов программирования-стирания флэш-памяти NAND ограничено. Достижение этого предела означает, что устройство находится в состоянии окончания срока службы (EoL), то есть более не является надежным. Рабочий ресурс зависит от конфигурации ячеек NAND.

Конфигурация с одноуровневыми ячейками: имеет самый высокий рабочий ресурс и наибольший допустимый предел ошибки.

eMMC LBA 512B Sector Address

NAND Page & Block Address
0:31 Blk10, Pg101
32:63 Blk10, Pg102
64:95 Blk10, Pg103
96:127 Blk10, Pg104
128:159 Blk15, Pg57
160:191 Blk8, Pg129
192:223 Blk10, Pg107
224:255 Blk22, Pg88

eMMC читает и записывает данные в блоки секторов по 512 байт, которые являются логическими, а не физическими. Адреса секторов называются адресами логических блоков (LBA). Когда данные изменяются, стирание всего блока NAND нецелесообразно, поскольку приводит к неэффективному износу не изменившихся страниц. Схема сопоставления LBA-PBA (адрес физического блока) позволяет сократить запись для балансировки износа блока. Это называется выравниванием износа. С помощью таблицы преобразования адреса LBA сопоставляются адресам PBA. Этот процесс уравновешивает износ блоков и повышает скорость записи.

Процесс отображения адресов выполняется следующим образом.

  • Сектора eMMC имеют размер 512 байт, а страницы NAND — 16 Кб. Таблица сопоставления группирует 32 последовательных адреса секторов в единицу размером со страницу.
  • Если сектор в группе страниц изменяется, контроллер считывает всю группу секторов для этой страницы, обновляет все измененные сектора, а затем программирует новые данные на новую страницу.
  • После программирования обновленной страницы таблица обновляется: в предыдущую запись вносится адрес блока и страницы обновленной страницы NAND.
  • Даже если был изменен всего лишь один сектор, флэш-память NAND должна запрограммировать всю страницу. Эта неэффективность называется увеличением объема записи. Отношение количества операций записи во флэш-память NAND к количеству операций записи на уровне устройства eMMC представляет собой WAF (коэффициент увеличения объема записи).

Небольшие, случайные, не соответствующие страницам операции перезаписи обычно являются самым большим источником увеличения объема записи. Чтобы свести к минимуму WAF, записи должны быть выровнены по границе страницы в единицах, кратных размеру страницы. Этот оптимальный размер единицы записи указывается в поле Optimal Write Size (Оптимальный размер записи) расширенного регистра управления микросхемой (CSD).

Формула для определения общего количества записанных байтов (TBW) проста:

(емкость устройства * коэффициент срока службы) / WAF = TBW

Часто WAF находится в диапазоне от 4 до 8, но это зависит от режима записи хост-системы. Например, последовательные операции записи большого объема снижают значение WAF, а произвольной записи небольших блоков данных соответствует более высокое значение WAF. Такое поведение часто может вести к преждевременному выходу устройств хранения из строя.

Например, для eMMC 4 ГБ с коэффициентом срока службы 3000 и WAF 8 получим:

(4 ГБ * 3000) / 8 = 1,5 ТБ

Суммарное число записываемых байтов устройства eMMC составляет 1,5 ТБ. Таким образом, мы можем записать 1,5 ТБ данных в течение его жизненного цикла, прежде чем оно достигнет состояния окончания срока службы.

Чтобы оценить свои требования к TBW, оцените ежедневное использование рассматриваемого устройства. Например, для рабочей нагрузки с ежедневным объемом записи 500 МБ (и предполагаемым 5-летним жизненным циклом) потребуется устройство, которое может достигать TBW более 915 ГБ:

0,5 ГБ * 365 = ~183 ГБ в год, или 915 ГБ за 5 лет

TBW можно использовать для определения максимально допустимого WAF для устройства, поскольку TBW = (DC * EF) / WAF. Если срок службы вашего устройства не может достичь целевого TBW для предполагаемого использования, вы можете попытаться увеличить его. Например, можно перевести его в режим с псевдоодноуровневыми ячейками. Это позволит увеличить срок службы в десять раз за счет перевода устройства из режима TLC или MLC в режим «один бит на ячейку». Однако это существенно сокращает емкость: на 50% для устройства MLC с двумя битами на ячейку и более чем на 66% для устройства TLC с тремя битами на ячейку. Если это решение вас не устраивает, можно выбрать для той же рабочей нагрузки устройство большей емкости. Устройство с вдвое большей емкостью будет иметь и вдвое больший TBW.

Алгоритмы Kingston для eMMC обеспечивают низкий коэффициент увеличения объема записи. Мы предлагаем несколько конфигураций, чтобы сбалансировать производительность, срок службы и надежность. Возраст устройства можно отслеживать с помощью инструментов оценки срока службы JEDEC, хранящихся в реестре EXT_CSD. Это общая функция для всех устройств eMMC. Срок службы указывается с шагом 10 % в зависимости от рабочего ресурса устройства. Один инструмент сообщает о возрасте блоков флэш-памяти NAND в конфигурации TLC или MLC, а другой — о возрасте блоков в конфигурации с псевдо-одноуровневыми ячейками. У устройств Kingston eMMC также есть команды поставщика, возвращающие средний возраст блоков устройства. Они более точны, чем инструменты JEDEC, но для их использования требуется определенное программное обеспечение (небольшой объем разработки). Кроме того, вы можете отправить свое старое устройство в Kingston для более комплексного анализа.

#KingstonIsWithYou

promo embedded

Спросите специалиста

Планирование правильного решения требует понимания требований вашего проекта и системных требований. Позвольте специалистам Kingston помочь вам.

Спросите специалиста

Проектирование встраиваемых продуктов для долговечности


51:35

Проектирование встраиваемых продуктов для долговечности

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

Оценка, проверка и отслеживание жизненного цикла eMMC


14:38

Оценка, проверка и отслеживание жизненного цикла eMMC

Важно понимать особенности управления флеш-памятью NAND в eMMC в современных устройствах и как они связаны с ее жизненным циклом. Это руководство поможет разработчикам и инженерам понять, как оценить и проверить срок службы устройства хранения данных eMMC при проектировании системы.

Дверь с вывеской South Seas LLC и сборка мини-ПК с установленным твердотельным накопителем Kingston


4:50

Как Kingston помогла South Seas Data завоевать репутацию надежной компании

Взаимоотношения South Seas Data и Kingston привели к большому успеху. Узнайте, как и почему.

Выравнивание износа памяти eMMC


3:13

Выравнивание износа памяти eMMC

Устройства хранения eMMC содержат блоки NAND, которые изнашиваются при постоянном использовании. Выравнивание износа продляет срок службы устройств eMMC, в первую очередь используя для хранения данных более «молодые» блоки памяти.

Блог Главная

MultiMedia Card (MMC. eMMC — улучшенная версия MMC) — портативная флеш-карта памяти, использующаяся для записи и хранения информации в электронных устройствах: планшетах, сотовых телефонах и т. д.

Картинки по запросу emmc ram chip

2. И все же, что представляет из себя eMMC память?

eMMC это стандарт архитектуры, состоящий из интерфейса ММС, флеш-памяти (NAND) и контроллера. Все компоненты находятся в компактном корпусе типа BGA. Обычно eMMC содержит следующие разделы:

  • BOOT — раздел, в котором хранится загрузочный образ устройства.
  • RMP — шифрованный раздел. Служит для защиты от записи пониженной версии загрузчика. Применяется не всегда.
  • USER AREA — раздел с пользовательскими данными. Занимает бОльшую часть памяти.
  • Также в блоке NAND расположена служебная информация. Одним из важных параметров является CSD (Card-specific data, содержит всевозможную информацию о карте памяти): если выставлен флаг перманентной защиты у аппарата, то он будет включатся и работать, но все изменения будут обнуляться после перезагрузки.

3. Основные проблемы eMMC карт

Благодаря народным умельцам на просторах интернета существует некоторое количество аккумулированной информации по причинам выхода из строя eMMC памяти. Зачастую, производители «халтурят», не до конца тестируя и проверяя контроллеры на наличие ошибок, что потом выливается в частичную или полную потерю данных карточки. Конечно, все причинно-следственные связи от аппарата к аппарату разнятся и в каждой новой версии eMMC могут присутствовать новые «глюки». Большинство программных ошибок, дающих зависание телефона на логотипе, поддается «лечению» перепрошивкой раздела boot. Аппаратные же недоработки ремонту не подлежат и потребуется заменить флеш-память на новую.

Если вы столкнулись с проблемами:

  • невозможно включить устройство
  • постоянные ошибки Google
  • зависания
  • невозможно сделать сброс устройства, либо появление приложений после их удаления
  • а также, если устройство висит на логотипе

то значит, это неисправность еММС памяти.

4. Программа для проверки eMMC памяти

eMMC Brickbug Check (ссылка на PlayMarket)

Обложка

Check your flash memory (eMMC) chip. Revise fw revision and check blocks.

The check dont write and is safe. If your device freeze you memory is damaged. For unfreeze the device remove battery and restart.

(Brickbug) Usefull with any version of:
— Samsung Galaxy R.
— Samsung Galaxy SII.
— Samsung Galaxy Note.
— Samsung Galaxy Nexus.
— Samsung Epic 4G Touch.

(Sudden Death) Usefull with any version of:
— Samsung Galaxy SIII.
— Samsung Galaxy Note II.

However, the use of this application is your responsibility.


Источник: https://it-lab23.ru/content/remont-emmc-pamyati.php

Everything looks fine, so why are your eMMCs failing? How do you track down the issue?

We previously introduced you to what eMMCs are used for, today we will be talking about how to fix a common issue with them.

Customer feedback we recently received indicates that some i.MX7 COM (system on module) boards encountered occasional boot failures. According to conventional fault analysis steps, the first step is to reproduce the fault after the receipt of faulty samples.

Fault reproduction:

Therefore, we install the COM board onto the carrier board, connect it to the terminal software Tera Term, power on/off and install/remove the motherboard frequently to reproduce the fault. It is confirmed that occasional boot failure does exist this way. Sometimes it boots normally, sometimes it fails to boot, and sometimes it boots slowly. Although this problem does not occur regularly, it is clearly something we can’t ship without solving first.

Preliminary analysis:

We can use a fishbone diagram analysis method:

  • Environment and personnel in the fishbone diagram: According to the customer feedback and fault reproduction, the possibility in these two aspects can be targeted.
  • Machine in the fishbone diagram: The factory test is carried out on the manufacturing test board, and the motherboard must have undergone all the tests and been judged to be qualified before delivery, while the fault is found on the carrier board. So it may be related to the testing equipment. Then the faulty board is placed on the manufacturing testing jig for testing, and the result is that multiple tests have qualified it.

Working steps for inspection of the manufacturing testing jig:

  1. Boot the COM board in other ways
  2. Test whether the flash and other modules of the COM board work normally
  3. Test the functionality of the interfaces
  4. Download the software to FLASH
  5. Finally, complete a reboot from FLASH boot.

This working sequence is obviously not a normal procedure, so the performance of the faulty board on the two jigs may be related to how the carrier board works and the sequence of the test boards. The basis is to be supplemented.

Fishbone diagram methodology:

The analysis on how it works starts from the boot option, and the confirmation is made first according to the boot option. There are four boot options on the COM board: SD, MMC/eMMC, QSPI, and NAND. By checking the hardware configuration (pull-up resistor), it is confirmed to be MMC/eMMC boot.

Then we analyze the boot program, which is basically divided into five steps:

  1. The processor executes BOOT ROM to load SPL
  2. SPL initializes SDRAM and loads u-boot
  3. U-boot initializes hardware and load device tree and Linux
  4. Linux activates peripheral equipment, mounts root file system, and executes the initializer
  5. The initializer enables services and the host application.

We know SPL is a subset of U-BOOT and is stored in the Boot Area of eMMC FLASH together with U-BOOT. Therefore, we narrow our focus to the eMMC FLASH.

  • Materials in the fishbone diagram: There are many materials related to boot, such as CPU, FLASH, RAM, and related hardware configuration devices. Others can be ruled out through the analysis of the working principle. The most direct method of testing the damage of FLASH material is to replace it with a new device for comparison, but such analysis is irreversible. It can be conducted as a final option when it comes to faulty boards.

Further analysis:

Now we begin to focus on the analysis of FLASH, we install the faulty board onto the Carrier board again, connect it to the Tera Term terminal software, power on/off frequently, observe the log, and inquire about the information of eMMc by inputting the MMC info instruction. However, three different kinds of information are captured. They are respectively the followings:

Boot normally: 

Boot slowly:

Boot failed:

Therefore, we can learn some important information from the display of LOG.

  • The boot failure is due to a block fetching error in MMC1, resulting in the failure of the boot program to be obtained from FLASH.
  • Even if the eMMC FLASH boots successfully, the bus bandwidth (8bit DDR VS 1-bit) is fluctuating.
  • The problem lies in step 2 or step 3 of the boot program.

Analyzing the Culprit

eMMC-DiagramXray scan

Figure on the top: Technical diagram of eMMC. Bottom: X-Ray scan of the faulty product

It can be seen from the structural diagram of eMMC FLASH that the management of bad blocks is automatically set through related control registers, and under the circumstance that the hardware configuration related to bandwidth setting on the motherboard is checked to be correct. The variation of bandwidth is probably due to the situation that some lines of DAT[7:0] are broken or non-wetting occurs on the bonding pad, and the intermittency leads to the abnormality in polling the bus bandwidth.

Therefore, X-RAY scanning is arranged, the red frame shows the bonding pad of the data line, and the result shows that non-wetting cannot be identified due to the angle of view.

Then the second step is performed, i.e., performing the repair welding of FLASH through a reflow oven, and the fault is not reproduced in the testing of the repaired samples, so this operation is extended to the other faulty samples, and the result is verified repeatedly.

Conclusion:

Non-wetting of eMMC Flash pads causes reduced reliability in the signal. 

Quality backtracking:

  1. Why can’t the test system find it? How to prevent it?

The working principle of the test system indicates that the probability of detecting occasional faults by a normal boot in step 5 is low, and even a product fails to pass a test initially, it may pass the retest later on.

It is considered to execute two times of resetting and booting in step 5 of the testing jig, and implement the retest invalidation mechanism, that is, any fault found must be repaired.

  1. How does the factory test and prevent the non-wetting of components?

Appropriate reliability test methods should be designed for motherboard products, such as the vibration test in the running state, and the full function strength test after the reliability test.

Have you ever had a similar problem driving you nuts and you realized the problem is caused by faulty soldering?

A simple cold joint can break a whole product. We don’t claim to make any errors at NexPCB, but we claim to find the underlying issues and fix them before your products can get harmed by them through diligent engineering.

Sign up for our blog to read more Quality Control tips like this one!

Jacen Wang

Head of Electronics Engineering @ NexPCB. Give this man a breadboard and a box of electronics and he will make magic (not to be confused with magic smoke). Almost all the Raspberry Pi’s in the office are his.

CNXSoft: Это пост от гостей Марселя Зисвилера (Marcel Ziswiler), менеджер платформы Embedded Linux, Toradex и Леонардо Грабоски Вейга (Leonardo Graboski Veiga), инженера по техническому маркетингу, Toradex, связанные с предстоящим докладом Марселя на тему «Оценка износа устройств с флэш-памятью eMMC» на конференции Embedded Linux 2019 года позже этот месяц.

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

Рисунок 1. от флэш-накопителей и SD-карт до SSD и интегральных микросхем, флэш-память является частью нашей повседневной жизни.

Как показано на рисунке 1, флеш-память везде в нашей повседневной жизни — от устройств, специально предназначенных для хранения данных, таких как флэш-накопители, SD-карты и жесткие диски SSD, до бытовой электроники, в которой используется флэш-память внутри, например смартфоны, модемы Wi-Fi и умные лампочки.

Знаковым противоположным примером является первая модель iPod, выпущенная в 2001 году. В ней использовался вращающийся жесткий диск для обеспечения высокой емкости хранения (для его времени — 5 или 10 ГБ). Однако, исследование показало, что частота отказов моделей с жестким диском была больше 20%, для сравнения, у моделей, оснащенных флэш-памятью она менее 10%. Из-за чувствительных движущихся частей, которые они содержат, вращающиеся диски не очень хорошо справляются с механическими ударами. Это играет значительную роль в частоте отказов портативных устройств, оснащенных магнитным накопителем.

Рисунок 2: Оригинальный iPod, выпущенный в 2001 году, является редким примером мобильного устройства с магнитным накопителем.

Когда речь идет о встраиваемых системах, флэш-память является предпочтительной энергонезависимой памятью. Во встраиваемых системах Linux распространенной практикой является использование интегральных микросхем (IC) в системах-на-модуле (SoM) и одноплатных компьютерах (SBC), поскольку они более устойчивы к повреждению данных, чем некоторые модели карт MicroSD. Они также более устойчивы, когда вибрация окружающей среды является решающим фактором. К примерам SoM, использующим встраиваемую флэш-память, относятся семейства Apalis и Colibri от Toradex. На рисунке 3 представлено увеличенное изображение модуля Colibri iMX8X, оснащенного eMMC от Micron:

Рисунок 3: Colibri iMX8X оснащен флэш-памятью eMMC от Micron.

Цель этой статьи — представить обзор того, как проектировать более надежные встраиваемые системы, используя преимущества как открытого, так и закрытого программного обеспечения для измерения и оценки износа eMMC. Это обусловлено (например) постоянно растущей потребностью в IoT-шлюзах и регистраторах данных, а также желанием хранить избыточные данные локально для повышения надежности или прерывистого соединения.  Из практических деталей реализации, SoM Toradex, оснащенные eMMC Micron, используются для иллюстрации того, как инструмент Flash Analytics — решение для мониторинга и оценки износа — может быть воплощен в жизнь.

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

Обзор технологии

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

В этой статье представлены только основы понимания износа, в Интернете доступно большое количество литературы по флэш-памяти. Например, у Toradex есть блог, архив вебинаров и ряд статей на веб-сайте разработчиков. Статья Википедии о флэш-памяти также содержит более ста ссылок на другие ресурсы.

NOR и NAND

Флэш-память — это широкий термин, и существует несколько комбинаций технологий, которые вместе образуют конечные флэш-продукты с определенными характеристиками. Первоначальное различие кроется в разделении флэш-памяти на два типа: NOR и NAND. Они названы по имени технологий, работающих на уровне транзисторов для хранения битов, напоминающих логические элементы NOR и NAND.

NOR имеет более простые принципы работы и более высокую надежность, но часто требуется более высокое число выводов и имеется более низкая плотность хранения на единицу площади кремния, чем NAND, что влияет на размер и стоимость. По этим причинам NOR часто используется только в определенных приложениях, которые считаются критическими даже для высоконадежных встраиваемых систем промышленного уровня. Вы можете узнать больше об этой теме в NOR | / NAND Flash Guide от Micron (PDF). На рисунке 4, взятом из руководства, упомянутого в этом параграфе, представлена сводка технологий NOR и NAND в контексте плотности и емкости хранилища:

Рисунок 4: Предложения NOR и NAND по плотности и емкости. (источник: Micron NOR / NAND Flash Guide)

Как видите, Micron eMMC — это исключительно устройства NAND в диапазонах MLC и TLC, которые мы обсудим более подробно. Поскольку SoM Toradex используют eMMC в диапазоне от 4 ГБ до 16 ГБ, мы можем сделать вывод, что они используют устройства MLC. Это также будет рассмотрено далее в этой статье.

Структура NAND

Флэш-устройство raw NAND можно разбить на три отдельные части.

  • Ячейка : самый маленький объект. Ячейка хранит данные на уровне битов и не может быть напрямую адресуемым устройством, управляющим хранилищем NAND.
  • Страница : Наименьший массив ячеек, которые можно адресовать для операций чтения и программирования. Программная операция состоит из «переворачивания» битов от значения 1 до значения 0. Размеры страниц находятся в диапазоне килобайт; например, 4 КБ.
  • Блок : наименьший массив страниц, который можно адресовать для операций удаления. Блок также известен как стираемый блок в некоторых контекстах, таких как стек MTD Linux. Операция удаления состоит из возврата битов со значения от 0 до значения 1. Размеры блоков находятся в мегабайтах; например, 4 МБ. Операции стирания выполняются намного медленнее, чем операции программирования или чтения, выполняемые на страницах.
    • Операции удаления стирают флэш-память с течением времени.
    • Когда блок больше не может использоваться для хранения данных, он помечается как плохой .

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

Рисунок 5: Диаграмма высокого уровня raw NAND флэш-кристалла.

NAND SLC и MLC

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

  • SLC : одноуровневая ячейка, хранит 1 бит на ячейку
    • pSLC : MLC, работающий в режиме SLC, сохраняет 1 бит на ячейку
  • MLC : многоуровневая ячейка, хранит 2 бита на ячейку
  • TLC : трехуровневая ячейка, хранит 3 бита на ячейку
  • QLC : четырехъярусная ячейка, хранит 4 бита на ячейку

Существует компромисс между плотностью и стоимостью в сравнении с надежностью и сроком службы, как показано в таблице 1.

NAND Cell Technology

Плотность (бит на ячейку)

Стоимость

Надежность

Срок жизни

SLC

1

Наибольший

Наибольший

Наибольший

pSLC

1

Средний

Высоко

Высоко

MLC

2

Средний

Высоко

Средний

ТСХ

3

Низкий

Низкий

Низкий

QLC

4

низший

низший

низший

Таблица 1: Сравнение клеточных технологий NAND

Рисунок 6 помогает визуализировать, как SLC и MLC хранят биты:

Рисунок 6: Пороги напряжения SLC и MLC

PSLC («pseudo-SLC») повышает скорость работы и срок службы устройства MLC за счет уменьшения его емкости вдвое. Срок службы не соответствует настоящему SLC, но он значительно увеличен. Pseudo-SLC не следует путать с быстрым режимом, который ускоряет работу устройства MLC, но не увеличивает его срок службы:

Рисунок 7: Pseudo-SLC и быстрый режим

Понимание того, настроены ли блоки как MLC или pSLC, важно для определения срока службы устройства, так как мы собираем количество поврежденных блоков с течением времени.

Для eMMC, в котором используется технология MLC, в зависимости от ширины трассировки кремния, блок длится в среднем от 3000 до 10000 циклов стирания. Время жизни для pSLC увеличивается более чем в 2 раза по сравнению с MLC; поэтому pSLC предпочтительнее быстрого режима или избыточного выделения ресурсов (т. е. использование флэш-памяти с удвоенной емкостью, чтобы она работала вдвое дольше). Может быть трудно найти количество циклов стирания и значения ширины трассировки в общедоступной документации производителей, поэтому бенчмаркинг самих устройств может быть решением.

ECC

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

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

Усиление Записи

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

Выравнивание износа и сбор мусора

Если всегда использовать одни и те же физические страницы и блоки, например, при обновлении файла, эти блоки будут преждевременно изнашиваться. В худшем случае система может даже перестать работать задолго до окончания срока службы флэш-памяти (EOL), если контроллер NAND не перемещает данные, поскольку эти блоки становятся неисправными.

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

  • Динамический : перемещаются только данные, которые являются динамическими (то есть обновляются с течением времени). Статические данные хранятся в блоках, в которые они были первоначально записаны. Этот алгоритм проще, но не использует всю емкость устройства хранения. Лучше всего использовать, когда только небольшой процент флэш-памяти содержит статические данные.
  • Статический : Этот алгоритм целенаправленно перемещает статические данные, равномерно распределяя все блоки флэш-памяти. Это более сложный алгоритм, но он продлевает срок службы устройства хранения, используя всю доступную флэш-память.

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

На рисунке 8 показано, как алгоритмы управления raw NAND вместе можно рассматривать как контроллер, который отображает физические блоки стирания (PEB) в логические блоки стирания (LEB) и абстрагирует специфичные для NAND операции в простые операции «чтения» и «записи»:

Рисунок 8. Операции raw NAND абстрагируются через контроллер.

Когда чип raw NAND подключен к системе, которая пытается реализовать «dumb» контроллер для простого преобразования операций программы NAND, чтения и стирания в операции чтения и записи, подобные жесткому диску, это серьезно влияет на производительность и срок службы флэш-памяти. Это одна из причин, по которой подсистема MTD Linux почти всегда используется файловыми системами, которые осведомлены о особенностях raw NAND — и, возможно, промежуточным слоем, в случае UBI и UBIFS — вместо файловых систем, которые обращаются к блочным устройствам.

Если вы хотите узнать больше о выравнивании износа, ознакомьтесь с документом Micron TN-29-42: Методы выравнивания износа и износа в устройствах NAND Flash (PDF) и статьей в Википедии «Выравнивание износа»  (а также с ее ссылками, включая некоторые статьи LWN.net). Для получения информации о сборке мусора прочтите «Micron TN-2960: Сборка мусора в одноуровневой ячейке NAND Flash Memory» (PDF).

Чтобы лучше понять полную реализацию уровней абстракции между устройством raw NAND и программой в деталях, вы можете прочитать исчерпывающую документацию по MTD , UBI и UBIFS. Конечно, чтобы узнать особенности реализации, вы также можете взглянуть на исходный код ядра Linux.

Несмотря на всю сложность операций raw NAND, которые мы, тем не менее, должны знать в некоторой степени для создания моделей оценки износа, простой способ абстрагироваться от этой сложности — купить устройство NAND со встроенным контроллером, также называемое управляемым NAND. Что касается интегральных схем, распространенные типы включают в себя встроенный USB, eMMC и UFS. Здесь мы сосредоточимся на eMMC.

Детальный взгляд на eMMC Flash

Одной из самых популярных высокопроизводительных флэш-технологий, используемых во встраиваемых промышленных системах, является eMMC ( Embedded MultiMediaCard), которая состоит из матрицы NAND, обычно MLC или TLC, и сопровождающего ее контроллера NAND. Он абстрагирует большую часть стека управляющего программного обеспечения от базовой операционной системы. Стандарт eMMC поддерживается JEDEC, и его база доступна бесплатно после регистрации. Последним стандартом, опубликованным до написания этой статьи, является Embedded MultiMedia Card Electrical Standard 5.1 (можно скачать PDF-файл после регистрации)

Поскольку контроллер обеспечивает высококачественный уровень абстракции (при условии, что он исходит от надежного производителя), можно безопасно использовать файловую систему, которая осведомлена о работе блочных устройств, если принять некоторые меры предосторожности. В BSP Toradex Embedded Linux используется файловая система EXT4 по умолчанию для компьютеров на модулях с флэш-памятью eMMC. Рисунок 9 суммирует различия между raw NAND и управляемым NAND относительно контроллера:

Рисунок 9: Raw NAND и контроллер eMMC.

В примерах, приведенных в этой статье, мы рассматриваем 4 ГБ MLC eMMC с 1024 блоками, которые в реальном мире могут быть (например, Micron MTFC4GACAJCN-1M-WT, использовавшимися в последней редакции Apalis iMX6Q 1 ГБ SoM). Мы также предполагаем, что средняя продолжительность жизни блока составляет 3000 циклов стирания, что является лишь обоснованным предположением. Оно не был взято из таблицы данных вышеупомянутого номера детали.

Проблемы использования eMMC заключаются в сборе сведений о реализации контроллера и сроке службы модуля, которые могут быть или не быть общедоступными. Кроме того, кто-то может предпочесть выбрать производителя, который предоставляет хороший собственный отчет о состоянии работоспособности. Стандарт eMMC резервирует некоторые регистры для этой цели, но их использование не является обязательным. У eMMC, выбранной для данного примера, есть подробный отчет о работоспособности, а подробную информацию о нем можно получить из TN-FC-32 Micron: Отчет о работоспособности устройства e.MMC, доступный после регистрации, в разделе программного обеспечения e.MMC на веб-сайте Micron. В этом разделе веб-сайта Micron вы также можете найти инструмент emmcparm, который будет использоваться позже в этой статье, и полезную TN-FC-25: Общие сведения о поддержке драйверов Linux для e.MMC.

Команды и регистры

Стандарт eMMC определяет работу через шину, которая содержит линии электропитания, линии CMD, DAT0-7 и CLK.

CMD — это последовательный канал, и разные значения CMD представляют разные операции. После отправки команды с хоста на карту выдается ответ с карты на хост по той же последовательной линии. Связанные данные доступны через линии DAT.  На рисунке 10 представлена иллюстрация операции чтения из нескольких блоков. К счастью, все инструменты, которые мы будем использовать, уже реализуют и абстрагируют коммуникацию eMMC для нас.

Рисунок 10. Многоблочная операция чтения. (Источник: Стандарт JEDEC № 84-B51, раздел 5.3.1, стр. 9)

Стандарт eMMC также определяет регистры с различными наборами информации, которые, в свою очередь, доступны через определенные команды CMD. В таблице 2 представлены регистры eMMC:

Название

Ширина (байты)

Описание

Реализация

CID

16

Идентификационный номер устройства, индивидуальный номер для идентификации

Обязательный

RCA

2

Относительный адрес устройства, это системный адрес устройства, назначаемый хостом во время инициализации.

Обязательный

DSR

2

Driver Stage Register, для настройки выходных драйверов устройства.

Необязательный

CSD

16

Специфичные данные устройства, информация об условиях работы устройства.

Обязательный

OCR

4

Регистр условий эксплуатации. Используется специальной широковещательной командой для определения типа напряжения устройства.

Обязательный

EXT_CSD

512

Расширенные данные, специфичные для устройства. Содержит информацию о возможностях устройства и выбранных режимах. Введено в стандарт v4.0

Обязательный

Таблица 2 : Регистры e.MMC (источник: Стандарт JEDEC № 84-B51, глава 5.3, стр. 8)

Расширенные данные конкретного устройства, ранее называемые расширенными данными карты — это то место, где доступны отчеты о работоспособности. Содержат:

  • собственный отчет о работоспособности разработчика, длина 32 байта
  • оценка срока службы устройства тип A, обеспечивающая состояние работоспособности с шагом 10%
    • относится к блокам SLC в нашей eMMC.
  • оценка срок службы устройства тип B, обеспечивающая состояние работоспособности с шагом 10%
    • относится к блокам MLC в нашей eMMC.
  • pre-EOL info, отражающая срок службы устройства по средним зарезервированным блокам
    • возвращает значения normal, warning (80% зарезервированных блоков использовано) и urgent (90% зарезервированных блоков использовано)

Уместный вопрос: если эта информация легко доступна, почему бы просто не использовать данные из стандарта JEDEC?

  • Одной из причин является тот факт, что отчет о работоспособности был представлен только в версии 5.0 стандарта JEDEC.
  • Другим является низкое разрешение значений (с шагом 10%), что плохо для бенчмаркинга программ, которые записывают небольшие объемы данных. Для получения полезной информации потребуется очень много времени.
  • Кроме того, инструмент оценки износа флэш-памяти, который предоставляет методы, независимые от конкретных технологий (т. е. также работает для карт SD или необработанной флэш-памяти поверх MTD), является более гибким.

Собственный отчет Micron о работоспособности

По этой теме мы (почти) не подпадаем под действие стандарта JEDEC. Единственная информация, которую нам нужно понять, это как получить доступ к этим данным. Нам нужно только знать, что мы должны использовать General Command, а именно GEN_CMD или CMD56, как входную дверь для получения этих данных из кремния. Раздел «Специфичные для программ команды» в спецификации eMMC содержит более подробную информацию.

Следующая информация, которая нам нужна, — реализация отчета о работоспособности разработчика. В нашем случае он содержится в отчете Micron TN-FC-32: Отчет о работоспособности устройства e.MMC, доступный в области программного обеспечения e.MMC.

Могут быть получены следующие данные:

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

Чтобы получить доступ к каждому из них, CMD56 должен быть с конкретным параметром.

Примечание о поддержке eMMC в течение срока службы SoM

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

Зачастую жизненный цикл отдельных компонентов короче, чем у SoM в целом. Таким образом, со временем выпускаются новые версии оборудования и рассылаются уведомления об изменении продукта (PCN). Это одно из главных преимуществ использования SoM — абстрагированность от сложности редизайнов.

С другой стороны, вы можете предложить аппаратное обеспечение с (например) eMMC, которое не соответствует последним стандартам. Это еще один практический сценарий, когда вы хотите иметь решение для оценки износа, каким-то образом отделенное от конкретных технологий или стандартов.

Работоспособность флэш-памяти

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

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

Где:

  • E — выносливость, выраженная числом циклов стирания (вверху) или байтов (внизу)
  • B — количество блоков
  • Lavg — это средняя продолжительность жизни блока, выраженная как количество стереть блок
  • S — размер блока в байтах

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

В приведенном выше примере, после того, как 1 536 000 стираний были равномерно переданы блокам или примерно 6 ТБ данных было записано на устройство, оно достигло 50% срока службы.

Мониторинг состояния Флэш-памяти в Linux

Для мониторинга параметров работоспособности флэш-памяти, которые обсуждались в предыдущих разделах, Linux необходимо программное обеспечение, которое извлекает значимую информацию из устройства eMMC. Инструмент с открытым исходным кодом, который можно использовать для этой цели — mmc-utils. Он реализует большую часть протокола eMMC, включая чтение данных из регистра расширенных данных, специфичных для карты (EXT_CSD), и отображение его в удобочитаемом формате. Он включает срок службы устройства, как это определено в стандарте JEDEC eMMC 5.0 и далее. Давайте кратко рассмотрим его, запустив программу без каких-либо параметров, которая выводит справку: 

root@colibriimx6:~# mmc

Usage:

mmc extcsd read <device>

Print extcsd data from <device>.

mmc extcsd dump <device>

Print raw extcsd data from <device>.

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

root@colibriimx605097264:/app# mmc extcsd read /dev/mmcblk1

=============================================

   Extended CSD rev 1.7 (MMC 5.0)

=============================================

Это подтверждает, что у нас есть eMMC, которая соответствует стандарту JEDEC 5.0. Затем мы можем отфильтровать выходные данные, чтобы получить состояние работоспособности, как определено JEDEC:

root@colibriimx6:~# mmc extcsd read /dev/mmcblk1 | grep LIFE

Device life time estimation type B [DEVICE_LIFE_TIME_EST_TYP_B: 0x01]

Device life time estimation type A [DEVICE_LIFE_TIME_EST_TYP_A: 0x01]

eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01

eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x01

root@colibriimx605097264:~# mmc extcsd read /dev/mmcblk1 | grep EOL

Pre EOL information [PRE_EOL_INFO: 0x01]

eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01

В приведенном выше примере мы видим, что состояние работоспособности оценивается от 0% до 10% срока службы устройства с нормальным состоянием до EOL. Следовательно, это новое устройство. Если мы попытаемся получить собственный отчет о работоспособности разработчика, мы обнаружим, что он недоступен в исходной версии mmc-utils. Даже ChromiumOS, представленный ниже , отображает только нули: 

root@colibriimx6:~# mmc-cos extcsd read /dev/mmcblk1 | grep -i health

Vendor proprietary health report:

[VENDOR_PROPRIETARY_HEALTH_REPORT[301]]: 0x00

[VENDOR_PROPRIETARY_HEALTH_REPORT[300]]: 0x00

[VENDOR_PROPRIETARY_HEALTH_REPORT[299]]: 0x00

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

/ Retrieve the erase count for each block

// A two-step approach is needed (read number of tables and then read tables)

int do_block_erase_info(int nargs, char **argv)

{

ret = CMD56_data_in(fd, cmd56_how_many_tables, data_in);

printf(«Block erase countn»);

printf(«BlocktErasen»);

for(table_idx = 0; table_idx < how_many_tables; table_idx++){

ret = CMD56_data_in(fd, (table_idx * 256) + cmd56_retrieve_base, data_in);

for(physical_block = 0; physical_block < 128; physical_block++){

printf(«%dt%dn»,

         (256*data_in[0+2*physical_block]) + data_in[1+2*physical_block],

         (256*data_in[256+2*physical_block]) + data_in[257+2*physical_block]);

}

}

}

У вас может быть приложение, которое извлекает следующие данные из флэш-памяти Micron: 

int do_bad_block_count(int nargs, char **argv);

int do_bad_block_info(int nargs, char **argv);

int do_block_erase_count(int nargs, char **argv);

int do_block_erase_info(int nargs, char **argv);

int do_block_addr_type_info(int nargs, char **argv);

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

На момент написания статьи (август 2019 г.) emmcparm периодически обновлялся с версии 2.6.0, выпущенной 27 мая 2016 г. (возможно, более старые версии больше не доступны в Micron) до версии 4.4.0, выпущенной 5 июня 2019 г. У инструмента есть несколько функций, из которых оценка работоспособности является одной из множеств: 

root@colibriimx6:~# emmcparm_arm

spare_block

bad_block

erase_count

sect_count


Отслеживание ввода/вывода

Отслеживание ввода/вывода может быть полезным индикатором того, что флэш-память будет быстро изнашиваться, а также индикатором отладки, показывающим, какие приложения записывают слишком много данных. Отслеживание ввода/вывода генерирует входные данные для модели оценки износа, которая не зависит от стандартов JEDEC или отчетов о работоспособности разработчика eMMC. Следовательно, это средство достижения идеи гибкого инструмента, который можно распространить на различные технологии, все из которых используют raw NAND в качестве технологии хранения.

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

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

Затем ядро ​​Linux работает с этим вводом / выводом через то, что обычно называют стеком ввода / вывода или стеком хранения. На последнем этапе он отправляет данные на устройство через низкоуровневый драйвер устройства, который в случае eMMC должен соответствовать стандарту JEDEC. На максимально возможном уровне на рисунке 11 показаны стеки для устройств raw NAND и eMMC.

Рисунок 11: Стек ввода / вывода для eMMC и raw NAND

Мы можем пройтись по стеку ядра сверху вниз:

Рисунок 12. Упрощенный обзор структуры ядра Linux. (Источник: Википедия )
  • Виртуальная файловая система — это уровень абстракции для пользовательского API.
  • Файловая система сама реализует определенную структуру для определения концепций, связанных с файлами.
  • Уровень общего блока, который часто включает в себя планировщик ввода-вывода, является местом в стеке, которое обрабатывает все блочные операции ввода-вывода (BIO) и, таким образом, среди других аспектов, абстрагирует блочные устройства для файловой системы.
  • Планировщик ввода-вывода принимает очередь запросов ввода-вывода и отправляет их драйверу блочного устройства в соответствии с определенным алгоритмом. Он пытается максимизировать производительность блочного ввода-вывода, и выбор планировщика может повлиять на задержку, пропускную способность и использование флэш-памяти.

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

Как показано на рисунке 13, ядро ​​Linux представляет собой сложную систему, которая реализует слои кэша через свой стек для предотвращения ненужного доступа к диску. Это вызывает беспокойство, потому что дисковые операции всегда были медленными; даже с появлением флэш-памяти и ее гораздо более быстрой работы теперь необходимо продлить срок службы устройства хранения, и кэши и очереди помогают в этом:

Рисунок 13: Кэши, буферы, очереди и синхронизации.

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

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

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

Измерение ввода / вывода при записи

Проблема становится более определенной с точки зрения мониторинга и учета всех записей, которые фактически достигают флэш-памяти:

  • Где в стеке Linux мы можем измерить записи, которые фактически достигают флэш-памяти?
  • Как мы измеряем это? (Какие инструменты мы можем использовать?)

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

Рисунок 14: Инструменты наблюдения производительности Linux. (Источник: Брендан Грег)

В ходе нашего исследования мы натолкнулись на iotop для отслеживания операций в пользовательском пространстве и blktrace / blkparse для точного отслеживания операций ввода-вывода на уровне блоков и того, что на самом деле достигает флэш-памяти. Поскольку мы не хакеры, и у нас еще есть много возможностей для исследований по этой теме, мы ни в коем случае не намекаем, что это лучшие или наиболее оптимизированные инструменты для работы. (Например, perf trace и eBPF также находятся в нашем перечне). Есть интересная статья на тему, под называнием трассировкой ввода-вывода Linux , а также многие другие ресурсы в Интернете, включая саму документацию ядра Linux. 

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

Давайте кратко рассмотрим на практике, как мы можем использовать iotop и blktrace.

У iotop есть несколько удобных опций, которые помогают с этой задачей, и очень легко собирать и анализировать метки времени, счетчики записи и процессы, ответственные за эти записи: 

root @ colibri imx6 : ~ # iotop –help

Options :

   o ,   only             only  show  processes  or   threads  actually  doing   I / O

   b ,   batch             non interactive  mode

   a ,   accumulated      show  accumulated   I / O   instead  of  bandwidth

   k ,   kilobytes        use   kilobytes  instead  of   a   human  friendly  unit

   t ,   time              add   a   timestamp  on  each   line   ( implies   batch )

   q ,   quiet            suppress  some  lines  of  header   ( implies   batch )

Вы можете увидеть пример ниже: 

root@colibriimx6:~# dd if=/dev/urandom bs=4k count=100000 | pv -L 25k > testfile

root@colibriimx6:~# iotop —only —batch —accumulated —kilobytes —time –quiet

TIME       TID         PRIO    USER       DISK READ  DISK WRITE  SWAPIN      IO    COMMAND

20190802 03:11:19    50 be/4 root          0.00 K     24.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:20    50 be/4 root          0.00 K     52.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:21    50 be/4 root          0.00 K     80.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:22    50 be/4 root          0.00 K    104.00 K 0.00 % 0.00 % pv L 25k

20190802 03:11:23    50 be/4 root          0.00 K    128.00 K 0.00 % 0.00 % pv L 25k

Когда дело доходит до blktrace, все немного сложнее. Пора обратиться к документации. Запуск его в режиме реального времени без фильтров может привести к огромному количеству вывода: 

oot@colibriimx6:~# blktrace -o — /dev/mmcblk1 | blkparse -i —

179,0    0       26     0.000114661   304  A  WS 4509800 + 8 < (179,2) 4468840

179,0    0       27     0.000117328   304  Q  WS 4509800 + 8 [jbd2/mmcblk1p2]

179,0    0       28     0.000119661   304  M  WS 4509800 + 8 [jbd2/mmcblk1p2]

179,0    0       29     0.000127328   304  U   N [jbd2/mmcblk1p2] 1

179,0    0       30     0.000131661   304  I  WS 4509736 + 72 [jbd2/mmcblk1p2]

179,0    0       31     0.008860277   279  D  WS 4509736 + 72 [kworker/0:3H]

179,0    0       32     0.012586780   279  C  WS 4509736 + 72 [0]

К счастью, как в blktrace, так и в blkparse, реализованы фильтры, облегчающий. В таблица 3, коротко перечислены описания:

barrier атрибут barrier 
complete завершенный драйвером
fs FS запросы
issue обращение к драйверам
pc

команды пакетной обработки

queue операции с очередями
read чтение следа
requeue операции запроса
sync атрибут synchronous
write запись следа
notify сообщения, уведомляющие о трассировке

Таблица 3: Маски фильтра (источник: руководство по blktrace)

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

  • C — завершено: ранее выданный запрос был выполнен. Вывод детализирует сектор и размер этого запроса, а также его успех или неудачу.
  • I — вставлено: запрос отправляется в планировщик ввода-вывода для добавления во внутреннюю очередь и последующего обслуживания драйвером. Запрос полностью сформирован на данный момент.

Оценка продолжительности жизни

Регистрируя отслеживание ввода-вывода и состояние флэш-памяти, можно определить две корреляции:

  • Флэш-память работоспособна с течением времени
  • Флэш-память работоспособна относительно скорости записи

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

Данная выносливость измеряется в циклах стирания:

Заданная выносливость в байтах или кратных:

Где:

  • L — продолжительность жизни в секундах
  • E — выносливость, выраженная числом циклов стирания (вверху) или байтов (внизу)
  • Cavg — это среднее глобальное количество блоков стирания; т. е. сумма счетчиков стирания блоков, деленная на количество блоков в секунду
  • Wavg — это скорректированная средняя скорость записи в байтах в секунду

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

Температура влияет на срок службы флэш-памяти. Вы должны принять во внимание использование режима pSLC, если доступно, использование статического и динамического выравнивания износа, наличие плохих блоков, что происходит, когда устройство находится рядом с EOL, и наличие запасных блоков, среди других возможностей.

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

Инструмент Flash Analytics, который в настоящее время разрабатывается в Toradex Labs, представляет собой инструмент, разработанный для того, чтобы абстрагироваться от всей сложности оценки износа устройств eMMC самостоятельно. Мы представили принципы, предостережения, краеугольные случаи и сложность этой задачи в этой статье. Надеемся, что становится понятно, почему это сложная задача, которую разработчики программ скорее всего будут избегать.

Рисунок 15. Функции Flash Analytics Tool.

Как показано на Рисунке 15, представленном выше, инструмент предназначен для оказания всесторонней помощи, а не только для оценки продолжительности жизни. Он предназначен для использования среды выполнения контейнера Docker с платформы Torizon, которая будет доступна в виде модульного решения, где вы выбираете, что использовать поверх базового модуля BSP.

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

На рисунке выше представлен пользовательский интерфейс. Предлагаем вам протестировать его из первых рук и рассказать нам, что вы об этом думаете.

Заключение

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

Рисунок 16: Оценка и прогнозирование продолжительности жизни raw NAND .

Комплексный подход предлагает некоторые преимущества по сравнению с более простым расчетом. В дополнение к более точному результату, это также предоставляет вам возможности мониторинга и возможность запуска сигналов тревоги для более прогнозирующего обслуживания. В конце концов, ряд низкоуровневых и высокоуровневых инструментов, в том числе emmcparm, mmc-utils от Micron и Toradex Flash Analytics Tool, могут облегчить ваши усилия по созданию надежных решений. Мы надеемся, что вы хорошо провели время, читая этот пост.

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

Оригинал статьи вы можете прочитать здесь.

Понравилась статья? Поделить с друзьями:
  • Как проверить ssd nvme на наличие ошибок
  • Как проверить wordpress на ошибки
  • Как проверить dll файлы на ошибки
  • Как проверить ssd kingston на наличие ошибок
  • Как проверить windows 7 на ошибки и исправить