[dimka76 42]

On 6/7/2023 at 10:46 AM, VaTiKaNeTs said:

Входные данные: OS Linux mint
                           STM32 CUBE IDE

Есть задача, посчитать CRC прошивки (hex файла). Эту задачу я выполнил, с помощью следующего кода

В скрип линкера ввести переменные, по которым определяется размер прошивки, и тем же скриптом линкера кладется в определенное место прошивки, например сразу за таблицей векторов прерываний.
STM32H743IITx_FLASH.ld

Смотрите секцию .text_len

[VaTiKaNeTs 0]

Написал такой код для awk

BEGIN{
	FS="" #каждый новый символ это новое поле данных
}
{
	if ($8 == 0 && $9 == 0) # 00 - запись содержит данные двоичного файла
	{
		# прибавляем поле длины к общему размеру
		size += (($2 * 10) + $3)
	}
}
END{
	print "size of data in HEX file: "size" Byte"
}

Вырезал несколько строк из hex файла, и протестировал на них, что бы проверить правильность. Выдает размер 60 байт, получается правильно считает размер

:203FA0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF21
:203FC0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF01
:203FE0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE1

 

@dimka76, если мой способ не выгорит, попробую ваш

[dimka76 42]

On 6/8/2023 at 9:02 AM, VaTiKaNeTs said:

@dimka76, если мой способ не выгорит, попробую ваш

Вот посчитаете вы эту CRC, а что потом с ней делать будите ?

[VaTiKaNeTs 0]

18 минут назад, dimka76 сказал:

Вот посчитаете вы эту CRC, а что потом с ней делать будите ?

Положу по адресу в конец флешки рядом с размером прошивки, а затем сама stm залезет в конец флешки, возьмет размер оттуда, посчитает по нему crc, и сравнит его с тем, что хранится в конце флешки

[aaarrr 63]

4 minutes ago, VaTiKaNeTs said:

Положу по адресу в конец флешки

ИМХО, удобнее держать по фиксированному адресу в начале

[VaTiKaNeTs 0]

может быть вы правы, но я пока не хочу сдвигать всю прошивку на 8 байт, и править стартовый адрес в линкере

[VladislavS 29]

10 минут назад, VaTiKaNeTs сказал:

но я пока не хочу сдвигать всю прошивку на 8 байт

У кортексов в таблице векторов прерываний есть пустые места. Идеальное место для хранения размера прошивки, crc и т.д.

[esaulenka 5]

14 hours ago, VaTiKaNeTs said:

а можете поделиться, кодом, которым вы считали размер hex файла

Давайте всё-таки определимся, что такое "размер файла" ?

Количество данных, которые там содержатся? Ваша магия на awk'е, кажется, должна корректно это считать. Но я плохо понимаю, зачем это нужно, поскольку из-за потенциальных "дырок" арифметика вида стартовый адрес + кол-во данных = конечный адрес здесь не работает.

Этот топик вы начинали с вопроса "хочу найти конечный адрес". С применением удобных инструментов это решается очень просто:

#!/usr/bin/env python
import sys
from intelhex import IntelHex
ih = IntelHex(sys.argv[1])
print('min addr = %X, max addr = %X' % (ih.minaddr(), ih.maxaddr()))

 

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

19 минут назад, VaTiKaNeTs сказал:

но я пока не хочу сдвигать всю прошивку на 8 байт, и править стартовый адрес в линкере

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

Ну вот положили вы размер прошивки и саму контрольную сумму куда-то в конец флеши, а дальше что? Вы потеряли одно очень удобное свойство циклической контрольной суммы - добавленная в конец блока данных она дает результирующую сумму равную нулю. То есть вам не нужно откуда-то дополнительно вычитывать ее, что-то сравнивать - просто обсчитываете блок данных с учетом размера этой контрольной суммы и проверяете результат на ноль. Положили вы размер прошивки тоже отдельно рядом с контрольной суммой - а вы не хотите его тоже защитить этой же контрольной суммой? Значит он должен лежать где-то вместе с прошивкой, в фиксированном месте (наиболее удобно - сразу после векторов, как показал dimka76).

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

