Полное руководство по накопителям Rockchip: flash, загрузка, разделы, запись и Vendor Storage

Общая основа — полный технический текст RK-SM-YF-017, китайская V2.2.0, сверенный по главам с английским оригиналом и дополненный его уникальными материалами. На английской обложке указана V2.5.0, но таблица изменений заканчивается V2.2.0; обложка не доказывает новизну всего содержания. Китайская версия использует китайские оригинальные рисунки, английская, русская и немецкая — английские. Дополнительные рисунки только из английского оригинала явно отмечены во всех языках. Источник указывает «все продукты» без версии ядра; это не подтверждает поддержку каждой платы ArmSoM. Это справочник по платформе: проверьте SoC, контроллер и компонент памяти, SDK/BSP, BOOTROM, Loader, U-Boot, ядро и разметку. Аппаратная проверка ArmSoM не проводилась. Описания испытаний производителя и цены — сведения оригинала и исторические примеры, а не измерения ArmSoM, актуальные предложения или обязательства поставки.

Безопасность: стирание, прошивка, efuse/OTP, изменение разделов и запись Vendor ID могут вызвать потерю данных или необратимые изменения. Пример записывает ID 1 (SN); не запускайте его на производственных устройствах. Сначала сохраните идентификационные данные и прошивку. Страница не выполняет команды.

ArmSoM Docs · Rockchip Linux kernel · EDITORIAL-NOTES

Дополнительные документы оригинала (соответственно: разделы, U-Boot, Vendor Storage, производственная запись, открытое flash-решение и два накопителя):

• Rockchip_Introduction_Partition
• Rockchip-Developer-Guide-UBoot-nextdev-CN
• RK Vendor Storage Application Note
• Rockchip量产烧录指南_v1.2
• Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN
• Rockchip_Developer_Guide_Dual_Storage_CN

Различия источников и принятый подход

Таблицы ниже последовательно используют согласованную китайскую V2.2.0. Противоречащие английские значения не подменяют её незаметно:

• §2.3: в китайском указаны корпуса SPI NOR 5x4 SOP8/8x6 WSON, на английской стр. 9 — только 5x4 SOP8. Сохранена более полная китайская запись.
• §2.8: английская стр. 17 уточняет ECC SLC NAND / Nand V6 как 16 bits per 1KB; китайская таблица указывает 16bits ECC, а текст §3.1 отдельно — 16bits/1KB. Английское уточнение приведено здесь без переписывания таблицы.
• §4.1: китайская стр. 23 указывает SD Boot RK2108 как N, английская стр. 25 — Y. Для RK3328 и RK3399 китайская таблица даёт EMMC/NAND Boot Y/N, английская — N/Y для обеих моделей. SPI NAND RK3399: Y*1 в китайском и Y в английском. Китайской строке RK3229 соответствует английская RK3228. Это противоречия оригиналов, требующие проверки; таблицы не подтверждают загрузочные возможности платы.
• §4.2: английская стр. 26 дополнительно ограничивает USB1 RK3568/RK3566 записью 3.0 OTG (RK3568 Only); китайская стр. 25 содержит лишь 3.0 OTG. Ограничение сохранено для проверки адаптации; из него не выводится общая поддержка RK3566.
• §4.3: в обеих таблицах порядка загрузки есть EMMC--; запись сохранена до уточнения. Разрыв схем вызван разбиением PDF на страницы; обе части сохранены без перерисовки и догадок о соединениях.
• §7.2: путь таблицы drivers/rkand не совпадает с последующим ./drivers/rk_nand/. Оба сохранены. Имена API vendor_storage_read, rk_vendor_write и строки кода % s, % x также сохранены; компилируемость и безопасность запуска примеров не подтверждены.
• §6.1.4–6.1.5: оба оригинала сравнивают Linux-инструмент с «инструментом Android»; это не заменено на Windows. Формулировка об обратном чтении для RB_CHECK_OFF и полярность флага неясны; нельзя выводить значения настройки из имени.

1. Правила наименования

2. Введение во flash-память

2.1 Типы flash-накопителей

В широком смысле flash — это все энергонезависимые накопители на основе NAND flash и NOR flash: например, EMMC и SPI flash в устройствах RK, а также ставшие распространёнными PCIe SSD, SATA SSD и UFS. Ниже поясняются различия между ними. Накопитель в основном включает две части: кристалл памяти и интерфейсный контроллер, обычно называемые die и controller.

2.1 Типы flash-накопителей: оригинальная схема, английский источник, стр. 7

Кристалл flash непосредственно хранит пользовательские данные, как NAND Flash Array на рисунке. Производитель выпускает кристаллы разной ёмкости и объединяет их с разными контроллерами, получая накопители для различных отраслей. Например, NAND flash die с интерфейсом EMMC образует EMMC, а NOR flash die с SPI — SPI flash. Как и микросхемы RK, такие накопители обычно исполняют внутреннюю прошивку Firmware. Ниже приведены некоторые варианты устройств:

Примечания:

• Накопители flash развиваются в сторону более быстрых интерфейсов, большего внутреннего параллелизма и большей ёмкости.
• Помимо перечисленных распространённых типов, продукты RK также поддерживали SD NAND в корпусах поверхностного монтажа.
• Всем устройствам на основе NAND flash нужен алгоритм FTL для управления NAND; причины объясняются в разделе об основах NAND.
• PP NAND и SPI NAND не содержат собственного FTL, поэтому он либо файловая система с FTL должны быть реализованы на стороне хоста.

Следующий рисунок поясняет взаимосвязь производителей кристаллов, брендов памяти и контроллеров RK:

2.1 Типы flash-накопителей: оригинальная схема, английский источник, стр. 9

Дополнение английского оригинала (стр. 9): зависимость MLC/TLC NAND от FTL, площадь NandC в SoC и число выводов PP NAND привели к постепенному отказу RK от интерфейса PP NAND; поэтому источник описывает текущую flash-линейку главным образом как SPI flash. Это контекст исходной платформы, а не утверждение о всех современных продуктах ArmSoM.

2.2 Выбор flash-памяти

SLC NAND, SPI NAND и SPI NOR: справочник выбора GigaDevice позволяет ознакомиться с ассортиментом компонентов flash. См. ссылку на справочник выбора компонентов GD.

2.3 Краткое сравнение типов flash

Краткое сравнение нескольких типов основного накопителя RK:

Примечания:

