Перевод апноута Atmel 6282 - общие инструкции для создания безопасного и защищенного бутлоадера для семейства микроконтроллеров AT91SAM (ARM7 и ARM9).

[1. Введение]

Этот документ описывает различные аспекты реализации безопасного (safe) и защищенного (secure) бутлоадера, наподобие представленного в апноуте Atmel №6253 "Safe and Secure Firmware Upgrade for AT91SAM Microcontrollers" [1]. В этом апноуте обсуждаются некоторые приемы разработки программного обеспечения такого типа.

Под термином safe (безопасно) обычно подразумевается высоконадежное обновление программы (прошивки firmware) без потери работоспособности устройства в случае проблем при обновлении. Secure (защита) означает невозможность (либо значительное удорожание) взлома / дизассемблирования кода в целью несанкционированного получения доступа к программному обеспечению. Корректная реализация бутлоадера подразумевает правильную перенастройку распределения памяти (remapping) микроконтроллера с новой загружаемой программой firmware. Такие вопросы будут обсуждены и разрешены далее в следующих частях этого апноута, с фокусировкой на специфике семейства микроконтроллеров Atmel AT91SAM ARM^® Thumb^®. Для этого апноута также имеется пример готового программного обеспечения.

[3. Реализация бутлоадера]

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

3.1 Общий алгоритм бутлоадера (Bootloader Flow)

3.1.1 Последовательность загрузки следующая:

- Инициализация.
- Проверка условия запуска бутлоадера. Если условие выполнено, то запускается обновление программного обеспечения (Firmware upgrade).
- Проверка firmware (необязательный шаг).
- Загрузка firmware (если проверка завершена успешно, или если проверка запрещена).

Пояснения к рисунку:

Start - точка запуска бутлоадера.
Initialization - инициализация (настройка порта USART и т. п.).
Trigger set? - проверка условия запуска бутлоадера. Обычно проверяется состояние ножки порта микроконтроллера (установлена ли на ней перемычка), поступление команды от хоста или другое условие для запуска.
Start upgrade - запуск процесса обновления.
Verify firmware - проверка на целостность кода firmware (обычно на совпадение контрольной сумме CRC16).
Delete firmware - удаление кода firmware.
Load firmware - загрузка полученного в процессе обновления firmware.

Алгоритму рисунка соответствует следующий код на C (в виде тела подпрограммы):

// Инициализация бутлоадера
trigger_init();
memory_init();
media_init();
communication_init();
encryption_init();
// Проверка условия запуска
if (trigger_poll())
{
   // Обновление firmware
   bootloader_load(APP_START_ADDRESS);
}
// Проверка firmware
if (integrity_check() != OK)
{
   //
   ...
}
return APP_START_ADDRESS;

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

3.1.2 Последовательность действий при обновлении firmware (Upgrade Sequence)

Основной алгоритм обновления стартует с момента отправки хостом данных firmware в перепрограммируемое устройство. Этими данными будет перепрограммирована память программ (обычно память FLASH микроконтроллера). Как только программирование памяти завершено, то новая программа firmware считается загруженной.

Несмотря на то, что в теории различают отдельно шаги загрузки (download) и программирования (programming), но на практике почти всегда это не так. Причина проста - микроконтроллеры AT91SAM обычно имеют размер памяти FLASH в 4 раза больше, чем размер RAM. Таким образом, нельзя сразу загрузить все данные firmware в RAM, чтобы потом записать эти данные во FLASH.

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

Имейте также в виду, что память FLASH внутренне разделена на фиксированные блоки, которые называют страницей (page). В зависимости от типа микроконтроллера и размера FLASH, размер страницы может варьироваться от 64 до 512 бит. Операции по записи во FLASH могут за один раз обновить только всю страницу целиком. Поэтому имеет смысл организовать протокол обмена таким образом, чтобы передавать данные порциями размером с одну полную страницу.

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

Пояснения к рисунку:

