[SpiritDance 0]

Люди я чето непонимаю.

Итак цель - бутром записывающийся в конец флеш, для бутрома нужны прерывания, для того чтобы его собственная таблица векторов не затиралась приложением нужно также хранить ее в конце флеша, при старте переписывать в RAM и делать remap, при выходе из загрузчика делать remap обратно на флеш.

 

Так вот как это грамотно сделать в IARе?, кроссворксовский код

    mov     r8, #0x00200000
    ldr     r9, =_vectors
    ldmia   r9!, {r0-r7}
    stmia   r8!, {r0-r7}
    ldmia   r9!, {r0-r6}
    stmia   r8!, {r0-r6}
    ldr     r0, =MC_RCR_RCB
    strb    r0, [r10, #MC_RCR_OFFSET]

просто так не проходит. RAMSTART в линкер-скрипте сделал 00200100- пофиг, без команды remap работает с ней беда, до main проц не доходит. Думаю причина в том, что remap как -то не вяжется с инитом компилера? причем посмотреть отладчиком что происходит тоже не очень удается.

 

Что такое

RSEG INTRAMSTART_REMAP

RSEG INTRAMEND_REMAP

в статртапе? недопонял.

 

может есть где проект под IAR с ремапом а?

[amw 0]

Не совсем то, что спрашивается, поскольку делает remap при старте на ОЗУ:

@--------------------------------------------------------
@ Memory controller definitions
    .equ    MC_BASE,        0xFFFFFF00    @ MC Base Address
    .equ    MC_RCR,            0x00        @ MC_RCR Offset
    .equ    MC_FMR,            0x60        @ MC_FMR Offset
@--------------------------------------------------------
@ Memory remap
_check_mapping:
    ldr    r0, =0x200014
    mov    r1, #0x14
    ldr    r2, =0x12345678
    str    r2, [r0]
    ldr    r0, [r1]
    cmp    r0, r2
    beq    _check_mapping_end
_mem_remap:
    @ RAM remap
    ldr    r0, =MC_BASE
    mov    r1, #1
    str    r1, [r0, #MC_RCR]
_check_mapping_end:
    mov    r0, #0x14
    mov    r1, #0
    str    r1, [r0]

Сначала проверка, что сейчас по нулевому адресу. Записывается 0x12345678 в ОЗУ на неиспользуемый вектор, а потом сравнивается с нулевым смещением. И не забудте првильно установить вектора Exceptions для обоих случаев.

Изменено 20 апреля, 2007 пользователем amw

[Сергей Борщ 126]

Итак цель - бутром записывающийся в конец флеш, для бутрома нужны прерывания, для того чтобы его собственная таблица векторов не затиралась приложением нужно также хранить ее в конце флеша, при старте переписывать в RAM и делать remap, при выходе из загрузчика делать remap обратно на флеш.

Системная ошибка. Загрузчик вместе со своими векторами живет в начале ФЛЕША, а пользовательское приложение работает в ремапе. Этим мы гарантируем, что при любом слете в процессе перезаписи проц будет в состоянии стартануть и попасть хотя бы в загрузчик.

Так вот как это грамотно сделать в IARе? может есть где проект под IAR с ремапом а?

Вот рыба. проект состоит из двух - загрузчика и приложения.

Действия загрузчика -

1) инициализация ноги PIO принудительного старта загрузчика и PLL.

2) проверка был ли это старт из приложения, если да - запуск собственно загрузчика.

3) проверка был ли сигнал принудительного старта, если да - запуск собственно загрузчика.

4) проверка КС приложения. Если не совпала - запуск загрузчика.

4a) Если совпала - копирование векторов приложения в ОЗУ, ремап, переход на вектор сброса (старт приложения).

---- действия 1-4 происходят в __low_level_init() ----

5) собственно загрузчик. Сброс периферии, проверка был ли это вызов из приложения, если нет - ждать команду начала прошивки. Если из периферии - пропустить ожидание команды, команда была получена приложением.

6) собственно прошивка - допишите во вкусу

7) рестарт. После рестарта снова попадем в загрузчик, он проверит КС и т.д.

 

 

Для приложения даю файл линкера. Единственное, что требуется от приложения - не трогать ремап.

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

 

В общем несколько сумбурно, но работает. Выдрал из проекта, если что - спрашивайте. Будет интерес - сделаю законченный проект -шаблон, но не сегодня.

Boot_fish.zip

[SpiritDance 0]

Да штука то в том что сам remap как раз и работает, только после него не работает ничего. Я кажется понял - pc после него указывает на рам а мне нужно чтоб оно из флеши выполнялось а таблица експекшены были в рам

 

Сергей Борщ

Насчет системной ошибки - я ему вектор ресета оставляю в начале флеша и не даю переписывать его через загрузчик.

Вообще спасибо большое, ушел думать.