• EMMC имеет большую ёмкость, сравнительно высокую стабильность и высокую скорость чтения/записи, но дороже за один компонент, занимает больше места и требует длительной инициализации, обычно порядка сотен миллисекунд.
• SPI NAND отличается малым корпусом, низкой ценой и большей ёмкостью, чем NOR flash. Однако ECC и алгоритмы управления памятью ограничивают скорость чтения/записи и стабильность в среднем обычным уровнем.
• SPI NOR имеет малый корпус, высокую стабильность, низкую цену и малые программные затраты на инициализацию. Особенно быстро загружается небольшая прошивка, но непрерывная передача медленнее EMMC, а при росте ёмкости компонент дорожает.
• Из-за зависимости MLC/TLC PP NAND от FTL, большой площади NandC на кристалле и множества выводов RK в последние годы отказалась от интерфейса PP NAND. Поэтому под малой ёмкостью здесь в основном понимается SPI flash, а MLC/TLC PP NAND в таблицу не включены.
• Цена указана за компонент; стоимость одного МБ уменьшается при росте ёмкости.

2.4 Распространённые корпуса flash

Сравнение нескольких корпусов:

2.4 Распространённые корпуса flash: оригинальная схема, английский источник, стр. 10

2.4 Распространённые корпуса flash: оригинальная схема, английский источник, стр. 11

Распространённые корпуса SLC NAND / SPI flash:

2.4 Распространённые корпуса flash: оригинальная схема, английский источник, стр. 11

Описание корпусов

2.5 Цены flash-памяти

Примечания:

• Выше приведены рыночные предложения определённых производителей без наценки за взаимодействие с заказчиком.
• Цены предназначены главным образом для сравнения типов памяти и иллюстрации роста цены с увеличением ёмкости внутри одного типа.

2.6 Основные принципы NAND

Физическая структура массива NAND flash на примере распространённой структуры SLC NAND:

2.6 Основные принципы NAND: оригинальная схема, английский источник, стр. 13

Примечания:

• SLC NAND состоит из нескольких блоков flash, обычно 1024, 2048 или 4096; на рисунке показаны 2048 блоков.
• Блок — минимальная единица стирания. Размер блока SLC NAND обычно 128KB или 256KB; стирание меняет логический 0 на 1.
• Блок обычно содержит 64 страницы; в некоторых компонентах их до 128.
• Страница — основная единица программирования и чтения NAND. Её размер для SLC NAND обычно 2KB или 4KB; программирование меняет логическую 1 на 0.
• Логические 0 и 1 физически соответствуют уровням напряжения в каждой битовой ячейке.

Далее приведён пример SLC NAND с плавающим затвором:

2.6 Основные принципы NAND: оригинальная схема, английский источник, стр. 14

Данные flash фактически хранятся на внутреннем плавающем затворе Floating gate. Напряжения на управляющем затворе Control gate и подложке определяют заряд или разряд. Логический 0 либо 1 зависит от превышения напряжением заряда порога Vth:

• При программировании NAND высокое напряжение на управляющем затворе заряжает плавающий затвор. Выше Vth это 0.
• Data Retention: заряд поступает под высоким напряжением и сохраняется без стирания, но электрическое поле между затвором и подложкой постепенно вызывает утечку.
• P/E cycle: с ростом числа циклов Program/Erase стареет оксид между затвором и подложкой, ухудшая удержание заряда.
• При стирании NAND высокое напряжение на подложке разряжает плавающий затвор. Ниже Vth это 1.

Wordline и Bitline: для эффективного заряда/разряда тысяч ячеек используются вспомогательные цепи Bitline/Wordline. Последовательно соединённые ячейки образуют NAND string, подключённую концами к Bit Line и Source line. Управляющий затвор каждой ячейки связан с Wordline; управляемые одной Wordline ячейки образуют логическую страницу. В совокупности они образуют блок с общей подложкой, поэтому минимальная единица стирания — блок.

2.6 Основные принципы NAND: оригинальная схема, английский источник, стр. 15

2.6 Основные принципы NAND: оригинальная схема, английский источник, стр. 15

Источник изображения Bitline. Основы SLC/MLC/TLC/QLC: Bitline управляет зарядом и разрядом, определяя уровень ячейки. Управление количеством заряда также позволяет хранить несколько уровней в одной ячейке:

• SLC (Single Level Cell): 1 бит, два логических уровня 0/1.
• MLC: 2 бита, четыре уровня 0–3.
• TLC: 3 бита, восемь уровней 0–7.
• QLC: 4 бита, шестнадцать уровней 0–15.

2.6 Основные принципы NAND: оригинальная схема, английский источник, стр. 16

Изображение взято из Интернета.

Нарушение удержания заряда в битовой ячейке вызывает инверсию битов. Физическое устройство NAND допускает нестабильность напряжения при заряде/разряде и старение структуры из-за циклов записи/стирания. Это ухудшает удержание заряда, меняет логические уровни и вызывает bit flip. Пользователь может наблюдать ошибки данных, сбои прошивки или повреждение файловой системы. Поэтому NAND использует ECC различной корректирующей способности для продления срока службы и повышения надёжности.

Из физических принципов следуют особенности NAND:

• Обновление с переносом (out-of-place update): программирование меняет ячейку только из 1 в 0, поэтому перед повторным программированием нужно стирание. Программирование выполняется страницами, стирание — блоками из нескольких страниц. Повторная запись одного логического адреса в то же физическое место потребовала бы стирания при каждом обновлении. Поскольку это долго и изнашивает flash, FTL обычно отображает обновлённые данные в новое место.

• Ограниченное число P/E: каждый блок NAND имеет предел циклов стирания. После достаточного числа циклов он становится нестабильным, записанные данные ошибочны, возможно и отсутствие успешного стирания. Старые техпроцессы SLC NAND обычно обеспечивали 100K циклов; новые более дешёвые техпроцессы могут иметь меньший ресурс.
• Более высокая производительность: в отличие от механического диска, flash не имеет механики и поиска дорожки, поэтому накладные расходы доступа к адресам примерно одинаковы. Случайное чтение SSD существенно быстрее механического диска. Теоретически случайный и последовательный доступ могли бы быть одинаковыми, но flash поддерживает кэширование: при последовательном чтении следующая страница заранее загружается во внутренние регистры. Поэтому последовательный доступ быстрее случайного.
• Неодинаковая скорость чтения и записи: ввод электронов в плавающий затвор (запись) занимает больше времени, чем обнаружение его электрического состояния (чтение). Поэтому FTL старается уменьшить число записей и стираний.

2.7 Основные принципы NOR

Принципы NOR похожи на NAND, но имеют отличия:

• Механизм ячейки аналогичен, однако её концы подключены непосредственно к Bit Line и Source line. Это стабильнее, поэтому NOR обычно не требуется ECC против физического старения, хотя крайне редкие инверсии битов возможны. Окружающая схема сложнее, поэтому кристалл той же ёмкости дороже.
• Размеры блоков и страниц отличаются от NAND.
• Обычно поддерживаются единицы стирания Block и Sector: соответственно 64KB и 4KB.
• Обычная минимальная единица программирования page — 256B.

