Есть структура

main.c:

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

Возможно, есть некий механизм, вроде этого:

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

PS: у меня такую структуру (только неизменного формата) добавляет внешнее приложение - берет hex файл, делает его merge с информацией о версии программы которую кладет в последнюю страничку app секции выбранного МК (кстати работает не только в пределах семейства AVR, но и чудесно работает для МК других семейств), добавляет crc и шифрует DES'ом. На выходе бинарник который постранично передается bootloader'у.

В хедерах WinAVR есть FLASHEND и SPM_PAGESIZE. Обои две в байтах.

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

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

Это меня и интересует. Хочется реализовать сей момент как-то более универсально, что ли. Одним словом, как скрестить FLASHEND, sizeof(MyStruct) и линковщик?

Я так и понял, вот только из ваших "во-первых" и "во-вторых" вытекает, что либо вы задумали раздавать обновления в девственно скомпиленном виде никак не зашифровав, либо просто пока не думали об этом.

Так вот если первое (раздача в открытом виде не планируется), тогда советую подумать над моим вариантом.
Компилятором да линкером, ничего лишнего не нужно вставлять в программу, никаких выделенных адресов для хранения версий.. Возложите это действие на __ваше__ внешнее ПО. Пусть внешнее ПО будет брать любой .hex файл, и вбивать в него ваши настройки которые собсно и будут уточнять "для какого __устройства__ эта прошивка собрана". Зная специфики бутлоадера конкретного устройства - вставлять структуру данных с версией поддерживаемого бутлоадера, версией программы, датой создания, коментариями, в правильную для конкретного бутлоадера страницу флеш памяти, считать CRC + шифровать результирующий бинарник конкретным алгоритмом с конкретным ключем (ключи и алгоритмы шифрования для разных бутлоадеров могут быть разными хотя бы в силу того, что толстый алгоритм не всегда можно впихнуть в совсем мелкий МК как m48/m8). А правильная страница для хранения такой структуры - это не последняя страница флеш, а страница, которая лежит непосредственно перед BOOT секцией, т.е. последняя страница APP секции. Напомню, что размер BOOT секции может изменяться в пределах одного МК, например сегодня чтобы уменьшить Time to market вы напишете бутлоадер левой ногой на бейсике и займете 8KB секцию, а завтра - соптимизируете и тот же функционал поместится уже в 2KB секцию.

Короче тут есть над чем хорошо подумать...

Мне процесс "заливки" видится так:
Бутлоадер - это отдельная универсальная прошивка, но которая при этом может отражать название девайса, его серийный номер, может быть какую-нибудь дату, одним словом, некоторые параметры, которые нежелательно утратить во время неудачного обновления основной программы. Правда, серийное производство меня мало волнует, но почему бы и не пофантазировать.
А вот, допустим, контрольная сумма, кол-во раз перепрошивания, возможно дата последней прошивки - такие вещи действительно необходимо хранить перед загрузчиком. Поэтому в первом моем посте один из фигурировавших параметров был MaxSizeBootMega128, к примеру. Но я так прикинул, что размер бутлоадера можно отразить в его версии, отдав под это дело пару бит. Но опять-таки, структура, а точнее ее последние поля должны быть одинаковы во всех версиях всех бутлоадеров и располагаться в самом финале флэша, т.е. относительно константы FLASHEND.

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

Достаточно только идентификатора устройства и версии bootloader'a
Для примера:
KIT-KP <-- эта строка определяет класс устройства
B1.120.5 <-- эта строка определяет тип программы - бутлоадер "B", HW ревизию платы - 1, объем флеш памяти МК доступной для App в KB - 120, и програмную реализацию bootloader'а - 5. Последняя уточняет необходимый алгоритм шифрования и ключ.

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


Несомненно.


Про информацию бутлоадера все известно из тех двух строк приведенных вышу - их достаточно чтобы полностью идентифицировать устройство, и определить какие app в это устройство можно грузить, какие - нет. Теперь надо подумать о информации о самой прошивке - ее название, ее версия, совместимый бутлоадер (для примера выше - строка "KIT-KP", можно и с уточнением HW и флеш памяти и ключа шифрования - "1.120.5"), CRC, коментарий, дата создания и т.д. - вот именно эту информацию и надо хранить по фиксированному адресу флеш, перед BOOT секцией.

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