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

MCU: at91sam7s256
toolchain: Yagarto (gcc-4.2.1)

Есть два простых приложения. Образ первого (размером XXX байт) расположен по адресу 0x100000 (т.е. в самом начале флеша), печатает строку в DBGU и переходит на адрес, по которому расположен другой образ.

Второй образ лежит по адресу 0x100000 + XXX . Все что он делает это выводит другую строку в DBGU и на этом успокаивается.

Но проблема в том, что переход по этому адресу не происходит! Адреса прописал верно, скрипты линкера подлправил. Не знаю, что я упустил...

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

Спасибо!

Не специалист, увы, но по моим соображениям:
- внушает опасение длина кода (orig 0x001004f8, LENGTH = 0x00010000), а ведь остается (0x10000 - 0x4f8).
- а объектники линкуются в один файл? или создаете два образа, которые потом прошиваете один за другим?
- стоило бы скачать прошивку с цели и посмотреть, есть ли в 0x1004fd искомое, а то может, его просто нет...
Наверно, так.

гм.. я сейчас не на работе, в понедельник проверю.


Я создаю два разных образа и прошиваю один за другим.


образ прошивается правильно, по крайней мере по адресу 0x1004fd он находится, проверял с помощью SAM-BA.

делал нечто похожее, но на lpc2378. Проблема была в том, что startup от первого приложения переводил процессор в user mode, соответственно startup от второго приложения уже не мог переключиться в supervisor mode (нужно для инициализации стеков в каждом их режимов). Все заработало после того, как я убрал перевод первого приложения в user mode из startup.

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

Проверил весь стартап, нигде переключения в user режим не обнаружил. Даже не знаю, что еще проверить...

А Вы можете сдампить прошивку контроллера и выложить ее? Хекс, без отладочных файлов... В симулятор загнать, посмотреть, чего он там творит... По-иному не знаю, как.

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

А что за симулятор? У меня gnu-arm тулчейн, в комлекте ничего похожего на симулятор нет.

у Вас есть gdb. Но я им пользоваться не умею... Загляните в раздел gnu/open source, или ман по gdb.
Идея в том, чтобы посмотреть какие инструкции ядро выполняет перед переходом и куда оно после него уходит. Это можно с помощью симулятора сделать (эмулирует работу контроллера на персоналке) или с помощью эмулятора (jtag, например).
Хотя не факт, что хекс Вам поможет.

Возьмите каждый из этих образов (.elf) и при помощи arm-elf-objcopy получите дизассемблерный листинг каждого из них. После этого пройдите "в уме" каждый листинг по командам и убедитесь, что
1) программы располагаются в тех адресах, куда вы их хотели разместить
2) они пытаются делать то, что вы от них хотели.

Еще посмотрите, не затирает ли самба одну прошивку другой.

А что, собственно, располагается по адресу 0x1004f8? А Вы что ожидаете по этому адресу? main()?
Так оно не должно там быть.
А startup код у Вас есть? Где он? В обоих программах?
И дайте вывод

PS: insight просимулирует этот код, но без периферии. Да из eclipse на gdb при target sim. Не знаю, входит ли insight в Yagarto. Я сам собирал.

Да, я уже прочитал в хелпе про target sim. Про gdb не забыл, просто ввело в ступор слово "симуляция"

Startup конечно же есть.


Приаттачил вывод objdump, C-startup и линк-скрипты (код немного модифицировался, размер бинарника и адрес второго образа тоже).

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



Может быть стартап второго приложения нужно переписать (на данный момент он идентичен с первым), ведь первое приложение все уже инициализирует, во втором наверное достаточно только настроить стек и bss?

Есть еще какие-то идеи?

Спасибо!

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


