Guardant Code, map_parse и флажки оптимизации

В общем с молчаливого согласия поддержки отвечаю сам на свои вопросы

Пункт 1.  Оказывается утилита работы с образами ключей считает что адрес озу всегда начинается с 0x40003000 а не с 0x10003000 как в новых ключах. Утилитка map_parse ищет в файле мап строчку следующего вида:
RAM              0x40003000         0x00004fe0         rw
и выдирает оттуда адрес начала ОЗУ, при этом если мап сделан для кода нового ключа, то адрес неверный. Выходов тут может быть два, либо заменить число 01 по смещению 0х13 в свежесозданном бмап файле, либо (как я сделал) можно перед этапом создания бмап файла в мэйкфайле добавить нечто меняющее адрес в мап файле на "корректный",

ищется такой участок:

postbuild:
    @echo
    @if [ -e ".obj/1" ]; then $(OBJDUMP1) -xD .out/$(TARGET)1.ELF > .out/$(TARGET)1.asm ; fi;
    @if [ -e ".obj/2" ]; then $(OBJDUMP2) -xD .out/$(TARGET)2.ELF --disassembler-options=force-thumb > .out/$(TARGET)2.asm ; fi;
    @if [ -e ".obj/1" ]; then $(MAP2BIN) .out/$(TARGET)1.map .out/$(TARGET)1.bin .out/$(TARGET)1.bmap ; fi;
    @if [ -e ".obj/2" ]; then $(MAP2BIN) .out/$(TARGET)1.map .out/$(TARGET)2.bin .out/$(TARGET)2.bmap ; fi;

и заменяется на нечто вроде

postbuild:
    @echo
    @if [ -e ".obj/1" ]; then $(OBJDUMP1) -xD .out/$(TARGET)1.ELF > .out/$(TARGET)1.asm ; fi;
    @if [ -e ".obj/2" ]; then $(OBJDUMP2) -xD .out/$(TARGET)2.ELF --disassembler-options=force-thumb > .out/$(TARGET)2.asm ; fi;
    @if [ -e ".obj/1" ]; then $(MAP2BIN) .out/$(TARGET)1.map .out/$(TARGET)1.bin .out/$(TARGET)1.bmap ; fi;

    perl -ig -ne "s/0x10003000/0x40003000/;print $_;" .out/$(TARGET)2.map

    @if [ -e ".obj/2" ]; then $(MAP2BIN) .out/$(TARGET)2.map .out/$(TARGET)2.bin .out/$(TARGET)2.bmap ; fi;

Проблемс номер2 с некорректной работой ключей оптимизации, дело в том что ключи -ffunction-sections -fdata-sections вызывают создание большого количества секций вида например  .text.чтототам , а скрипт линкера их не учитывает, тем не менее можно все исправить следующим образом , редактируется файл rom2.ld , в нем меняется

         *(.text)                            /* remaining code */
на
         *(.text .text.*)                            /* remaining code */

         *(.data)
на
         *(.text .text.*)                            /* remaining code */

         *(.bss)
на
         *(.bss .bss.*)

Могут быть еще какие то секции, которые я не учел, но этих обычно достаточно

Я ошибался, это скучно. Оказалось, что феерическая сборка в предлагаемой сдк сразу двух версий бинарников это фича чтобы обойти кривизну утилиты map_parse и прочих для работы с ключом,  решение достойное студента-первокурсника :)

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

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

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

Я вас уверяю , все проблемы которые я нашел были связаны с использованием чисто yagarto без каких либо других установленых сред.

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

Я измерял времена работы SSL на ключе, и получилось парадоксальное соотношение,
допустим ключ без кода вообще тратит на передачу килобайта (на ключ и обратно)  60милисекунд, если работает ssl c AES-CBC/HMAC-SHA256  то это время увеличивается на 2 милисекунды, странно да?

Вот это отличная новость, думаю ключам Code именно этого и не хватает. В свою очередь могу описать несколько криптографических примитивов и безопасных протоколов, с тем чтобы разработчики не начинали на ровном месте.

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

Я согласен, можно обходить препятствия, но ведь многие из них могли бы не существовать и тогда не пришлось бы "умело обходить", кроме того там не 20мс, 20 это для пустого запроса без передачи данных, более близкая к реальности цифра - порядка 100мс или 10 запросов в секунду для вызова кода, или порядка 40мс для вызова встроеных алгоритмов.

+1

ещё раз +1

Здравствуйте, Jeevoy,

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