[Сергей Борщ 126]

Сергей Борщ

Насчет системной ошибки - я ему вектор ресета оставляю в начале флеша и не даю переписывать его через загрузчик.

Размер страницы - 128 байт, размер сегмента векторов - вдвое меньше. Чтобы переписать остальные вектора надо предваритально затереть их все, вместе с вектором ресета.

[SpiritDance 0]

Размер страницы - 128 байт, размер сегмента векторов - вдвое меньше. Чтобы переписать остальные вектора надо предваритально затереть их все, вместе с вектором ресета.

Не понял причем здесь размер страницы. Я по вектору ресета всегда в лоб пишу команду "b reset_загрузчика" если идет запись в начало флеш - это все что меняется в исходной программе. Адрес, который реально был в программе запоминается и по нему происходит прыжок в конце работы загрузчика. Правда нужно еще добавить вычисления, когда в начале программы стоит инструкция "ldr pc..". Но мысль насчет того что команда затирается понятна.

 

Все таки я что-то не пониммаю насчет remap. В приведенных примерах вроде нет никакого шамантсва с pc.Судя по логике после этой команды pc естественно не меняется и так как сейчас код выполняется из Internal Memory Area 0, то после подсовывание на это место RAM получается фигня. Вопрос - каким образом перескочить на выполнение кода из Internal Memory Area 1? Или я вообще все не так понял?

[Сергей Борщ 126]

В приведенных примерах вроде нет никакого шамантсва с pc.

Да, вместо этого шаманство в файле линкера. Загрузчик исполняется не с отремапленых адресов 0x0000.... а с реальных адресов флеш 0x01000000.... Поэтому после ремапа его код остается на месте. Именно для этого я положил в архив исправленный загрузчик для иара FlashAT91SAM7Sx.d79, ибо родной из-за ошибки умеет писать только в адреса 0x00.....

 

 

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

А если программа пользователя хочет подвесить свои обработчики на остальные вектора? Можно конечно там сразу поставить LDR PC, AIC_IVR, но это уже ограничение, а как быть с FIQ?

[SpiritDance 0]

Да, вместо этого шаманство в файле линкера. Загрузчик исполняется не с отремапленых адресов 0x0000.... а с реальных адресов флеш 0x01000000....