[dimka76 42]

On 6/8/2023 at 10:07 AM, VaTiKaNeTs said:

может быть вы правы, но я пока не хочу сдвигать всю прошивку на 8 байт, и править стартовый адрес в линкере

стартовый адрес никуда не денется

Да и с HEX файлом работать не удобно, с бинарным удобнее (ИМХО)

[VaTiKaNeTs 0]

46 минут назад, esaulenka сказал:

Давайте всё-таки определимся, что такое "размер файла" ?

Некорректно выразился, мне нужен размер моей прошивки, которая содержится в hex файле

[x893 35]

1. Конвертируйте hex -> bin

2. Размер файла == размеру прошивки

3. Удаляете bin файл

Две страницы воды можно удалить

[xvr 12]

3 hours ago, jcxz said:

.......и "ваши данные" оказываются в совсем неожиданном месте. 

Да, про сенмент я как то не подумал. Значит надо 2 строки добавить - сегмент + данные

 

[uni 6]

VaTiKaNeTs писал:

Цитата

Положу по адресу в конец флешки рядом с размером прошивки, а затем сама stm залезет в конец флешки, возьмет размер оттуда, посчитает по нему crc, и сравнит его с тем, что хранится в конце флешки

В 08.06.2023 в 13:42, x893 сказал:

1. Конвертируйте hex -> bin

2. Размер файла == размеру прошивки

3. Удаляете bin файл

Две страницы воды можно удалить

Почти так у меня и работает. Уже давно кладу значение CRC32 в конец автоматом. Но вообще, есть определённые тонкости в этом деле. Я приложил пример доработанного проекта загрузчика openblt для STM32F103 (Windows).

Особенности:

- мне нужно, чтобы подписан был elf-файл для целей отладки, т.е. фактически происходит двойное формирование elf-файла, из которого уже можно получить всё остальное;
- hex-файл может иметь "пропуски", пустые места, для которых нужна договорённость как их считать (это важно для самопроверки всего бинарного образа);
- значение контрольной суммы кладётся в самый конец прошивки с выравниванием, код проверки использует это для теста целостности прошивки путём сравнения с нулём (если посчитать вместе со значением CRC32);
- место после таблицы векторов прерываний тоже используется, но я туда кладу размер прошивки до значения CRC32 (на всякий случай, в загрузчике это не используется);
- для автоматической работы этого всего изменён ld-файл и в корень проекта добавлен makefile.targets, ссылка на который есть в mk-файлах сборок (вы должны понимать для чего это сделано);

При реконфигурации проекта ld-файл может быть заменён, поэтому нужно понимать где и что там добавлено. В main.h объявлены внешние переменные, используя которые можно сделать проверку целостности всей прошивки.

Сам загрузчик проверяет приложение на целостность по этой же схеме перед передачей управления. Это есть в коде.

Указанные выше в цитате пункты реализованы в файле makefile.targets. Расчёт для bin-файла осуществляется собственной самописной внешней утилитой.

Всё действо в makefile.targets будет работать только если доступна sh.exe под Windows или оно же под Линукс. Если запустить сборку под Windows, где нет доступа к sh в окружении, то она завершится с ошибкой. Это связано со способом вызова внешней программы для расчёта CRC32 прямо в строке опций компилятора gcc (одинарные кавычки). В CubeIDE это условие выполняется по умолчанию. При сборке среда окружает процесс всеми нужными утилитами.

В общем, на свой страх и риск. Нужно соображать что делаешь. Ах да, пустые места у меня заполняются 0xFF, либо действуют умолчания, что там будет 0xFF, либо мк должен быть предварительно потёрт. Иначе может возникнуть ситуация, что значение CRC32 не сойдётся при самопроверке. Но в общем и целом, при прочих равных, метода работает (проверено на F0, F1 и F4).

Можете назвать это "реализация подписи прошивки от uni".

Boot-20230706.7z

Изменено 6 июля, 2023 пользователем uni
Добавлена картинка

[x893 35]

21 minutes ago, uni said:

Можете назвать это "реализация подписи прошивки от uni".

Хорошо. Так и будем называть.