Бутлоадер., Жду критики от знающих. Опции

[SasaVitebsk]

Доброго всем времени суток. Те кто занят, прошу не беспокоится, - срочного ничего нет.
Ну а тем кто найдёт время мне на ответ, - заранее благодарствие и салют.
Принимаются все ответы. Причём благожелательно. Ценятся ответы знающих людей,
которые всё это уже прошли и мысли тех кто это не реализовал пока, но планирует и
обдумывает. Желательно, конечно, чтобы я знал - где просто мысли, а где реально
работающие идеи.

Теперь к самому вопросу.
Хотелось бы реализовать бутлоадер. Похоже я до него созрел. Но что-то стандартный
подход мне не очень нравится. Хотя я в этой теме ноль без палочки и возможно я
просто ещё многого не понимаю. Короче жду предложений и критики. А свой подход
изложу ниже и попытаюсь его обосновать. Возможно кто-то ещё подключится.

Кратко опишу само изделие, чтобы понятно было почему стандартный подход не нравится.
1) Изделие имеет постоянную связь с компом по RS485. Свой протокол.
2) Изделие настраивается и конфигурируется "на готовое". Для чего существует спец
программа. Отсюда можно узнать текущую версию встроенного ПО. Сюда и планируется
воткнуть обновление ПО.
3) Изделие не имеет никаких кнопок и т.п.
4) В изделии может быть установлено несколько паралельно подключенных блоков с
разными серийными номерами.
5) Изделие выпускается и, поэтому новое должно быть совместимо снизу вверх.

Какие планы.
1) Не устраивает перезагрузка по нажатию или по включению. Хотелось бы обновление
Стандартными средствами (моими конфигурационными) причём в любой момент во время
работы.
2) В связи с тем, что протокол уникальный и меняться не будет (в связи с совместимостью)
то желательно чтобы загрузка шла в рамках данного протокола.
3) Исходя из п.2 хотелось бы саму процедуру загрузки (формирование протокола) вывести
из под программы. То есть чтобы программа и bootloader использовали процедуры bootloadera.
Я это предполагаю сделать путём ссылки обоих груп векторов на одни и теже обработчики.
Также в начальном проекте планирую сразу разместить bootloader. Так сказать сделать его
интегрированной составляющей проекта. Также хочу вынести из под "переписываемой-обновляемой"
части некоторые фиксированные таблицы. Например CRC.

Плюсы я вижу такие. Меньший объём обновляемой части. (для моего проекта это всего 25-30к из
60). Сохранение работоспособности в плане перезаписи даже при разрыве в режиме обновления ПО.
Удобство для конечного пользователя.

Некоторые непонятные для меня моменты следующие. Кристал 64к, а должно работать около 10к в режиме
бутлоадера. Слишком большой размер для бутлоадера это не проблема?
Переписывается незначительная часть. Насколько я понимаю если это кратно страницам, то проблем с
этим быть не должно. Главное чтобы я сам не запортил при программировании. Я прав?

[defunct]

Какие планы.
1) Не устраивает перезагрузка по нажатию или по включению. Хотелось бы обновление
Стандартными средствами (моими конфигурационными) причём в любой момент во время
работы.

Введите штатную команду вашего ПО, по которой устройство должно перезагрузиться.
Конечно, можно сделать, что после перезапуска бутлоадер будет определенное время ждать команд "Host'a", но мне например такой подход не годился, т.к. ПО при старте у меня также запускается в специальном режиме конфигурации. Всвязи с этим, чтобы исключить паузу - я отвел несколько ячеек eeprom для общения основной программы с бутлоадером.

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

Неисключено, что во время работы основной программы может произойти сбой, который приведет к несанкционированному прыжку в секцию бутлоадера. (У меня такие ситуации бывали). Поэтому в функции записи страницы непосредственно перед записью - очень желательно проверить, что эта функция вызвана правильным процессом (опять таки на помощь приходит та же ячейка eeprom, в которой хранится запрос на обновление ПО).

После того как программа обновлена, бутлоадер затирает эту ячейку eeprom и т.о. при следующем перезапуске автоматически перейдет к выполнению основной программы.

2) В связи с тем, что протокол уникальный и меняться не будет (в связи с совместимостью)
то желательно чтобы загрузка шла в рамках данного протокола.

Такое желаение естественно... Можно зарезервировать ряд функций в вашем протоколе для работы с бутлоадером. У меня бутлоадер работает по модбас, я отвел следующие функции (коды функций приводить не буду, как и формат, только расшифровку):

CMD_BM_ENTER // Enter FW upgrade mode
CMD_BM_READ_PAGE // Read flash page via bootloader
CMD_BM_WRITE_PAGE // Write page via bootloader
CMD_BM_CHECK_CONSISTENCY // checking fw consistency, returns - 2 bytes of Image CRC (0 if ok) + 64 bytes of FW info
CMD_BM_EXIT // exit from bootloader (execute main FW)

их с головой хватает как для обновления, так и для организации проверки версии, CRC и прочего.
READ/WRITE PAGE работают следующим образом. WRITE PAGE предполагает, что страница передается зашифрованной, ключ распаковки для конкретного класса устройств (речь о модификации железа, тобиш напр мигалка светиками имеет ключ X, модем - ключ Y и т.д) всегда одинаковый и прошит намертво в бутлоадер). READ Page перед отправкой страницы на "Host" ее зашифровывает тем же ключем. CHECK_CONSISTENCY - передает данные в открытом виде.

Т.о. получается, что у конечного пользователя будет программа в зашифрованном виде, и он нигде не увидит ее в расшифрованном виде.

Один момент, бутлоадер также входит в режим обновления прошивки если CRC загруженой программы несовпадает.

3) Исходя из п.2 хотелось бы саму процедуру загрузки (формирование протокола) вывести
из под программы. То есть чтобы программа и bootloader использовали процедуры bootloadera.
Я это предполагаю сделать путём ссылки обоих груп векторов на одни и теже обработчики.
Также в начальном проекте планирую сразу разместить bootloader. Так сказать сделать его
интегрированной составляющей проекта. Также хочу вынести из под "переписываемой-обновляемой"
части некоторые фиксированные таблицы. Например CRC.

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

Плюсы я вижу такие. Меньший объём обновляемой части. (для моего проекта это всего 25-30к из
60). Сохранение работоспособности в плане перезаписи даже при разрыве в режиме обновления ПО.
Удобство для конечного пользователя.

Бутлоадер может располагаться только в секции специально для этого отведенной (а это максимум 2-4kb).

Некоторые непонятные для меня моменты следующие. Кристал 64к, а должно работать около 10к в режиме бутлоадера. Слишком большой размер для бутлоадера это не проблема?

проблема.

Но почему он у вас так много занимает.
У меня для сравнения - modbus бутлоадер занимает 1kb и помещается в секцию 512 слов.
LAN бутлоадер - 1.7k (секция 1024 слов).

Переписывается незначительная часть. Насколько я понимаю если это кратно страницам, то проблем с этим быть не должно. Главное чтобы я сам не запортил при программировании. Я прав?

Слишком сложно и не будет возможности полностью обновить ПО.
IMHO не очень универсальный метод.