Jump to content

    

STM32 Cortex-M4 - ремап адресов для внешней программы

И снова, доброго времени суток! Просто запустить внешнюю программу из под SDRAM мне оказалось мало.

Есть адрес SDRAM: 0x8000 0000 - 0x807F FFFF

И есть адрес внутренней флешки со всем нужным API (типа BIOS): 0x0800 0000 - 0x081F FFFF

 

Собственно, внешней ОЗУ много, и камень STM32F429 весьма серьёзен, хотелось бы сделать многозадачную ОС на RTOS с поддержкой запуска внешних приложений. Проблема следующая:

Как сделать ремап адресов в этой внешней программе?

Допустим, есть виртуальная память, которая ремапится следующим образом:

0x0000 0000 - 0x000F FFFF в 0x8000 0000 - 0x800F FFFF- память программ

0x0010 0000 - 0x001F FFFF в 0x8010 0000 - 0x801F FFFF - оперативная память данной программы

 

Да, понятно, что нужно прописать нечто вроде следующего:

if ((Address >= 0x00000) && (Address <= 0xFFFFF))

STM32Address = 0x80000000 + (Address - 0x00000);

 

Проблема в том, что для каждой переменной прописывать такую строку крайне долго и мучительно. Особенно для внутренних функций данной программы.

 

"Вообще, зачем нужен конкретный ремап? Почему бы в линкере не сделать нужные адреса самостоятельно?"

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

 

Вот как сделать так, чтобы можно было сделать этакое "виртуальное адресное пространство?"

 

Ну и задача... Использую CooCox CoIDE и GCC компилятор.

Edited by VHEMaster

Share this post


Link to post
Share on other sites
Вот как сделать так, чтобы можно было сделать этакое "виртуальное адресное пространство?"

Никак. Для этого есть процессоры, которые это умеют.

Между прочим, некоторые компиляторы умеют генерить PIC (position-independent code). То есть такой код, который может выполняться из любых адресов.

Share this post


Link to post
Share on other sites
некоторые компиляторы умеют генерить PIC (position-independent code).

А умеет ли его GCC?..

 

Share this post


Link to post
Share on other sites
Вот как сделать так, чтобы можно было сделать этакое "виртуальное адресное пространство?"

 

Нужен контроллер с MMU, в нем есть режимы виртуальной адресации, защиты и автоматической трансляции адресов.

Edited by mantech

Share this post


Link to post
Share on other sites
А умеет ли его GCC?..

Гугл говорит, что умеет.

Кстати, есть ещё один вариант: генерить перемещаемый ELF. При этом нужно сделать загрузчик, который сможет загружать этот ELF в память по требуемым адресам.

Share this post


Link to post
Share on other sites
Кстати, есть ещё один вариант: генерить перемещаемый ELF. При этом нужно сделать загрузчик, который сможет загружать этот ELF в память по требуемым адресам.

Как это сделать, подскажите, пожалуйста?) *.elf файл при компиляции создаётся.

Share this post


Link to post
Share on other sites
Как это сделать, подскажите, пожалуйста?

Долго и мучительно. Гуглить, читать, разбираться. Английский понимаете, надеюсь. Вы же не хотите, чтобы я за вас это делал?

 

*.elf файл при компиляции создаётся.

Ну и что? Это же не тот эльф, который вам нужен. Короче, копайте в этом направлении.

Share this post


Link to post
Share on other sites
Ну и что? Это же не тот эльф, который вам нужен. Короче, копайте в этом направлении.

Окей, погуглю. А почему не тот?

Share this post


Link to post
Share on other sites
Окей, погуглю. А почему не тот?

MMU умеет транслировать адреса в адресное пространство процесса.

В нашем случае MMU нет, но это не проблема - посмотрите в сторону, как грузятся динамические либы (.dll, .so) - загрузчик работает примерно так:

* загружает либу в RAM

* смотрит в специальную секцию в либе, где указаны адреса, которые надо поправить (прямые обращения к памяти, прямые переходы и пр.), далее правит их в RAM исходя из начального адреса, по которому загружен модуль.

Вам все равно надо будет определиться с загрузчиком, который будет грузить программы. С него и начните. Еще можно почерпнуть вдохновение http://www.uclinux.org/

Share this post


Link to post
Share on other sites
* смотрит в специальную секцию в либе, где указаны адреса, которые надо поправить (прямые обращения к памяти, прямые переходы и пр.), далее правит их в RAM исходя из начального адреса, по которому загружен модуль.

 

Это довольно сложные программы, по сути дизассемблер своего рода...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Загрузчикам нет необходимости что-то дизассемблировать, списки настраиваемых адресов присутствуют в исполняемом файле.

 

Распишите алгоритм кратенько, тоже интересно :rolleyes:

Share this post


Link to post
Share on other sites
Распишите алгоритм кратенько, тоже интересно :rolleyes:

Кратенько здесь

Патчится код, загруженный в RAM. новое значение = старое + смещение, по которому загружен модуль.

Список чего патчить готовит компилятор.

Подробнее - гуглить "Relocation code". Можно начать с Wiki

 

Удачного хака!

Share this post


Link to post
Share on other sites

Вот тут обсуждение загрузчика ELF для STM32. Товарищ утверждает, что адаптировал загрузчик под Cortex-M и сконфигурировал gcc так, чтобы он выдавал ему правильный ELF. Код загрузчика здесь.

Share this post


Link to post
Share on other sites
сконфигурировал gcc так, чтобы он выдавал ему правильный ELF.

 

Жаль, что не ИАР :crying:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this