Все о ARM GCC4.3, Linker, ASM, C/C++, Windows/Linux. Опции

[Vitaliy_ARM]

Все больше прощаюсь с IAR.

Разбираюсь с компановщиком. Документация на него не впечатлила . Есть ли у кого готовый пример скрипта размещения констант по указанному адресу во Flash LPC2xxx или другого арма?

[oll]

Все больше прощаюсь с IAR.

Разбираюсь с компановщиком. Документация на него не впечатлила . Есть ли у кого готовый пример скрипта размещения констант по указанному адресу во Flash LPC2xxx или другого арма?

может тут? http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/

[zltigo]

Все больше прощаюсь с IAR.

Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....

[singlskv]

Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....

А если это настроечные константы прибора хранящиеся в флеш и требуется возможность
их изменения/записи с помощью спец процедуры ? Как обойтись без абсолютных адресов ?
Как сделать кратность записи странице флеш ?

[zltigo]

А если это настроечные константы прибора хранящиеся в флеш и требуется возможность
их изменения/записи с помощью спец процедуры ? Как обойтись без абсолютных адресов ?
Как сделать кратность записи странице флеш ?

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

[singlskv]

Если у Вас флеши слишком много, что Вы можете отдать целый сегмент, то и отдайте его в конце.

Флеши много не бывает.
Ну конечно в конце, но это не всегда конец флеши, иногда
это конец некоторого логического куска, ну там всякие бутлоадеры итд...

А если нет, то по любому считать->отпатчитть-стереть->записать придется. Процедура занимающаяся этим изнутри и так знает где что лежит. А наружные патчеры и по сигнатуре найдут без проблем.

А вот это очень может быть ненадежно..., там ведь с кодом может пересекаться и при
аппаратном сбое умрет все...

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

Это плата за надежность, поэтому ИМХО, фиксированное размещение данных(для отделения
от всего остального) может быть очень даже оправданно.

[zltigo]

Флеши много не бывает.

Тогда зачем спрашивали о выравниванию на границу..

А вот это очень может быть ненадежно..., там ведь с кодом может пересекаться и при
аппаратном сбое умрет все...

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

[Harbour]

не надо думать узкими категориями только своей задачи. мне for ex. часто приходится размещать код и данные в определенных адресах - иначе таки да получится не приложение, а какая-то каша.
корректно это делается выделением отдельной секции (в моем случае .bootloader) и ее описанием в линкер-файле - имеем определенную гарантию, так как при налезании границ сегментов ругаться будет линкер, что много лучше вылетающего в неопределенный момент приложения

[VslavX]

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

+10
Еще дополнительно полезно при старте изделия "об-assert-ить" нужные адреса/смещения - у меня окончательную сборку проекта проводят коллеги и иногда ухитряются криво это сделать даже по предоставленным готовым скриптам.

[zltigo]

не надо думать узкими категориями только своей задачи

Это Вы кому?

корректно это делается...

Когда это НУЖНО, типа bootloader-a, то это несомненнно ДЕЛАЕТСЯ. Вопрос в том, что этого незачем делать без всякой на то надобности, как в заявленном случае.

[Vitaliy_ARM]

Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....

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

Сообщение отредактировал Vitaliy_ARM - Dec 10 2008, 13:44

[zltigo]

Прощание с "дурной привычкой" не позволить сделать программу и бутлодер независымыми .

Примерно в аналогичных случаях в фиксированном месте boot (сразу после векторов) размещаю УКАЗАТЕЛЬ на находящийся в произвольном месте блок общих данных. Boot, естественно, линкуется в конкретное место, но это единственная по любому необходимая привязка к адресам - сущности более не плодятся.

[Vitaliy_ARM]

Примерно в аналогичных случаях в фиксированном месте boot (сразу после векторов) размещаю УКАЗАТЕЛЬ на находящийся в произвольном месте блок общих данных. Boot, естественно, линкуется в конкретное место, но это единственная по любому необходимая привязка к адресам - сущности более не плодятся.

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

[Harbour]

вот примерчик из моего проекта под atmel :

scripts.ld:
.....
MEMORY
{
FLASH (rxx) : ORIGIN = 0x00100000, LENGTH = 0x00005F80
BOARD ® : ORIGIN = 0x00105F80, LENGTH = 0x80
DATA (rw) : ORIGIN = 0x00200000, LENGTH = 0x00007000
STACK (rw) : ORIGIN = 0x00207000, LENGTH = 0x00001000
}
.....
.board : {

*(.board)

} > BOARD

. = ALIGN(4);

_etext = . ;
PROVIDE (etext = .);
......

Использование, например серийный номер устройства, файл sn.c:

....
u32 sn __attribute__ ((section(".board"))) = 12345678;
....

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

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

В моей задаче это просто не возможно. Бутлодер + Программа имеют две константы - мак адрес и ай пи адрес, строго расположенные в указанных местах.

