Загрузчик ESP32, поддерживаемый средой разработки ESP-IDF (Software Bootloader), выполняет следующие функции:
1. Минимальная начальная конфигурация внутренних модулей. 2. Инициализация функций шифрования (Flash Encryption) и/или безопасности (Secure), если они сконфигурированы. 3. Раздел приложения для загрузки (boot) на основании таблицы разделов и информации в разделе ota_data (если они присутствуют). 4. Загрузка этого образа в ОЗУ (IRAM и DRAM) и передача управления в загруженный образ (запуск приложения).
Bootloader находится в памяти SPI-flash по адресу 0x1000.
Для полного описания процесса запуска (startup), включая работу ESP-IDF bootloader, см. документ [2].
[Совместимость загрузчика]
Рекомендуется выполнить обновление, чтобы использовать самые новые версии ESP-IDF. Процесс обновления OTA (over the air) может прошить новые приложения непосредственно у пользователя устройства, однако OTA не позволяет прошить новый загрузчик. По этой причине bootloader поддерживает загрузку приложений из новых версий ESP-IDF.
Bootloader не поддерживает загрузку приложений из старых версий ESP-IDF. Когда ESP-IDF обновляется вручную на существующем продукте, для которого может понадобится обновление вниз (downgrade) приложения на старую версию, продолжайте использовать более старый ESP-IDF bootloader.
Важное замечание: если тестируется обновление OTA для существующего изделия, находящегося в производстве, всегда делайте эту проверку с тем же двоичным кодом ESP-IDF bootloader, который распространяется при производстве.
Версии до ESP-IDF V2.1. Загрузчики, собранные в очень старых версиях ESP-IDF (до ESP-IDF V2.1) выполняют меньше действий по аппаратной конфигурации, чем более новые версии. Когда используется bootloader из этих ранних версий ESP-IDF, и выполняется сборка нового приложения, разрешите опцию конфигурации CONFIG_ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS.
Версии до ESP-IDF V3.1. Загрузчики, собранные в версиях ESP-IDF до V3.1, не поддерживают контрольные суммы MD5 в бинарной таблице разделов [4]. Когда используется bootloader из этих версий ESP-IDF, и собирается новое приложение, разрешите опцию конфигурации CONFIG_ESP32_COMPATIBLE_PRE_V3_1_BOOTLOADERS.
Конфигурация SPI Flash. Каждое приложение ESP-IDF, или bin-файл загрузчика содержит заголовок с встроенными параметрами CONFIG_ESPTOOLPY_FLASHMODE, CONFIG_ESPTOOLPY_FLASHFREQ, CONFIG_ESPTOOLPY_FLASHSIZE. Это используется для конфигурирования SPI flash во время загрузки (boot).
Загрузчик первой стадии (First stage bootloader), находящийся в ROM, считывает из flash информацию заголовка загрузчика второй стадии (Second stage bootloader header), и использует её для загрузки из flash остальной части Second stage bootloader. Однако в это время частота тактов системы (system clock speed) ниже, чем сконфигурирована, и поддерживаются не все режимы flash. Когда затем запускается Second stage bootloader, он переконфигурирует flash, используя значения, прочитанные из выбранного в настоящий момент заголовка двоичного образа приложения (не из заголовка Second stage bootloader). Это позволяет функционировать обновлению OTA изменять используемые настройки памяти SPI flash.
Загрузчики версий до ESP-IDF V4.0 использовали свой собственный заголовок для конфигурирования SPI flash, это значит, что эти значения настроек не могут быть изменены при обновлении. Чтобы обеспечить совместимость со старыми загрузчиками, приложение повторно инициализирует настройки flash во время startup, используя конфигурацию в заголовке приложения.
[Уровень вывода в лог загрузчика]
По умолчанию у загрузчика используется уровень информативности вывода Info. Установкой опции CONFIG_BOOTLOADER_LOG_LEVEL, можно увеличить или уменьшить уровень этот уровень. Этот уровень вывода относится только к загрузчику, у приложения настраивается отдельный уровень вывода (см. [5]).
Уменьшение детализации вывода или полный запрет вывода в лог для загрузчика может немного уменьшить общее время загрузки приложения.
[Сброс к заводскому состоянию]
Иногда нужно каким-то способом откатить устройство в заранее известное состояние, например в случае проблем с обновлением.
Чтобы откатить устройство в оригинальную, "заводскую" конфигурацию и очистить любые настройки пользователя, сконфигурируйте в загрузчике опцию CONFIG_BOOTLOADER_FACTORY_RESET.
Механизм сброса в заводское состояние (factory reset) позволяет вернуть устройство в заранее известное состояние двумя способами:
• Очистка одной или большее количество разделов данных (data partitions) памяти SPI flash [4]. Опция CONFIG_BOOTLOADER_DATA_FACTORY_RESET позволяет пользователям указать, какие разделы данных будут очищены, когда выполняется factory reset.
Пользователи могут указать имена разделов в качестве списка, где имена отделены запятой. Для удобства читаемости списка также могут быть после запятой добавлены пробелы (примерно так: nvs, phy_init, nvs_custom).
Убедитесь, что имена разделов, указанные в опции, совпадают с именами, которые находятся в таблице разделов. Разделы типа "app" здесь не могут быть указаны.
• Загрузка из "factory" app partition. Разрешение опции CONFIG_BOOTLOADER_OTA_DATA_ERASE приведет к тому, что устройство загрузится из раздела "заводского" приложения по умолчанию (default factory app partition) после выполнения factory reset или? если нет раздела factory app partition в таблице разделов, то вместо этого будет выбран раздел OTA-приложения по умолчанию (default ota app). Этот тип сброса к заводскому состоянию вовлекает стирание раздела данных OTA (OTA data partition), где находится информация выбранного слота раздела OTA. Слот factory app partition (если он существует) не выполняет обновление через OTA, так что такой способ factory reset позволяет вернуться к "хорошему известному" состоянию firmware приложения.
Вход в обе эти конфигурации может быть разрешен независимо друг от друга.
Дополнительно условием сброса в заводское состояние управляют следующие опции:
CONFIG_BOOTLOADER_NUM_PIN_FACTORY_RESET. Номер входной ножки GPIO, используемой для запуска factory reset. Для активации factory reset при включении питания эта ножка должна быть подтянута к уровню лог. 0 или 1 (уровень конфигурируется).
CONFIG_BOOTLOADER_HOLD_TIME_GPIO. Здесь указывается время удержания ножки GPIO для активации режима reset/test (по умолчанию 5 секунд). Ножка после сброса/включения питания должна непрерывно удерживаться в этом состоянии перед выполнением factory reset или загрузки из test partition (если это применимо).
CONFIG_BOOTLOADER_FACTORY_RESET_PIN_LEVEL. Эта опция конфигурирует логический уровень на ножке GPIO, которым активируется factory reset. Если на ножке GPIO есть внутренняя подтяжка pullup, то эта подтяжка разрешается до того, как начнет анализироваться уровень на ножке. Для получения полной информации по наличию внутренних подтяжек проконсультируйтесь с даташитом на устройство ESP32.
[Загрузка из Test Firmware]
Можно написать специальное тестовое приложение (test firmware) для тестирования на производстве, и при необходимости выполнить загрузку этого firmware. Таблица разделов проекта должна в таком случае содержать отдельную запись для раздела приложения (app partition), предназначенного для тестового приложения. У этого раздела тестового приложения должен быть тип app и подтип test (см. [4]).
Реализация отдельного тестового firmware приложения требует создания абсолютно отдельного проекта ESP-IDF (каждый проект в ESP-IDF делает сборку только одного приложения). Тестовое приложение может быть разработано и протестировано независимо от основного проекта, и затем интегрировано во время тестирования в производстве как предварительно скомпилированный файл *.bin, который прошивается по адресу раздела тестового приложения основного проекта.
Для поддержки этой функциональности в загрузчик основного проекта установите опцию конфигурации CONFIG_BOOTLOADER_APP_TEST, и сконфигурируйте также следующие 2 опции:
CONFIG_BOOTLOADER_NUM_PIN_APP_TEST. Задает ножку GPIO для загрузки из TEST partition. Выбранная ножка GPIO будет сконфигурирована как вход, на которой разрешена внутренняя подтяжка вверх (pull-up). Для активации загрузки тестового приложения эта ножка должна при сбросе/включении питания подтянута к уровню лог. 0.
Когда вход GPIO будет отпущен (что позволит его уровню вернуться обратно к лог. 1) и затем устройство перезагрузится, это приведет к загрузке обычного сконфигурированного приложения (из слота раздела factory или любого раздела OTA app).
CONFIG_BOOTLOADER_HOLD_TIME_GPIO. Задает время удержания уровня GPIO для активации режима reset/test (по умолчанию 5 секунд). Уровень GPIO после сброса должен непрерывно удерживаться в лог. 0 в течение этого периода, перед тем как будет выполнен factory reset или загрузка из test partition (если это применимо).
[Rollback]
В загрузчике также должны быть сконфигурированы функции rollback и anti-rollback, подробности см. в документации по OTA [6].
[Watchdog]
По умолчанию аппаратный сторожевой таймер (RTC Watchdog) продолжает работать, и автоматически сбросит чип, если при в течение 9 секунд не было успешно загружено приложение. Этот период времени может быть настроен путем установки опции CONFIG_BOOTLOADER_WDT_TIME_MS и перекомпиляции загрузчика bootloader.
Поведение приложения может быть настроено таким образом, чтобы RTC Watchdog оставался разрешенным во время процесса запуска приложения (app startup). В течение выполнения любого кода (как приложения, так и загрузчика) сторожевой таймер должен явно сбрасываться, чтобы избежать сброса. Настройте опцию CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE, измените при необходимости код приложения, и перекомпилируйте его.
RTC Watchdog может быть запрещен в загрузчике путем запрета опции CONFIG_BOOTLOADER_WDT_ENABLE и перекомпиляции загрузчика. Это делать не рекомендуется.
[Размер загрузчика]
Если разрешаются дополнительные функции загрузчика (такие как Flash Encryption, Secure Boot или другие), и особенно если установлен высокий уровень подробности лога CONFIG_BOOTLOADER_LOG_LEVEL, то важно следить за размером двоичного файла *.bin загрузчика.
Когда используется значение по умолчанию 0x8000 опции CONFIG_PARTITION_TABLE_OFFSET, размер двоичного файла загрузчика ограничен 0x7000 (28672) байтами.
Если двоичный код загрузчика слишком большой, то код загрузчика завершится с ошибкой "Bootloader binary size [..] is too large for partition table offset". Если двоичный код загрузчика будет все равно прошит в память flash, то ESP32 не сможет выполнить загрузку, и в лог будет выведено сообщение о поврежденной таблице разделов (invalid partition table) или ошибке контрольной суммы загрузчика (invalid bootloader checksum).
Чтобы избежать слишком большого двоичного кода загрузчика, выполните следующее:
• Установите опцию оптимизации компиляции загрузчика в значение по умолчанию "Size", если эта опция была ранее изменена на другое значение. • Уменьшите уровень подробности вывода в лог для загрузчика. Установка уровня вывода в Warning, Error или None значительно снизит конечный размер двоичного файла (однако усложнит отладку ). • Установите опцию CONFIG_PARTITION_TABLE_OFFSET в значение, превышающее 0x8000, чтобы переместить таблицу разделов дальше в сторону увеличения адреса flash. Это увеличит доступное место для кода загрузчика. Если таблица разделов, определенная в файле CSV, содержит явные смещения для разделов, то эти смещения должны быть изменены, чтобы ни один из разделов не имел смещения меньше, чем CONFIG_PARTITION_TABLE_OFFSET + 0x1000 (это касается CSV-файлов по умолчанию, поставляемых вместе с ESP-IDF).
Когда разрешена функция Secure Boot V2, также существует ограничение на абсолютный размер двоичного кода 48KB или 0xC000 байт (за исключением сигнатуры 4 KB), потому что загрузчик для проверки сначала загружается в буфер фиксированного размера.
[Быстрая загрузка из режима Deep Sleep]
У загрузчика есть опция CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP, которая позволяет уменьшить время выхода из глубокого сна Deep Sleep (этот режим полезен для снижения энергопотребления устройства). Эта опция доступна, когда запрещена опция CONFIG_SECURE_BOOT. Уменьшение времени загрузки достигается за счет отсутствия проверки образа приложения. Во время первой загрузки bootloader сохраняет адрес запускаемого приложения в память RTC FAST memory. И после пробуждения этот адрес используется для запуска приложения без каких-либо проверок, в результате чего активация приложения ускоряется.
[Пользовательский загрузчик]
Текущая реализация загрузчика позволяет расширять или модифицировать его проект. Есть 2 способа выполнения такой модификации: путем реализации перехватчиков выполнения кода загрузчика (hooks), или путем непосредственного изменения кода загрузчика. Оба способа представлены в папке custom_bootloader среди примеров проектов среды разработки ESP-IDF:
• Проект bootloader_hooks демонстрирует, как подключить некоторые перехватчики выполнения (hooks) к инициализации загрузчика. • Проект bootloader_override показывает пример изменения реализации загрузчика.
В коде загрузчика нельзя использовать драйверы или функции из других компонентов. Если это необходимо, то требуемый функционал должен быть в каталоге bootloader_components проекта загрузчика (имейте в виду, что это увеличит размер кода загрузчика).
Если загрузчик слишком разросся, то он может наложиться на таблицу разделов, которая прошивается в память SPI flash сразу за кодом загрузчика (таблица разделов по умолчанию находится по смещению 0x8000 в памяти flash). Чтобы переместить таблицу разделов дальше в сторону старших адресов, увеличьте для неё значение смещения. Это позволит увеличить пространство, доступное для кода загрузчика.
Примечание: значение смещения должно нацело делиться на размер страницы flash (4 KB).
[Словарик]
APP CPU, PRO CPU условное обозначение двух ядер ESP32, на которые в примерах среды разработки ESP-IDF возлагаются различные задачи приложения.
OTA Over The Air, технология загрузки (обновления) по радиоканалу.
