|
Размер прошивки средствами линкера, С сохранением в тело прошивки |
|
|
|
Nov 26 2014, 07:36
|
Частый гость
 
Группа: Свой
Сообщений: 171
Регистрация: 22-03-05
Из: Новосибирск
Пользователь №: 3 578

|
Суть проблемы: рассчитываю контрольную сумму прошивки как написано в http://supp.iar.com/Support/?note=62709 в пункте "Alternative solution using checksum-start and checksum-end markers". Сохраняю размер блока ROM_CONTENT как описано в http://supp.iar.com/Support/?note=52791. Но при этом значение ROM_length_used равна не размеру всей области до "checksum_end_mark", а только до адреса 0x0802bd04 (см. map-файл ниже). Подозреваю, что размер прошивки надо рассчитывать в Post-Build Actions и сохранять в заранее выделенную секцию выходного файла, но как это сделать не нашел. Можно ли это сделать средствами линкера и его утилит? Контрольная сумма считается правильно для всей прошивки. Контроллер STM32. CODE ******************************************************************************* *** PLACEMENT SUMMARY ***
"A1": place at 0x08002000 { ro section .intvec }; "P1": place in [from 0x08002000 to 0x080edfff] { block ROM_CONTENT }; "P2": place in [from 0x20000000 to 0x20017fff] { rw, block CSTACK, block HEAP };
Section Kind Address Size Object ------- ---- ------- ---- ------ "A1": 0x130 .intvec ro code 0x08002000 0x130 startup_stm32f10x_xl.o [1] - 0x08002130 0x130
"P1": 0x29d04 ROM_CONTENT 0x08002130 0x29d04 <Block> ROM_length_used const 0x08002130 0x4 Place holder ROM_CONTENT_size checksum_start_mark const 0x08002134 0x1 main.o [1] .rodata const 0x08002138 0x10 arrow_down2.o [1] .rodata const 0x08002148 0x10 arrow_up2.o [1] .rodata const 0x08002158 0x1c calendar.o [1]
.text ro code 0x0802b234 0x62 memcmp_unaligned.o [5] .text ro code 0x0802b298 0x10 startup_stm32f10x_xl.o [1] .text ro code 0x0802b2a8 0x10 stm32f10x_adc.o [1] .text ro code 0x0802b2b8 0x894 stm32f10x_it.o [1] .text ro code 0x0802bb4c 0x15c system_stm32f10x.o [1] .text ro code 0x0802bca8 0x1a cmain.o [5] .text ro code 0x0802bcc2 0x4 low_level_init.o [3] .text ro code 0x0802bcc8 0x28 data_init.o [5] .text ro code 0x0802bcf0 0x4 exit.o [3] .text ro code 0x0802bcf4 0xa cexit.o [5] .text ro code 0x0802bd00 0xc XXexit.o [5] Initializer bytes ro data 0x0802bd0c 0x20 <for P2-1> (used: 0x1c) .text ro code 0x0802bd2c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd30 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd34 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd38 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd3c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd40 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd44 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd48 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd4c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd50 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd54 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd58 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd5c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd60 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd64 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd68 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd6c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd70 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd74 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd78 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd7c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd80 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd84 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd88 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd8c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd90 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd94 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd98 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bd9c 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bda0 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bda4 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bda8 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdac 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdb0 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdb4 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdb8 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdbc 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdc0 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdc4 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdc8 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdcc 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdd0 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdd4 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdd8 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bddc 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bde0 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bde4 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bde8 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdec 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdf0 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdf4 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdf8 0x4 startup_stm32f10x_xl.o [1] .text ro code 0x0802bdfc 0xc cstartup_M.o [5] .iar.init_table const 0x0802be08 0x24 - Linker created - .rodata const 0x0802be2c 0x0 zero_init3.o [5] .rodata const 0x0802be2c 0x0 copy_init3.o [5] checksum_end_mark const 0x0802be2c 0x4 main.o [1] checksum const 0x0802be30 0x4 Place holder ielftool_checksum - 0x0802be34 0x29d04
|
|
|
|
|
Nov 26 2014, 07:58
|
Частый гость
 
