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

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

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

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

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

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

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

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

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

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



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

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 загруженой программы несовпадает.


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


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


проблема.

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


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

По поводу зугрузчика - цитата из даташита Entering the Boot Loader takes place by a jump or call from the application program. This may be initiated by a trigger such as a command received via USART, or SPI interface. Соответсвенно, никаких проблем вызвать программу загрузчика из кода приложения нет. Кстати, максимаьный размер программы загрузчика 8 КБ для ATmega128.

Мысли:
Программу загрузчик в МК, можно поместить в бут области, а по команде которую получает прибор переходить в загрузчик и управлять процессом загрузки(это даст возможность неснимать с прибора питание или делать ресет, хотя если у вас используется ватчдог то при завершении обновления можно воспольтзоватся им для перезапуска устройства ).

Короче если подытожить, то первый пункт, в смысле переход в бутлоадер во время работы и работа под своим протоколом - это нормально. И уже практикуется другими.

Остался для меня неясным один момент. Ну например у меня 60к кода. Могу ли я обновить только первых 20к, например? А остальные оставить без изменения? Насколько я понимаю, то могу это сделать кратно странице. Я прав?

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

Я использую и один вариант, и другой.


Конечно. Но это решение мне напоминает методику 20-летней давности, когда объем компилируемой программы был ограничен, в результате вся программы билась на части, а взаимодействие между частями организовывалось с помощью векторов входа и внешних переменных по фиксированным адресам. Вам это надо? В наше то время, когда космические корабли бороздят просторы вселенной? (с)

Да можете, но для чего это делать? Ведь надежнее и проще - скомпилированную программу запаковать соответсующим образом, проверить, что она правильно зашивается бутлоадером и работает нормально - и слать всю.

2Саша

Это случайно не то ,что ты ищеш Прога конечно дизайном не блещет ,делал для себя.

Вообще все сказали верно.
Например у меня бут работает совершенно независимо от программы,тоесть все равно что я через него залью, будет бут работать.
Естественно это обеспечиваетя изменением вектора ресета и расположением в секции бута.
Второе ,бут никаких признаков не дает при запуске,он просто пару секунд ждет команды соединения(пока конденсаторы в схеме заряжаются ),если нет переходит на выполнение программы .Тоесть он может иметь свой протокол и скорость обмена.
Лично я делал бут ,так как надоело перетыкать разьемы и скорость просто офигеть ,мегу88 я ПОЛНОСТЬЮ флеш шью за 2 сек,а после применения алгоритма ускорения за 1 ,когда при отладке перешиваеш за день раз 50 - тоже приятный момент,да и аппаратный СПИ тоже частенько нужен с схеме .Поэтому лучше заливай полностью код в секцю программы ,времени это много не займет.А вот над размерчиком нужно поработать,пиши на асме,тем более что ты его знаш.

Так что бут - это рулез ,ЮЗАТЬ ВСЕМ

Честно говоря так и планировал.

Простите ребята. В общем-то в жизни меня никто по крупному не обманывал. В кого я такой? Ну ничего на веру не принимаю. По работе. Пока сам не убежусь. Обязательно надо на грабли наступить. Вы уж простите. Ну и спасибо всем участвующим в обсуждении. Попробую по своему, но Ваше мнение (причём единогласное) конечно же в уме держать буду. В конце концов приду к какому-нибудь гибриду.

2 Богдан ответь мне на пару вопросов.
1) У тебя бутлоадер с шифрованием?
2) Разве из бута можно ставить и читать фузы?

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

2 Можно читать конфигурационные фузы ,читать и писать фузы защиты касающиеся доступа к секции бутлоадера и секции программ.Защиту можно увеличить только в большую сторону ,снять и изменить ее нельзя.

Хочу еще через бут заливать внешнюю память подключенную к МК,пока над этим работаю.

Ниужели более непробиваемый, чем AES256?

Да ,более непробиваемый ,чем AES256.Или не менее

Дайте угадаю - у вас шифрование методом подстановки по таблице?
Тогда это хорошая шутка про сравнение с AES

Не угадали
,наложением маски из 256 байт ,количество вариантов 256 в 256-ой степени без учета алгоритма наложения,
если кому не нравиться столько вариантов,я не виноват.

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

Я знаю только один случай, когда это нужно использовать. Одна из крупных фирм в нефтехимии сертифицирует оборудование сторонних изготовителей. После сертификации версия фиксируется. Обычно это касается поддержки протокола связи. Если поддержка протокола связи интегрирована в основной блок прибора, то участок кода поддержки протокола выделяется, считается контрольная сумма, и так далее. Если возникают вопросы с работоспособностью, проверяется код, и всем раздается по заслугам. К счастью, в нашей системе за протокол отвечает отдельный модуль, и этого делать не пришлось.
То, что подход работает - я не сомневаюсь, сам так "подходил", но что заставляет так делать сейчас?!