2.8 Зависимость NAND от ECC

Интеграция в RK:

Примечание: некоторые SLC NAND имеют встроенную ECC. Остальные PP NAND не интегрируют ECC и используют ECC контроллера.

2.9 Заводские дефектные блоки NAND

Физические особенности NAND flash допускают некоторую долю заводских дефектных блоков. При выпуске в определённой области, обычно в первом байте spare (область OOB), записывается заводская метка bad block. Обычно эти метки нельзя повреждать. Исключение — W25N01GV SPI NAND.

2.10 Ресурс NAND и ошибки ECC

Ресурс NAND обычно характеризуется циклами P/E (стирание/запись). При определённом числе циклов компонент выходит из строя. В испытаниях оригинала отдельные некачественные компоненты проявляли сбои примерно после 30K циклов. Если это не совпадает с паспортом производителя, заказчику рекомендуется обратиться к нему для диагностики.

При приближении к концу ресурса типичны предупреждения:

• Число инверсий прочитанных битов требует обновления данных.
• Данные остаются корректными, работа нормальная.

При достижении или превышении ресурса возможны:

• Необходимость обновления из-за инверсий, при этом данные корректны и работа нормальная.
• ECC fail при чтении: данные некорректны. Повторные низкоуровневые попытки могут сильно загружать CPU потока.
• Частичная потеря данных, вызывающая сбои верхнего уровня.
• Ошибка стирания/записи: блок помечается дефектным без влияния на использование и без потери данных.

2.11 Основные технологии алгоритмов FTL для NAND

• Отображение адресов: устройство flash — чёрный ящик с NAND flash и FTL. Приложения обращаются по логическим адресам, а FTL отображает их на физические и хранит актуальное местоположение данных каждого адреса.
• Сборка мусора: по мере записи часть данных в блоках становится недействительной. Корректные данные переносятся, а блок стирается для новых записей.
• Выравнивание износа и управление дефектными блоками: ресурс P/E каждого блока ограничен. Одни блоки могли бы постоянно использоваться и изнашиваться, другие — оставаться нетронутыми из-за редкого доступа. FTL балансирует использование через сборку мусора и управление пулом свободных блоков; в идеале все блоки достигают порога износа одновременно. Flash содержит заводские дефектные блоки, а новые могут возникать при эксплуатации, поэтому FTL избегает непригодных блоков и своевременно переносит данные из нестабильных в надёжные области.

2.12 Развитие решений NAND (PP NAND и SPI NAND)

• Ранние продукты RK поддерживали только закрытое решение FTL rkflash, главным образом RK3326, RK3308 и RV1108.
• Потребности заказчиков в UBIFS, MTD и записи программатором потребовали драйверную инфраструктуру MTD.
• Начиная с RK3308, драйверы, алгоритмы и файловая система такого решения открыты; внутри компании оно называется открытым решением MTD в отличие от закрытого.
• Для RK3308 поставляется низкоуровневый драйвер, а верхние уровни самостоятельно интегрирует заказчик с достаточной компетенцией.
• Команда RK3308 ранее предоставляла конфигурацию SDK для открытого решения PP SLC NAND MTD.
• Затем SDK полностью перешли на MTD с более подробной поддержкой и инструкциями:

RV1126, RK3568 и последующие микросхемы.

2.13 Контроллеры flash на стороне хоста

2.13.1 Контроллер SFC

Serial Flash Controller (SFC) управляет передачей между системой микросхемы и последовательной NOR/NAND flash. Возможности:

• Поддержка SPI NOR и SPI NAND.
• Передача SPI NOR по 1, 2 и 4 линиям.
• Передача DMA.

2.13.2 Контроллер FSPI

FSPI (Flexible Serial Peripheral Interface) — гибкий контроллер последовательной передачи, новая конструкция SFC. Название изменено из-за изменения набора поддерживаемых устройств. Возможности:

• SPI NOR, SPI NAND, PSRAM и SRAM с протоколом SPI.
• Передача SPI NOR по 1, 2 и 4 линиям; версия 8 и новее поддерживает 8-линейную DDR-передачу.
• Технология XIP.
• Передача DMA.

2.13.3 Контроллер NandC

NandC передаёт данные между NAND flash и основной микросхемой, поддерживая прямую передачу в режиме master шины AHB. Для разных применений RK в основном использует две версии: функционально насыщенную NandC V9 и упрощённую NandC V6 с меньшей площадью кристалла. Версия обычно выбирается по рыночному назначению микросхемы. NandC V6 поддерживает только SLC NAND и используется для малой ёмкости, обычно менее 512MB. NandC V9 поддерживает MLC и TLC и применяется в продуктах большей ёмкости.

2.13.4 Интерфейс SPI общего назначения

FSPI — специализированный интерфейс SPI flash. В SoC RK обычно также есть несколько универсальных интерфейсов SPI, к которым можно подключить внешнюю SPI flash, но устройства на них обычно нельзя использовать как bootdev.

2.14 Статистика задержки выхода SPI flash

Сводка:

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

3. Проверка компонентов памяти

3.1 Обзор проверки SLC NAND/SPI NAND/SPI NOR

Пояснение проверки: компоненты малой ёмкости относительно стабильны и обычно хорошо совместимы с контроллером. Поэтому для большинства выполняется только функциональная проверка; надёжность и стабильность в основном зависят от масштабных испытаний производителя и его отчётов.

1. Функциональная проверка

2. Базовая проверка надёжности жизненного цикла

3. Проверка программной совместимости и стабильности

Примечания:

1. Для SPI NOR выполняется только функциональная проверка: компонент относительно стабилен и совместим, а выявление предельных случаев требует очень большого числа тестов. Надёжность и стабильность обеспечивает производитель компонента.

2. TBD: соответствующие испытания проводятся только для компонентов с существенными изменениями совместимости или крупных обновлений драйвера. Обычно этот пункт не тестируется.

3. Для SLC NAND ECC в основном обеспечивает NAND-контроллер RK с коррекцией до 16bits/1KB. Избыточность и стабильность высоки, поэтому дополнительная проверка надёжности компонента не выполняется; её обеспечивает производитель.

Методы проверки:

1. Функциональная проверка: совместимость контроллера, успешная загрузка системы, нормальная работа базовых функций и прохождение 10 циклов стресс-теста flash.

2. Проверка надёжности компонента. Retention: после выполнения определённой доли циклов P/E проводится температурная выдержка, имитирующая срок службы продукта.

