Добрый день! Есть девайс на stm32 c эзернетом и SPI флешкой.

На флешке храниться контент web сервера.
Задача сделать обновление прошивки + контента.
Как я это вижу.
Половина SPI флеша под web контент, другая - обновления прошивки.
Прошивка - монолитный образ где содержится бинарь и контент для web сервера.
Загружаю по HTTP этот образ, дальше ребут в бутлоадер где он уже делает все полезную работу.
Вопросы:
Как собрать такую прошивку, что бы не изобретать велосипед. Может есть уже какой-то готовый формат. Собираем на хосте и просто парсим в бутлодере?
Может я не туда думаю и надо делать по другому?

1. Собираешь как обычную, только в линкерном файле правишь смещения по которым эта прошивка должна лежать во Flash. 2. Лучше собрать бинарь на хосте (если принципиален размер - можешь сжать простеньким алгоритмом, т.к. в прошивке бывает много 0хFF). 3. По-хорошему bootloader должен проверять целостность прошивки (и опционально цифровую подпись если используешь криптографию). Примеры bootloader с проверкой цифровой подписи есть у STM в пакете Secure Boot. Просто bootloader'ы для STM на любой вкус есть на Github. Еще нередко делают возможность отката к последней стабильной версии прошивки (т.е. на флешке лучше зарезервировать место для пары образов).

Там разве не внешняя флеш?

Да, но из внешней нужно во внутреннюю память всё равно копировать. XIP (execute in place) поддерживается только совместно с OCTO-/QSPI в старших семействах STM-ок.

Неплохой пример как сделано обновление прошивки есть в esp-idf https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/ota.html

Мне кстати тоже загрузчик писать скоро

Не думаю что это доставит какие-то серьёзные проблемы. Пример переноса вектора прерываний и исполнения кода из произвольного места у STM есть. А дальше нужно накрутить свой функционал. Мы, например, проверяли причину предыдущей перезагрузки. Если это был WD и в течение небольшого количества времени произошло несколько перезагрузок - откатывали к предыдущей стабильной.

Я тоже не думаю)

всмысле как? собираешь в bin и отправляешь. можно и в hex собрать и отправить, только в какомто месте на хосте или контроллере придется в бин перекодировать.

Как собрать файл обновления при условии что внутри кроме основной прошивки буду много кастомных файлов? Логично использовать для этого какую простую файловую систему, что бы потом потом бутлоадрер смог распарсить все это. Может уже есть готовые легкие либы для этого? Собственно в этом основной вопрос

Кроме прошивки внутри должна быть еще куча файлов, как это все собрать?

А что за HTTP сервер? Вроде как обычно для таких приложений весь контент собирается утилитой в один большой массив и прикомпиливается к основной прошивке.

На SPI флешке легко собрать FATFS. А часть флешки ты резервируешь под буфер прошивки, которую собираешь как обычно - без затей

Ок, как отправляешь файл? Своей программой - тогда можно выбрать все файлы и отправить . Или для отправки нужен единый файл? Тогда можно подключить текстовые файлы к проекту с исходными кодами, только надо задать линкеру область.

LWIP Кроме большого массива поддерживает и чтение с файловых систем

Я правильно понял идею отравлять образ прошивки в формате FatFs? Т.е собираем FatFs на компе с добавлением всех файлов и отправляем. (пока вопрос безопасности не обсуждается)

Окружение такое: есть файл прошивки и есть контент web сервера. Web сервер, естественно, только подгружает файлы с флеша и все. Естественно он ничего заранее о файлах. Я хочу завернуть это в единый файл (например FatFs), отправить на контроллер (через HTTP), потом все распарсить в бутлодере записать бинарь во флеш контроллера, а файлы web сервера в другую половину SPI флешки . (В случае FatFs просто монтировать файловую систему) Возможно я плохо объясняю что хочу, сорри

Можно и так. Тогда в качестве прошивки у тебя будет .bin файл

а кто программер прошивки, он должен все это знать