Wait for data - ожидание поступления новых данных для обновления.
End of transfer? - проверка на окончание передачи.
Data received? - данные приняты?
Write last page - запись последней страницы.
Store data - сохранение данных.
Verify firmware - проверка загруженного firmware на целостность.
Page received? - Страница принята?
Delete firmware - удаление загруженного firmware.
Decrypt page - расшифровка загруженных данных страницы памяти FLASH.
Write page - запись данных страницы во FLASH.
Load firmware - запуск загруженного firmware.

Вот код, который иллюстрирует процесс загрузки:

// Прием и запись firmware
pCurrent = APPLICATION_STARTING_ADDRESS;
do
{
   bytes = communication_receive(page);
   // Если принят хотя бы один байт, запись страницы
   if (bytes > 0)
   {
      // Дешифровка firmware
      encryption_decrypt(page, page, bytes);
      // Дополнение данных страницы пустыми байтами
      while (bytes < MEMORY_PAGE_SIZE)
      {
         page[bytes] = 0xFF;
         bytes++;
      }
      // Запись страницы
      memory_write(pCurrent, page);
      pCurrent += MEMORY_PAGE_SIZE;
   }
} while (bytes > 0);

В этом примере функция communication_receive ожидает целиком данные всей страницы, детектируя окончание передачи. Возвращаемое значение 0 означает завершение передачи.

3.1.3 Разделение памяти на части (Memory Partioning)

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

Чтобы добиться этого, память FLASH делится на два различные региона, A и B (исключая отдельный регион для бутлоадера). Первый из регионов, A, размещается выше бутлоадера, и содержит рабочий код. Регион B работает как буфер при обновлении: сначала код загружается в регион B, проверяется, и затем, если код успешно проверен, копируется в регион A.

При таком сценарии последовательности запуска (boot) и обновления (upgrade) будут незначительно изменены. Во время обновления код записывается сначала в регион B (зона буфера). В процесс запуска добавляется некоторые шаги, независимо от того, пришел или нет запрос на обновление firmware. Бутлоадер сначала проверяет, идентичны ли копии кода в регионах A и B. Если они идентичны, то запускается код региона A. Если нет, то код региона A будет удален.

Разделение памяти делает также возможным использовать полезную, незначительно отличающуюся от обычной, стратегию бутлоадера. Поскольку всегда имеется встроенное рабочее firmware в устройстве, некоторый функционал бутлоадера может быть перенесен в код основной программы. Благодаря этому, этот функционал также может быть модернизирован при обновлении.

Например, передача firmware может быть делегирована в код основной программы. Она просто скачивает новый код в регион буфера и перезагружает (сбрасывает) микроконтроллер. Всю остальную задачу выполняет бутлоадер - он проверяет регион B, и если там находится новое firmware (более новое, чем в регионе A), то данные региона A перезаписываются данными региона B, и система снова перезагружается. Алгоритм загрузки с разделением памяти показан на рисунке.

Пояснения к рисунку:

Initialization - начальная инициализация (настройка канала связи и т. п.).
Trigger set? - проверка условия на запуск обновления.
Compare A&B - сравнение регионов A и B.
Start upgrade - запуск процесса обновления.
Verify B - проверка данных firmware, загруженных в регион B.
Delete B - удаление загруженных данных в регионе B.
Copy B over A - копирование данных региона B поверх региона A. При этом старая программа региона A перетирается данными новой прошивки firmware, загруженными в регион B.
Load firmware - запуск основной программы firmware.

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

Пояснения к рисунку:

Flash - область памяти FLASH.
Bootloader - область памяти, где находится бутлоадер.
Region A, Region B - регионы для хранения firmware A и B соответственно. A - текущая (рабочая) версия firmware, B - загруженная в процессе обновления.
Old firmware - старая версия firmware.
New firmware - новая версия firmware.
Unknown data (firmware empty?) - неизвестные данные (firmware не загружено?).
Before upgrade - перед обновлением firmware.
Buffer erased - буфер очищен.
No data - нет данных.
After download - после окончания процесса перекачки firmware от хоста.
After recopy - после копирования данных региона B поверх региона A.

3.2 Программирование бутлоадера для чипов AT91SAM

3.2.1 Программирование памяти Flash