Только что проделал следующее:
1) На чистый компьютер с Win7 Pro установил Guardant SDK 6.1 - с сайта скачал для чистоты эксперимента
2) Установил последние версии YAGARTO Tools и YAGARTO GNU Toolchain с сайта http://www.yagarto.de/#download
3) Открыл наш самый наглядный пример C:\Program Files (x86)\Guardant\Guardant 6.1\DEMONVK\Samples\ARM\05 - LED Control\Loadable Code
Здесь загружаемый код заставляет ключ моргать с определенной периодичностью. Очень просто отследить работоспособность
4) Запустил команду make template, затем make all. Скомпилировалась пара файлов bin/bmap
5) Загрузил bin в ключ, маска по умолчанию.
6) Все работает, при вызове GrdCodeRun ключ моргает, никаких ошибок на всем пути.

Но ключ Code и вся инфраструктура GCC весьма сложные вещи, там все может слетать из за какого нибудь пробела в пути к файлу или подобной мелочи. Поэтому для локализации конкретно вашей ошибки нужно больше информации:
- версия SDK
- в какие папки на диске установлен SDK, Yagarto toolchain, Yagarto tools
- откуда и как запускаете make
- файл makefile
- полный вывод с команд make template и make all

Я сожалею что мы не ответили ранее, т.к. просто не заметили вопроса. Кривая освоения для Code в любом случае существует, ошибки неизбежны.

В итоге: map_parse отлично совместим с тулчейном, но небольшие правки makefile в зависимости от вашей инфраструктуры разработки это вполне нормальная вещь. Пишите подробности на hotline, разберемся.

Касательно пути установки Guardant - ограничений нет для примеров, если вы makefile не трогаете. Там пути указаны в относительном виде. YAGARTO должен быть по пути без пробелов.

Я установил наш SDK в папку по умолчанию...

Не смог найти рабочие сборки на вашем сайте и на своём CD диске (полученном от вас в декабре 2012 г.) тоже. А это необходимо, т.к. с сайта http://www.yagarto.org/ их уже не скачать. Проект перешёл на SourceForge, но yagarto-tools там нет.

Нашёл в интернете ‘yagarto-tools-20121018-setup.exe’ и ‘yagarto-bu-2.22_gcc-4.7.2-c-c++_nl-1.20.0_gdb-7.5_eabi_20121013.exe’, установил их в ‘c:\YAGARTO\’. SDK установлено в директорию по умолчанию ‘c:\Program Files (x86)\Guardant\SDK 6.3\’. И ваши примеры загружаемого кода из SDK не компилируются.

На Windows 8.1 Pro x64 я получаю:

c:\Program Files (x86)\Guardant\SDK 6.3\XXX\Samples\ARM\00 - Template\Loadable Code>make all
-------- begin --------
--Check WinARM--
      0 [main] sh 5992 sync_with_child: child 8340(0x16C) died before initialization with status code 0xC0000142
    660 [main] sh 5992 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
make: *** [prebuild] Error 128

На Windows XP SP3 x32 (всё установлено по тем же путям: ‘c:\YAGARTO\’ и ‘c:\Program Files\Guardant\SDK 6.3\’) получаю, как в теме https://forum.guardant.ru/post/1020/:

c:\Program Files\Guardant\SDK 6.3\XXX\Samples\ARM\00 - Template\Loadable Code>make all
-------- begin --------
--Check WinARM--
/usr/bin/sh: arm-elf-gcc: command not found
--Check Yagarto--
arm-none-eabi-gcc.exe: fatal error: no input files
compilation terminated.
Compiling: main.o main.c
arm-none-eabi-gcc.exe: fatal error: no input files
compilation terminated.
make: *** [main.o] Error 1

Make.exe точно вызывается из ‘c:\YAGARTO\bin\make.exe’, проверял, подставлял полный путь, в обоих случаях результат тот же.

В чём может быть беда? Проверьте сами, работает ли это сейчас. Обращаюсь к разработчикам, только не тяните, ответьте, как можно быстрее. Уже почти 3 недели ковыряю защиту и большую часть времени по вине ошибок в ваших утилитах и описании к ним.

Спасибо Вам за мощную обратную связь.
Действительно, в связи с окончанием поддержки проекта Yagarto мы и наши клиенты (особенно новые) столкнулись с некоторыми сложностями. Мы решаем вопрос комплексно, дабы в ближайшем будущем сделать использование ключей Code как можно более удобным и простым прямо "из коробки".

Информация в данной ветке, особенно найденная Phaza7 нам очень поможет в этом деле.

Мы постараемся придумать, как отблагодарить Вас за помощь и такое глубокое вникание в наши технологии (особенно учитывая что в данном случае оно далеко от беспроблемного).

Спасибо за обратную связь.