Группа: Свой
Сообщений: 171
Регистрация: 22-03-05
Из: Новосибирск
Пользователь №: 3 578

|
Цитата(jcxz @ Nov 26 2014, 11:49)  Воспользуйтесь поиском - здесь буквально пару тем назад обсуждался этот вопрос. И там подробно расписано как надо делать. Второй день штудирую данную тему в интернете, если не сложно - киньте ссылку на то, как надо делать.
|
|
|
|
|
Nov 26 2014, 09:03
|
Частый гость
 
Группа: Свой
Сообщений: 171
Регистрация: 22-03-05
Из: Новосибирск
Пользователь №: 3 578

|
Цитата(jcxz @ Nov 26 2014, 12:47)  И где там про сохранение размера, занятой программой, области флэша по заданному адресу? Вопрос сводится к тому, как с помощью IAR прописать в секцию памяти "ROM_length_used" адрес другой секции "checksum_end_mark"после всех действий линкера на выходным файлом? Вот вырезка из icf файла: Код define block ROM_CONTENT with fixed order { readonly section ROM_length_used, readonly section checksum_start_mark, readonly, readonly section checksum_end_mark, readonly section checksum, };
keep { section ROM_length_used };
place in ROM_region { block ROM_CONTENT };
|
|
|
|
|
Nov 26 2014, 19:06
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(Prowler @ Nov 26 2014, 18:23)  Разобрался, опять невнимательность), в блок ROM_CONTENT обозначенный в icf-файле не входит таблица векторов прерываний, и размер собственно без нее. А я думал что-то с конца прошивки байтов недосчитывается.. Да, когда я разбирался с этим, столкнулся с этой проблемой - если включать в область расчёта CRC вектора прерывания, то CRC потом не сходится. Так что пришлось вектора исключить. CRC у меня считается начиная после векторов. Т.е. - даже не обязательно полностью всю таблицу векторов исключать, достаточно исключить первые вектора (для которых IAR считает контрольную сумму). В том треде я как раз об этом писал.
|
|
|
|
|
Nov 27 2014, 03:02
|
Частый гость
 
Группа: Свой
Сообщений: 171
Регистрация: 22-03-05
Из: Новосибирск
Пользователь №: 3 578

|
Цитата(Сергей Борщ @ Nov 27 2014, 02:48)  А заставить линкер самостоятельно посчитать эту контрольную сумму и положить ее в нужное место нельзя? Мне удавалось заставить гнутый линкер делать такое (правда таблицу пришлось разбить на две - до и после суммы). У меня контрольная сумма считается по всей прошивке с таблицей векторов, но кладется в конец прошивки. Чтобы потом без проблем проверить аппаратным модулем CRC32 STM32. Если класть в область расчета, то потом почему-то не сходилось. Наверно из-за того что в выходном бинарнике в секции выделенной под контрольную сумму прошивки вообще пусто (0x00000000), а функция расчета предполагает что там 0xFFFFFFFF, или вообще не учитывает эту секцию. Считаю после работы линкера следующим батником: Код set OUT=%1.out set HEX=%1.hex set BIN=%1.bin
:: calculate checksum of the application ielftool --fill 0xFF;0x08002000-checksum_end+3 --checksum ielftool_checksum:4,crc32:ir,0xFFFFFFFF;0x08002000-checksum_end+3 --verbose %OUT% %OUT%
:: generate additional ouput: hex ielftool.exe --ihex --verbose %OUT% %HEX%
:: generate additional ouput: binary ielftool.exe --bin --verbose %OUT% %BIN% 0x08002000 - адрес начала основной прошивки. Данные настройки расчета контрольной суммы кстати соответствуют аппаратному CRC32 в STM32.
|
|
|
|
|
Nov 27 2014, 08:20
|

Гуру
     
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095