3. Проверка программной совместимости и стабильности при внезапном отключении питания; рекомендуется испытывать реальный продукт.

Испытание:

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

Продолжать 7 дней: это соответствует базовым требованиям большинства продуктов — около 10K операций чтения/записи и около 10 000 отключений питания.

3.2 Обзор требований к образцам RK flash

3.2.1 Условия проверки

Общие сведения:

1. К памяти малой ёмкости относятся SLC PP NAND, SPI NAND и SPI flash.

2. Приоритет отдаётся основным компонентам, находящимся в продаже.

3. Канал предназначен для проверки драйверов; коммерческие рекомендации сейчас не предоставляются.

4. Список поддержки памяти малой ёмкости обычно обновляется каждые 1–2 месяца. Срок проверки компонента различается, но она завершается до обновления списка.

5. Отправьте не менее 10 pcs и документацию соответствующего компонента.

6. Приоритет имеют компоненты, срочно необходимые заказчикам.

Особые требования SPI NAND:

1. Компонент должен иметь собственный модуль ECC; иначе он не поддерживается, поскольку контроллер RK не интегрирует такой модуль.

2. В конце flash не должно быть последовательных дефектных блоков: они повреждают информацию хвостовой таблицы bad block. Если проблему устранить нельзя, поддержка невозможна.

3. Блок нечётной плоскости должен выбираться без plane-select bits. У некоторых двухплоскостных компонентов выбор нечётной плоскости требует этих битов в передаваемом адресе. Они имеют проблемы совместимости с платформой RK, требуют доработки драйвера и не рекомендуются.

Особые требования SPI NOR:

1. Для SPI NOR требуется tRST менее 200us.

3.2.2 Процедура проверки

Внутренние функциональные и стресс-тесты проверяют совместимость компонента с контроллером. Собственная стабильность и результаты нагрузочных испытаний определяются спецификацией производителя. Проверки выполняются только на типовых платформах. Контроллеры малой памяти RK используют совместимый IP, поэтому проверка RK3568 охватывает большинство SoC с соответствующим контроллером. Например, SPI NAND, проверенная на RK3568, совместима с RV1126 и RK3308.

3.2.4 Передача исправлений заказчику

Для новых компонентов flash, особенно SPI flash, после проверки обычно нужен патч исходного кода. Заказчику, которому требуется драйвер, следует создать обращение на платформе RK Redmine; пакет патча будет предоставлен онлайн.

4. Процесс загрузки устройства

Загрузка — программная последовательность от включения питания до завершения запуска системы. Далее показана загрузка Linux:

4. Процесс загрузки устройства: оригинальная схема, английский источник, стр. 24

4.1 Поддержка загрузки BOOTROM в SoC RK

*1: поддерживается аппаратно, но не поддерживается выпущенным пакетом SDK.

4.2 Характеристики интерфейсов памяти SoC RK

Примечание: отметка Boot в столбце SPIx или SFC означает возможность загрузки BOOTROM через соответствующий SPI/SFC.

4.3 Алгоритм BOOTROM

После подачи питания RK первым исполняется неизменяемый встроенный масочный код BOOTROM. Он есть и в AP, и в MCU. BOOTROM запускается первым, обнаруживает внешние накопители и загружает их код Loader. Порядок опроса зависит от микросхемы. Ниже приведён пример загрузочного алгоритма BOOTROM:

4.3 Алгоритм BOOTROM: оригинальная схема, английский источник, стр. 28

4.3 Алгоритм BOOTROM: оригинальная схема, английский источник, стр. 29

Примечания:

• Некоторые микросхемы используют уровни входа ADC Key для выбора накопителя, опрашиваемого BOOTROM. При неудаче устройство сразу переходит в maskrom mode.
• Наличие внешнего устройства обычно определяется чтением его ID.
• Если корректная прошивка не найдена ни на одном устройстве, maskrom mode ожидает её загрузки через заданный интерфейс, например USB/UART. Не каждая микросхема поддерживает обновление USB/UART.

Порядок загрузки BOOTROM по микросхемам

4.4 Алгоритм Pre Loader

Сборка RK SDK обычно создаёт MiniloaderAll.bin с двумя основными функциями: обеспечение процесса прошивки и запись образа IDB. Образ IDB — полезный образ, извлечённый из MiniloaderAll.bin, также называемый idblock; он записывается во flash. Обычно он объединяет ddr.bin и Pre Loader; некоторые микросхемы допускают дополнительные функциональные образы. В оригинале перечислены три основных типа Pre Loader: закрытый miniloader, U-Boot SPL и loader.

4.4.1 Miniloader

Введение: miniloader — закрытая прошивка Pre Loader RK, обычно объединяемая с ddr.bin и usbplug.bin в loader.bin. Структура показана ниже:

4.4.1 Miniloader: оригинальная схема, английский источник, стр. 31

Комментарии:

1. ddr.bin: прошивка инициализации DDR, сокращённо 471.

2. usbplug.bin: исполняемая прошивка для процесса записи, сокращённо 472.

3. miniloader.bin: закрытая прошивка Pre Loader.

4. MiniloaderAll.bin: единое имя файла SDK, фактически упакованный loader.bin соответствующей микросхемы.

5. При обновлении инструменты RK извлекают idblock.bin из loader.bin, записывают его и создают несколько резервных копий.

6. idblock объединяет ddr.bin и Pre Loader; в закрытом варианте Pre Loader означает miniloader.bin.

Упаковка Miniloader в репозитории rkbin. Для RK3308 перейдите в каталог rkbin SDK и создайте rk3308_loader_v1.xx.1xx.bin:

./tools/boot_merger ./RKBOOT/RK3308MINIALL.ini .
./tools/boot_merger ./RKBOOT/RK3308MINIALL_WO_FTL.ini . /* 尾缀为 _WO_FTL ⽂件、为开源存储⽅案选
⽤的 Pre Loader，⽂件系统选择ubifs或者jaffs2 */
./tools/boot_merger ./RKBOOT/RK3326MINIALL_SLC.ini . /* 尾缀为 _SLC ⽂件、为⼩容量存储（SLC
Nand、SPI Nand、SPI Nor）⽅案专⽤的 Pre Loader，内带rk ftl算法，不⽀持ubifs */

Как BOOTROM, Pre Loader опрашивает различные накопители для поддержки разных типов памяти:

4.4.1 Miniloader: оригинальная схема, английский источник, стр. 32

Код закрыт, поэтому пользователь не может самостоятельно изменить порядок загрузки.

Алгоритм загрузки:

4.4.1 Miniloader: оригинальная схема, английский источник, стр. 33

4.4.2 u-boot spl

