Аудитория: Данное руководство предназначено для OEM-менеджеров программ, архитекторов прошивки и инженеров по соответствию требованиям, которым необходимо понимать точную последовательность событий от включения микросхемы до первого звука на считывающем устройстве. В нем рассматриваются загрузчик из масочного ПЗУ, загрузчики второго этапа, проверка подписанных образов, переключение разделов A/B и пути восстановления, которые мы поставляем на 11 собственных SKU (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6).
Загрузка считывающего устройства — это не единичное событие. Это конвейер из 5–7 этапов, который выполняется примерно за 280–1 450 миллисекунд в зависимости от SKU. Каждый этап выполняет свою задачу: загружает код, проверяет подпись, передает управление. Если какой-либо этап завершается неудачно, следующий не запускается, и устройство либо перезагружается, либо переходит на образ восстановления, либо выходит из строя.
В этой статье подробно рассматривается этот конвейер с измеренными временными показателями для каждого из 11 SKU. Мы покажем вам структуру разделов A/B, счетчики отката, процесс подготовки OTA и пути обработки ошибок, которые выполняются на наших двух заводах. К концу вы сможете читать наши примечания к выпуску прошивки и точно знать, что изменяется при переходе версии с 2.4.7 на 2.5.0.
1. Почему «BIOS» — неправильное слово, но правильная идея
Считывающее устройство не имеет BIOS в понимании ПК. Оно оснащено загрузчиком из масочного ПЗУ — несколькими килобайтами неизменяемого кода, записанного в микросхему на этапе производства пластин. Этот код ПЗУ является корнем доверия: под ним нет программного обеспечения, и его невозможно перезаписать.
Называть его BIOS по-прежнему полезно, потому что архитектура напрямую соответствует концепциям UEFI: ПЗУ = фаза SEC, загрузчик второго этапа = PEI, прошивка = DXE, приложение = BDS. Поставщики, включая нас, часто используют BIOS нестрого в B2B-разговорах, потому что OEM-покупатель его понимает.
Цепочка доверенной загрузки — это конвейер проверки, который работает поверх этого ПЗУ. Его задача — гарантировать, что каждый фрагмент кода, выполняемый после ПЗУ, подписан закрытым ключом OEM. Если подпись неверна, цепочка останавливается.
2. Семиэтапный загрузочный конвейер
Каждый SKU считывающего устройства реализует одни и те же семь логических этапов. Реализации различаются структурой флеш-памяти и временными характеристиками.
| Этап | Компонент | Выполняется из | Проверяет | Типичная задержка |
|---|---|---|---|---|
| S1 | Загрузчик из масочного ПЗУ | ПЗУ | Вендорский ключ (зашитый) | 6–14 мс |
| S2 | Загрузчик 1-го этапа (SBL) | Загрузочный раздел NOR/eMMC | OEM RSA-2048 / ECDSA P-256 | 60–220 мс |
| S3 | Загрузчик 2-го этапа (при наличии) | Загрузочный раздел NOR/eMMC | OEM RSA-2048 / ECDSA P-256 | 40–160 мс |
| S4 | Образ прошивки (RTOS или ядро Linux) | Основной раздел NOR/eMMC | OEM RSA-2048 / ECDSA P-256 | 80–320 мс |
| S5 | TrustZone / TEE раздел | Защищенное хранилище TrustZone | Подпись SE | 30–120 мс |
| S6 | Приложение + аудиоресурсы | Основной раздел | Расшифровка AES-128 / AES-256 | 50–280 мс |
| S7 | Аудиодрайвер + первый сэмпл | ЦАП | н/д | 14–60 мс |
Общее время холодной загрузки до первого звука варьируется от 280 мс (B2) до 1 450 мс (L5). Разница обусловлена почти исключительно этапами S4 и S6 — SKU на базе Linux требуется больше времени для монтирования rootfs и инициализации ALSA.
3. Время загрузки по SKU
| SKU | S1 ПЗУ | S2 SBL | S3 2-й | S4 ПРОШ | S5 TEE | S6 Прилож | S7 Звук | Итого |
|---|---|---|---|---|---|---|---|---|
| B1 | 8 мс | 90 мс | n/a | 120 мс | n/a | 80 мс | 22 мс | 320 мс |
| B2 | 6 мс | 70 мс | n/a | 90 мс | n/a | 84 мс | 30 мс | 280 мс |
| F8 | 10 мс | 110 мс | 80 мс | 240 мс | 60 мс | 700 мс | 50 мс | 1,250 мс |
| K7 | 7 мс | 80 мс | n/a | 140 мс | 40 мс | 60 мс | 33 мс | 360 мс |
| KF1 | 7 мс | 80 мс | n/a | 140 мс | 40 мс | 60 мс | 33 мс | 360 мс |
| L5 | 12 мс | 130 мс | 100 мс | 290 мс | 80 мс | 760 мс | 78 мс | 1,450 мс |
| P2 | 14 мс | 130 мс | n/a | 160 мс | н/д | 90 мс | 26 мс | 420 мс |
| Q6 | 7 мс | 75 мс | н/д | 100 мс | н/д | 92 мс | 26 мс | 300 мс |
| Q8 | 7 мс | 75 мс | н/д | 100 мс | н/д | 92 мс | 26 мс | 300 мс |
| T2 | 11 мс | 120 мс | 90 мс | 280 мс | 70 мс | 720 мс | 58 мс | 1350 мс |
| Y6 | 10 мс | 110 мс | 80 мс | 260 мс | 70 мс | 800 мс | 70 мс | 1400 мс |
B2 — самая быстрая холодная загрузка в нашем ассортименте. L5 показывает самое медленное время. Разница в 1,17 с имеет принципиальное значение: она определяет переход от мгновенного отклика «коснулся — говорит» к задержке «подожди — потом говорит».
Совет покупателю: Потребуйте у OEM подробную разбивку процесса загрузки, а не только общее время. Ручка, которая загружается за 700 мс при 200 мс криптографической проверки, поддаётся аудиту. Ручка, которая загружается за 700 мс, но не может объяснить разбивку, остаётся чёрным ящиком.
4. Структура разделов A/B
Каждая Linux-based ручка для чтения (F8, L5, T2, Y6) использует схему разделов A/B для прошивки. Это золотой стандарт безопасности OTA, поскольку он позволяет устройству вернуться к предыдущему стабильному образу, если новый образ не загружается.
Схема A/B на L5 выделяет 3,2 ГБ для загрузочных и системных разделов (4 × 800 МБ) и 4,6 ГБ для пользовательских данных. Раздел TrustZone TEE составляет 200 МБ и включает прокси SE и защищённую область хранения для ключей OEM.
5. Структура разделов RTOS
RTOS-based модели (B1, B2, K7, KF1, P2, Q6, Q8) не требуют полной схемы A/B, поскольку их образы прошивки размером 1,4–3,0 МБ легко помещаются в двухбанковый NOR с аппаратным переключением. Структура на B2 выглядит следующим образом:
| Смещение | Размер | Содержимое | Проверяется |
|---|---|---|---|
| 0x00000000 | 16 КБ | SBL | Mask ROM (RSA-2048) |
| 0x00004000 | 1,0 МБ | Слот прошивки A | SBL (RSA-2048) |
| 0x00104000 | 1,0 МБ | Слот прошивки B | SBL (RSA-2048) |
| 0x00204000 | 4,0 МБ | OID аудио + ресурсы | Прошивка (AES-128-CTR) |
| 0x00604000 | 1,0 МБ | Подготовка OTA | Прошивка (AES-128-CTR) |
| 0x00704000 | 64 КБ | Пользовательское NVM (хранилище ключей) | TrustZone-M SAU |
| 0x00714000 | 64 КБ | Загрузочные флаги + счётчик отката | Аппаратная однократная запись |
Счётчик отката — это 32-битный монотонный счётчик, который увеличивается при каждой успешной загрузке. Если SBL обнаруживает значение счётчика меньше последнего известного корректного значения, происходит возврат к слоту B. Это защищает от атаки, при которой злоумышленник понижает версию прошивки до уязвимой предыдущей версии.
6. Машина состояний проверочной загрузки
Машина состояний, управляющая переключением A/B, является общей для всей линейки с незначительными вариациями. Машина состояний работает в SBL:
| Текущее состояние | Событие | Следующее состояние | Действие |
|---|---|---|---|
| Загрузка A | Проверка OK | Загрузка A | Увеличить счётчик |
| Загрузка A | Ошибка проверки | Загрузка B | Пробовать слот B |
| Загрузка B | Проверка OK | Загрузка B | Увеличить счётчик |
| Загрузка B | Ошибка проверки | Восстановление | Ожидание образа по USB |
| Восстановление | Получен подписанный образ | Восстановление | Записать новый образ |
| Восстановление | Ошибка проверки образа | Окирпичивание | Ожидание восстановления, подписанного HSM |
| Загрузка A или B | Подготовка OTA завершена | Перезагрузка промежуточного режима | Переключить слот при следующей загрузке |
| Перезагрузка промежуточного режима | Проверка OK | Загрузка (новый слот) | Продвинуть слот, уменьшить окно отката |
"Окно отката" — это количество загрузок, после которого новая прошивка считается стабильной. По умолчанию используется 4 успешных загрузки; если ручка даёт сбой в первые 4 загрузки после OTA, SBL автоматически выполняет откат к предыдущему слоту.
7. Процесс OTA-подготовки и восстановления
Процесс OTA на SKU с Linux выглядит следующим образом:
- Сервер OEM создаёт образ прошивки с подписью RSA-2048 / ECDSA P-256.
- Образ шифруется с помощью AES-128-CTR для транспортировки.
- Ручка загружает образ по Wi-Fi (F8, L5, T2, Y6) или BLE (K7, KF1, Q6, Q8).
- TrustZone TEE расшифровывает и проверяет подпись по корневому ключу OEM в SE.
- Расшифрованный образ записывается в неактивный слот (например, система B).
- Флаги загрузки устанавливаются на «загрузка с B при следующем перезапуске».
- Ручка перезагружается в слот B и выполняет 4 цикла загрузки.
- Если все 4 загрузки успешны, слот B повышается; счётчик отката увеличивается.
- При сбое любой загрузки слот A восстанавливается и флаг отправляется на сервер OTA.
OTA на RTOS аналогична, но меньше: образы 1,4–3,0 МБ, OTA занимает 8–25 секунд по BLE на K7 / Q6 / Q8 против 40–90 секунд по Wi-Fi на L5.
8. Методы оптимизации времени загрузки
Мы применяем пять методов для поддержания конкурентного времени загрузки:
| Метод | Использующие SKU | Экономия |
|---|---|---|
| Параллельный запуск SBL и инициализации SE | F8, L5, T2, Y6 | 60–110 мс |
| Пропуск инициализации UART/JTAG в производстве | Все | 12–20 мс |
| Использование сжатого ядра с ранней распаковкой | F8, L5, T2, Y6 | 80–150 мс |
| Предварительное декодирование первого аудио OID во время SBL | B1, B2, P2 | 18–30 мс |
| Отключение мер по смягчению Spectre/Meltdown (RTOS) | B1, B2, P2, Q6, Q8 | 8–14 мс |
SKU на базе Linux не отключают защиту от Spectre/Meltdown, поскольку обрабатывают недоверенный контент из библиотеки OID. SKU на базе RTOS отключают, поскольку вся их прошивка подписана.
9. Типичные режимы отказа загрузки, которые мы наблюдали
Среди 47 000+ отгруженных устройств с 2023 года, вот распределение отказов холодного старта в полевых условиях:
| Режим отказа | Частота | Решение |
|---|---|---|
| Антипереполнение счётчика (атака понижения версии) | 0,02 % | Перепрошивка в сервисном центре |
| Цикл переключения A/B | 0,18 % | Принудительный слот A через USB |
| Прерывание записи при OTA-подготовке | 0,34 % | Автовосстановление из промежуточной версии |
| Потеря питания во время загрузки | 0,91 % | Загрузка с резервного слота B |
| Износ eMMC | 0,06 % | Гарантийная замена |
| Установлен флаг взлома SE | 0,04 % | Переинициализация в сервисном центре |
| Просадка питания от батареи | 0,22 % | Загрузка из холодного состояния |
Отказ 0,91 % «потеря питания во время загрузки» — наибольшая отдельная причина заявок полевого обслуживания. Мы добавили блок конденсаторов 1,2 мс в прошивку L5 4.1.5, который удерживает шину eMMC VCCQ через 12 мс просадку; это снизило частоту отказов до 0,31 % в следующих 8 000 устройствах.
10. Какие изменения ожидаются в ближайшие 18 месяцев
Ожидаются два изменения. Во-первых, прошивка 4.3.0 для L5 и T2 представит загрузку UEFI с заменой цепочки загрузки Linux U-Boot на U-Boot 2024.10 + GRUB 2.12. Это сделает загрузку более прозрачной для OEM-покупателей, которые хотят подключать собственные дистрибутивы. Во-вторых, прошивка 2.0.0 для K7 / KF1 представит аппаратный корень доверия (RoT), основанный на защищённом элементе OPTIGA Trust M, заменяя текущий программный подход TrustZone-M SAU.
Оба изменения обратно совместимы: существующий процесс загрузки продолжает работать, но новый режим открывает доступ к UEFI или аппаратному RoT для тендеров, которые этого требуют.
11. Как читать номера версий нашей прошивки
Версии нашей прошивки следуют шаблону MAJOR.MINOR.PATCH. Например, прошивка B2 версии 2.4.7 означает: основная версия 2, минорная 4, патч 7. Правила следующие:
- MAJOR увеличивается при критическом изменении (например, переход с FreeRTOS на Zephyr, изменение структуры rootfs).
- MINOR увеличивается при добавлении новой функции (например, нового языка, нового OID-кодека).
- PATCH увеличивается при исправлении ошибки или обратном портировании безопасности.
Правила отката: вы можете свободно откатывать MINOR и PATCH. Откат MAJOR требует явного согласия OEM. Это защищает вас от случайного понижения до ветки с истёкшим сроком поддержки.
Текущий ассортимент версий прошивки: 1.9.5 (K7/KF1), 2.0.3 (P2), 2.4.7 (B1/B2), 2.6.4 (T2/Y6), 3.1.2 (F8), 3.3.1 (Q6/Q8), 4.2.0 (L5). Мы публикуем заметки о выпуске прошивки на нашем OEM-портале каждые 6 недель.