Добрый день.
Имеется библиотека (криптография) которая писалась и отлаживалась на ПК в Visual C++. Нужно перенести получившийся код на процессор ARM926EJ-S. На что нужно (и можно) обратить внимание?
К сожалению, тупо вставить, ничего не меняя, не получилось - код компилируется, но система после запуска вылетает в Fatal Error (конкретное исключение вроде бы MisAligned, но не уверен). Ну а поскольку в коде так и так придется ковыряться, хотелось бы по максимуму ускорить его выполнение.

Для ARM используется gcc?

Как минимум - изучить матчасть (ядро ARM9).
Вам об этом намекает MisAligned. Раз вылетает на невыровненном доступе, значит те кто писал эту библиотеку, ничего кроме ПК не видели.

Размерности по типам данных в обоих компиляторах совпадают? Нумерация байтов и бит в слове.

Если есть стабильное исключение, то установить где оно происходит с помощью JTAG дело пяти минут.
Обратите внимание на JTAG

Не забудьте включить MMU, Instruction cache и Data cache, иначе выйдет не криптография, а сплошные тормоза. А для этого как раз и придется вникать в документацию по ядру, как заметили чуть выше.
В моих опытах с RSA2048 на этом ядре после включения MMU и кэшей скорость вычислений возрастала примерно в 6 (!) раз ...

Вангую, на 100% это все крутится под линукс.

Кто ж на линуксе такое делает. Он же весь насквозь дырявый. Там вон даже в bash-е открыли огромную дыру.

Больше похоже на то самое "защищенное хранилище", для которого тут полгода назад искали Cortex-M3 на 800 МГц
И похоже наконец дело сдвинулось.

Спасибо всем за отклики и добрые слова
На всякий случай попробую описать ситуацию подробней.
Компилятор - ADS 1.2 build 842
Отладчик - Lauterbach T32 (китайский клон)
SoC - Qualcomm MSM6290
Само устройство - 3G-модем. Соответственно, объем Firmware очень большой (исходников под 2 гига), само ПО - многоуровневое и многоступенчатое , поэтому в "потроха" процессора я лезть не могу и не хочу. Но, думаю, MMU там все же включен .
По поводу операционки - там действительно не линукс, а микроядро L4:Pistachio, поверх простейшей РТОС "REX" (или РТОС поверх микроядра, не знаю как будет правильнее).
Что какется размерности типов и порядка байт - буду смотреть. В самой библиотеке вроде как просматриваются попытки оптимизации под разные размеры int.
С JTAG у меня 2 проблемы:
1. В отладчике не отображаются С-исходники, только ассемблерный код. Может позже создам отдельную тему, если отчаюсь найти решение.
2. В связи с многоуровневой загрузкой ПО, после каждого Fault необходимо заново запускать отдельный сценарий для загрузки символьной информации. И заново устанавливать точки останова.
В результате процесс поиска источника проблемы получается очень долгим и утомительным. Я устал искать и создал тему
P.S. Это не "защищенное хранилище", это параллельный проект. Для хранилища, насколько я знаю, взяли Freescale Keenetic (Cortex-A9)

И??... Установили что оно происходит к примеру в диапазоне адресов: 0x00000000...0xFFFFFFFF (каждый раз - в новом месте). Что дальше?
Как догадаться, что оно происходит к примеру: из-за переполнения/разрушения стека, после которого происходит POP {PC} в случайный адрес,
далее несколько тыс. команд CPU бродит по случайным адресам, пока не натыкается на нечто, вызывающее это исключение?

Хотя с определённой долей вероятности можно предположить, что у ТС всё проще. И раз код писали люди, не понимающие чем грозит *(int *)0x00000001
на CPU типа ARM9, то возможно что адрес исключения укажет на одну из точек бага.
Только начинать всё равно нужно с изучения мануала на CPU.


Не очень понятно, как MMU повлияет на быстродействие...
Раскройте секрет.


Странный вывод....
Т.е. - если-бы ПО было простое - полезли-бы? Вы считаете, что сложность внутреннего устройства CPU увеличивается при усложнении ПО на нём выполняющегося???
Т.е. - в простом ПО типа HelloWorld в CPU имеется скажем всего 4 РОН, но при увеличении размера кода до 1гига - кол-во регистров может увеличиться до 256???