Поддержку микросхем см. в Rockchip-Developer-Guide-UBoot-nextdev-CN. Для NAND и SPI NAND используются только открытые NAND-драйверы без FTL; рекомендуется UBIFS.

Введение:

4.4.2 u-boot spl: оригинальная схема, английский источник, стр. 34

Комментарии:

1. ddr.bin: прошивка инициализации DDR, сокращённо 471.

2. usbplug.bin: исполняемая прошивка для процесса записи, сокращённо 472.

3. spl.bin: прошивка SPL, собранная из исходного кода U-Boot; результат — spl/u-boot-spl.bin в каталоге U-Boot.

4. MiniloaderAll.bin: единое имя SDK, фактически пакет spl_loader.bin соответствующей микросхемы.

5. При обновлении инструменты RK извлекают idblock.bin из loader.bin, записывают его и создают несколько резервных копий.

6. idblock объединяет ddr.bin и Pre Loader. В варианте SPL это u-boot-spl.bin. RK SDK периодически собирает u-boot-spl.bin и сохраняет в соответствующем каталоге rkbin под именем rkxxxx_spl_vx.xx.bin.

7. Инструмент обновления ПК хранит две копии idblock для SLC NAND/SPI flash и пять для других накопителей.

С учётом BOOTROM выражение «загрузить xxx.bin и выполнить функцию xxx» означает следующее. Прошивка:

• BOOTROM загружает ddr.bin для инициализации DDR.
• BOOTROM загружает usbplug.bin и использует USB plug для записи.

Запуск:

• BOOTROM загружает ddr.bin для инициализации DDR.
• BOOTROM загружает spl.bin для функций Loader и загрузки последующих прошивок.

Некоторые микросхемы также включают mcu.bin и PCIe.bin в idblock с аналогичной целью: предварительно загрузить предварительный загрузчик.

Порядок опроса накопителей SPL:

4.4.2 u-boot spl: оригинальная схема, английский источник, стр. 35

Примечания:

• SPL поддерживает включение загрузки с SD: обнаружив карту с корректной прошивкой, он загружает с неё последующие образы и завершает SD-запуск.
• SPL с atags отдаёт приоритет накопителю, успешно обнаруженному BOOTROM; подробности atags см. в руководстве U-Boot.

Журнал работы SPL с накопителями:

U-Boot SPL 2017.09-gcc781e0266-230509-dirty #ldq (Nov 24 2023 - 00:15:39)
unknown raw ID 0 0 0
unrecognized JEDEC id bytes: 00, 00, 00
Trying to boot from MMC2
MMC: no card present
mmc_init: -123, time 0
spl: mmc init failed with error: -123
Trying to boot from MMC1                # bootdev 探测结果：MMC2(SD Card)、MMC1(EMMC)、
MTD0(SLC Nand)、MTD1(SPI Nand)、MTD2(SPI Nor)
No misc partition
Trying fit image at 0x4000 sector

Алгоритм загрузки:

4.4.2 u-boot spl: оригинальная схема, английский источник, стр. 36

Дополнение английского оригинала: на стр. 36–37 после текста SPL дополнительно приведены порядок опроса и схема Loader, повторённые далее в разделе Loader. В китайском оригинале здесь рисунков нет. Они сохранены ниже в исходном порядке; расположение не доказывает отдельный алгоритм исключительно для SPL.

4.4.2 u-boot spl: оригинальная схема, английский источник, стр. 36

4.4.2 u-boot spl: оригинальная схема, английский источник, стр. 37

4.4.3 loader

Поддерживаются RV1107, RV1108, RK3036, RK3128 и RK3229. Этот loader обычно используется для малой ёмкости и запускает ядро непосредственно, без U-Boot.

*1: В проектах RK3036, RK3128 и RK3229 с SLC NAND или EMMC обычно используется непосредственно miniloader.

Порядок опроса накопителей:

4.4.3 loader: оригинальная схема, английский источник, стр. 38

Алгоритм загрузки:

4.4.3 loader: оригинальная схема, английский источник, стр. 39

5. Разделы и хранение данных

5.1 Хранение данных

5.1.1 Введение в преобразование адресов

Большинство накопителей не имеет плоского отображения: логический сектор LBA преобразуется в физический сектор flash PBA. Это отображение выполняет FTL (Flash Translation Layer) с учётом износа, дефектных блоков и сборки мусора. Независимо от наличия FTL пользователи и файлы работают только с логическими адресами, а преобразование выполняет ПО. Для доступа к сектору 0x4000 связь следующая:

5.1.1 Введение в преобразование адресов: оригинальная схема, английский источник, стр. 40

При доступе интерфейса файловой системы к сектору 0x4000 преобразование адреса следующее:

5.1.1 Введение в преобразование адресов: оригинальная схема, английский источник, стр. 41

5.1.2 Разделы и логические адреса данных

5.1.2 Разделы и логические адреса данных: оригинальная схема, английский источник, стр. 42

5.2 Схемы таблиц разделов

В решениях RK используются три типа таблиц, сохраняемых на накопителе: MTD Partition, GPT и RK partition. Подробности см. в Rockchip_Introduction_Partition.

*1: Платформы ветки uboot-next больше не поддерживают MTD partition; при необходимости нужна собственная адаптация.

*2: Платформы uboot-next по умолчанию используют GPT; другие типы требуют адаптации.

5.2.1 MTD Partition

См. Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN.md.

5.2.2 GPT

GPT настраивается файлом parameter со структурой, похожей на MTD Partition. Четыре отличия:

1. Установите TYPE в GPT.

2. Не определяйте раздел parameter; даже определённый, он не используется.

3. Добавьте grow к последнему разделу.

4. Задайте UUID rootfs: значения SDK различаются, необходимо соответствие UUID rootfs в DTS.

FIRMWARE_VER:8.1
MACHINE_MODEL:RK3326
MACHINE_ID:007
MANUFACTURER: RK3326
MAGIC: 0x5041524B
ATAG: 0x00200800
MACHINE: 3326
CHECK_MASK: 0x80
PWR_HLD: 0,0,A,0,1
TYPE: GPT /* GPT 分区 */
CMDLINE:mtdparts=rk29xxnand:0x00002000@0x00004000 (uboot),0x00002000@0x00006000(trust),0x00002000@0x00008000 (misc),0x00008000@0x0000a000 (resource),0x00010000@0x00012000(kernel),0x00010000@0x00022000 (boot),0x00020000@0x00032000 (recovery),0x00038000@0x00052000(backup),0x00002000@0x0008a000 (security),0x000c0000@0x0008c000(cache),0x00300000@0x0014c000 (system),0x00008000@0x0044c000(metadata),0x000c0000@0x00454000 (vendor),0x00040000@0x00514000 (oem),0x00000400@0x00554000(frp),-@0x00554400 (userdata:grow)
uuid:rootfs=614e0000-0000-4b53-8000-1d28000054a9

