ESP32-C6 получил «BIOS»: payload-архитектура, ABI и network boot на микроконтроллере
OpenC6 BIOS переносит на ESP32-C6 схему с постоянной базовой прошивкой и небольшими RISC-V payload’ами, которые можно исполнять из RAM или из выделенной XIP-области flash. Проект заявляет HTTP-загрузку по Wi‑Fi, настройку через web-интерфейс и управление частотой 80, 120 или 160 МГц. Фактическая разметка 8-МиБ flash при этом раскрывает ограничение заявленного OTA-rollback.
OpenC6 BIOS предлагает для ESP32-C6 модульную firmware-архитектуру: базовый образ поднимает периферию, хранит конфигурацию и предоставляет ABI системных вызовов, а прикладная логика поставляется отдельными bare-metal payload’ами. Такой payload не является обычным приложением ESP-IDF: он собирается с `-nostdlib` и `-fPIC`, рассчитывает на интерфейс базовой прошивки и имеет заявленный размер 2–10 КиБ. Тем самым эксперименты с задачей, диагностикой или сетевой ролью устройства можно отделить от кода инициализации платы и беспроводного стека.
Целевой чип содержит одноядерный RISC-V HP CPU, Wi‑Fi 6 на 2.4 ГГц, Bluetooth LE и маломощное LP-ядро. В OpenC6 LP Core отведена роль служебного контроллера: автор проекта заявляет мониторинг состояния, участие в энергосбережении и восстановлении после сбоя. Возможности самого LP Core соответствуют документации Espressif: сопроцессор способен работать с low-power GPIO, I2C и UART при спящем основном CPU, а затем разбудить его по событию. Практическая надёжность конкретной supervisory-логики OpenC6 публичными стендовыми тестами пока не подтверждена.
Payload можно передать по UART через внешний CP2102 или CH340; для этого в документации назначены GPIO18 как TX и GPIO19 как RX ESP32-C6. Второй путь — загрузка по Wi‑Fi: HTTP-клиент получает бинарник блоками по 1024 байта и записывает его во flash, после чего код стартует в режиме XIP. Название PXE в документации следует понимать как аналогию по назначению. Речь идёт об HTTP-загрузке пользовательского бинарника, а не о реализации PC-совместимого PXE-протокола.
Таблица разделов рассчитана на 8 МиБ flash. Под factory-приложение отведено 1.5 МиБ, ещё 1.5 МиБ занимает единственный OTA-раздел `ota_0`; файловая область `openc6_fs` занимает 3.875 МиБ, а последние 1 МиБ выделены под `payload_xip`. Именно эта разметка создаёт существенное расхождение с заявлением об A/B OTA. Обычная схема ESP-IDF предполагает как минимум два OTA-слота, `ota_0` и `ota_1`, чтобы новая версия записывалась в неактивный раздел. В текущем `partitions.csv` второго слота нет. Документация сетевой загрузки одновременно упоминает `ota_1` и раздел `network_buf`, которых в актуальной разметке также нет.
В конфигурации включён `CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE`, однако сам флаг ещё не доказывает работу автоматического отката. В ESP-IDF новая прошивка должна загрузиться в статусе pending verification и самостоятельно подтвердить работоспособность; только после этого образ становится валидным. Сценарий с watchdog и LP Core потребует проверки всей этой цепочки на реальной плате.
Для сетевой доставки остаётся и более жёсткое ограничение: SHA-256-проверка payload’ов указана в roadmap. Подписей и описанной криптографической аутентификации HTTP-бинарников пока нет. Поэтому network boot пригоден для лабораторного развёртывания, разработки приборных сценариев и воспроизводимых демонстраций в доверенной сети. До защищённого механизма обновления ему потребуются подпись образа, политика ключей и согласованная схема разделов.
Проект интересен самой границей архитектур: ESP32-C6 с 8 МиБ flash получает стабильный слой запуска и компактные взаимозаменяемые программы, однако ценность этой модели будет зависеть от строгости ABI, контроля доступа к радио и памяти, а также от доведения OTA до проверяемой двухслотовой реализации.