Перейти к содержанию
    

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, k155la3 said:

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

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

Да. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

46 minutes ago, Arlleex said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, Arlleex said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, Arlleex said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...