Обновление GPT:

1. Инструмент читает определения разделов из parameter.

2. Получает ёмкость накопителя от Loader.

3. Меняет размер последнего раздела и создаёт файл GPT.

4. Записывает таблицу по адресу 0 и -33 в конце накопителя.

Примечание 1: сам файл parameter на накопитель не записывается.

5.2.3 RK partition

RK partition — собственная таблица со структурой, похожей на GPT, малым потреблением ресурсов и быстрой инициализацией, главным образом для RV1107/8 и MCU. Ниже приведён шаблон разделов Linux/Android:

#Flag ⽬前只有两个值，1 为分区需要下载，0 为不需要下载
#type ⽬前有 5 种值，0x1=Vendor 分区 0x2=IDBlock 分区 0x4=Kernel 分区 0x8=boot 分区 0x80000000 = 普通分区

#PartSize 和 PartOffset 字段的值都是以扇区为单位
[System]
FwVersion=16.12.23
# 如果 Nano=1, 则⽣成 nano 的 idblock
Nano=
# 如果 BLANK_GAP＝1, 则⽣成的 idblock 按每 2k 数据间隔 2k 空⽩保存
BLANK_GAP=1
#FILL_BYTE 表⽰分区尾部空⽩⽤什么数据填充，默认为 0
FILL_BYTE=
[IDBlock]
Flag=1
DDR_Bin=rk3399_DDR_800MHz_v1.17.bin
Loader_Bin=rk3399_miniloader_spi_nor_v1.14.bin
PartOffset=0x40
PartSize=0x780
[UserPart1]
Name=trust
Type=0x10
Flag=1
File=trust_1MB.img
PartOffset=0x800
PartSize=0x800
[UserPart2]
Name=uboot
Type=0x20
Flag=1
File=uboot_1MB.img
PartOffset=0x1000
PartSize=0x800

Обычный раздел

Ниже шаблон RTOS. Спецификация bits [8,10] поля Flag в оригинале действует только для продуктов RTOS:

#Flag:
#  bits filed:
#  [0]    : skip                  : 0 - disabled (default), 1 - enable
#  [2]    : no partition size     : 0 - diabled (default), 1 - enable
#  [8, 9] : property              : 0 - do not register (default), 1 - read only, 2 - write only, 3 - rw
#  [10]   : register type         : 0 - block partition (default), 1 - MTD partition
#type can suppot 32 partiton types,0x0:undefined 0x1:Vendor 0x2:IDBlock ,bit3:bit31 are available
#PartSize and PartOffset unit by sector
#Gpt_Enable 1:compact gpt,0:normal gpt
#Backup_Partition_Enable 0:no backup,1:backup
#Loader_Encrypt 0:no encrypt,1:rc4
#nano 1:generate idblock in nano format
[System]
FwVersion=1.0
Gpt_Enable=
Backup_Partition_Enable=
Nano=
Loader_Encrypt=
Chip=
Model=
[UserPart1]
Name=IDBlock
Type=0x2
PartOffset=0x80
PartSize=0x80
Flag=
File=../../Image/rk2108_loader.bin,../../Image/Boot2_Fake.bin
[UserPart2]
Name=rtthread
Type=0x8
PartOffset=0x100
PartSize=0xa00
Flag=
File=../../Image/rtthread.img
[UserPart3]
Name=root
Type=
PartOffset=0x1100
PartSize=0x6f00
Flag=0x305
File=../../Image/root.img

5.2.4 Разделы ENV

ENV (Environment-Variables) — механизм U-Boot для глобального управления и передачи данных через хеш-таблицу пар ключ–данные. Некоторые платформы RK сохраняют ENV во flash как раздел ENV, формируют сведения mtdparts из cmdlines, записывают их в таблицу ENV и передают от SPL или U-Boot ядру.

5.3 Редактор таблицы разделов parameter

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

5.3 Редактор таблицы разделов parameter: оригинальная схема, английский источник, стр. 47

5.4 Защита разделов от записи

5.4.1 Защита разделов блочных устройств от записи

EMMC и SD CARD в Linux — блочные устройства. NAND FLASH с rknand или rkflash также блочная. Следующие команды задают права доступа раздела. Пример 1: system только для чтения:

./busybox blockdev --setro /dev/block/by-name/system

Пример 2: system для чтения и записи:

./busybox blockdev --setrw /dev/block/by-name/system

Примечание: настройте раздел до монтирования. Если он смонтирован для записи и затем переведён в режим только чтения, файловая система сообщает ошибки.

5.4.2 Защита разделов MTD от записи

Разделы MTD обычно задаются через cmdline. Добавьте ro после имени, чтобы сделать раздел доступным только для чтения. Для защиты конкретного раздела измените mtdparts при передаче cmdline из U-Boot ядру. Пример: сделать boot только для чтения:

mtdparts=rk29xxnand:0x00002000@0x00004000(uboot),0x00004000@0x00006000(boot)ro,...

6. Запись прошивки

Основные способы записи прошивки при серийном производстве: обновление по USB, обновление с SD-карты и запись программатором.

6.1 Обновление по USB

Обновление по USB использует два протокола: rockusb и fastboot. Здесь описан только rockusb; сведения о fastboot см. в Rockchip-Developer-Guide-UBoot-nextdev-CN.

6.1.1 Блок-схема

6.1.1 Блок-схема: оригинальная схема, английский источник, стр. 49

AP rockusb: maskrom rockusb, miniloader rockusb и uboot rockusb. NVM: SPI NOR, SPI NAND, SLC NAND, EMMC, M/TLC NAND.

6.1.2 Windows: RKDevTool

Для схем GPT/RKPartition AP SDK предоставляет инструменты разработки для настройки и обновления всей прошивки либо отдельных разделов. Подробности см. в документации к инструментам. Полезные функции перечислены ниже:

1. Чтение таблицы разделов устройства: в режиме обновления Loader нажмите «Таблица разделов устройства».

2. В режиме MSC/MTP нажмите «Переключить», чтобы перейти в Loader.

3. В дополнительных функциях используйте «Войти в maskrom» для перехода из Loader в maskrom.

4. В режиме Loader или maskrom используйте «Перезапустить устройство». Интерфейс инструмента:

6.1.2 Windows: RKDevTool: оригинальная схема, английский источник, стр. 50

Дополнительные функции:

6.1.2 Windows: RKDevTool: оригинальная схема, английский источник, стр. 50

1. В режиме maskrom выберите и загрузите Loader для выполнения в DDR.

2. Распаковать update.img.

3. Выполнить скрипт.

