время загрузки базового адреса cortex-m3 bare metal

Question

Я работаю над проектом на процессоре cortex-m3 с чистым окружением. Из-за необходимости обновления программного обеспечения исполняемый образ на ЦП может находиться по одному из двух адресов во флэш-памяти, что представляет проблему. Начальный адрес изображения известен только во время загрузки, а не во время статического связывания. Я не слишком уверен, но я думаю, что это на самом деле не квалифицируется как динамическая загрузка, но я могу действительно ошибиться, поскольку я не эксперт в этом. Есть ли способ скомпилировать и связать образ таким образом, чтобы его базовый адрес мог быть задан только во время загрузки, если нет ОС и динамического загрузчика?

Answer 1

Для таких встроенных систем, как ваша, это достигается за счет компиляции / связывания вашего кода как перемещаемого кода, также известного как Независимый от позиции код .

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

Все становится немного проще, когда вы работаете с платформой (процессором и ОС), которая поддерживает MMU (не на CM3, извините) - тогда код может быть расположен где угодно в физической памяти, но через MMU, его логическое адресное пространство может быть другим. Таким образом, во время соединения адреса для кода и данных могут быть фиксированными, а затем во время загрузки пространство логических адресов настраивается через MMU, и программа не является разумной.

Вам также может пригодиться этот другой вопрос SO ( "Попытка загрузить независимый от позиции код в cortex-m3" ).

Answer 2

Вам необходимо каким-то образом определить, когда устройство будет сброшено, из какого из двух возможных местоположений оно должно начать выполняться.Но, как правило, устройство с «голым железом» имеет только одно начальное местоположение, из которого оно запускается при сбросе (некоторые контроллеры могут выбирать одну или более точек входа на основе логического уровня некоторых выводов на устройстве).

У нас было аналогичное требование, и мы разработали следующую схему:

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

. Загрузчик проверяет фиксированные, общеизвестные местоположения, чтобы проверить контрольные суммы двух возможных изображений.

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

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

Теперь устройство можно обновить, пока оно работает, мигая образом в нерабочее место (Cortex-Устройство M3, которое у нас есть, позволяет это - если LPC1758 не позволяет этого, вам нужно что-то, что запускается из ОЗУ, для обновления флэш-памяти).Сброс, и загрузчик выбирает только что перепрошитый образ.

Системе требуется небольшая предварительная работа, чтобы запустить загрузчик и работать надежно, но как только он заработает, обновления будут на 100% надежными (если новыйflash не завершается, старый образ является единственным, который проверяет контрольную сумму, поэтому он будет работать при следующем сбросе - без кирпичей).Главный недостаток - и это серьезный недостаток - это то, что вы по существу теряете половину адресного пространства флэш-памяти для основной программы, поскольку флэш-память должна содержать два конкурирующих изображения.