[Harvester 0]

Добрый день.

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

К сожалению, тупо вставить, ничего не меняя, не получилось - код компилируется, но система после запуска вылетает в Fatal Error (конкретное исключение вроде бы MisAligned, но не уверен). Ну а поскольку в коде так и так придется ковыряться, хотелось бы по максимуму ускорить его выполнение.

[Виктория 0]

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

[jcxz 184]

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

Как минимум - изучить матчасть (ядро ARM9).

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

[Виктория 0]

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

[AlexandrY 3]

На что нужно (и можно) обратить внимание?

 

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

Обратите внимание на JTAG ;)

[kovigor 5]

... хотелось бы по максимуму ускорить его выполнение.

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

В моих опытах с RSA2048 на этом ядре после включения MMU и кэшей скорость вычислений возрастала примерно в 6 (!) раз ...

[Lagman 1]

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

[AlexandrY 3]

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

 

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

 

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

И похоже наконец дело сдвинулось.

 

 

 

[Harvester 0]

Кто ж на линуксе такое делает. Он же весь насквозь дырявый. Там вон даже в 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)

 

 

Изменено 5 октября, 2014 пользователем Harvester

[jcxz 184]

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

И??... Установили что оно происходит к примеру в диапазоне адресов: 0x00000000...0xFFFFFFFF (каждый раз - в новом месте). Что дальше?

Как догадаться, что оно происходит к примеру: из-за переполнения/разрушения стека, после которого происходит POP {PC} в случайный адрес,

далее несколько тыс. команд CPU бродит по случайным адресам, пока не натыкается на нечто, вызывающее это исключение? :laughing:

 

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

на CPU типа ARM9, то возможно что адрес исключения укажет на одну из точек бага.

Только начинать всё равно нужно с изучения мануала на CPU.

 

Не забудьте включить MMU, Instruction cache и Data cache, иначе выйдет не криптография, а сплошные тормоза.

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

Раскройте секрет. :)

 

Само устройство - 3G-модем. Соответственно, объем Firmware очень большой (исходников под 2 гига), само ПО - многоуровневое и многоступенчатое :), поэтому в "потроха" процессора я лезть не могу и не хочу.

Странный вывод....

Т.е. - если-бы ПО было простое - полезли-бы? Вы считаете, что сложность внутреннего устройства CPU увеличивается при усложнении ПО на нём выполняющегося???

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

[Виктория 0]

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

К сожалению, тупо вставить, ничего не меняя, не получилось - код компилируется, но система после запуска вылетает в Fatal Error (конкретное исключение вроде бы MisAligned, но не уверен).

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

Отладчик у Вас крутой!

[AlexandrY 3]

На всякий случай попробую описать ситуацию подробней.

Компилятор - ADS 1.2 build 842

Отладчик - Lauterbach T32 (китайский клон)

SoC - Qualcomm MSM6290

 

Да, вам не позавидуешь.

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

 

Если верить википедии то REX OS не имеет механизмов защиты памяти и виртуализации адресного пространства.

Значит ваша библиотека может завалить всю ситему по любой мелочи.

 

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

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

Легко запутаться. Нужно как минимум найти в сорсах все места где выделяется динамическая память и проверить на корректность.

[jcxz 184]

Отладчик у Вас крутой!

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

[Harvester 0]

Да, вам не позавидуешь.

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

 

Если верить википедии то REX OS не имеет механизмов защиты памяти и виртуализации адресного пространства.

Значит ваша библиотека может завалить всю ситему по любой мелочи.

 

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

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

Легко запутаться. Нужно как минимум найти в сорсах все места где выделяется динамическая память и проверить на корректность.

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

 

 

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

Отладчик у Вас крутой!

Warning-ов нет. Что там используется и как это называется - не в курсе. Но походу придется разбираться :laughing:

Да, порядок байтов как и на ПК - little-endian.

 

Т.е. - если-бы ПО было простое - полезли-бы? Вы считаете, что сложность внутреннего устройства CPU увеличивается при усложнении ПО на нём выполняющегося???

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

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

 

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

[AlexandrY 3]

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

 

А как тогда ваша библиотека стыкуется к основному образу ПО?

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

 

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