Особенности работы parallel NAND-flash

[Le ecureuil]

В массовых моделях роутеров до недавнего времени преобладало полное господство SPI-NOR (serial) флэш-памяти. Она недорога, удобна, и очень стандартизована - в принципе, ее можно менять на платах даже между разными вендорами без каких-либо изменений в софте. В том числе, подобные устройства легко ремонтировать при появлении признаков износа - выпаивание старой, прошив и запайка новой микросхемы занимает пять минут с перекурами. Даже более, на многих моделях изначально разводят контактные площадки сразу и под SOIC-8, и под SOP-16, соединяя одинаковые пины и позволяя ставить любую флешку любого формфактора.

Но кроме преимуществ у SPI-NOR есть и недостатки. В первую очередь, это скорость записи, которая для сравнимого по цене nand выше почти на 2 порядка. Затем идет высокая удельная стоимость, которая к середине 2010-х годов сравняла по стоимости 16 Мбайт serial-NOR и 128 Мбайт parallel-NAND. Это привело к тому, что начинает использоваться более быстрая NAND-память в параллельном варианте. На данный момент parallel NAND активно вытесняется serial NAND, который собрал самые лучшие черты обоих типов флэш-памяти, но о нем здесь разговора не будет - с точки зрения замены чипов все сильно похоже на serial NOR.

Итак, в середине 2010-х годов начинается проникновение parallel-NAND флэш-памяти. С точки зрения износоустойчивости она представляет собой все тот же SLC-тип с 100 000 циклами перезаписи, но с точки зрения софта она изначально выстроена иначе. На NAND-flash допускается наличие видимых пользователю "битых" блоков уже с завода; причем их количество может расти по мере старения микросхемы. Потому применение NAND автоматически влечет за собой использование ECC для проверки данных и систему ремапа "плохих" блоков в "хорошие"; а также их запас на случай замены.

Здесь нужно сделать отступление о том, что логическая организация raw flash в Linux не является ни классическим блочным, ни классическим символьным устройством. Существует особая подсистема MTD (memory technology device). Она принимает на вход микросхему NAND в виде "как есть", то есть массив страниц и блоков (страница - минимально адресуемый для чтения/записи элемент, блок - минимально стираемый элемент; обычно блок заметно больше страницы; типичные значения для микросхем в 128 Мбайт: 2 Кбайт на страницу, 128 Кбайт на блок). Затем mtd внутри себя производит операции, за которые отвечает FTL (flash translation layer), например remap плохих блоков, выравнивание износа (wear leveling), особый стиль стирания - и после этого устройство доступно как "обычное" блочное, навроде жесткого диска.

Также стоит отметить, что алгоритм работы с "плохими" блоками определяется не столько производителем flash-памяти, сколько производителем NAND-контроллера и драйвера. Например, один и тот же чип flash с геометрией страница/oob/блок 2048/64/128K будет совершенно по-разному вести себя с чипсетом RT63368 (контроллер с т.н. BMT-таблицей) и MT7621 (контроллер со skip-листами). Основная заметная разница между BMT и SKIP в том, что SKIP просто помечает и пропускает "плохие" блоки, но при этом не скрывает их из вида. BMT-контроллер же производит прозрачный remap, и наружу никогда "плохие" блоки не выдает, а только их замены из подменного фонда.

Из-за такой очень своеобразной специфики работы для Flash плохо подходят традиционные ФС, особенно журналируемые. Постоянная запись и стирание определенного, строго заданного количества блоков гарантированно выведет их из строя. Поэтому были разработаны как особые ФС (JFFS2, Yaffs2, LogFS, F2FS), так и целые "многослойные" решения (например UBI/UBIFS), которые целиком заменяют весь блочный стек вида "device > device-mapper > lvm > filesystem" на "raw flash > ubi > ubifs (filesystem)", при этом позволяя как эффективно управлять местом, скрывая внутри все сложности FTL навроде wear leveling и обработку "плохих" блоков.

Для работы opkg-раздела в итоге был выбран вариант UBI + UBIFS, поскольку при этом максимально рационально используется ресурс перезаписей flash (ubi сам всегда делает wear leveling), а также слой ubi отвечает за обработу видимых "плохих" блоков.

Но и это еще не все - поскольку при работе с NAND "все начинается с контроллера", это приводит к несовместмости форматов записанного на flash на разных устройствах. Если SPI-NOR flash можно прошить обычным файлом на ПК через программатор, и это в неизменном виде будет работать на устройстве, то в случае с NAND "программатором" является сочетание "драйвер - контроллер SoC - чип", и записанное на ПК через программатор будет представлять собой кашу с точки зрения SoC. Этот вариант flash можно программировать или напрямую с устройства в замкнутом цикле, или (например) через аппаратные отладчики навроде JTAG.

Давайте рассмотрим эту плату:

Казалось бы, что такого особенного? Обычный ZK LTE в виде платы с собственной персоной, ничего необычного (кроме отсутствия модема). Если не переворачивать...

Что это такое сзади? Давайте рассмотрим поближе

Теперь стало понятнее - это сменная панель для корпуса TSOP-48, а именно для микросхем parallel-NAND flash-памяти.

Расмотрим еще, как именно панель крепится к плате:

В "неофициальных" кругах это чудо инженерной мысли получило прозвище "матерь всех NAND", поскольку именно здесь можно запрограммировать NAND в понятном SoC формате.

Чтобы "добить" всю эту историю нужно понять, что процессор должен откуда-то начать загрузку. Да, у него обычно есть выводы, замыкая которые в землю можно выбрать режим flash - SPI NOR / parallel NAND, но от этого не легче. Прочитав нулевую страницу NAND чип увидит только "ff" полностью стертой микросхемы, впадет в осадок и все будет выглядеть как полный кирпич. То есть на устройство нужно записать bootloader, но это невозможно сделать из-за несовместимости форматов, а без него все так и останется кирпичом.

К счастью, именно у чипа RT63368 есть встроенная крохотная ПЗУ с микрозагрузчиком. Загрузившись в этот recovery режим можно дальше через xmodem передать драйверы RAM и NAND, включить их в работу и, затем передав через xmodem нужные данные корректно запрограммировать их на flash. Очень удобный способ "вытягивания себя за волосы", и особенно удобный для экспериментов с bootloader. Если на 7621 ваши опыты привели к стиранию flash, то кроме JTAG у вас нет никаких шансов; в случае с 63368 достаточно загрузиться в recovery-режим, записать новый bootloader и продолжить как ни в чем не бывало.

Ну и понятно, что на этапе разработки устройств с NAND это устройство на базе ZKLTE очень сильно помогло с разметкой и программированием parallel NAND flash.

 

 

Все это было написано, чтобы стало максимально понятно, что постоянная мелкая запись на flash - это очень вредно, и ее нужно минимизировать. Если нужен log - лучше разместить его в /tmp. Размещение БД на flash тоже не самая лучшая идея. А в связи с тем, что замена parallel NAND малореальна, то и "убитая" flash остается такой навсегда - до смены устройства. К частью, это касается только испорченных разделов, соседние этому не подвержены. И что радует еще сильнее - новые модели оснащаются уже SPI-NAND, который восстаналивается в программаторе в разы лучше.