Нифига себе - никакого
Но этот код должен исполняться не с 100000, а с нуля, хотя расположен должен быть действительно по адресу 100000. Kоманда B, будучи перемещенная в адрес 0, прыгнет совсем не туда, куда вы хотите, ибо использует относительную адресацию. Вы попадете на адрес 0x48, и надо ли описывать, что произойдет после ремапа? В начале этого стартапа крупными буквами написано: Он предназначен для линковки с адреса 0.

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

Прикладываю свой вариант стартапа, скриптов линкера и "рыбу" загрузчика. Проверка целостности приложения происходит в __low_level_init(). Если приложение можно запускать, оно тут же и запускается (приложение получает практически всю периферию нетронутой - только запущен PLL и настроено направление портов). Если нельзя - после возврата из __low_level_init() заканчиввается инициализация загрузчика и запуск main() собственно загрузчика. Приложение использует этот же стартап-код из crt.s.

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

большое спасибо за ценные замечания.

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

После ресета АРМ переходит на адрес 0х0 и выполняет найденную там инструкцию; обычно по этому адресу располагается таблица векторов.

Обычно девайсы грузятся с ROM'a. Согласно даташиту, ПЗУ в SAM7 после сброса чипа (и до ремапа) доступно по адресу 0x0; также в любое время к флешу можно обратиться по адресу 0x00100000 - т.е. флэш "двуликий"

RAM, в свою очередь, располагается по адресу 0x00200000. После ремапа - с адреса 0x0.

Как я понял, основная польза от ремапа в том, чтобы код выполнялся из SRAM, что значительно быстрее, и для модификации таблицы векторов. А также при работе с флешом (запись, чтение) - функции, оперирующие с флешем, должны выполняться из RAM.


Понятно, ведь ARM стартует с 0x0. Но тогда почему все атмеловские примеры для САМ7 привязываются к 0x100000 (это и по objdump видно, и по линк-скриптам)....


Вот здесь опять конфуз в голове... Ведь после ремаппинга RAM также доступна с 0x0. Или здесь под адресами линковки подразумевается только internal flash?


Я посмотрел стартап, не заметил больших отличий от того, что я использую (из атмеловского примера). Только в main.c вы делаете ремап (устанавливаете битик в MC_RCR). И есть разница в линкерном скрипте... Вот это:



говорит линкеру грузить секцию .vectors в область REMAPED, определенную ранее. правильно я понимаю?

абсолютно правильно. Кроме записи-чтения флеша. Чтение может выполняться откуда угодно, а при записи в ОЗУ должна находиться лишь мааленькая функция:А вызываться она может из флеша:Видимо у них первой командой идет не 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.
НО!!! В телевизоре Вы можете только видеть. Телевизор не становится ни морем ни горами.
Так вот Вы - процессор АРМ . Вы можете посмотреть в телевизор и узнать, в какое окно Вам прыгать то есть по какому адресу должен быть переход.

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



Таким образом, в _основной_ программе мне нужны вектора (обработчики 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. ?????

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

Спасибо за ваше терпение в ответах на мои глупые вопросы


Хорошо. Итак, берем линкер скрипт из поста N24 (скрипт из приложенного вами проекта отличается совмем немного, но об этом позже), приложенный проект и успешно компилирую.
НО - binary образ, полученный в результате arm-elf-objcopy -O binary tst.elf tst.bin получается огромным (1,052,808байт!) и соответственно не прошивается. При этом бинарник из архива jump.zip крохотный, благополучно прошивается и похоже на то, что работает.

Мой тулчейн взят с www.yagarto.de, собран под Win32:


Вопросы:
1) почему в вашем стартапе вектора определены через "ldr pc, ..." и далее просто word-ами размещены точки входа в обработчики? Чем это лучше/правильнее/оптимальнее, почему не сразу, например:


2) в стартапе вы не делаете ремап и не инициализируете стеки (это наверное связано с тем, что приложение простое и дано как пример?)

3) непонятет вот этот кусок:


Обычно я видел, что в r0 кладется адрес ф-ции main, а потом bx r0

