Уважаемые товарищи!

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

Прошу вашей помощи.

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

Речь идет о следующем:
- бутлоадер в принципе может быть рано или поздно применен для разных архитектур;
- может случиться, что он будет работать отнюдь не с UARTом а по каким-то странным причинам, например, с I2C и др.;
- тем не менее, ясно, что он занимается тем, что воспринимает прошивку в некотром виде и записывает ее на флешку контроллера;
- и вот вопросы лезут - с одной стороны есть ли независимо от перечисленных разнообразий, определенная тенденция к применению файлов прошивок в каком-то определенном формате (intel HEX, скажем), к применению какого-то привычного протокола (скажем, XMODEM), к применению какого-то популярного вида шифрования, надежного по крайней мере для прошивок (или лучше "каждый шифруй по своему, чтоб никто не догадался"), ужимания умеренного.

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

заранее спасибо,
Родион

Вот такого точно не бывает, т.к. есть DES. Его сложно поломать, а "каждый по-своему" - поломать легко.
Затем, бутлоадер - это программа минимальная по размеру. Чаще всего размер диктует все остальное.

Спите спокойно - не обнаружите . Посему с учетом Ваших правильных рассуждений пишите свое. В качестве базы,которую в свое время взял и я, для подготовки прошивок можете взять, полагаю, известный AN Атмела по AES бутлоадеру.
http://www.atmel.com/dyn/resources/prod_do...nts/doc2589.pdf
Исходники написаны крайне дурно (и bootloader и PC утилиты), но в качестве отправной точки и идеи годится вполне. Record Types можно добавлять, отказываясь для других контроллеров от буквального управления процессом прошивки заточенном под AVR. Сейчас оно у меня живет (c добавлением двух Record Type) и на ARM. Сырой бинарный фомат я, естественно, сразу похерил - сделал по мотивам HEX - огрызок в приложении. Загрузчик встроен в том числе и в терминальную программу. Загрузчик в контроллере распознает и Intel HEX Extended формат и соответствено позволяет, если не установлены биты защиты, заливать и его.

Хотелось бы добавить к сказанному следующее.
Я у себя добавил запрос / ответ идентификации устройства.
На данном этапе вывожу туда:
1. ID устройства
2. ID процессора
3. Версия HARDWARE
4. Версия SOFTWARE
5. Логический номер устройства
6. Серийный номер устройства


Эта идентификация едина и для бута и для приложения. Причём при заливке новой версии меняется только версия SOFTWARE (что очевидно).
В результате у меня единообразные PC проги. С помощью редактирования текстового файла можно пользоваться с разными устройствами. Также избегаешь определённой чехарды. Ну например имеется изделие. Чуть изменили схему и продолжили выпускать в том же корпусе. Нет на складе atmega8 - запаяли atmega88.

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

_Pasha: спасибо, ваша мысль правильна на мой взгляд и потому понятна, за исключением того, что есть "политический момент". Когда заказчику (требовавшему "очень страшно засекретить его разработку" супротив поганых конкурентов) в отчете сообщают что используется шифрование DES, он лезет в википедию и обнаруживает что "ну вот, он уже давно сломан, вместо него иногда используется Triple-DES, но честь уже замарана и т.п." - объяснять, что его разработка не стоит тех денег, которые потребуются на оплату трудов потенциального взломщика довольно трудно. С этой точки лучше, конечно, указать что используется "оригинальный алгоритм"... ;-) Ну кроме того реализация DES и AES для некоторых особо мелких бутлоадеров на мой взгляд "жирновата".

Zltigo: весьма благодарен за экспертное и объемлющее сообщение, собственно являющееся ответом на мой вопрос. На упомянутый AN я уже неоднократно натыкался, собственно он и побудил меня задать вопрос... ;-)

SasaVitebsk: также спасибо за указание полезных моментов, которые, видимо, следует принять на вооружение.

В общем, я примерно все понял. %)

Есть еще некоторые идеи:
1. Сам bootloader может быть модульным и конфигурируемым. Что бы пользователь мог выбрать из всех фич, предоставляемых им (bootloader'ом) то, что ему (пользователю) реально нужно
2. Bootloader должен поддерживать сменные модули доступа к внешнему интерфейсу (например UART, I2C, etc)
3. Загрузчик на PC должен быть пострен по компонентному принципу, что бы позволить заливать прошивки в нестандартно включенные МК (например по цепочке JTAG -> CPLD (в boundary scan mode) -> МК (с UART) )

У меня есть весьма старый лоадер для PIC, который поддерживает п1. К сожалению на WEB он похоже не сохранился