Я уже понял вроде. Пасибо. Туплю бывает. Добавил еденички, только после команды ремап все равно не работает код. :( Прерывания отключены и всякие копирования векторов в рам тоже закоменчены. Отладкик такой код прошивать-отлаживать уже отказывается, наверно надо ковырятся в mac-файле.

А без ремапа работает - флешка шьется читается, нормально все. :( Волшебство.

 

А если программа пользователя хочет подвесить свои обработчики на остальные вектора? Можно конечно там сразу поставить LDR PC, AIC_IVR, но это уже ограничение, а как быть с FIQ?

Так, еще раз. Я при заливке программы через бутром меняю ей только вектор ресета, все остальное остается как есть.

[d__ 0]

А вот если так:

 

Если программа должна работать из РАМ

то

она вся линкуется по адресам 0х200000(секции кода и данных

упираясь своими векторами в адрес 0х20000

при старте она проверяет был ли ремап если не был то ремапирует

и продолжает выполнение по коду расположенному на 0х20000

содержание векторов дублируется на нулевые адреса автоматически

иначе

она линкуется вся по адресам 0х10000 (в РОМ векторы и секция кода , секция данных начиная

с адресов 0х200040)

при старте вектора из секции кода ручками копируются с адреса 0х100000-0х10003ф

на адрес 0х200000 после этого проверяется был ли ремап

после ремапа вектора автоматически дублируются в трех местах по адресу 0х0 0х100000 0х200000

и вуаля!

[Сергей Борщ 126]

Отладкик такой код прошивать-отлаживать уже отказывается, наверно надо ковырятся в mac-файле.

Хм. У меня работает. Как ругается когда не прошивает? У меня просто вис, попробуйте мой прошивальщик положить вместо штатного.

А без ремапа работает - флешка шьется читается, нормально все. :( Волшебство.

Посмотрите в окне памяти что творится в области векторов. Окно дизассемблера не обновляется, а в окне памяти все изменения видны сразу.

Так, еще раз. Я при заливке программы через бутром меняю ей только вектор ресета, все остальное остается как есть.

Да, меня заклинило - у вас же загрузчик в конце памяти. Т.е. остается нехорошесть в виде переписывания сегмента с векторами. Что-то там не сложилось и прибор надо возвращать к разработчику вместо повтороной перепрошивки на месте.

при старте она проверяет был ли ремап

Уже одно это действие на SAM7 нетривиально - надо изменить что-то в начале ОЗУ и посмотреть как это отразилось в нулевых адресах. После чего вернуть исходное значение. В моем варианте все гораздо проще - для старта приложения скопировал вектора приложения в начало ОЗУ, сделал ремап, перешел на адрес 0. Переход из приложения обратно в загрузчик - запретил прерывания, сделал ремап, перешел на адрес 0.

[Waso 1]

Есть несколько непоняток по скрещиванию программы с бутлоадером.

1. Если я ставлю линкеру например -DROMSTART=00008000 в программе, то размер выходного бинарника не меняется. Значит вначале файла идут вектора, а затем программа как и в обычном случае, но со смещенными переходами?

2. Если я хочу прошить в чистый кристалл сразу и прогу и бутлодер, то как быть с векторами программы? Получается, нужно самому в этом случае создавать табличку векторов перед началом кода программы чтобы все это вместе вело себя также как и после перепрошивки проги бутом.

 

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

[Сергей Борщ 126]

1. Если я ставлю линкеру например -DROMSTART=00008000 в программе, то размер выходного бинарника не меняется. Значит вначале файла идут вектора, а затем программа как и в обычном случае, но со смещенными переходами?

Трудно сказать, не видя файла линкера. Зависит от того, как описан сегмент векторов - он либо линкуется в нулевые адреса ( -Z(CODE)INTVEC=00-3F ) либо начиная с ROMSTART (-Z(CODE)INTVEC=ROMSTART-ROMEND или подобное).

2. Если я хочу прошить в чистый кристалл сразу и прогу и бутлодер, то как быть с векторами программы? Получается, нужно самому в этом случае создавать табличку векторов перед началом кода программы чтобы все это вместе вело себя также как и после перепрошивки проги бутом.

Я опишу как делаю я. Насколько это правильно - со стороны, наверное, виднее. Я использую AES Loader и на мегах и на ARMах. У меня загрузчик и приложение - два отдельных проекта. Я прошиваю сначала загрузчик, потом приложение. В процессе этого заодно тестируется канал связи. Если мне надо прошивать все сразу программатором (пока нужно было только на мегах) - я прошиваю загрузчик без лок-битов, прошиваю загрузчиком приложение, убеждаюсь, что все работает, считываю программатором всю память, открываю полученный .hex текстовым редактором и удалаю все строки, содержащие одни 0xFF. Получаю прошивку для масового производства. В голове крутится еще такой вариант - если прошиваем .hex, то можно "склеить" два файла (загрузчика и приложения) текстовым редактором или утилитой вроде srecord. Если прошивка делается из ИАРа через JTAG, то наверняка можно склеить полученный файл загрузчика с приложением при помощи postlink (не пробовал, не подскажу).

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

[Waso 1]

У меня основная программа закачивает обновление через изернет, рестартует и затем бут его переписывает на место проги. В будущем бут должен будет уметь закачать прошивку через UART, но... незнаю, может и придется реализовать это сейчас, но времени в обрез. А пока хочу попробовать воспользоваться опцией линкера "Raw binary image"... Как все получится - отпишу.

 

==============================================================

Шить еще не пробовал (заменил FlashAT91SAM7Sx.d79 на ваш), но отладчик упорно начинает работать с нулевого адреса даже если ROMSTART=00100000. Какнибудь можно его научить учитывать ремап/неремап при запуске? А вообще линкует хорошо. Дописывает указанный в rawbinary image файл куда надо.

 

Кстати, как отладчика заставить вставлять больше брейкпоинтов? В некоторых программах при отладке у меня получалось ставить одновременно не больше 2-3х брейков. А взялся за бут - так он мне вообще фигу показывает и даже пошагам смотреть может только на ассемблеровский код. Чтото гдето забыл я настроить. Раньше пользовался шаблонами...

[Сергей Борщ 126]

но отладчик упорно начинает работать с нулевого адреса даже если ROMSTART=00100000

То же самое будет происходить и в железе. По нулевой адрес в зависимости от ремап/не ремап должна зеркалится команда перехода на загрузчик (с адреса 0x00100000) или на приложение (зеркалится с адреса 0x00200000, куда ее копирует загрузчик).

. Какнибудь можно его научить учитывать ремап/неремап при запуске?

можно. в .mac - файле написать соответствующий скрипт. Напишите, что конкретно он должен сделать, я накидаю скрипт. Пока непонятно зачем, но накидаю.

[Waso 1]

нулевой адрес в зависимости от ремап/не ремап должна зеркалится команда перехода на загрузчик (с адреса 0x00100000) или на приложение (зеркалится с адреса 0x00200000, куда ее копирует загрузчик).можно. в .mac - файле написать соответствующий скрипт.

Отладчик не зеркалит флеш в нулевые адреса при старте. Это и надо исправить.

Отлаживаю пока в симуляторе. Оттого и удивляюсь насчет брейкпоинтов.

Проц - AT91SAM7X256, ИДЕ IAR 440A