ELVEES R&D Center

По итогам совместной проработки обнаружили, что проблема была в пересекающихся адресах секций .bss и .sbss: Вот начало секции .bss: Disassembly of section .bss: 80004028 <testcnt>: 80004028: 00000000 nop А вот – секция sbss: Disassembly of section .sbss: 80004038 <_edata>: 80004038: 00000000 nop Переменные, находящиеся в разных секциях, имели одинаковые адреса. Из-за этого и портились те переменные, которые не ожидались. Само же пересечение секций было вызвано ошибкой в скрипте линковки: .data : { __data_start = . ; /* .eh_frame = .; */ _edata = .; } > sdram_c .bss ADDR (.data) + SIZEOF (.data) (NOLOAD) : { __bss_start = .; . = ALIGN (64 / 8); } > sdram_c Секция же sbss ставится линковщиком сразу после .data, без указания в скрипте линковки. Для решения проблемы оказалось достаточно изменить объявление секции bss: .data : { __data_start = . ; /* .eh_frame = .; */ _edata = .; } > sdram_c .bss (NOLOAD) : { __bss_start = .; . = ALIGN (64 / 8); } > sdram_c

Ну, как минимум навскидку ничего критичного в коде нет. Так что надо смотреть настройки размещения в памяти.

Судя по приведенным кускам дизассемблера в конце, тут вопрос не к процессору, а к компоновке программы. Потому что обе записи происходят по адресу (0x8002_0000-10440). По какой-то причине при сборке обоим символам назначаются одинаковые адреса. Процессор лишь исправно выполняет запись по неправильно указанному адресу, что в симуляторе, что на живом чипе :) Я бы сказал, что MAP-файл тут малоинформативен. Можете дать ELF-файл или (лучше) проект целиком? Можно на [email protected].

1) Значение указателя стека в пределах, но как-то очень уж маленькое. Верхушка стека, выходит, 0x9802_0000, а указатель сдвинут на 0x18 байт. Маловато как-то. Вход в каждую функцию сдвигает указатель стека еще немного вниз относительно верхушки. Если исключение происходит, когда мы находимся в main(), то выглядит нормой, а если хоть немного "глубже" в функциях - то уже нет. Пока выглядит лишним аргументом в пользу некорректного восстановления контекста. Можно поставить точки останова перед сохранением и после восстановления контекста, убедиться, что значение sp не меняется. Ну и надо понять, какое штатное значение указателя стека при штатном входе в функцию, из которой происходит исключение. 2) По логу сборки вроде особо нечего пока сказать. 3) По коду после ERET - штатно он действительно не исполняется. Введён из каких-то соображений, которые сейчас нет смысла уточнять, а навскидку вспомнить не получается. Это скорее всего никак не связано с обсуждаемой проблемой.

Тут сложный момент. С одной стороны, правильнее сохранять все регистры. С другой стороны, кэш надо сбрасывать сразу при входе в обработчик. Здесь нам на помощь приходит MIPS ABI (application binary interface) - соглашение, по которому регистры k0, k1 используются именно что в обработчиках, а в основной программе не используются. Поэтому мы вроде бы безбоязненно можем "портить" эти регистры. По факту GCC по умолчанию это требование не выполняет и вполне может использовать эти регистры. Чтобы он этого не делал, есть ключ -ffixed. В наших проектах для MCStudio 4 как раз по умолчанию выставлены ключи GCC " -ffixed-k0 -ffixed-k1". Возможно, их по какой-то причине нет в Вашем проекте? Покажете лог сборки на всякий случай? Еще как вариант - может, просто где-то что-то не так с сохранением и восстановлением стека? В какой-то момент он сдвигается за границы допустимого и все портится? Или, совсем уж простое - размер стека физически "вылезает" за границы доступной физически памяти? Чему равно значение sp в момент исключения? Чему равно значение символа _stack и размер стека в настройках проекта? В функции действительно ничего криминального нет.

1) Включено ли кэширование в Вашем проекте? Если включено - то сбрасывается ли кэш в обработчике прерываний? 2) Вероятно, стоит сразу указывать, какое значение у регистра CP0.EPC при возникновении исключения? Что за код находится по этому адресу?

Добрый день! Спасибо коллегам, которые помогли решить проблему до нашего участия. Выглядит так, что проблема была действительно связана с выравниванием стека. Мы обновим процедуру сохранения контекста в наших примерах, спасибо за указание на проблему. Предполагаемый обновленный обработчик прилагаем. Там также добавлен сброс кэша, сохранение части регистров CP0 и некоторые другие вещи. Если планируется работать с float/double - нужно также сохранять в обработчике регистры FPU. Пока мы этого не добавили в обработчик, чтобы не перегружать его. Возможно, добавим. Если кому-то интересна причина, почему сейчас такое сохранение контекста в примерах, то даём пояснение: он создавался достаточно давно, когда в наших чипах CPU-ядро не имело сопроцессора FPU. Соответственно, у CPU не было 64-разрядных обращений в память, только 32-разрядные (инструкции LW/SW) - и выравнивания по 32-разрядному слову было достаточно. С появлением FPU появились 64-разрядные обращения (SDC1/LDC1) - появилась необходимость выравнивать стек по границе 64-разрядного слова. Но поскольку примеры в составе IDE демонстрируют узконаправленную работу с конкретным блоком - в примерах этой проблемы не всплывало. Теперь обновим, еще раз спасибо за указание на проблему. hb80000180.s