4) в линкер файле вы определяете размер секции векторов в 64 байта. Это потому, что там сначала идут ldr pc ... (7 штук и ноль), а потом 7 слов ?

5) в линкер скрипте секция .vectors вынесена отдельно и .text описывается дважды. Ранее вы советовали vectors вынести внутрь .text. Какой же способ правильный?

Мой тулчейн собран мной и работаю я на Debian/Lenny amd64.
Давайте отлчия в скрипте линкера.
Скорее всего проблема с LOAD ADDRESS (то что в секции после } > !!!!!!!).

Почти одинаково. Думаю это не имеет значения.

Потому что команда B использует относительную адресацию.
Если Вы переместите этот кусок кода в другое место (а Вы его копируете в нулевой адрес), то разница между текущим PC и адресом перехода изменится, а команда B ничего про это не знает.
Объявленные адреса обработчиков через .word содержат АБСОЛЮТНЫЕ адреса обработчиков.
Команда LDR то-же использует относительную адресацию, но Вы же копируете и собственно LDR .... и абсолютные адреса (всего 64 байта). Таким образом в команде LDR после копирования будет правильное смещение до слова в памяти, по которому лежит абсолютный адрес обработчика.

Ну этот кусок кода просто для того, что бы что-то было определенное, а не просто заглушка в виде
xxx: B xxx
Этот кусок кода можна, например, пройти отладчиком и смотреть на адреса и тп.

Всего векторов 8 (один резервный) плюс 8 абсолютных адресов обработчиков. Итого 16 слов по 4 байта. Всего 64 байта. В LPC, например ремапу подлежит только 64 первых байта флеш или ОЗУ.
Ну и для ровного счета. Это называется "common practics".

Правильно и так и эдак.
Все зависит от нужной в каждом конкретном случае линковки.
Внесение .vectors внутрь .text облегчает написание скрипта, но менее гибко.

Отличий нет, я пытаюсь скомпилировать ваш код из архива jump.zip из прежнего поста, используя ваш линкер-скрипт, на своей системе. Изменений не вносил, просто набираю make. Все компилируется и линкуется, но бинарный образ исключительно огромный (!), 1052808байт.

Ну что-ж, тогда Вам придется переписать скрипт по приложенному примеру.
Ключевое место - определение символов, заканчивающихся на _lma__
Возможно я ошибся и binutils-2.17 ведут себя неправильно. Если есть возможность проверте jump.zip с binutils-2.18.

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

Учитывая все это, я переделал стартап приложения, линкер скрипт сделан с вашей помошью. Я прикрепил архив с стартапом/линк-скриптом бутлоадера, стартапом/линк-скриптом приложения и картой памяти. Посмотрите plz что еще не так, возможно с инициализацией периферии или стеками... не знаю, что еще проверить

Судя по всему, сейчас все линкуется правильно, грузится по нужным адресам. Вот фрагмент objdump'a приложения:



Обновил тулчейн до binutils-2.18, ваш пример собирается, скрипт не понадобилось править. Спасибо, что надоумили обновиться

Файл app.S

Попробуйте объяснить русским языком что делает этот код . С точным указанием адресов .
Вот как это понимаю я.
1. r0 = _vectors_start
2. r1 = 0x00200000
3. r2 = _vectors_start
4. r3 = тому, что лежит по адресу _vectors_start, r0 = r0 + 4
5. По адресу 0x00200000 положить значение из r3, r1 = r1 + 4
6. Сравнить r0 и r2. Результат сравнения: r0 = _vectors_start + 4, r2 = _vectors_start
7. Если r0 не равен r2 повторить все начиная с пункта 4.
Вывод: Это будет продолжаться до тех пор пока не будет скопировано 4 гигабайта памяти .
r2 нужно загружать не _vectors_start, а _vectors_end
А лучше сделать так как это у Вас для копирования секции .data. То есть сначала проверить, а потом уже копировать и прибавлять 4.