Выполнение программы из области FLASH означает её чтение, а перепрошивка памяти FLASH означает её запись. Однако память FLASH микроконтроллеров семейства AT91SAM устроена так, что она не может одновременно и читаться, и записываться. Это потому, что она организована как единый массив (single plane). Таким образом, если программа выполняется из памяти FLASH, то она не в состоянии выполнять запись в память FLASH. Поскольку сам бутлоадер находится в памяти FLASH, его код должен быть обязательно скопирован в RAM перед выполнением, т. е. сам код бутлоадера должен работать из памяти RAM.

Есть два метода для удовлетворения этого. Первый из них доступен в основных системах разработки firmware, таких как популярная IAR Embedded Workbench®. В этой системе можно использовать атрибут для функции __ramfunc, который говорит компилятору, что эта функция предназначена для работы из памяти RAM, а не из FLASH. Подпрограмма инициализации / предварительного запуска (C-initialization routine) копирует код этих функций из FLASH в RAM во время выполнения. Имейте в виду, что для использования первого метода необходимо запретить прерывания во время записи FLASH, потому что для ядра ARM векторы прерываний (exception vectors) все еще будут находиться в памяти FLASH. Пример кода функции, работающей с FLASH, и имеющей атрибут __ramfunc:

__ramfunc void flash_cmd (unsigned int fcr)
{
   // Запуск работы с FLASH и ожидание завершения, прерывания
   // во время этого замаскированы (запрещены).
   while (!(AT91C_BASE_MC -> MC_FSR & AT91C_MC_FRDY));
   mask = AT91C_BASE_AIC -> AIC_IMR;
   AT91C_BASE_AIC -> AIC_IDCR = 0xFFFFFFFF;
   AT91C_BASE_MC -> MC_FCR = fcr | AT91C_MC_FCMD_START_PROG | AT91C_MC_CORRECT_KEY;
   while (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY));
}

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

;-- Копирование кода бутлоадера в RAM
   LDR r0, =__ramstart
   LDR r1, =__bootloaderend
   LDR r2, =0
copy:
   LDR r3, [r2]
   STR r3, [r2, r0]
   ADD r2, r2, #4
   CMP r2, r1
   BNE copy