При запуске U-Boot (начиная с версии v2017.07.0.7) останавливает ядро CPU1 и отключает его домен питания. Предполагается, что U-Вoot загружает приложение используя только одно ядро CPU. Само приложение может включить домен питания и использовать второе ядро. Вы можете доработать U-Вoot так, чтобы он запускал baremetal-приложение на ядре CPU1. Штатно такой возможности нет. Для добавления такой возможности необходимо разработать отдельный драйвер. На данный момент ведётся разработка драйвера Linux для DSP-кластера DELcore-30M. Драйвер позволит запускать задачи на DSP-ядрах и получать результаты в user space. Доступ к регистрам разрешен из ядра Linux (kernel space). Можно реализовать в драйвере мапировние регистров в пользовательское пространство. Такой подход не рекомендуется, т.к. некорректная работа пользовательского приложения может нарушить работоспособность всей системы.

Для этого существует параметр запуска ядра nosmp. Тут возможны два варианта: 1.Можно ограничить использование памяти (SDRAM) с помощью параметра запуска ядра mem=; 2. Можно использовать другой тип памяти (SRAM) для второго ядра. Во втором случае необходимо будет настроить блок NORMPORT микросхемы 1892ВМ14Я в загрузчике U-boot. Для этой цели можно использовать блок Mailbox микросхемы 1892ВМ14Я. Не понятно о каких регистрах идет речь. Описанный Вами режим работы потребует существенной доработки загрузчика U-boot. При разработки baremetal-приложения следует учесть тот факт, что контроллер прерываний (GIC) общий для двух ARM-ядер.

Да. В составе демо-версии IDE MCStudio 4 для ОС Linux (CentOS 7). Также toolchain для DSP-ядра ELcore-30M доступен отдельно: ftp://ftp.elvees.com/1892VM14YA/Baremetal/Tools/Linux/eltools_3.6_linux_5519_2017.04.03.tar.gz

Добрый день! Рекомендуем ориентироваться на микросхему 1892ВМ15АФ. Информация по ней представлена здесь - http://multicore.ru/index.php?id=1340 Информация по отладочному модулю для нее здесь - http://multicore.ru/index.php?id=1405 Линейка радстойких микросхем в целом представлена здесь - http://multicore.ru/index.php?id=556 В целом по рынку радстойких микросхем у нас очень конкурентоспособные цены. Для уточнения подробностей рекомендуем обратиться в отдел продаж – [email protected]. В микросхемах НПЦ «ЭЛВИС» есть и CPU-ядро (в радстойких это MIPS32-совместимое ядро), и высокопроизводительные DSP-ядра. DSP-кластер DELcore-30MH в составе 1892ВМ15АФ не имеет ограничений по доступу к памяти и другим ресурсам микросхемы. Если под «ISA» имеется в виду система команд – то наши ядра описанию соответствуют. Имеющиеся ограничения приведены в документации. Это не так. Существует достаточно много применений, где использован оригинальный код, написанный нашими пользователями самостоятельно. Компилятор Си для DSP-ядер есть. Доступен свободно в составе демо-версий среды разработки на сайте - http://multicore.ru/mc/software/MCStudio3M_Demo_Setup.exe Мы заинтересованы в увеличении количества разработчиков, работающих с нашими микросхемами. Для этого мы максимально документируем наши микросхемы, проводим курсы и семинары, сотрудничаем с университетами и авторами независимых курсов, и стараемся отвечать на все запросы, поступающие в техподдержку. another_one, Вы также можете обратиться на [email protected] с более подробным описанием задачи, мы постараемся подсказать, как ее можно решить с применением наших микросхем.

Можно включить в состав ядра файловую систему в виде диска c файловой системой в ОЗУ. Сделать это можно в конфигураторе ядра Linux (make menuconfig). Там же указывается путь до каталога с rootfs.

Нет, утилита mcom_flash_mmc.py не подходит для прошивки NAND-Flash. Инструкция по прошивке NAND-Flash представлена в п.5.3.1. документа "Загрузчик U-Boot для 1892ВМ14Я. Руководство пользователя". Настройку TFTP Вы выполняете правильно. В U-Boot 2017.07.0.14 (из Buildroot v.2.9) возникает ошибка при загрузке через TFTP. Ошибка будет исправлена в следующих выпусках дистрибутива Buildroot. Если Вам требуется загрузка по TFTP, рекомендуем Вам использовать Buildroot v.2.8 и соответствующий загрузчик U-Boot.

