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

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


Хорошо. Итак, берем линкер скрипт из поста 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. Так что внесите изменения, потестите, сообщите симптомы.
Смотрите вложение и дайте недостающие функции.

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

Сообщение отредактировал amw - May 6 2008, 18:19