отладка at91R40008, простенькая программа Опции

[Серокой]

Добрый день. Совсем замучился я, что-то я не догоняю. Прошу помощи.
Задача стоит совсем простая: на не прошедшем remap AT91R40008 запустить программу. Отладка идёт с помощью собранных под ARM gnotools, сама платка подключена через Wiggler к insight.
Текст программы такой:

Код

int main(void)
{
int a, b, c;
a = 8;
b = 7;

c=a+b;

while (1)
    {
    c=c+1;
    }
return (c);
}

Компилируется без оптимизации, в итоге листинг выглядит так:

Код

00300000 <main>:
 300000:    e1a0c00d  mov    ip, sp
 300004:    e92dd800  stmdb    sp!, {fp, ip, lr, pc}
 300008:    e24cb004  sub    fp, ip, #4; 0x4
 30000c:    e24dd00c  sub    sp, sp, #12; 0xc
 300010:    e3a03008  mov    r3, #8; 0x8
 300014:    e50b3010  str    r3, [fp, -#16]
 300018:    e3a03007  mov    r3, #7; 0x7
 30001c:    e50b3014  str    r3, [fp, -#20]
 300020:    e51b2010  ldr    r2, [fp, -#16]
 300024:    e51b3014  ldr    r3, [fp, -#20]
 300028:    e0823003  add    r3, r2, r3
 30002c:    e50b3018  str    r3, [fp, -#24]
 300030:    e51b3018  ldr    r3, [fp, -#24]
 300034:    e2833001  add    r3, r3, #1; 0x1
 300038:    e50b3018  str    r3, [fp, -#24]
 30003c:    eafffffb  b    300030 <main+0x30>

Проверяю работу пошагово по GDB. Первая инструкция выполняется без нареканий, видно, как SP переместился в 12 регистр. После попытки выполения второй инструкции всё рухает со страшным грохотом. Wiggler кричит, что его заставляют читать с какого-то адреса, и по этой причине у него случается Bus Error. Адрес этот содержится в 11 регистре, он же fp в списке блочного сохранения. Мне непонятно, кто его заставляет читать оттуда, ведь происходит просто "засовывание" данных в стек? И, кстати, стек-поинтер тоже не проинициализирован - в регистрах этих, которые программа сторит, мусор по включению питания...
Просьба такая: подскажите, как с этим бороться и каким образом инициализируется стек?

[Серокой]

Ну вот, отлаживаю я по выходным, когда время есть, поэтому вопросы медленно скапливаются...
Собираю файл я "дёрнутым" из кейловского примера "Hello" скриптом линковки для RAM, и там указано следующее:

Код

MEMORY
{
 CODE (rx) : ORIGIN = 0x00010000, LENGTH = 0x00020000
 DATA (rw) : ORIGIN = 0x00030000, LENGTH = 0x00010000
}

Но когда я загружаю получившуюся прогрмамму insight'ом, получается, что он её кладёт непонятно куда, но только не в память, посколько процессор-то ещё не ремэпленный. :-/
Что делать, как отлаживать программу, стартующую на "голом" процессоре?
Если я правлю ld-шник, то получается ещё хуже, но уже после ремепа...
Или можно insigh'ту указать, куда класть программу и с какого адреса стартовать?

[v_shamaev]

Но когда я загружаю получившуюся прогрмамму insight'ом, получается, что он её кладёт непонятно куда, но только не в память, посколько процессор-то ещё не ремэпленный. :-/
Что делать, как отлаживать программу, стартующую на "голом" процессоре?
Если я правлю ld-шник, то получается ещё хуже, но уже после ремепа...
Или можно insigh'ту указать, куда класть программу и с какого адреса стартовать?

Обычно старт программы в ARM-е происходит след. путем: назначаются вектора прерываний, загружаются регистры EBI, и сразу remap. Insight сам по себе делать
это не умеет, а занимается этим обычно интерфейсная программа, связывающая GDB
с процессором - если это резидентный монитор (RedBoot, например) - то он. А в случае
с вигглером - та утилита, которая работает с вигглером. Есть команды записи в регистры,
обычно включаются в стартовый скрипт - вы видимо макрегоровским OCDLibRemote пользуетесь - там есть пример стартового скрипта для Insight-а.