Рекомендую так-же:
1. Привести в порядок инициализацию стеков. Там у Вас полный бардак. Хотя в простейшем примере это работает, но это не критерий, правда .
2. Используйте один стиль коментариев. А то мешанина из символов коментариев #, ;, //, /* приводит к неожиданным результатам, по крайней мере в синтаксической раскраске редактором, но часто может сыграть злую шутку и с Вами при компиляции. И придерживайтесь стиля коментариев, рекомендованного для ассемблера данного процессора. Для ARM это символ @.
Например где заканчивается коментарий примера ниже по Вашему мнению? А по мнению компилятора? А как расценивать символ # в начале строки? Как коментарий или как директиву препроцессора?


И еще. Чесно говоря MAP файл сам по себе малоинформативен. objdump -SD часто дает гораздо больше полезного (а совместно с MAP файлом вообже супер ) чем сам по себе MAP файл. И не забывайте, что BIN или HEX тоже можно читать с помощью человека .

Признаю, лоханулся


Пока оставил вышеотквоченный вариант. Хотя бы добиться чтобы работало, но пока изменений не заметил.


А в чем именно бардак? Я взял инициализацию стеков из одного из атмеловских примеров (оттуда и мешанина стилей комментариев, наверное индусики портировали тот код ). Таким же образом инициализация делается в аппноте http://www.atmel.com/dyn/resources/prod_do...ation%201.0.zip

(правда там для SAM7X/XC)

Или вы намекаете на то, что правильнее инициализировать стеки только для тех режимов, в которых собираюсь работать, т.е. например IRQ mode и system mode, а остальные не трогать?




А вот еще такой интересный момент, связанный с отладкой. Загружаю свой бутлоадер в gdb, ставлю break на строку, где передача управления приложению:


Вплоть до этого брейкпоинта иду по шагам, смотрю регистры, все ОК. А как теперь прыгнуть на код по адресу 0x00101000? Просто next не работает:


Интересно проверить, как стартап приложения себя действительно ведет.

Ну Вы хоть исправили значение для конца цикла?

Ну вот пример из boot.S с моими коментариями


Чтобы отлаживать то, что Вы хотите, в elf файле bootloader должно быть и приложение.
А его там нет. Что в таком случае будет с gdb?

Да, конечно.

Код стартапа для бутлоадера я взял из атмеловского примера. К сожалению, не до конца понимаю логику работы, АРМ ассемблер только изучаю..

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


Я правильно понимаю, что bootloader нужно оставить в supervisor режиме, а в стартапе приложения перейти в user mode?




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

А ходить по дизассемблированному коду по одной ассемблерной команде за раз он разве не умеет?

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

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

Единственно, что риходит в голову, это слинковать для симулятора boot и app в один файл. Хотя тут будут проблемы с дублями сиволов main(), _start, и пр.


Да вроде может, но вопрос втом есть ли оно там, этот код, по которому нужно ходить.

Но ведь user mode это непривилигерованный режим. Или вы имеете в виду, что от бутлоадера после передачи управления второму приложению достанется supervisor режим. После выполнения всего необходимого, второе приложение уходит в юзер-моуд?



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

NotaBene. Я стараюсь польностью понять, как правильно сделать бутлоадер. Я думаю, что сам загрузчик должен быть компактный, без инициализации лишнего, и главная его задача - получить образ (в моем случае через usb, я возьму за основу пример от атмела с USB CDC), записать во флеш и передать управление дальше. Соответственно и стартап загрузчика будет отличаться. Вот как я его представляю (попправьте plz где ошибаюсь!):

1) определить точку входа [это сделал]
2) установить вектора [это сделал]
3) проинициализировать флеш [во всех примерах, что я встречал, выставляется flash wait state]
4) настроить критические устройства [все что я видел - это отключение watchdog'a, настраивается осциллятор...]
5) инициализация стека [это тоже есть, вроде разобрался что к чему]
6) включить прерывания [это нужно сделать после настрйки стеков. Обязательно настроить стек supervisor режима]
7) сменить режим процессора [как я понял, это делается вместе с пункотом 6; выставляется нужный режим в program status регистре]
8) jump на main()

