Ну так и в этот будет простейший - вычисление контрольной суммы ( можно и CRC вместо хэша), сравнение версий и копирование уже загруженной копии на рабочее место.
Мне кажется использование загрузки из ОЗУ при использовании субзагрузчика тогда избыточно. Только для того , чтобы обойти ограничения привязки к адресу.
Но суть вашего предложения ясна.
Надо обмозговать. Благодарю.
ЗЫ Мы же в любом случае должны писать в субзагрузчике бизнеслогику выбора активного и старого.
Почему занавес.
Ресет.
Проверяет основной - а там мусор невалидный. sha256 не совпадает.
Проверяет области для временного хранения - там живой рабочий бут. Копирует - взлетает.
Получается, что чтобы окирпичить девайс - надо и невалидно бут залить и начать его прошивать когда он невалидный, что можно исключить бизнес-логикой субзагрузчика
Вариант окирпичивания - это убить флеш . но ее убить можно только если мы будем постоянно пытаться перелить из временной области в основную.
Ну в моём случае проверка хэша.
Во флешь. Основной загрузчик пишет в сектор в конце флешь новую версию загрузчика, который будет позже переписан при старте субзагрузчиком
да не, я понял. Теперь мне кажется избыточным исполнение из ОЗУ. Почему я не могу заниматься копированием их области А в область Б в необновляемом субзагрузчике?
Я пока склоняюсь к промежуточной части.
Есть субзагрузчик. Всё что он делает - это проверяет нет ли новой версии загрузчика во временном хранилище и если нет - валидирует загрузчик по фиксированному адресу и прыгает туда. Если есть, то копирует новую версию на место загрузчика А уже в основном загрузчике валидация приложения и прыжок в приложение.
Хотя вариант с целым загрузчиком для ОЗУ - тоже мне нравится.
А как лучше? Получается , всё зависит только от того сколько озу...
ЗЫ А зачем тогда две копии? И что делать с копией прежней ревизии? Перетирать ? Мы же не можем откатится назад...Или отдать это решение на кастомную бизнес логику?
да, я уже выбрал вариант как вы предложили. суббутлоадер, бутлоадер , область для копирования, область для приложения.
Мне просто для себя понять - как я могу отправить приложение в RAM , если оно собрано по адресу 0x800000?
Кубизмом не пострадаешь.
Тут СДК от китайцев - ниже LL библиотек STM. Просто обёртки над регистрами.
И то я в нём не уверен.
Целиком копировать загрузчик в RAM?
Этож мне его и собрать надо относительно адреса 0x2000000?
Вот тут мне не особо понятно, когда говорят про "полностью в RAM"
вот это скорее самый лучший вариант.
можете скинуть пример?
Я ещё не достиг этого уровня познания линкер-скриптов.
Как мне в скрипте указать какой фаил куда пихать? Или это в мейкфайле надо делать?
Я могу просто целую папку с CMSIS и SDK запихать по секциям?
вот тут у меня затык сейчас.
на сколько я понимаю мне надо создать статические либы , а потом притянуть их в линкере.
Только получается, что собирать статически надо весь SDK, а не отдельные файлы.
ну собственно в этом и проблема.
И тут гарантия только в том, чтобы не использовать не RAM функции внутри функции.
Ну это я как раз всё сделал.
ECDSA и тд.
Перепрошивка Бута - одно из требований.
Ну идея в этом и состояла.
Просто как я понимаю, если я расположу копирующую функцию в RamFunc существующей секции , то стартап код для нее уже есть.
Достаточно прописать атрибут для функции и не "выпрыгивать" из этой функции до полного копирования?
или это не будет работать?
да сверху уже расписали. резервирование на А и Б загрузчик во флеше.
Но тогда нужна ещё и область которая будет валидировать и выбирать нужный.
Скорее так и сделаю.
Максимально безопасным.
Копировать или сразу слинковать?
Я пытаюсь слинковать часть кода сразу
Но , тогда придётся переписывать ХАЛ под эту область или писать на регистрах.
Не могу найти мануал как прямо объектный фаил запихнуть в линкер скрипт?
идея в том, что сразу добавить gd32f30x_fmc.o ... целиком.
Как это правильно сделать с помощью линкера?
Наверно этот способ самый простой и надёжный.
