Сигнатура LPC Опции

[3.14]

Как автоматизировать процесс вычисления и подстановки сигнатуры?
Использовать только ради этого LPC2000 Flash utility не самый лучший вариант.

[amw]

Как автоматизировать процесс вычисления и подстановки сигнатуры?
Использовать только ради этого LPC2000 Flash utility не самый лучший вариант.

Если я правильно понял, может это оно?
http://electronix.ru/forum/index.php?showtopic=23109

Или имеется ввиду сигнатура наличия кода по адресу 0x18?
Я для этого использую самописную программу, подключаемую в Makefile и запускаемую на бинарик.

Сообщение отредактировал amw - Jan 12 2007, 17:15

[3.14]

Именно та что по 0х14 адресу ставится, не поделитесь своей тулзой.

[makc]

Именно та что по 0х14 адресу ставится, не поделитесь своей тулзой.

Их есть у нас. См. в приложении.

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

 patch_0x14.zip ( 77.54 килобайт ) Кол-во скачиваний: 71

 

[zltigo]

Их есть у нас. См. в приложении.

К делу не относится, но размер приблуды в 163840 байт резанул глаз несоразмерностью решаемой задаче

[3.14]

2 makc
Спасибо!

[Alex03]

А чем жёсткий стартап (область векторов прерываний) не устраивают?
Посчитал один раз контрольную сумму и забыл.
Как например в CW

Код

  .section .vectors, "ax"
  .code 32
  .align 0

