STM32L471 запрет прямой адресации

[Димон Безпарольный 0]

Доброго всем дня. Написал бутлоадер, теперь заказчик хочет чтобы в памяти располагалось две прошивки. Рабочие. Намекает что можно установить такой запрет. Может кто подскажет как это сделать и чем это грозит?

[Forger 0]

.

[k155la3 2]

>> STM32L471 запрет прямой адресации

Это в смысле что прошивка(и)/код должны быть "переносимые" ? 

Большая часть переходов и так имеет относительную адресацию. За "переносимость" данных Вы можете позаботится сами.

[aaarrr 1]

Почитайте про генерацию PIC/PID (position independent code/position independent data) в документации на ваш компилятор.

[Димон Безпарольный 0]

2 hours ago, k155la3 said:

>> STM32L471 запрет прямой адресации

Это в смысле что прошивка(и)/код должны быть "переносимые" ? 

Да. 

[Димон Безпарольный 0]

Кажется нашел

Bare-metal Position Independent Executables
A bare-metal Position Independent Executable (PIE) is an executable that does not need to be executed at a specific address. It can be executed at any suitably aligned address.

 

https://developer.arm.com/documentation/100748/0618/Mapping-Code-and-Data-to-the-Target/Bare-metal-Position-Independent-Executables

[Arlleex 1]

Сами прошивки откуда будут выполняться? Flash/RAM? А то, может, и не нужны там никакие PIC.

[Димон Безпарольный 0]

46 minutes ago, Arlleex said:

Сами прошивки откуда будут выполняться? Flash/RAM? А то, может, и не нужны там никакие PIC.

Из Flash. В которой должны быть две прошивки.

[Arlleex 1]

Ну слинкуйте их с разных исполняемых адресов...

[Димон Безпарольный 0]

Just now, Arlleex said:

Ну слинкуйте их с разных исполняемых адресов...

Это тяжело. Потому как прошивки должны лежать на сетевом ресурсе. Если одна не пошла, запускаем предыдущую с нижних адресов. Какая из прошивок не пойдет предугадать невозможно - кто из них окажется в верхней или нижней части памяти Flash.

[Arlleex 1]

Вы сказали, что в памяти МК будет лежать 2 прошивки. Я и говорю, что можно проекты прошивок настроить так, чтобы они были слинкованы с разных (прибитых гвоздями) адресов. Одна - там, другая - сям. Бутлоадер (или некая прослойка) определяет, какую из них запустить и отдает управление. Заказчику отдать (или как Вы говорите "положить на сетевой ресурс") объединенный hex/bin-файл из двух этих прошивок.

[Димон Безпарольный 0]

Just now, Arlleex said:

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

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

[Arlleex 1]

Понятно. Тогда PIC.

[Forger 0]

Я бы сделал иначе - прошивка шифрованная и всегда с того же адреса.

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

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

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

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

В этом случае такие прошивки можно выкладывать да хоть на открытом ресурсе )

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

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

9 minutes ago, Димон Безпарольный said:

Это две одинаковые прошивки одного проекта.

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

Вот если бы адреса запуска были неизвестны, то другое дело. А когда они фиксированы и жестко оговорены, то задача сильно упрощается )

[Arlleex 1]

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