mmc0 это микросхема eMMC, установленная на процессорном модуле Салют-ЭЛ24ПМ2. Для этого можно использовать утилиту mcom02_flash_mmc.py из пакета mcom02-flash-tools. Ссылка на github: https://github.com/elvees/mcom02-flash-tools Ссылка на дистрибутив: ftp://ftp.elvees.com/1892VM14YA/linux/Buildroot/v2.9/mcom02-buildroot-v2.9.0-2018-09-21.tar.bz2 . Путь относительно корня архива: Процесс установки данного пакета в Windows описан в п.3 документа «Инструкция по прошивке SPI флеш-памяти модулей на базе 1892ВМ14Я». В ОС Linux пакет Python 2.7 обычно уже установлен. Необходимо выполнить одно из предложенных ниже действий: pip install --upgrade <mcom02_flash_tools> для установки из распакованного архива, где <mcom02_flash_tools> — путь к архиву пакета или директории, содержащей распакованный пакет. pip install --upgrade git+https://github.com/elvees/mcom02-flash-tools.git для установки из репозитория на github. При работе в OC Windows путь установки python/имя пользователя/имя компьютера не должны содержать кириллических символов. После установки пакета необходимо: Прошить на SD-карту образ ftp://ftp.elvees.com/1892VM14YA/linux/Buildroot/v2.9/mcom02-buildroot-sdcard-v2.9.0-2018-09-21.img.gz или аналогичный, если используется дистрибутив Buildroot версии отличной от 2.9. Процесс записи образа на SD-карту в ОС Linux описан в п.6 документа «Дистрибутив ОС GNU/Linux на базе Buildroot для 1892ВМ14Я.Руководство системного программиста». Запись образа SD-карты в ОС Windows можно выполнить с помощью программы Win32DiskImager (https://sourceforge.net/projects/win32diskimager/). Необходимо использовать загрузчик U-boot с версией, соответствующей версии используемого дистрибутива. Выполнить загрузку ОС с SD-карты: Установить джампер XP4 в положение "uSDcard"; Установить переключатели BOOT (SA1) в положение «011» (загрузка из SPI-Flash); Подключить разъем XS13 к ПЭВМ c помощью кабеля MiniUSB-USB; Запустить терминал COM-порта; Подать питание на отладочный модуль; Остановить автозагрузку U-Boot отправкой любого символа в терминал COM-порта; Выполнить команды: env set mmcdev 1 //устанавливаем загрузку и импорт переменных окружения с SD-карты; saveenv //Сохраняем изменения 8. Перезагрузить отладочный модуль. Прошить необходимый образ SD-карты в eMMC (mmc0) c помощью утилиты mcom02_flash_mmc.py. 1. Подключить отладочный модуль к сети; 2. Подать питание на отладочный модуль; 3. Дождаться появления запроса входа в систему в терминале COM-порта; 4.На ПК запустить процесс прошивки eMMC: mcom_flash_mmc.py <bord ip or host name > </dev/ mmcblk0> <path to img> , где <bord ip or host name > - ip-адрес или сетевое имя отладочного модуля; </dev/ mmcblk0> - имя устройства, в которое будет записан образ. В Вашем случае необходимо использовать /dev/ mmcblk0 т.е. eMMC; <path to img> - путь до образа SD-карты, который необходимо прошить в eMMC. 5. Дождаться окончания процесса прошивки (Verifying... ОК). Проверить работоспособность записанного образа: 1. Выполнить перезагрузку отладочного модуля; 2.Остановить автозагрузку U-Boot отправкой любого символа в терминал COM-порта; 3. Выполнить команды: env set mmcdev 0 //устанавливаем загрузку и импорт переменных окружения с eMMC; saveenv //Сохраняем изменения 4. Перезагрузить отладочный модуль; 5.Убедиться в успешном запуске ОС с eMMC. Возникающие вопросы лучше адресовать напрямую на [email protected], чтобы сократить время ответа.

Добрый день! Оценка производительности одного DSP-ядра ELcore-30M при реализации КИХ-фильтра приведена в приложенном файле. В микросхеме 1892ВМ15АФ кластер из двух ядер ELcore-30M. Дополнительно хотелось бы отметить, что в составе микросхемы есть блок аппаратных ускорителей функций БПФ и сжатия JPEG. Описание известных ограничений отдельных блоков приведено соответствующих разделах технических описаний. Например, ограничения конвейера DSP-ядра ELcore-30M приведены в разделе 7.7 документа «DSP-КЛАСТЕР DELCORE-30М. АРХИТЕКТУРА. DSP-ЯДРО ELCORE-30М» - http://multicore.ru/mc/data_sheets/Manual_...-30M_031210.pdf Также обращаем ваше внимание на документ «Рекомендации по проектированию принципиальной электрической схемы» и другие общие документы в разделе «Техподдержка->Документация->Цифровые сигнальные процессоры» на нашем сайте. Если ответов от коллег в форуме не будет, можно обратиться за подобной информацией в ЭЛВИС. Подскажем, кто именно применял процессор. FIR_ELCore_30M.pdf