|
Цитата(Prowler @ Nov 27 2014, 05:02)  Наверно из-за того что в выходном бинарнике в секции выделенной под контрольную сумму прошивки вообще пусто (0x00000000), а функция расчета предполагает что там 0xFFFFFFFF, или вообще не учитывает эту секцию. C CRC32 все понятно. Конечно она должна лежать в конце прошивки. И конечно, в процессе расчета должны участвовать все слова до этой суммы, а в процессе проверки - все слова включая эту сумму (тогда результат равный 0 покажет целостность прошивки). Я имел ввиду контрольную сумму векторов, которая должна располагаться по адресу 0x0800001C и которая проверятется после сброса встроенным загрузчиком имени NXP до перехода по вектору сброса. Из вашего файла я вижу что речь идет о приложении, вызываемом пользовательским загрузчиком, а ему эта контрольная сумма векторов не важна. Я думал, что речь идет о приложении без пользовательского загрузчика, которое начинается с адреса 0x08000000. И смею предположить, что jcxz тоже имел вииду такое приложение. Добавлено: прошел по ссылке jcxz, там он пишет что ИАР считает эту контрольную сумму векторов для любого приложения. Тогда мое предложение остается в силе - заставить его линкер подставлять туда в процессе линковки точно ту же самую сумму, которую потом подставит ИАР. Тогда CRC сможет охватить весь образ прошивки, включая область векторов.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
Nov 27 2014, 08:23
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(Сергей Борщ @ Nov 27 2014, 05:48)  А заставить линкер самостоятельно посчитать эту контрольную сумму и положить ее в нужное место нельзя? Мне удавалось заставить гнутый линкер делать такое (правда таблицу пришлось разбить на две - до и после суммы). Проблема не в том чтобы "заставить положить", а в том чтобы "заставить не ложить". Как написал уже Prowler - в момент расчёта CRC IAR-ом в таблице векторов одни значения, а в выходном бинарнике - другие. Поэтому мне и пришлось исключить эти первые 8*4 байт из расчёта. Тоже разбив таблицу векторов на две части. Если так уж нужно включить все вектора, то думаю можно сделать просто - после таблицы векторов разместить 8 комад безусловных переходов, так чтобы они находились по фиксированному адресу, самостоятельно посчитать и заполнить 8 первых слов в таблице прерываний на эти команды перехода.
|
|
|
|
|
Nov 27 2014, 09:35
|

Гуру
     
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095

|
Цитата(jcxz @ Nov 27 2014, 10:23)  Как написал уже Prowler - в момент расчёта CRC IAR-ом в таблице векторов одни значения, а в выходном бинарнике - другие. Так я и предлагаю заставить линкер сразу класть туда эти самые "другие" значения. Такие же, какие будут в выходном бинарнике. Цитата(jcxz @ Nov 27 2014, 10:23)  так чтобы они находились по фиксированному адресу, самостоятельно посчитать и заполнить 8 первых слов в таблице прерываний на эти команды перехода. Зачем? линкер прекрасно знает адреса, куда указывают вектора прерываний. Надеюсь, ИАРовский линкер сумеет эти числа сложить между собой и вычесть из нуля. Для гнутого у меня в скрипте это делается так: Код KEEP(*(.isr_vector1)) LONG(0 - (6 + _estack + Reset_Handler + NMI_Handler + HardFault_Handler + MemManage_Handler + BusFault_Handler + UsageFault_Handler)); KEEP(*(.isr_vector2))
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
Nov 27 2014, 09:50
|
Частый гость
 
Группа: Свой
Сообщений: 171
Регистрация: 22-03-05
Из: Новосибирск
Пользователь №: 3 578

|
Цитата(jcxz @ Nov 27 2014, 12:23)  Проблема не в том чтобы "заставить положить", а в том чтобы "заставить не ложить". Как написал уже Prowler - в момент расчёта CRC IAR-ом в таблице векторов одни значения, а в выходном бинарнике - другие. Поэтому мне и пришлось исключить эти первые 8*4 байт из расчёта. Тоже разбив таблицу векторов на две части. Данная проблема видимо касается только контроллеров NXP, для ST не нужна специальная контрольная сумма для таблицы векторов. Решение описано здесь - http://supp.iar.com/Support/?Note=52619. Я имел ввиду другое - у меня сумма не записывалась в выходной бинарник, на ее месте были нули (http://supp.iar.com/Support/?note=62859), и расчет CRC ИАРа с расчетом CRC самим контроллером не совпадали.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|