Кроме этого в примерах видел, что ставятся заглушки для AIC обработчиков. Это как быcommon practics?

Лучше всего, в bootloader использовать минимум. И передачу управления на приложение делать в ARM Supervisor режим.
Суть в том, что приложение вообще не должно знать о наличии bootloader, и потому действовать как будто оно там одно.
Если Вы хотите использовать прерывания в bootloader - инициализируйте два стека - SVC и IRQ.
А приложение потом переинициализирует все по полной программе.

Ну "правильно" - здесь достаточно растяжимое понятие. Главное - что бы он выполнял нужные Вам функции.

1) - не понял, точка входа куда?
7) - ну режимы процессора меняются по мере настройки стеков. Потом не забыть вернуться в SVC.

В общем да.
Хотя не обязательно нужно устанавливать заглушки.
Здесь есть подводный камень. Он появится если Вы захотите из приложения "вызвать" функции bootloader. Это и стеки и прерывания, используемые приложением.

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

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

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

Здесь есть одно НО - всякий раз, когда я пытался добавить что-то свое (например, IRQ_handler) в ваш стартап, то линкер ругался "not enough room for headers".

И напрасно. С телепатией у меня что-то пока туго. Я ж их теперь должен искать и придумывать чем заменить функции из Board.h, dbgu.h и все остальное.
Я, знаете ли, в уме компилировать не умею.

Буду отвечать поэтапно, по мере накопления мыслей. Так что будут добавления позже.
И так скрипты линкера.
boot:

app:

Перекрываются MEMORY REGION. Может это не заметно сейчас, но потом вылезет боком.
boot:

А почему ноль а не 0x00100000?

app, AT91SAM7S64-ROM.ld

Этой секции нет в bin/hex. После дизассеблирования получаем

А в hex файле (начало файла)

Переместить вектора в секцию .text и поставить С НАЧАЛА СТАРТАП ФАЙЛА.

PS: Проверить в железе сейчас не могу, нет под рукой SAM7. Так что внесите изменения, потестите, сообщите симптомы.
Смотрите вложение и дайте недостающие функции.

----------------
Пока все. Действуйте.

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

Выкладываю полный архив со всеми инклюдами.


Возможно это и было корнем проблем. Как же я упустил это из виду...


Но ведь стартует с 0х0? Хотя не уверен, откуда взялась эта строчка.


Ранее вы советовали выносить vectors в отдельную секцию, а не мешать с .text. IMHO это вполне логично, особенно если потом планируется тусовать вектора по памяти.


А почему вы решили, что в bin этой секции нет, ведь там явно написано "дизассемблируем секцию .vectors" и далее армовские инструкции.
А hex я пока читать не умею

Я протестирую приложенный архив, о результатах сообщу.
Спасибо.

Вряд ли. Бинарники пока меньше 1К.

Нужно смотреть на результат.

В дизассемблере даны КОДЫ КОМАНД. В бинарике и HEX файле этих кодов НЕТ.

Да, сейчас вижу, разбираюсь.
Все проверил - видимо, дело в ключах компилятора/линкера, используемых вами и мною, и это сильно влияет на генерируемый бинарник. Сейчас все пересобрал у себя и специально проверил : и в бинарнике и в hex-файле коды присутствуют, но в hex они в перевернутом виде (endianess?).

Я только подправил секцию MEMORY в скриптах, чтобы секции не перекрывались.

Вопрос по makefile'ам. Никак нельзя сделать так:



Линковщик ругается "nonconstant expression for length". Поискал в документации среди встроенных ф-ций линкера, но ничего подходящего не нашел.

Ну и каков результат?

Во первых это линкер скрипт а не Makefile.
Во вторих - никак. Здесь могут использоваться толко константы.
Выдержки из info ld

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


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