прыгнуть на другой адрес в ROM Опции

[romez777]

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

MCU: at91sam7s256
toolchain: Yagarto (gcc-4.2.1)

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

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

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

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

Спасибо!

Прикрепленные файлы

 fwdat91boot.zip ( 4.81 килобайт ) Кол-во скачиваний: 122

 

[romez777]

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

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

boot:

Код

  CODE (rx) : ORIGIN = 0x00100000, LENGTH = 0x00040000

app:

Код

  ROM (rx) : ORIGIN = 0x00101000, LENGTH = 0x00001000    /* 4K is enough for bootloader */

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

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

Код

SECTIONS
{
  /* first section is .text which is used for code */
  . = 0x0000000;
  .text : { *Cstartup.o (.text) }>CODE =0

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

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

app, AT91SAM7S64-ROM.ld

Код

  .vectors :
  {
    _vectors_start = .;
    *(.vectors)
    KEEP(*(.vectors))
    _vectors_end = .;
  } >REMAPPED AT >ROM

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

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

Код

app.elf:     file format elf32-littlearm

Disassembly of section .vectors:

00000000 <_vectors_start>:
   0:    e59ff018     ldr    pc, [pc, #24]; 20 <resetvec>
   4:    e59ff018     ldr    pc, [pc, #24]; 24 <undefvec>
   8:    e59ff018     ldr    pc, [pc, #24]; 28 <swivec>
   c:    e59ff018     ldr    pc, [pc, #24]; 2c <pabtvec>
  10:    e59ff018     ldr    pc, [pc, #24]; 30 <dabtvec>
  14:    00000000     .word    0x00000000
  18:    e59ff014     ldr    pc, [pc, #20]; 34 <irqvec>
  1c:    e59ff014     ldr    pc, [pc, #20]; 38 <fiqvec>

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

Код

:020000040010EA
:10103C00FEFFFFEAFDFFFFEAFCFFFFEAFEFFFFEA0F
:10104C0004E04EE200402DE900E04FE100402DE9C4

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

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

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

Прикрепленные файлы

 loader.zip ( 141.26 килобайт ) Кол-во скачиваний: 41

 

[amw]

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

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

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

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

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

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

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

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

[romez777]

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

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

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

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

Код

/* Size of bootloader region */
BOOTSIZE = 0x00040000;

/* Memory Definitions */
MEMORY
{
  CODE (rx) : ORIGIN = 0x00100000, LENGTH = BOOTSIZE
  ...
}

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

[amw]

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

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

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

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

Код

/* Size of bootloader region */
BOOTSIZE = 0x00040000;

/* Memory Definitions */
MEMORY
{
  CODE (rx) : ORIGIN = 0x00100000, LENGTH = BOOTSIZE
  ...
}

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

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

A linker script may contain at most one use of the `MEMORY' command.
However, you can define as many blocks of memory within it as you wish.
The syntax is:
MEMORY
{
NAME [(ATTR)] : ORIGIN = ORIGIN, LENGTH = LEN
...
}
The ORIGIN is an numerical expression for the start address of the memory region. The expression must evaluate to a constant and it cannot involve any symbols. The keyword `ORIGIN' may be abbreviated to `org' or `o' (but not, for example, `ORG').
The LEN is an expression for the size in bytes of the memory region. As with the ORIGIN expression, the expression must be numerical only and must evaluate to a constant. The keyword `LENGTH' may be abbreviated to `len' or `l'.
In the following example, we specify that there are two memory regions available for allocation: one starting at `0' for 256 kilobytes, and the other starting at `0x40000000' for four megabytes. The linker will place into the `rom' memory region every section which is not explicitly mapped into a memory region, and is either read-only or executable. The linker will place other sections which are not explicitly mapped into a memory region into the `ram' memory region.
MEMORY
{
rom (rx) : ORIGIN = 0, LENGTH = 256K
ram (!rx) : org = 0x40000000, l = 4M
}

[romez777]

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

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

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

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

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

[amw]

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

Ну так у SAM7S little endian. Все правильно. По младшему адресу - младший байт.
Если есть светодиоды на плате, то для визуализации процесса можно понатыкать в Cstartup.S поочередное зажигание. И посмотреть где оно стопорится.
Давайте последний проект, посмотрю.

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

[romez777]

Ну так у SAM7S little endian. Все правильно. По младшему адресу - младший байт.

Я так и думал, но как объяснить слудующее. Фрагмент дизассемблера:

Код

Disassembly of section .text:

0010403c <Undef_Handler>:
  10403c:    eafffffe     b    10403c <Undef_Handler>

А вот hex:

Код

:10403C00FEFFFFEA......

Дизассембляция сделана командой: arm-elf-objdump -h -S -C - то есть дамп, как я понимаю, уже должен быть с перевернутыми байтами?

Если есть светодиоды на плате, то для визуализации процесса можно понатыкать в Cstartup.S поочередное зажигание. И посмотреть где оно стопорится.
Давайте последний проект, посмотрю.

Отличная идея! Сейчас приложу архив.

Прикрепленные файлы

 boot.zip ( 106.05 килобайт ) Кол-во скачиваний: 40

 

[amw]

Я так и думал, но как объяснить слудующее. Фрагмент дизассемблера:

Код

Disassembly of section .text:

0010403c <Undef_Handler>:
  10403c:    eafffffe     b    10403c <Undef_Handler>

А вот hex:

Код

:10403C00FEFFFFEA......

Дизассембляция сделана командой: arm-elf-objdump -h -S -C - то есть дамп, как я понимаю, уже должен быть с перевернутыми байтами?

Тут как раз байты не перевернуты, а стоят в правильном порядке. Маленький экскурс в HEX файлы.
: - Признак начала строки HEX. Все строки должны начинаться с него.
10 - Размер строки в байтах. Считаются только полезные байты.
403C - Адрес с которого начинает размещаться строка.
00 - Код записи. 00 - значит строка с данными.
FE - Первый байт данных. Размещается по указанному адресу.
FF - Второй байт данных. Размещается по адресу (указанный + 1)
....
Всего байтов данных столько, сколько указанно после двоеточия.
<Последний байт в строке> - контрольная сумма.

Отличная идея! Сейчас приложу архив.

Сейчас гляну.

Посмотрел.

1. У Вас приложение (в бинарик и HEX) начинается вот с этого кода

Код

Undef_Handler:
    B    Undef_Handler
  10403c:    eafffffe     b    10403c <Undef_Handler>

А векторов там нет.

2. Разберитесь сначала с ARM режимом, а то сразу и ARM и THUMB Вас запутывает.
Например, Ваш boot переходит в THUMB, а потом запускает приложение командой BL, а приложение начинается с ARM режима, и соответмтвенно ничего не работает.

3.

arm-elf-objdump -h -S -C - то есть дамп, как я понимаю, уже должен быть с перевернутыми байтами?

А причем здесь endian?
-h - Показать заголовок
-S - Показать исходный код

-C
--demangle[=style]
Decode (demangle) low-level symbol names into user-level names. Besides removing any initial underscore prepended by the system, this makes function names readable. Different compilers have different mangling styles. The optional demangling style argument can be used to choose an appropriate demangling style for your compiler.

Указать тип разименования символов, например c, cxx ....
Причем тут endian? Радуйтесь, что у Вас litle-endian .

[romez777]

1. У Вас приложение (в бинарик и HEX) начинается вот с этого кода

Код

Undef_Handler:
    B    Undef_Handler
  10403c:    eafffffe     b    10403c <Undef_Handler>

А векторов там нет.

2. Разберитесь сначала с ARM режимом, а то сразу и ARM и THUMB Вас запутывает.
Например, Ваш boot переходит в THUMB, а потом запускает приложение командой BL, а приложение начинается с ARM режима, и соответмтвенно ничего не работает.

Вот смотрите... После сброса чип бутлоадеру в ARM-режиме. В стартапе бутлоадера после различных инициализаций и пр. происходит переход на main()-функцию, причем переход по инструкции BX, которая, суда по документации, переводит процессор в THUMB-режим.

Выходит, что приложение получает thumb-процессор?

Но как это может повлиять на расположение секций в памяти и в образе? Означает ли это, что все приложение, запускаемое бутом, нужно пересобирать c ключем -mthumb?

[amw]

Вот смотрите... После сброса чип бутлоадеру в ARM-режиме. В стартапе бутлоадера после различных инициализаций и пр. происходит переход на main()-функцию, причем переход по инструкции BX, которая, суда по документации, переводит процессор в THUMB-режим.

Выходит, что приложение получает thumb-процессор?

Но как это может повлиять на расположение секций в памяти и в образе? Означает ли это, что все приложение, запускаемое бутом, нужно пересобирать c ключем -mthumb?

Если bootloader переводит процессор в thumb то и приложение должно быть ЦЕЛИКОМ thumb.
Поскольку процессор по ресету стартует в ARM SUPERVISOR и все исключения - а соответственно и обработчики прерываний, которые у Вас в Cstartup.S то-же работают в ARM - то запуск приложения ДОЛЖЕН производится в ARM режиме.
ВО ВСЯКОМ СЛУЧАЕ ПРИЛОЖЕНИЕ ПО ВЕКТОРУ ИСКЛЮЧЕНИЯ RESET (у Вас ӕто 0x00001000) ДОЛЖЕН СТАРТОВАТЬ В ARM SUPERVISOR РЕЖИМЕ. Конечно Вы можете делать все что угодно, но тогда подразумевается, что Вы точно знаете что делаете.
То есть, по крайней мере Вы должны из bootloader перейтив ARM SVC.

Прежде чем смешивать ARM и THUMB и в bootloader и в app разберитесь сначала с одним режимом. И ӕтот режим для Вас должен быть ARM.

А THUMB введете потом.
И вообще, у Вас что действительно есть необходимость в thumb прямо сейчас?
В конечном итоге, рекомендую оставить main() в bootloader полностью ARM и запускать приложение bootloaderом именно из ARM и именно в ARM приложения, а функции перепрошивки флеш можно и THUMB сделать.

[aaarrr]

В стартапе бутлоадера после различных инициализаций и пр. происходит переход на main()-функцию, причем переход по инструкции BX, которая, суда по документации, переводит процессор в THUMB-режим.

BX вовсе не обязательно переводит процессор в Thumb, для этого должен быть установлен нулевой бит в операнде.