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

[romez777]

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

MCU: at91sam7s256
toolchain: Yagarto (gcc-4.2.1)

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

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

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

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

Спасибо!

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

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

 

[amw]

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

Код

Тут убрать секцию с векторами
    .text :
    {
        /* ARM Exception vectors */
        . = _vectors;
        KEEP (*(.vectors*))
        . = _evectors;
        KEEP (*Cstartup.o (.text) )        /* Startup code */
        *(.text*)            /* remaining code */
        *(.glue_7t) *(.glue_7)
    } >Что тут у Вас должно быть
Дальше продолжение вашего скрипта.

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

[romez777]

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

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

Код

Тут убрать секцию с векторами
    .text :
    {
        /* ARM Exception vectors */
        . = _vectors;
        KEEP (*(.vectors*))
        . = _evectors;
        KEEP (*Cstartup.o (.text) )        /* Startup code */
        *(.text*)            /* remaining code */
        *(.glue_7t) *(.glue_7)
    } >Что тут у Вас должно быть
Дальше продолжение вашего скрипта.

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

Код

SECTIONS
{
    .text :
    {
        /* ARM exception vectors */
        _vectors_start = .;
        KEEP(*(.vectors))
        _vectors_end = .;
       KEEP(*Cstartup.o (.text))    /* Startup code */
       *(.text)        /* code */
       *(.rodata)        /* read-only data (constants) */
       *(.rodata*)

       *(.glue_7t) *(.glue_7)
    } >ROM =0
}

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

Код

Memory Configuration

Name             Origin             Length             Attributes
ROM              0x00101000         0x00001000         xr
RAM              0x00200000         0x00004000         rw
STACK            0x00204000         0x00000000         rw
REMAPPED         0x00000000         0x00004000         xrw
*default*        0x00000000         0xffffffff
...

.text           0x00101000      0x4f0
                0x00101000                _vectors_start = .
*(.vectors)
.vectors       0x00101000       0x20 Cstartup.o
                0x00101000                _startup
                0x00101020                _vectors_end = .
*Cstartup.o(.text)
.text          0x00101020      0x14c Cstartup.o
...

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

Код

main.elf:     file format elf32-littlearm

Disassembly of section .text:

00101000 <_startup>:
//*- If an exception occurs before remap, this would result in an infinite loop.
//*- To ensure if a exeption occurs before start application to infinite loop.
//*------------------------------------------------------------------------------*/

                B           InitReset           /* 0x00 Reset handler */
  101000:    ea000011     b    10104c <InitReset>
...

Дело в том, что
1. Ваш скрипт описывает действия с секцией текст несколько раз

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

[amw]

Приветствую.
Наверное вы имели в виду:

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

Код

$ arm-elf-as -v
GNU assembler version 2.18 (arm-elf) using BFD version (GNU Binutils) 2.18
$ arm-elf-ld -v
GNU ld (GNU Binutils) 2.18
$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: /home/amw/devel/ARM/arm7tdmi/tools/src/gcc-4.2.2/configure --target=arm-elf --prefix=/usr/local/arm/arm-elf --enable-interwork --enable-multilib --with-newlib --with-headers=/usr/local/arm/arm-elf/arm-elf/include --with-gnu-ld --with-gnu-as --disable-nls --disable-shared --enable-languages=c
Thread model: single
gcc version 4.2.2

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

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

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

 jump.zip ( 6.68 килобайт ) Кол-во скачиваний: 78

 

[romez777]

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

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

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

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

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

Код

D:\Documents and Settings\sam>arm-elf-gcc --version
arm-elf-gcc (GCC) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


D:\Documents and Settings\sam>arm-elf-ld --version
GNU ld version 2.17
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

D:\Documents and Settings\sam>arm-elf-as --version
GNU assembler 2.17
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `arm-elf'.

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

Код

                B           InitReset
undefvec:
                B           undefvec
swivec:
                B           swivec
...

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

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

Код

_startup:
    ldr    r0, =0x12345678
    mov    r1, #0x14
    str    r0, [r1]
    bl    main
    b    _startup

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

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

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

[amw]

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

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

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

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

Код

D:\Documents and Settings\sam>arm-elf-gcc --version
arm-elf-gcc (GCC) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
D:\Documents and Settings\sam>arm-elf-ld --version
GNU ld version 2.17
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

D:\Documents and Settings\sam>arm-elf-as --version
GNU assembler 2.17
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `arm-elf'.

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

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

Код

                B           InitReset
undefvec:
                B           undefvec
swivec:
                B           swivec
...

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

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

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

Код

_startup:
    ldr    r0, =0x12345678
    mov    r1, #0x14
    str    r0, [r1]
    bl    main
    b    _startup

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

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

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

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

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

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

[romez777]

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

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

[amw]

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

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

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

 at91sam7s.lds.zip ( 1.1 килобайт ) Кол-во скачиваний: 42

 

[romez777]

Потому что команда B использует относительную адресацию.
Если Вы переместите этот кусок кода в другое место (а Вы его копируете в нулевой адрес), то разница между текущим PC и адресом перехода изменится, а команда B ничего про это не знает.

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

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

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

Код

main.elf:     file format elf32-littlearm

Disassembly of section .vectors:

00000000 <_vectors_start>:
//*------------------------------------------------------------------------------*/
    .section .vectors
    .code 32
EXCEPTION_VECTORS:
        ldr    pc, resetvec
   0:    e59ff018     ldr    pc, [pc, #24]; 20 <resetvec>
        ldr    pc, undefvec
   4:    e59ff018     ldr    pc, [pc, #24]; 24 <undefvec>
        ldr    pc, swivec
   8:    e59ff018     ldr    pc, [pc, #24]; 28 <swivec>
        ldr    pc, pabtvec
   c:    e59ff018     ldr    pc, [pc, #24]; 2c <pabtvec>
        ldr    pc, dabtvec
  10:    e59ff018     ldr    pc, [pc, #24]; 30 <dabtvec>
  14:    00000000     andeq    r0, r0, r0
        .word    0
        ldr    pc, irqvec
  18:    e59ff014     ldr    pc, [pc, #20]; 34 <irqvec>
        ldr    pc, fiqvec
  1c:    e59ff014     ldr    pc, [pc, #20]; 38 <fiqvec>

00000020 <resetvec>:
...

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

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

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

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