прыгнуть на другой адрес в 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

 

[amw]

Файл app.S

Код

/* Copy exception vectors in RAM */
        LDR     r0, =_vectors_start
        LDR     r1, =0x00200000
        LDR     r2, =_vectors_start
copy:
        LDR     r3, [r0], #4
        STR     r3, [r1], #4
        CMP     r0, r2
        BNE     copy

Попробуйте объяснить русским языком что делает этот код . С точным указанием адресов .
Вот как это понимаю я.
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 это символ @.
Например где заканчивается коментарий примера ниже по Вашему мнению? А по мнению компилятора? А как расценивать символ # в начале строки? Как коментарий или как директиву препроцессора?

Код

#//* Comment
ldr pc, initreset /* Jump to initialization */

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

[romez777]

Код

/* Copy exception vectors in RAM */
        LDR     r0, =_vectors_start
        LDR     r1, =0x00200000
        LDR     r2, =_vectors_start
copy:
        LDR     r3, [r0], #4
        STR     r3, [r1], #4
        CMP     r0, r2
        BNE     copy

Попробуйте объяснить русским языком что делает этот код . С точным указанием адресов .

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

А лучше сделать так как это у Вас для копирования секции .data. То есть сначала проверить, а потом уже копировать и прибавлять 4.

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

Рекомендую так-же:
1. Привести в порядок инициализацию стеков. Там у Вас полный бардак. Хотя в простейшем примере это работает, но это не критерий, правда .

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

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

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

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

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

Код

int main(void)
{
  ...
  ((funct)0x00101000)();  /* здесь ставим break point */
}

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

Код

Breakpoint 1, main () at main.c:102
102         ((funct)0x00101000)();
Current language:  auto; currently c
(gdb) n
Cannot access memory at address 0x8008126
0x00100300 in ?? ()
(gdb)

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

[amw]

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

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

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

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

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

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

Код

                mov     r0,r13 - Понятно. r13пока содержит RAM_TOP
/*- Set up Fast Interrupt Mode and set FIQ Mode Stack*/
                msr     CPSR_c, #ARM_MODE_FIQ | I_BIT | F_BIT
/*- Init the FIQ register*/
                ldr     r8, =AT91C_BASE_AIC - А в чем смысл? Оно действительно используется?

/*- Set up Interrupt Mode and set IRQ Mode Stack*/
                msr     CPSR_c, #ARM_MODE_IRQ | I_BIT | F_BIT
                mov     r13, r0                     /* Init stack IRQ */ Стек для FIQ и IRQ один и тот -же? А Вы уверены, что разрулите это?
                sub     r0, r0, #IRQ_Stack_Size
/*- Set up Supervisor Mode and set Supervisor Mode Stack*/
                msr     CPSR_c, #ARM_MODE_SVC
                mov     r13, r0                     /* Init stack Sup */

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

Код

int main(void)
{
  ...
  ((funct)0x00101000)();  /* здесь ставим break point */
}

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

Код

Breakpoint 1, main () at main.c:102
102         ((funct)0x00101000)();
Current language:  auto; currently c
(gdb) n
Cannot access memory at address 0x8008126
0x00100300 in ?? ()
(gdb)

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

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

[romez777]

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

Да, конечно.

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

Ну вот пример из boot.S с моими коментариями
mov r0,r13 - Понятно. r13пока содержит RAM_TOP
/*- Set up Fast Interrupt Mode and set FIQ Mode Stack*/
msr CPSR_c, #ARM_MODE_FIQ | I_BIT | F_BIT
/*- Init the FIQ register*/
ldr r8, =AT91C_BASE_AIC - А в чем смысл? Оно действительно используется?

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

Код

      .EQU        IRQ_STACK_SIZE,    (3*8*4)
      .EQU        FIQ_STACK_SIZE,    (3*4)
          .EQU        ARM_MODE_FIQ,       0x11
          .EQU        ARM_MODE_IRQ,       0x12
          .EQU        ARM_MODE_SVC,       0x13

          .EQU        I_BIT,              0x80
          .EQU        F_BIT,              0x40
...

@-------------------------------------
@- Setup the stack for each mode
@-------------------------------------
                mov     r0,r13

@- Set up Fast Interrupt Mode and set FIQ Mode Stack
                msr     CPSR_c, #ARM_MODE_FIQ | I_BIT | F_BIT
        mov    sp, r0
        sub    r0, r0, #FIQ_STACK_SIZE

@- Set up Interrupt Mode and set IRQ Mode Stack
                msr     CPSR_c, #ARM_MODE_IRQ | I_BIT | F_BIT
                mov     sp, r0
                sub     r0, r0, #IRQ_STACK_SIZE

@- Set up Supervisor Mode and set Supervisor Mode Stack
                msr     CPSR_c, #ARM_MODE_SVC
                mov     r13, r0

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

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

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

[amw]

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

Код

      .EQU        IRQ_STACK_SIZE,    (3*8*4)
      .EQU        FIQ_STACK_SIZE,    (3*4)
          .EQU        ARM_MODE_FIQ,       0x11
          .EQU        ARM_MODE_IRQ,       0x12
          .EQU        ARM_MODE_SVC,       0x13

          .EQU        I_BIT,              0x80
          .EQU        F_BIT,              0x40
...

@-------------------------------------
@- Setup the stack for each mode
@-------------------------------------
                mov     r0,r13

@- Set up Fast Interrupt Mode and set FIQ Mode Stack
                msr     CPSR_c, #ARM_MODE_FIQ | I_BIT | F_BIT
        mov    sp, r0
        sub    r0, r0, #FIQ_STACK_SIZE

@- Set up Interrupt Mode and set IRQ Mode Stack
                msr     CPSR_c, #ARM_MODE_IRQ | I_BIT | F_BIT
                mov     sp, r0
                sub     r0, r0, #IRQ_STACK_SIZE

@- Set up Supervisor Mode and set Supervisor Mode Stack
                msr     CPSR_c, #ARM_MODE_SVC
                mov     r13, r0

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

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

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

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

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

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

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

[romez777]

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

Но ведь 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?

[amw]

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

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

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

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

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

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

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

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

[romez777]

Лучше всего, в bootloader использовать минимум. И передачу управления на приложение делать в ARM Supervisor режим.
Суть в том, что приложение вообще не должно знать о наличии bootloader, и потому действовать как будто оно там одно.

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

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

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

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

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

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

 

[amw]

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

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

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

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

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

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

Код

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

app:

Код

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

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

Код

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

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

app, AT91SAM7S64-ROM.ld

Код

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

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

Код

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 и поставить С НАЧАЛА СТАРТАП ФАЙЛА.

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

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

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

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

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

 

[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?