абсолютно правильно. Кроме записи-чтения флеша. Чтение может выполняться откуда угодно, а при записи в ОЗУ должна находиться лишь мааленькая функция:А вызываться она может из флеша:Видимо у них первой командой идет не B, а LDR PC,[PC, #24], которая грузит в PC абсолютный адрес, расположенный тут же в сегменте векторов. Т.е. для первой команды все равно где располагаться, а вторая передаст управление на абсолютный адрес во флеше, т.е дальше программа работает в адресах 0x10.... Почему они линкуют вектора на абсолютные адреса флешь - загадка. Может быть, для упрощения скрипта. А может просто исходят из того, что поскольку и в адресах флеша и в нулевых адресах лежат копии, то как бы все равно, откуда реально исполняется код. Ну побегает он по нулевым, потом на первой же команде абсолютного перехода перескочит в адреса флеш. Но если, находясь в нулевых адресах, он сделает ремап - наступит карамба, поскольку следующую команду он неожиданно получит из ОЗУ.Да. А в начало RAM перед ремапом скопирован сегмент векторов приложения. Код в это время исполняется уже с адресов 0x10...., и передав выполнение на адрес 0 мы попадаем на начальную команду приложения. А там стоит LDR PC, [PC, #24], а по адресу 0x20 лежит абсолютный адрес начала стартапа приложения. Он грузится в PC и управление снова попадает на адреса флеш, куда-то после 0x101000. При этом приложение имеет свой сегмент векторов, который совершенно независим от векторов загрузчика. Ближе к обеду еще раз внимательно изучу ваш код, возможно вы пытались построить передачу управления на другом принципе.
Не совсем. Оно говорит, что во время исполнения эта секция будет находиться в области REMAPED. Поэтому все ссылки из нее должны быть установлены так, как будто она находится в области REMAPED. Но физически эти байты надо сложить в область ROM. Аналогично для секции .data - все ссылки будут на область RAM, а физически начальные значения будут сложены в область ROM. Как будет происходить перемещение кода (ремап или копирование, как для секции .data), линкер не знает.

Приветствую.

Все немного проясняется, из мозаики складывается картинка Но все же не до конца представляю: для моей задачи (бутлоадер), нужен ли стартап с remap или без оного? Отсюда соответственно и линкер срипт.

И еще. Как Вы уже упомянули, мой первоначальный startup-код "должен исполняться не с 100000, а с нуля, хотя расположен должен быть действительно по адресу 100000". Почему тогда в отдельности (т.е. _без_ перехода на второй образ) этот простой код работает?

И вот еще по адресам: как я понимаю, до ремапа все адреса, о которых мы говорили, физические (например, физически флеш находится по адресу 0x100000, но отмаплена на 0х00 при старте), а после ремапа - они логические?


Ваш стартап использует remap; вопрос - область REMAPED, описанная в линкер скрипте, определяет именно SRAM область после ремапа - правильно я понимаю?

Спасибо !

Зависит от того, как Вы напишете бутлоадер.
Например часть кода из стартап линкуется для исполнения во флеш. А все остальное слинковано для выполнения в ОЗУ. Если нужны прерывания - то ремап думаю нужен (если обработчики в ОЗУ то лучше и вектора туда положить).

Первые команды (бутлоадер) пользуясь относительной адрессацией выполняют переход по абсолютному адресу.
Во второй части программы (собственно программа) то-же самое, но смещения не верны из-за того, что код расположен не с нулевого адреса.
И ОЗУ и флеш доступны одноврнменно и по адресу 0 и по их фактическому = абсолютному адресу и смщения как от нуля так и от, скажем 100000 для флеш одинаковы как от 0 так и от 100000 для бутлоадера, а вот для основной программы - нет.

Нет. В этом процессоре все адреса физические. Просто флеш (или ОЗУ) доступна одновременно по двум адресам.

Сергей, в вашем варианте стартапа вы не инициализируете стеки для каждого из режимов (interrupt mode, supervisor mode). Почему?

И еще. В этом примере http://www.atmel.com/dyn/resources/prod_do...started_1.0.zip в линкер-скрипте они вообще не описывают секции памяти (директива MEMORY), секция .vectors (содержит таблицу векторов) помещается в область .data; сам стартап делает remap



Видно, что область .data линкуется в 0x100000 адреса. Это потому, что remapping происходит?

Эх... все больше загадок

Здравствуйте,


Я делаю бутлоадер для конкретного применения, т.е. он не универсальный, а будет обновлять в железке конкретное ПО, которое активно использует прерывания (fiq и irq), работает с TWI, spi и пр.
То есть remap таки нужен?


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

Правильно ли я понимаю? Это справедливо для всех ARM-ов или только sam7?

Спасибо.

Если Вам в основной программе нужны вектора, то располагайте вектора в ОЗУ (линкуйте вектора для ОЗУ), копируйте вектора в ОЗУ и делайте потом REMAP.

Ой ни ни!!!!
Не правильно!
Линковка определяет абсолютные адреса по кторым будут располягаться функции и данные фактически.
В процессоре имеется:
1. Вектора, и они всегда по нулевому адресу.
2. Флеш, она хранит и программу и данные. Находится по адресу X. Данные в ней не модифицируются и при отключении питания не теряются.
3. ОЗУ, она хранит и программу и данные. Гаходится по адресу Y. Данные в нет теряются при выключении питания. Но быстрее флеш.

Если Вам нужно иметь быстрый код - линкуйте его в ОЗУ. Но! При выключении питания этот код исчезает. Так как он попадет в ОЗУ при следующем включении?
А очень просто! Он хранится во флеш и при каждом включении питания программа, запускаемая из флеш копирует нужный кусок в ОЗУ.
Как это обеспечить? При линковке, все команды перехода используют абсолютный адрес ОЗУ для вычисления адреса конкретной команды перехода. Линкер складывает в HEX файл все подряд. Сначала то, что слинковано для запуска из флеш по адресам во флеш, где этот код должен находится во время выполнения программы.
За ним (за этим кодом) фо флеш лежит копия того, что должно во время выполнения быть в ОЗУ. А стартап код выполняет копирование этой копии в ОЗУ по нужным адресам.

Вектора находятся по адресу ноль. И как не линкуй, а вектора должны быть по адресу ноль и только ноль. Так что же делать? Да просто сделать так, что бы флеш или ОЗУ было видно по адресу ноль. Как это сделать? Ну в процесоре ставят "хитрый" адресный дешифратор, который в зависимости от бита REMAP будет показывать по нулевому адресу либо флеш либо ОЗУ. Тут главное обеспечить из вектора команду перехода так, что бы он "послал" процессор по правильному абсолютному адресу!

Не зависимо от REMAP и флеш и ОЗУ остаются доступны по своим адесам. То есть по адресу X всегда видна флеш а адресу Y всегда видно ОЗУ. А адресу ноль видно "то же самое" что и во флеш/ОЗУ. Что именно видно по адресу ноль - зависит текущего значения REMAP.
Но прогамма слинкованная для ОЗУ, расположенному по адресу Y не может выполнятся по адресам, видимым начиная с нуля! Тогда в вектора ставятся адреса перехода, указывающие адреса ОЗУ.

В разных АРМ по разному. В SAM7 все ОЗУ или вся флеш мапится на нолевой адрес, в LPC - только первые 64 байта (то есть сами вектора и место для указания абсолютных адресов перехода).


Представте, что Вы сидите в комнате. Слева у Вас окно, и Вы в нем видите море. Справа у Вас окно, и Вы в нем видите горы. А прямо перед Вами супер пупер фул ХД телевизор. К телевизору подключены две камеры. Однв показывает то, что видно в левом окне, а вторая - то что в правом.
Море - это флеш. Горы - это ОЗУ. Телевизор - это то что видно по адресу ноль.
Щелкая ДУ телевизора Вы можете видеть либо море, либо горы. То есть либо флеш, либо ОЗУ переключая бит REMAP.
НО!!! В телевизоре Вы можете только видеть. Телевизор не становится ни морем ни горами.
Так вот Вы - процессор АРМ . Вы можете посмотреть в телевизор и узнать, в какое окно Вам прыгать то есть по какому адресу должен быть переход.

Сообщение отредактировал amw - Apr 12 2008, 07:46

Большое спасибо за подробные разъяснения!



Таким образом, в _основной_ программе мне нужны вектора (обработчики fiq и irq):
1) в основной программе (загружаемой бутлоадером) копируем таблицу векторов в RAM, далее устанавливаем бит remap, тем самым отмапливаем ОЗУ по адресам 0x200000 И 0x0
2) бутлоадер - ремап не обязателен, ведь нам нужно только загрузить приложение куда следует, а оно уже само разберется. Как я понял, ремаппинг может понадобиться только для работы с флэшем, чтобы избежать compiler-specific фич (например, __ramfunc в IAR'e).

Такая концепция верная?


Здесь речь идет о командах типа B, BL, BX или что-то другое? Есть какие-то специализированные инструкции послать процессор по абсолютному адресу?

Примерно так.
Учтите, что в ОЗУ копировать нужно вектора ПРИЛОЖЕНИЯ ане бутлоадера. При этом векора приложения сами должны быть слинкованы по адресу ноль, а остальное приложение по его родному адресу.

Команды B и BL используют относительную адресацию.
В них указывается смещение (т.е. разница) до нужного адреса от текущего значения PC. Это смещение должно после копирования векторов в ОЗУ соответствовать расположению программы (обработчика).
Команда BX использует абсолютную адресацию.
То есть для команды BX абсолютный адрес перехода находится в регистре. Как он туда попал - вот это вопрос.

А вот дальше не уверен что все правильно распишу, поправте кто-нибудь, если я лажанулся.
Команда LDR PC, AAA использует значение AAA как смещение от текущего PC до адреса, где лежит абсолютный адрес перехода. Брррр.
Пример

В данном примере команда
ldr pc, IRQ_ADDR
Загрузит в PC число, лежащее в памяти по адресу IRQ_ADDR.
По адресу IRQ_ADDR лежит число = адресу собственно обработчика прерывания IRQ_handler.

Приветствую.
Есть вопрос по линкер-скрипту приложения. Взял скрипт из одного из атмеловсеих примеров под gcc и немного переделал. Вот что получилось:



После компиляции смотрю map-файл (он генерируется гнушным линкером и содержит карту памяти) и вижу, что секция vectors занимает 0 байт Что неправильно в этом скрипте?

Спасибо.

А в файле с исходным текстом указано, что вектора надо класть в секцию vectors? Сделайте дизассемблерный файл и посмотрите, куда они попали на самом деле.

Здравствуйте.



В оригинальном стартапе вектора не были оформлены в отдельную секцию директивой .section, поэтому я сделал таким образом:



Как я догадываюсь (в документации на GNU assembler не нашел явной информации), сеция определенная с помощью .section простирается до следующей директивы .section. Но вот откуда начинается следующая за .vectors секция, т.е. .text? С вектора InitReset?

А вот так копируются вектора в память с последующим ремапом:





Должно же быть "b 0x0 ..."? Гм...

Немного покрутил, но все равно не работает Сейчас карта памяти вроде выглядит правильно:



То есть вектора расположились правильно и размер у них правильный - 32байта. А вот objdump:

Может быть это особенность компилятора (или скорее ассемблера)?

Да есть такая проблема. Сделайте так

Дело в том, что
1. Ваш скрипт описывает действия с секцией текст несколько раз
2. Секции располагаются в памяти в алфавитном порядке если не указанно иное. Поскольку vectors идет после text то тут возникают вопросы.

Приветствую.



Наверное вы имели в виду:

Но это все равно не помогает. Map-файл выглядит так:

Вектора он таки поместил в начало и размер 0x20, то есть 32 байта. Но objdump тем не менее видит эти вектора по неверному адресу:



В линкер-скрипте секция .text только один раз.

Давайте согласуем действия.
Возмем за основу приложенный проект.
Линкер скрипт взят из поста #24.
Ваши коментарии? Результаты компиляции?


Пост #24. ?????