Мысли в слух. Кто чего может прделожить интересного.
Имеем однокристалльный МК - как частность АРМ.
Программа МК содержит самописный загрузчик и собственно основную программу.
Собсвенно сами интересности:
1. Куча разнообразного железа, имеющего по сути дела одинаковый загрузчик.
2. Куча версий основных программ предназначенных для разных версий изделий, которые могут быть несовместимы с железом. (Более поздняя версия железа не подходит для старой прошивки и наоборот)
Ну и как следствие проблемы:
Залита не та версия программы - не в ту железку.

Если на своем рабочем месте - это легко исправимо. Загрузчик - защищает сам себя от перезаписи и все легко можно откатить.
А если где-то удаленно? И это делает человек очень далекий от железа и приборов перепрошивается много?
А если после выпуска прибора прошло пару лет?

Т.е. система должна быть дубовой и надежной))))

Дорогие форумчане, что можете предложить? Проблема ведь типовая?

Если прошивку обновляет клиент - она должна быть криптована. Соответственно для несовместимых версий железа используются разные ключи криптования и "неправильная" прошивка не будет расшифрована и, следовательно, будет отвергнута загрузчиком. Другое дело, если основной функционал прошивок для разных модификаций железа сильно схож - тогда может иметь смысл хранить в области загрузчика идентификатор версии железа и в одной глобальной прошивке предусмотреть поддержку всех вариантов железа с ветвлением по прочитанному из загрузчика идентификатору. В этом случае загрузчик может в начале обновления получать информацию о версии прошивки и сравнивая с минимально допустимой версией отвергать либо принимать ее. Причем идентификатор версии имеет смысл заложить изначально, даже если не планируете ветвление по нему. Со временем захочется прийти к объединенному варианту прошивок, а все необходимое для поддержки такого варианта у вас уже будет даже в старых приборах.

Столкнулся с подобной проблемой. Есть много устройств в которых используется по сути один и тот же загрузчик. Устройства различаются незначительно и построены на одной платформе. К сожалению изначально не была предусмотрена проверка приложения на соответствие данному устройсту, и было несколько случаев когда покупатели случайно дистанциооно заливали в одно устройство прошивку от другого устройства. В итоге перепрошитое устройство умирало и требовало железной перепрошивки у производителя. Для решения данной проблемы при загрузке обновления ПО в основной программе была введена проверка на соответствие загружаемомго ПО данному устройству. При загрузке обновления загружались первые 1024 байта, расшифровывались и по определённой позиции читался идентификатор устройства. Если Идентификатор совпадал, то загрузка обновления продолжалась, иначе - останавливалась. С тех пор жалоб на мёртвые устройства после некорректного обновления не поступало.
Для новых устройств с динстанционной перепрошивкой я уже вводил проверку соответствия загруженного обновления данному устройству в загрузчике и в приложении при загрузке обновления.

По поводу проверки версии ПО. Не самый лучший вариант т.к. иногда требуется не только upgrade но и downgrade прошивки на более старую версию. Поэтому лучше в прошивке иметь идентификатор устройства и версию ПО, но при дистанционной перепрошивке проверять только идентификатор устройства.

Криптование прошивок пока не предуматривается.
Вопрос каким образом хранится ID железа? Загрузчик в МК имеет какую то версию и ID - или тип прибора . Т.е. - это по сути ID железа?
Загрузчик верхнего уровня - читает этот ID. - т.е. знает тип железа и модификацию загручика.
Остается записать файл основной программы. Причем сам файл по себе должен нести информацию о допустимости записи в тот или иной прибор.
Выбор типа файла как правило bin или hex???? -
Т.е. должны иметь служебные поля, позволяющие верхнему загрузчику по файлу определить тип железа для которого он предназначен. (ID, номер билда и т.п.)
И версии поддерживаемого железа????

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


Т.е. программа верхнего уровня "парсила" заливаемую прошивку? (Как вариант искала текстовое описание устройства в прошивке)
Ну и разумеется заменила более ранюю версию у клиента?

1) Каждая железка = свой уникальный ID и ID партии (читай топологии платы).
2) Вы можете как угодно тусовать софт, но всё равно либо часть, либо весь софт _должен_ знать ID партии(топологии). И именно это соответствие где то должно храниться для генерации новых прошивок и при контроле заливки софта.
3) Ещё один нюанс. Если софт универсален, и подходит для множества ID партий железок, то тогда _обязательно_ софт должен нести свой _уникальный_ ID соответствующий данной партии железок. Более того, этот ID должен легко считываться сервисной службой и иметь возможность его лёгкого воспроизведения Вами. Обычно при компиляции иф-дефами удобно отключать-подключать различные обработчики нижнего уровня (драйвера - модное словечко), и именно эти-же дефайны включают-выключают биты в ID данного софта.

к слову о надёжности -
сейчас пришёл даже к такому варианту:
внутри МК содержится(может содержаться) несколько версий модулей, либо всей прошивки в целом. бутлодырь имеет возможность анализировать надёжность каждой комбинации загрузки, и в случае большого кол-ва сбоев какой-либо комбинации - перейти на предыдущий вариант сборки. Сама сборка может содержать как фулл, диференциальные, так и инкрементальные версии...

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

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

Не въехал в проблему.
Это как железка умрет если не ту программу залить?
Она ж всегда стартует с загрузчика?
Значит всегда можно новую залить. В смысле старую.
Главное чтоб загрузчик не переписался, но это легко, он знает свой размер и положение.

Лучшее решение в вашем случае - не делать ничего. Залили неправильную прошивку - несут вам для восстановления. Случай это достаточно редкий, да и за восстановление функционала можно денег брать дополнительно.

К тому же при нормально использовании бутлоадер не дохнет при перешивке, поэтому можно просто-напросто по телефону проконсультировать, как вручную перевести железку в загрузчик и передать правильную прошивку.