Jump to content
    

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

46 minutes ago, Arlleex said:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Just now, Arlleex said:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Just now, Arlleex said:

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...