4. Прочитать FLASH ID.

5. Прочитать сведения FLASH.

6. Прочитать сведения о микросхеме.

7. Прочитать дополнительные функции, поддерживаемые Loader.

8. Проверить готовность устройства.

9. Перезапустить устройство.

10. Перезапустить в maskrom, обычно для перехода из Loader в maskrom.

11. Перезаписать данные для очистки серийного номера. Эта операция может повредить прошивку.

12. Экспортировать структуру IDB из заголовка Loader.

13. Стереть диапазон по начальному адресу и числу секторов из полей 16 и 17. Требуется выравнивание по 4 МБ; иначе может быть стёрто больше или меньше данных.

14. Экспортировать сообщения последовательного порта работающего Loader в каталог output инструмента.

15. Экспортировать образ прошивки в каталог output инструмента по начальному адресу и числу секторов из полей 16 и 17.

16. Задать начальный сектор.

17. Задать число секторов операции.

18. Журнал инструмента.

6.1.3 Windows: SocToolKit

Некоторые AP поддерживают открытую схему хранения сведений о разделах ENV. Таблица разделов и bootargs записываются в ENV и передаются ядру через cmdline. Предоставляются отдельные инструменты упаковки образов и обновления. Интерфейс:

6.1.3 Windows: SocToolKit: оригинальная схема, английский источник, стр. 51

6.1.4 Linux: upgrade_tool

Инструмент Linux предоставляет функции, аналогичные инструменту Android. Интерфейс:

6.1.4 Linux: upgrade_tool: оригинальная схема, английский источник, стр. 52

6.1.5 Linux: SocToolKit

Инструмент Linux предоставляет функции, аналогичные инструменту Android.

6.1.6 Производственный инструмент

Производственный инструмент поддерживает асинхронную запись нескольких устройств. После запуска обновления каждое подключаемое устройство обновляется независимо. Интерфейс:

6.1.6 Производственный инструмент: оригинальная схема, английский источник, стр. 53

Каждый параметр config.ini подробно прокомментирован. Часто используемые настройки:

1. FW_BURN_EFUSE: записать efuse одновременно с прошивкой для включения secure boot. Включать нельзя, если AP использует OTP или на PCB отсутствует управление питанием EFUSE.

2. NOTRESET_AFTER_UPGRADE: не перезапускать после обновления. Это требуется изделиям, питание которых нельзя отключать во время первого запуска.

3. FORCE_DATA_BAND: изменить размер пакета USB. При тайм-ауте USB для SPI NOR его можно уменьшить.

4. SN_DLL_ON: записывать серийный номер при обновлении.

5. RB_CHECK_OFF: управляет необходимостью проверки обратным чтением при обновлении прошивки. Здесь исходный текст не определяет полярность флага.

6.2 Обновление с SD-карты

SD_Firmware_Tool записывает update.img на SD-карту обновления. Вставьте её в разъём SD/TF и включите питание: устройство загрузится с SD, войдёт в recovery и обновит внутренний накопитель. Интерфейс:

6.2 Обновление с SD-карты: оригинальная схема, английский источник, стр. 54

Функции инструмента:

1. Тест PCBA: выполнить проверку перед обновлением.

2. Загрузка с SD: создать загрузочную карту с полной прошивкой.

3. Восстановить диск: удалить загрузочный код и вернуть карту к обычному использованию.

6.3 Обновление по UART

Обновление по UART на поддерживаемых микросхемах доступно в инструментах Linux, Windows и производственном инструменте.

6.3 Обновление по UART: оригинальная схема, английский источник, стр. 55

6.4 Запись образа EMMC

SpiImageTools преобразует update.img в образ для программатора. Интерфейс:

6.4 Запись образа EMMC: оригинальная схема, английский источник, стр. 55

Настройки инструмента:

1. Заполнение пустой области: для EMMC выберите 0x0.

2. Не устанавливайте флажок SPI FLASH.

3. Включите резервирование области данных. Для создания образа прошивки GPT файл parameter должен содержать DISKSIZE; см. «Rockchip 量产烧录指南_v1.2». Настройки программатора:

1. Записать data.bin в пользовательский раздел EMMC.

2. Для RK3188/RKPX3 записать boot0.bin в оба раздела EMMC boot1 и boot2.

3. Включить пропуск полностью нулевых данных в программаторе.

4. Оставить все значения CSD по умолчанию.

5. Не указанные здесь поля EXTCSD оставить по умолчанию.

RK3188/RKPX3:

• EXT_CSD[167] = 0x1f (обязательно, если поддерживается накопителем).
• EXT_CSD[162] = 0x1: включить вывод reset.
• EXT_CSD[177] = 0x0 (по умолчанию).
• EXT_CSD[178] = 0x0 (по умолчанию).
• EXT_CSD[179] = 0x8: загрузка из boot1.

Другие AP:

• EXT_CSD[167] = 0x1f (обязательно при наличии поддержки).
• EXT_CSD[162], EXT_CSD[177], EXT_CSD[178] и EXT_CSD[179] = 0x0 (по умолчанию).

6.5 Запись образа SLC NAND

См. соответствующий раздел Rockchip_Developer_Guide_Linux_Nand_Flash_Open_Source_Solution_CN.pdf.

6.6 Запись образа SPI NAND

См. соответствующий раздел Rockchip_Developer_Guide_Linux_Nand_Flash_Open_Source_Solution_CN.pdf.

6.7 Запись образа SPI NOR

См. соответствующий раздел Rockchip_Developer_Guide_Linux_Nand_Flash_Open_Source_Solution_CN.pdf.

7. Настройка программных драйверов памяти

Rockchip предоставляет главным образом следующие решения для хранения данных:

7.1 u-boot

Подробности U-Boot см. в CH05 «Модули драйверов» / Storage документа Rockchip-Developer-Guide-UBoot-nextdev-CN.

7.2 kernel

В ядре 4.4 и более ранних версиях открытая поддержка SPI flash неполная. Открытое flash-решение ядра отличается от решения U-Boot.

7.2.1 MLC NAND/TLC NAND: решение rknand

Конфигурация:

CONFIG_RK_NAND=y

Файлы драйверов:

./drivers/rk_nand/

7.2.2 SLC NAND/SPI NAND/SPI NOR: решение rkflash

См. Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN.md.

7.2.3 SLC NAND/SPI NAND/SPI NOR: открытое решение MTD

См. Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN.md.

7.3 Настройка iomux/clk и порядок опроса памяти на разных этапах

7.4 Расширение с двумя накопителями

См. Rockchip_Developer_Guide_Dual_Storage_CN.md.

8. OTA для открытых решений

См. Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN.md.

9. Поддержка файловых систем

9.1 Файловая система UBIFS

См. Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN.md.

9.2 Поддержка файловой системы JFFS2

См. Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN.md.

10. Использование Vendor Storage

Vendor Storage хранит небольшие данные, не относящиеся к безопасности, например серийные номера и MAC-адреса. Справочные документы:

• EMMC: Rockchip_Application_Notes_VendorStorage.
• Flash с rkflash: Rockchip_Application_Notes_VendorStorage.
• Flash с MTD: Rockchip_Developer_Guide_Linux_Flash_Open_Source_Solution_CN.pdf.

10.1 Vendor Storage ID

Vendor ID имеет ширину 16 бит и обозначает данные независимо от места хранения, подобно индексу или имени файла. ID 0–31 зарезервированы для общих функций SDK; заказчик может использовать 32–65535. Назначения ID приведены ниже:

10.2 Vendor Storage API

10.2.1 Uboot API

int vendor_storage_init (void)
    function: Initialize vendor storage
    input: none
    return: 0, Initialize success
            other, Initialize fail

int vendor_storage_read (u32 id, void *pbuf, u32 size)
    function: read vendor storage by id
    input: id, item id; pbuf, data buffer; size, number byte to read.
    return: -1, read fail.
            other: number byte have read.

int rk_vendor_write (u32 id, void *pbuf, u32 size)
    function: write vendor storage by id
    input: id, item id; pbuf: data buffer; size: number bytes to write.
    return: 0: write success
            other : write fail

10.2.2 kernel API

Исходный код: kernel/drivers/soc/rockchip/rk_vendor_storage.c

Заголовочный файл: include/linux/soc/rockchip/rk_vendor_storage.h

int vendor_storage_init (void)
    function: Initialize vendor storage
    input: none
    return:  0, Initialize success
            other, Initialize fail

int vendor_storage_read (u32 id, void *pbuf, u32 size)
    function: read vendor storage by id
    input: id, item id; pbuf, data buffer; size, number byte to read.
    return: -1, read fail.
            other: number byte have read.

int rk_vendor_write (u32 id, void *pbuf, u32 size)
    function: write vendor storage by id
    input: id, item id; pbuf: data buffer; size: number bytes to write.
    return: 0: write success
            other : write fail

10.2.3 User API

Пользовательское приложение читает и записывает данные через IOCTL. Пример кода:

#include <fcntl.h>
#include <sys/ioctl.h>

#define VENDOR_REQ_TAG  0x56524551
#define VENDOR_READ_IO  _IOW ('v', 0x01, unsigned int)
#define VENDOR_WRITE_IO _IOW ('v', 0x02, unsigned int)
#define VENDOR_SN_ID        1
#define VENDOR_WIFI_MAC_ID  2
#define VENDOR_LAN_MAC_ID   3
#define VENDOR_BLUETOOTH_ID 4

struct rk_vendor_req {
    u32 tag;
    u16 id;
    u16 len;
    u8 data [1];
};

static void print_hex_data (uint8 *s, uint32 *buf, uint32 len)
{
    uint32 i, j, count;

    ERROR ("% s", s);
    for (i = 0; i < len; i += 4)
        ERROR ("% x % x % x % x", buf [i], buf [i + 1], buf [i + 2], buf [i + 3]);
}

int vendor_storage_read_test (void)
{
    u32 i;
    int ret, sys_fd;
    u8 p_buf [2048];/* malloc req buffer or used extern buffer */
    struct rk_vendor_req *req;

    req = (struct rk_vendor_req *) p_buf;
    sys_fd = open ("/dev/vendor_storage", O_RDWR, 0);
    if (sys_fd < 0){
        ERROR ("vendor_storage open fail\n");
        return -1;
    }

    req->tag = VENDOR_REQ_TAG;
    req->id = VENDOR_SN_ID;
    req->len = 512; /* max read length to read*/
    ret = ioctl (sys_fd, VENDOR_READ_IO, req);
    print_hex_data ("vendor read:", (uint32*) req, req->len + 8);
/* return req->len is the real data length stored in the NV-storage */
    if (ret){
        ERROR ("vendor read error\n");
        return -1;
    }

    return 0;
}

int vendor_storage_write_test (void)
{
    uint32 i;
    int ret, sys_fd;
    uint8 p_buf [2048]; /* malloc req buffer or used extern buffer */
    struct rk_vendor_req *req;

    req = (struct rk_vendor_req *) p_buf;
    sys_fd = open ("/dev/vendor_storage", O_RDWR, 0);
    if (sys_fd < 0){
        ERROR ("vendor_storage open fail\n");
        return -1;
    }

    req->tag = VENDOR_REQ_TAG;
    req->id = VENDOR_SN_ID;
    req->len = 32; /* data len */
    for (i = 0; i < 32; i++)
        req->data [i] = i;
    print_hex_data ("vendor write:", (uint32*) req, req->len + 8);
    ret = ioctl (sys_fd, VENDOR_WRITE_IO, req);
    if (ret){
        ERROR ("vendor write error\n");
        return -1;
    }

    return 0;
}

10.2.4 PC Tool API

Инструмент ПК предоставляет исходный код эталонного проекта C++ с двумя API чтения и записи:

int RK_ReadProvisioningData (int id, (PBYTE) pbuf, int size)
    function: read vendor storage by id
    input: id, item id; pbuf, data buffer; size, number byte to read.
    return: 0, read data okay.
            other: read fail.

int  RK_WriteProvisioningData (int id, (PBYTE) pbuf, int size)
    function: write vendor storage by id
    input: id, item id; pbuf: data buffer; size: number bytes to write.
    return:  0: write success
            other : write fail

10.3 Замечания по использованию

10.3.1 Максимальный размер одного элемента VENDOR

Общий размер раздела Vendor в NAND/EMMC — 64 КБ, в NOR — 4 КБ. Данные хранятся в структуре vendor.

struct vendor_info {
    struct vendor_hdr *hdr; //32byte
    struct vendor_item *item; //8byte * item
    u8 *data; //size = sum (item 1, item 2, ... item n)
    u32 *hash;
    u32 *version2;
};

Если записывается только один элемент:

NAND/EMMC: один элемент данных может занимать 64*1024-32-8-4-4 = 65488 байт.

NOR: один элемент данных может занимать 4*1024-32-8-4-4 = 4048 байт.

10.3.2 Поддержка двух копий данных VENDOR

По умолчанию поддерживаются две копии:

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

11. Справочные материалы приложения

Справочные ссылки:

• http://www.linux-mtd.infradead.org/faq/ubi.html
• http://www.linux-mtd.infradead.org/faq/ubifs.html#L_lebsz_mismatch
• http://www.linux-mtd.infradead.org/faq/general.html