Warning-и от компилятора есть? Сравните код ассемблера ПК и ARM по этим предупреждениям. Возможно много одинаковых предупреждений, и больше внимания данным. Криптография... Используется целочисленная арифметика неограниченной длины?
Отладчик у Вас крутой!

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

Если верить википедии то REX OS не имеет механизмов защиты памяти и виртуализации адресного пространства.
Значит ваша библиотека может завалить всю ситему по любой мелочи.

Как то приходилось портировать крипто библиотеки, там чаще всего вопрос утыкается в правильное портирование механизмов динамической памяти.
Причем ADS имеет механизм retargeting для портирования стандартных функций типа malloc в окружение RTOS и сама оcь может предлагать подмену malloc.
Легко запутаться. Нужно как минимум найти в сорсах все места где выделяется динамическая память и проверить на корректность.

Он с Trace-ом что-ль?

Ну, от REX там только API - определение процессов, межпроцессное взаимодействие и т.п. Дальше это все превращается в процессы L4. За совет спасибо, но динамическое выделение памяти в портируемой библиотеке не используется.



Warning-ов нет. Что там используется и как это называется - не в курсе. Но походу придется разбираться
Да, порядок байтов как и на ПК - little-endian.


Я просто хотел сказать, что настройки SoC определяются исходным ПО (модем и иже с ним). А поскольку это ПО сложное, то отследить взаимосвязь между его работой и настройками процессора не представляется возможным. А влезать в них - 100% развалить все.

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

А как тогда ваша библиотека стыкуется к основному образу ПО?
Сразу все линкуется вместе с вашей библиотекой на стадии компиляции или библиотека компилируется отдельно и потом динамически загружается и связывается с основным ПО уже на стадии исполнения?

Может просто перекомпилировать весь образ надо.

Я работаю не с образом ПО, а с исходниками. Т.е. я добавляю в исходники новые файлы со своим процессом, а потом все вместе компилируется.

Что меня больше всего смущает - Fatal Error происходит не в моем процессе, а каком-то глубоко системном (от него даже исходников нет, только заголовки). Судя по имени обработчика IxTimeOfDay_IPC_Server(), это что-то связанное с часами реального времени.

А как узнали имя функции в которой прооисходит аборт?

И как понимаю работаете с скомпилированным ядром в виде библиотеки и перекомпилировать его не можете, раз одни только хидеры имеете.

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

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

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

Просто совет, основанный на личном опыте. Я использовал вот эту библиотеку (bnlib) от Филиппа Зиммермана:

http://philzimmermann.com/EN/bnlib/index.html

Спасибо, буду иметь в виду.

Арифметика произвольной точности есть в любой реализации SSL.
Можно взять уже адаптированную для embedded библиотеку, например из MatrixSSL.
Все в одном файле, компактно, без нагромаждения архитектур.

Спасибо. Разберусь с текущей задачей - буду изучать

Причина в том, что во многих АРМовских процессорных ядрах, в том числе на ARM926, кэш данных может работать только при включённом MMU. Соответственно, если MMU выключено, кэш данных не работает и любое обращение к памяти реально обращается к памяти А это, понятное дело, -- большие задержки. Поэтому, даже если виртуальная память совершенно не нужна, крайне рекомендуется включать MMU, заполнив переадресации таким образом, чтобы виртуальные адреса просто совпадали с физическими, а защита не использовалась.

Вам сказали

Вы пока проверили только байты...

Да, пожалуй Вы правы:
Открываем TRM на ARM926EJ-S раздел "Caches and Write Buffer":
Table 4-3 CP15 c1 C and M bit settings for the DCache
C bit/M bit____ARM926EJ-S behavior
...
1/0______DCache enabled, MMU disabled. The C bit is overridden by the M bit setting, so that the DCache is
_________effectively disabled. All data accesses are noncacheable, nonbufferable, with no protection checks. All
_________addresses are flat mapped, that is VA = MVA = PA.
...