;-- Выполнение RAM remap
   LDR r0, =AT91_BASE_MC
   LDR r1, =AT91_MC_RCB
   STR r1, = [r0, #MC_RCR]

Не забудьте сделать обратный remap перед запуском выполнения firmware, используя последние три строки кода.

3.2.2 Переназначение отображения в памяти векторов прерывания (Exception Vectors Remapping)

Микроконтроллеры Atmel AT91SAM основаны на ядре ARM (либо ARM7™, либо ARM9™). Когда ядро стартует, оно всегда начинает выполнение кода с адреса 0x0. Поскольку при этом во время выполнения команда remap не активна, то память FLASH доступна одинаково как по адресу 0x100000, так и по адресу 0x0. Таким образом, здесь должен находиться код бутлоадера, чтобы он мог запуститься.

Кроме того, ядро ARM ожидает иметь по адресу 0x0 корректные адреса векторов прерывания / исключений (exception vectors, самый первый из них вектор сброса). Поскольку бутлоадер не может быть обновлен, его вектора прерывания будут всегда находиться в начале памяти FLASH. Это создаст проблему, если программа пользователя (firmware) должна иметь свои собственные вектора исключений.

Серия AT91SAM имеет достаточно удобный механизм для обхода этой проблемы. В любом случае, всегда либо внутренняя память FLASH (0x00100000 - 0x001FFFFF), либо внутренняя память SRAM (0x00200000 - 0x002FFFFF) отображена на адрес 0x0. Команда remap делает возможным переключать текущее отображение памяти на обратное. Когда чип был сброшен, память FLASH автоматически зеркально отображена по двум адресам - как по адресу 0x100000, так и по адресу 0x0 (т. е. нет переназначения RAM на адрес 0x0).

Пояснения к рисунку:

Before remap - состояние памяти перед выполнением команды remap (такое состояние сразу после сброса).
After remap - состояние памяти после выполнения команды remap.
Data - данные, различные переменные в RAM.
Reserved space - зарезервированная область адресного пространства.
Application code - код приложения пользователя, т. е. firmware, выполняющее основные функции устройства. Именно код приложения перезаписывается бутлоадером при обновлении firmware.
Application vectors - вектора исключений (прерываний) приложения пользователя.
Bootloader code - код бутлоадера.
Bootloader vectors - вектора исключений (прерываний) бутлоадера.
Mirrored flash - зеркальная копия данных FLASH, отображенная по адресу 0x0.
Mirrored RAM - зеркальная копия данных RAM, отображенная по адресу 0x0.

С помощью использования механизма remap новые вектора прерываний могут быть скопированы в RAM. Переназначение отображения памяти (memory remap) выполняется для того, чтобы зеркально отобразить память RAM как по адресу 0x00200000, так и по адресу 0x0. Эта операция может быть произведена самим firmware при инициализации. Кусок кода ниже делает memory remap:

;-- Копирование векторов прерывания (exception vectors) firmware в RAM
   LDR r0, =INTERRUPT_VECTORS_START
   LDR r1, =INTERNAL_RAM_START
   LDR r2, =INTERRUPT_VECTORS_END
copy:
   LDR r3, [r0], #4
   STR r3, [r1], #4
   CMP r0, r2
   BNE copy
;-- Remap SRAM, чтобы новые вектора прерываний были доступны по адресу 0x0
   LDR r0, =AT91C_BASE_MC
   LDR r1, =AT91C_MC_RCB
   STR r1, [r0, #MC_RCR]

Чтобы можно было сделать такую операцию, нужно зарезервировать в сегменте данных (data segment) некоторое пространство. В противном случае компилятор (точнее, компилятор вместе с линкером) может привязать переменные к самому началу RAM, что приведет к проблемам. Резервирование младших адресов в RAM выполняется путем модификации настроечного скрипта для линкера (linker script), который используется компилятором. Эта операция производится по аналогии с описанием, приведенном в следующей секции.

3.2.3 Линковка кода приложения (Application Code Linking)

Как мы все знаем, линковка - это привязка кода приложения и данных (переменных) к абсолютным адресам в памяти микроконтроллера. В самом простом, обычном случае сегмент кода (code segment) приложения пользователя линкуется на начало памяти FLASH. Это происходит потому, что ядро ARM семейства микроконтроллеров AT91SAM начинает выполнение кода с адреса 0x0. Однако в случае использования бутлоадера так делать нельзя, поскольку бутлоадер сам по себе должен находиться по адресу 0x0.

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

Как известно, ядро ARM, выполняющее код, может работать в одном из двух режимов - ARM (32 бита) или Thumb. Линковщики ARM могут генерировать код PI, но только в режиме ARM (32 бита). Это потому, что инструкция BX (которая используется для переключения между режимами) линкуется с использованием абсолютного адреса функции. Таким образом, решение использовать код PI работает только в том случае, если Вы не используете код Thumb в Вашем приложении.

Другое решение состоит в том, чтобы модифицировать адрес, к которому линкуется приложение, в зависимости от размера бутлоадера. Чтобы выполнить это, измените скрипт линкера (linker script) для проекта Вашего приложения. Просто назначьте константу "bootloader_size" равной размеру скомпилированного бутлоадера и первый доступный адрес для выполнения приложения будет равен "flash_start+bootloader_size" (flash_start обычно равен 0x00100000). Вот простой пример куска файла *.xcl для среды IAR Embedded Workbench версии 4.0 (для 5.0 и более поздних синтаксис и расширение файла скрипта линкера отличаются):

//--
// Размер области памяти для бутлоадера
//--
-DBOOTSIZE=2000
...
//--
// Сегменты Read-only (только чтение)
//--
-DROMSTART=(00000000+BOOTSIZE)
-DROMEND=0003FFFF

Сегменты кода приложения заданы между адресами ROMSTART и ROMEND.

3.2.4 Защита от записи области памяти бутлоадера (Boot Region Locking)

Чтобы исключить случайное стирание кода бутлоадера из приложения пользователя, желательно заблокировать запись FLASH в области кода бутлоадера с помощью программирования контроллера FLASH. Любая попытка записи в защищенный регион FLASH будет автоматически прервана. Для встроенного в ядро контроллера памяти FLASH (Embedded Flash Controller, EFC) имеется специальная команда для блокирования указанного региона памяти. Есть некоторая проблема в том, что минимальный защищаемый регион может быть довольно большим от 4 до 16 килобайт. Поскольку нужно защитить только область бутлоадера, то получается, что программа пользователя может начинаться только с начала следующего (неблокируемого) региона.

На практике устанавливают размер сегмента бутлоадера по кратности размеру минимально защищаемого региона. Это означает, что Вы потеряете некоторое пространство защищенного от записи кода FLASH, которое не используется бутлоадером.

Бит защиты security bit), используемый для защиты внутренней памяти (FLASH + SRAM) от внешнего доступа (с помощью стандартных средств загрузки и отладки кода), также может быть установлен в EFC.

[4. Пример реализации бутлоадера]

Далее идет описание примера реализации безопасного и защищенного бутлоадера. Реализация состоит из трех программ: bootloader сам по себе и две вспомогательные программы. Одна из вспомогательных программ используется для передачи firmware между компьютером PC и bootloader. Вторая вспомогательная программа нужна для шифрования firmware перед передачей в bootloader. Все эти три части программного обеспечения детально описаны далее.

4.1 Bootloader

4.1.1 Возможности бутлоадера
Реализованы следующие возможности:
• Базовая система загрузки кода (bootloading) с использованием интерфейса USART для передачи данных firmware.
• Протокол XON/XOFF для управления обменом данными (flow control) при загрузке / программировании FLASH.
• Защита от записи области памяти бутлоадера (Boot region locking).
• Шифрование передаваемых данных прошивки firmware методом AES или Triple DES (тройной DES).
• Разделение памяти (Memory partitioning).

Программное обеспечение bootloader разработано в среде IAR Embedded Workbench.

4.1.2 Конфигурируемость

Бутлоадер разработан так, что в него можно довольно просто добавить новые компоненты, типа новых носителей данных или новых коммуникационных протоколов. Файл /inc/config.h управляет конфигурацией главных обязательных компонент (таких как используемый носитель данных) и дополнительные необязательные опции (защита security, безопасность safety). Отдельный компонент конфигурации может быть выбран заданием соответствующей константы:

#define USE_COMPONENTNAME

Здесь имя USE_COMPONENTNAME является именем компонента (например USART0). Имейте в виду, что в обязательных категориях и некоторых других может быть выбран только один компонент. К категориям, в которых допустим одиночный выбор, относятся:

• Включение управления потоком в протоколе обмена XON/XOFF (USE_XON_XOFF).
• Слой носителя данных (Media layer), USART (USE_USART0).
• Работа отладочного вывода (Debug) DBGU (USE_DBGU).
• Тип памяти, Flash (USE_Flash)
• Условие запуска бутлоадера (Trigger condition), простой Dummy (USE_DUMMY) или перемычками Switches (USE_SWITCHES).
• Отсчет реального времени, Timer0 (USE_TIMER0)

Категории отладки (debug) и отсчета реального времени не являются по-настоящему обязательными. К примеру, если не требуется драйвер для отладочного вывода, то бутлоадер не будет выводить никаких отладочных сообщений. Модуль отсчета реального времени может в некоторых случаях понадобиться для оценки скорости выполнения разных участков кода (benchmarks).

Есть также три необязательных параметра:

• Блокировка на запись области бутлоадера (Boot region locking, USE_BOOT_REGION_LOCKING).
• Шифрование кода (Code encryption, USE_ENCRYPTION)
• Разделение памяти (Memory partitioning, USE_MEMORY_PARTITIONING).

4.1.3 Размещение кода (Code Location)

Основной алгоритм бутлоадера

Файл /src/main.c содержит основной код алгоритма bootloader. Это включает в себя последовательность старта (boot sequence, секция 3.1.1), последовательность обновления firmware (upgrade sequence, секция 3.1.2), как и модифицированная последовательность старта и обновления при использовании разделения памяти (memory partitioning, секция 3.1.3). Блокировка на запись области кода бутлоадера также осуществляется при инициализации бутлоадера (если задана соответствующая опция).

Переназначение отображения в памяти векторов прерывания (Exception Vectors Remapping)

Переназначение векторов исключения (прерывания) осуществляется напрямую при старте программного обеспечения пользователя (основное firmware). Код remap находится в файле /resources/firmware_remap_startup_SAMxxxx.s79.

Перепрошивка FLASH

Алгоритмы для перепрограммирования FLASH, как и код блокировки/разблокировки на запись областей памяти размещены в файле /src/media/flash.c. Имейте в виду, что для правильной работы эти функции используются с атрибутом __ramfunc. Бутлоадер может быть модифицирован для использования переназначения RAM (RAM remapping), чтобы избежать ошибочного использования этого атрибута, который специфичен для определенных компиляторов - например, при портировании кода на другую среду разработки, отличающуюся от IAR. Чтобы выполнить портирование, замените следующие файлы:

• /resources/bootloader_startup.s79
   – /resources/bootloader_startup_remap.s79
• /resources/bootloader_linkscript_XXX.xcl
   – /resources/bootloader_linkscript_XXX_remap.xcl
• /src/media/flash.c
   – /src/media/flash_remap.c

Линковка (Linking) и стартовый код (Startup Code)

Все файлы для линковки и запуска как для бутлоадера, так и для приложения пользователя, находятся в папке /resources. Они включают в себя:

• Файл запуска (startup) и линковки (linker) для bootloader.
• Файл запуска (startup) и линковки (linker) для firmware без переназначения векторов исключения (without remapped exception vectors).
• Файл запуска (startup) и линковки (linker) для firmware с переназначением векторов исключения (with remapped exception vectors).

4.2 Firmware Updater - вспомогательная утилита для передачи кода firmware в бутлоадер

Эта программа используется для передачи firmware между хостом PC (обычным компьютером) и программой bootloader. Поскольку в настоящий момент реализована только передача через RS232 (PC COM-порт), то для той же самой функции может использоваться обыкновенная стандартная программа терминала (наподобие HyperTerminal операционной системы Windows). Однако потребуется разработать специальную программу, если будет использоваться другой носитель данных или коммуникационный протокол, не поддерживаемый стандартными программами.

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

• Выбрать файл firmware для отправки в bootloader.
• Выбрать носитель данных (media, в нашем случае это COM-порт) и связанные с ним параметры (скорость, наличие бита четности, количество стоповых бит).
• Выбрать протокол обмена и связанные параметры (в нашем примере никакого выбора пока нет).
• Запуск процесса обновления (кнопка Upgrade).

Имейте в виду, что Вы должны выбрать опции, соответствующие тем же параметрам обмена, которые выбраны в бутлоадере. Например, если у бутлоадера USART сконфигурирован для соединения на скорости 115000 bps, no parity и 1 stop bit, то соответствующие параметры также должны быть выбраны и в окне Firmware Updater.

4.3 Firmware Packager - утилита для упаковки и шифрования firmware

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

В настоящее время реализован следующий функционал:

• Выбор исходного файла firmware для упаковки.
• Выбор выходного файла.
• Выбор метода шифрования (AES или Triple DES) вместе со связанными параметрами.
   – режим шифрования, ключ и вектор инициализации.
• Запуск упаковки firmware.

Имейте в виду, что Вы должны выбрать те же самые параметры в Firmware Packager, которые выбраны в коде bootloader. Например, если bootloader сконфигурирован для загрузки firmware с шифрованием AES-CBC, специальным ключом и вектором инициализации IV (Initialization Vector), введите те же самые параметры в окне утилиты Firmware Packager.

[Ссылки]

1. Безопасное и защищенное обновление firmware для AT91SAM. Перевод апноута Atmel 6253.
2. 130110Safe-and-Secure-Bootloader-Impl-1.0.zip - код примеров программ, обсуждаемых в апноуте 6282.
3. AT91SAM7X: бутлоадер SAM-BA от компании Atmel.
4. SAM-BA boot agent.
5. AT91SAM7X: простейший bootloader, читающий firmware с карты SD/MMC (используется EFSL).