_vectors:
  ldr pc, [pc, #reset_handler_address - . - 8]  /* reset */
  ldr pc, [pc, #undef_handler_address - . - 8]  /* undefined instruction */
  ldr pc, [pc, #swi_handler_address - . - 8]    /* swi handler */
  ldr pc, [pc, #pabort_handler_address - . - 8] /* abort prefetch */
  ldr pc, [pc, #dabort_handler_address - . - 8] /* abort data */
#ifdef VECTORED_IRQ_INTERRUPTS
  .word 0xB9205F88                              /* boot loader checksum */
  ldr pc, [pc, #-0xFF0]                         /* irq handler */
#else
  .word 0xB8A06F60                              /* boot loader checksum */
  ldr pc, [pc, #irq_handler_address - . - 8]    /* irq handler */
#endif
  ldr pc, [pc, #fiq_handler_address - . - 8]    /* fiq handler */

reset_handler_address:
  .word reset_handler
undef_handler_address:
  .word undef_handler
swi_handler_address:
  .word swi_handler
pabort_handler_address:
  .word pabort_handler
dabort_handler_address:
  .word dabort_handler
#ifndef VECTORED_IRQ_INTERRUPTS
irq_handler_address:
  .word irq_handler
#endif
fiq_handler_address:
  .word fiq_handler

Иль ради экономии нескольких байт/тактов? ...

[makc]

Их есть у нас. См. в приложении.

К делу не относится, но размер приблуды в 163840 байт резанул глаз несоразмерностью решаемой задаче

Могу сделать на Python'е. Будет на порядки короче.
А вообще это все происки C++, который не жалеет байты в век терабайтов.

[3.14]

2 Alex03
Как то боязно, хотя пока так и делаю. Компилятор/линковщик сам решает где чего лежать должно ...

[makc]

2 Alex03
Как то боязно, хотя пока так и делаю. Компилятор/линковщик сам решает где чего лежать должно ...

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

[zltigo]

А вообще это все происки C++, который не жалеет байты в век терабайтов.

С++ оно ясно, хотя откомпилировав исходник я не получил такого монстра (см. в приложении). Для
монстрального результата без "соответствующего" компилятора не обойтись .
Ну а на С в килобайт 6-7 уложиться можно.

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

 main_p14.rar ( 24.55 килобайт ) Кол-во скачиваний: 38

 

[3.14]

2 makc
Ну а если вот такой случай:
изначально обработчики прерываний занимали определенный объем, была просчитана сигнатура и забита в стартап. По ходу работы эти обработчики разростлись в размере и сместились в карте памяти т.е. наступил кердык.
Или я что упустил?

[makc]

А вообще это все происки C++, который не жалеет байты в век терабайтов.

С++ оно ясно, хотя откомпилировав исходник я не получил такого монстра (см. в приложении). Для
монстрального результата без "соответствующего" компилятора не обойтись .
Ну а на С в килобайт 6-7 уложиться можно.

MS Visual С шестой версии - это далеко не лучший компилятор для C++.

2 makc
Ну а если вот такой случай:
изначально обработчики прерываний занимали определенный объем, была просчитана сигнатура и забита в стартап. По ходу работы эти обработчики разростлись в размере и сместились в карте памяти т.е. наступил кердык.
Или я что упустил?

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

[3.14]

И все-таки, сместятся обработчики, изменятся и ссылки ...
Наверное все-таки правильнее в стартапе ложить ссылки на обложки обработчиков в которых ссылки на реальные обработчики.

[makc]

И все-таки, сместятся обработчики, изменятся и ссылки ...
Наверное все-таки правильнее в стартапе ложить ссылки на обложки обработчиков в которых ссылки на реальные обработчики.

Тогда посмотрим на проблему так:
1. В векторе исключения лежит команда загрузки в PC содержимого по фиксированному адресу (косвенная ссылка).
2. По фиксированному адресу, на который ссылается вектор исключения, лежит значение адреса реального обработчика.

Таким образом, если изменится место расположения реального обработчика прерывания, то изменится не адрес ссылки, а только ее значение. При этом, поскольку при вычислении контрольной суммы (сигнатуры) используется адрес ссылки (фиксированный в стартапе), то ровным счетом ничего не изменится.

[zltigo]

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

Ассемблер не сможет ничего "изменить" и сгенерить более короткй/длинный код, если он конечно он для ARM . Для маньяков - никто не мешает нафаршировать код ORG-ами перед каждой из первых 16 команд , а не только QRG 0 перед первой.

[makc]

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

Ассемблер не сможет ничего "изменить" и сгенерить более короткй/длинный код, если он конечно он для ARM . Для маньяков - никто не мешает нафаршировать код ORG-ами перед каждой из первых 16 команд , а не только QRG 0 перед первой.

Это все понятно. Я просто попытался описать гипотетическую ситуацию, при которой может нарушиться установленный сейчас порядок вещей.

[3.14]

Тогда разъясните плиз по синтаксису (приведенного выше стартапа).
После загрузки РС (хотя выражение "#reset_handler_address - . - 8" выглядит как-то странно), в РС снова должен грузится адрес, а вместо этого:
reset_handler_address:
.word reset_handler
Это как ...?

[Alex03]

Тогда разъясните плиз по синтаксису (приведенного выше стартапа).
После загрузки РС (хотя выражение "#reset_handler_address - . - 8" выглядит как-то странно), в РС снова должен грузится адрес, а вместо этого:
reset_handler_address:
.word reset_handler
Это как ...?

Код

_vectors:
  ldr pc, [pc, #reset_handler_address - . - 8]  /* reset */

Тут #reset_handler_address это адрес переменной (константы) в которой лежит адрес настоящего обработчика.
"." это адрес текущей инструкции.
"-8" - особенности АРМ архитектуры, где, скажем так, PC указывает не на текущую исполняемую команду, а на голову конвеера, которая уже убежала вперёд. (поправьте если я не так выразился )
Кстати этого момента я не очень понял, не уж то так сложно им было расширить корвеер 32-х битным регистром для PC на каждой стадии.

В LPC контольная сумма считается только для первых 8-ми слов.
Т.е. из приведённого примера от

Код

  ldr pc, [pc, #reset_handler_address - . - 8]  /* reset */

до

Код

  ldr pc, [pc, #fiq_handler_address - . - 8]    /* fiq handler */

поэтому изменение "указателей" на обработчики (при их перемещении линкером)

Код

  .word reset_handler
  .word undef_handler
  .word swi_handler
  .word pabort_handler
  .word dabort_handler
  .word fiq_handler

Никак не влияет на контрольную сумму.

Ну а

Код

ldr pc, [pc, #-0xFF0]                         /* irq handler */

Это сразу загрузка из VICVectAddr

[zltigo]

Ну а

Код

ldr pc, [pc, #-0xFF0]                         /* irq handler */

Это сразу загрузка из VICVectAddr

Дополнительные разъяснения:
VICVectAddr = 0xFFFFF030
Текущий PC 18h +8 конвеер поминаемый ранее. Вычитаем 0xFF0 получаем желанный
0xFFFFF030.

[amw]

Именно та что по 0х14 адресу ставится, не поделитесь своей тулзой.

В составе самописного программатора.
_hттp://projects.org.ua/project/amw/arm/lpcflash-0.2.0.tar.gz

Сообщение отредактировал amw - Jan 15 2007, 16:01

[3.14]

Кстати, в подробности не вдавался, но HEX-ы IAR-а уже имеют правильную сигнатуру, хотя к его стартапу я не прикасался.

[zltigo]

Кстати, в подробности не вдавался, но HEX-ы IAR-а уже имеют правильную сигнатуру, хотя к его стартапу я не прикасался.

Незнаю не знаю - при заливке IARовских HEX своим программатором неизменно получаю уведомление о том, что контрольная сумма была посчитана, не совпала и была заменена.....