Как-то так. Выделяете регион памяти(CONFIG), потом складываете в него нужные сегменты (*.config)

Код

/* memory layout */
MEMORY
{
  REMAP (rx)   : ORIGIN = 0x00000000, LENGTH = 0x00000040
  ROM (rx)     : ORIGIN = 0x00000000, LENGTH = 128K - 8K
  CONFIG (rx)     : ORIGIN = 128K - 8K, LENGTH = 8K
  RAM (rw)     : ORIGIN = 0x40000000, LENGTH = 16K
}

SECTIONS
{
.............
  .config :
  {
    KEEP(*(.config))
  } > CONFIG
...........

Harbour: стоило подождать сутки, чтобы выложить одновременно Но у меня оформлено тегами [ code ], [ /code ]

[Harbour]

Sorry, если что

[zltigo]

Ага, а как тогда....

C точностью до наоборот, в этом случае расположите указатель в самом начале загружаемого кода.

[Vitaliy_ARM]

C точностью до наоборот, в этом случае расположите указатель в самом начале загружаемого кода.

В моем случае уже не стоит этим заниматься, два огромных проекта написано. Нет смысла их переделывать заново.
Чревато новыми ошибками.

Как-то так. Выделяете регион памяти(CONFIG), потом складываете в него нужные сегменты (*.config)[code]/* memory layout */

Вроде бы прояснилось.

[Vitaliy_ARM]

Генерирование отладочной информации в коде процессора - подскажите, что это такое и с чем его едят?
Где можно почитать об этом (строчки в скрипте компоновщика)?

Код

/* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug           0 : { *(.debug) }
  .line            0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo   0 : { *(.debug_srcinfo) }
  .debug_sfnames   0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges   0 : { *(.debug_aranges) }
  .debug_pubnames  0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info      0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev    0 : { *(.debug_abbrev) }
  .debug_line      0 : { *(.debug_line) }
  .debug_frame     0 : { *(.debug_frame) }
  .debug_str       0 : { *(.debug_str) }
  .debug_loc       0 : { *(.debug_loc) }
  .debug_macinfo   0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

Сообщение отредактировал Vitaliy_ARM - Jan 19 2009, 11:27

[amw]

Генерирование отладочной информации в коде процессора - подскажите, что это такое и с чем его едят?
Где можно почитать об этом (строчки в скрипте компоновщика)?

Код

/* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug           0 : { *(.debug) }
  .line            0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo   0 : { *(.debug_srcinfo) }
  .debug_sfnames   0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges   0 : { *(.debug_aranges) }
  .debug_pubnames  0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info      0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev    0 : { *(.debug_abbrev) }
  .debug_line      0 : { *(.debug_line) }
  .debug_frame     0 : { *(.debug_frame) }
  .debug_str       0 : { *(.debug_str) }
  .debug_loc       0 : { *(.debug_loc) }
  .debug_macinfo   0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

Это отрывок скрипта линкера. Он указывает, куда линкер будет ложить отладочную информацию в исполняемый файл.
Генерируется она компилятором, при использовании ключа -g с опциями. Например (варианты)

Код

gcc -g main .o main.c
gcc -g3 main .o main.c
gcc -ggdb main .o main.c
gcc -gdwarf-2 main .o main.c

Линкуется потом обычным способом (линкеру не имеет особых флагов для отладочной информации).
После этого можно спокойно отлаживать программу с помощью gdb.

[Vitaliy_ARM]

Это отрывок скрипта линкера. Он указывает, куда линкер будет ложить отладочную информацию в исполняемый файл.
Генерируется она компилятором, при использовании ключа -g с опциями. Например (варианты)

Код

gcc -g main .o main.c
gcc -g3 main .o main.c
gcc -ggdb main .o main.c
gcc -gdwarf-2 main .o main.c

Линкуется потом обычным способом (линкеру не имеет особых флагов для отладочной информации).
После этого можно спокойно отлаживать программу с помощью gdb.

Да, уже разобрался. Есть еще некоторые непонятности.
Как я понимаю OpenOCD уже научился поддерживать J-Link и еще кучу всяких Jtag. Но для этого надо ли его пересобрать? Кто-нибудь пользуется связкой Eclipse+GCC+OpenOCD+J-Link?

[Doka]

Как я понимаю OpenOCD уже научился поддерживать J-Link и еще кучу всяких Jtag. Но для этого надо ли его пересобрать? Кто-нибудь пользуется связкой Eclipse+GCC+OpenOCD+J-Link?

ну, пока непонятно.. мой опыт с OpenOCD + MT-link закончился вот чем: http://electronix.ru/forum/index.php?showtopic=58123
и трудно понять что не так - толи VID&PID не распознаёт/не нравится - толи еще что не так.. не было времени после этого разбираться