Jump to content

    

ELVEES R&D Center

Участник
  • Content Count

    50
  • Joined

  • Last visited

Community Reputation

0 Обычный

About ELVEES R&D Center

  • Rank
    Участник

Recent Profile Visitors

2103 profile views
  1. По итогам совместной проработки обнаружили, что проблема была в пересекающихся адресах секций .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
  2. Ну, как минимум навскидку ничего критичного в коде нет. Так что надо смотреть настройки размещения в памяти.
  3. Судя по приведенным кускам дизассемблера в конце, тут вопрос не к процессору, а к компоновке программы. Потому что обе записи происходят по адресу (0x8002_0000-10440). По какой-то причине при сборке обоим символам назначаются одинаковые адреса. Процессор лишь исправно выполняет запись по неправильно указанному адресу, что в симуляторе, что на живом чипе :) Я бы сказал, что MAP-файл тут малоинформативен. Можете дать ELF-файл или (лучше) проект целиком? Можно на support@elvees.com.
  4. 1) Значение указателя стека в пределах, но как-то очень уж маленькое. Верхушка стека, выходит, 0x9802_0000, а указатель сдвинут на 0x18 байт. Маловато как-то. Вход в каждую функцию сдвигает указатель стека еще немного вниз относительно верхушки. Если исключение происходит, когда мы находимся в main(), то выглядит нормой, а если хоть немного "глубже" в функциях - то уже нет. Пока выглядит лишним аргументом в пользу некорректного восстановления контекста. Можно поставить точки останова перед сохранением и после восстановления контекста, убедиться, что значение sp не меняется. Ну и надо понять, какое штатное значение указателя стека при штатном входе в функцию, из которой происходит исключение. 2) По логу сборки вроде особо нечего пока сказать. 3) По коду после ERET - штатно он действительно не исполняется. Введён из каких-то соображений, которые сейчас нет смысла уточнять, а навскидку вспомнить не получается. Это скорее всего никак не связано с обсуждаемой проблемой.
  5. Тут сложный момент. С одной стороны, правильнее сохранять все регистры. С другой стороны, кэш надо сбрасывать сразу при входе в обработчик. Здесь нам на помощь приходит MIPS ABI (application binary interface) - соглашение, по которому регистры k0, k1 используются именно что в обработчиках, а в основной программе не используются. Поэтому мы вроде бы безбоязненно можем "портить" эти регистры. По факту GCC по умолчанию это требование не выполняет и вполне может использовать эти регистры. Чтобы он этого не делал, есть ключ -ffixed. В наших проектах для MCStudio 4 как раз по умолчанию выставлены ключи GCC " -ffixed-k0 -ffixed-k1". Возможно, их по какой-то причине нет в Вашем проекте? Покажете лог сборки на всякий случай? Еще как вариант - может, просто где-то что-то не так с сохранением и восстановлением стека? В какой-то момент он сдвигается за границы допустимого и все портится? Или, совсем уж простое - размер стека физически "вылезает" за границы доступной физически памяти? Чему равно значение sp в момент исключения? Чему равно значение символа _stack и размер стека в настройках проекта? В функции действительно ничего криминального нет.
  6. 1) Включено ли кэширование в Вашем проекте? Если включено - то сбрасывается ли кэш в обработчике прерываний? 2) Вероятно, стоит сразу указывать, какое значение у регистра CP0.EPC при возникновении исключения? Что за код находится по этому адресу?
  7. Добрый день! Спасибо коллегам, которые помогли решить проблему до нашего участия. Выглядит так, что проблема была действительно связана с выравниванием стека. Мы обновим процедуру сохранения контекста в наших примерах, спасибо за указание на проблему. Предполагаемый обновленный обработчик прилагаем. Там также добавлен сброс кэша, сохранение части регистров CP0 и некоторые другие вещи. Если планируется работать с float/double - нужно также сохранять в обработчике регистры FPU. Пока мы этого не добавили в обработчик, чтобы не перегружать его. Возможно, добавим. Если кому-то интересна причина, почему сейчас такое сохранение контекста в примерах, то даём пояснение: он создавался достаточно давно, когда в наших чипах CPU-ядро не имело сопроцессора FPU. Соответственно, у CPU не было 64-разрядных обращений в память, только 32-разрядные (инструкции LW/SW) - и выравнивания по 32-разрядному слову было достаточно. С появлением FPU появились 64-разрядные обращения (SDC1/LDC1) - появилась необходимость выравнивать стек по границе 64-разрядного слова. Но поскольку примеры в составе IDE демонстрируют узконаправленную работу с конкретным блоком - в примерах этой проблемы не всплывало. Теперь обновим, еще раз спасибо за указание на проблему. hb80000180.s
  8. При запуске U-Boot (начиная с версии v2017.07.0.7) останавливает ядро CPU1 и отключает его домен питания. Предполагается, что U-Вoot загружает приложение используя только одно ядро CPU. Само приложение может включить домен питания и использовать второе ядро. Вы можете доработать U-Вoot так, чтобы он запускал baremetal-приложение на ядре CPU1. Штатно такой возможности нет. Для добавления такой возможности необходимо разработать отдельный драйвер. На данный момент ведётся разработка драйвера Linux для DSP-кластера DELcore-30M. Драйвер позволит запускать задачи на DSP-ядрах и получать результаты в user space. Доступ к регистрам разрешен из ядра Linux (kernel space). Можно реализовать в драйвере мапировние регистров в пользовательское пространство. Такой подход не рекомендуется, т.к. некорректная работа пользовательского приложения может нарушить работоспособность всей системы.
  9. Для этого существует параметр запуска ядра nosmp. Тут возможны два варианта: 1.Можно ограничить использование памяти (SDRAM) с помощью параметра запуска ядра mem=; 2. Можно использовать другой тип памяти (SRAM) для второго ядра. Во втором случае необходимо будет настроить блок NORMPORT микросхемы 1892ВМ14Я в загрузчике U-boot. Для этой цели можно использовать блок Mailbox микросхемы 1892ВМ14Я. Не понятно о каких регистрах идет речь. Описанный Вами режим работы потребует существенной доработки загрузчика U-boot. При разработки baremetal-приложения следует учесть тот факт, что контроллер прерываний (GIC) общий для двух ARM-ядер.
  10. Да. В составе демо-версии 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
  11. Добрый день! Рекомендуем ориентироваться на микросхему 1892ВМ15АФ. Информация по ней представлена здесь - http://multicore.ru/index.php?id=1340 Информация по отладочному модулю для нее здесь - http://multicore.ru/index.php?id=1405 Линейка радстойких микросхем в целом представлена здесь - http://multicore.ru/index.php?id=556 В целом по рынку радстойких микросхем у нас очень конкурентоспособные цены. Для уточнения подробностей рекомендуем обратиться в отдел продаж – market@elvees.com. В микросхемах НПЦ «ЭЛВИС» есть и CPU-ядро (в радстойких это MIPS32-совместимое ядро), и высокопроизводительные DSP-ядра. DSP-кластер DELcore-30MH в составе 1892ВМ15АФ не имеет ограничений по доступу к памяти и другим ресурсам микросхемы. Если под «ISA» имеется в виду система команд – то наши ядра описанию соответствуют. Имеющиеся ограничения приведены в документации. Это не так. Существует достаточно много применений, где использован оригинальный код, написанный нашими пользователями самостоятельно. Компилятор Си для DSP-ядер есть. Доступен свободно в составе демо-версий среды разработки на сайте - http://multicore.ru/mc/software/MCStudio3M_Demo_Setup.exe Мы заинтересованы в увеличении количества разработчиков, работающих с нашими микросхемами. Для этого мы максимально документируем наши микросхемы, проводим курсы и семинары, сотрудничаем с университетами и авторами независимых курсов, и стараемся отвечать на все запросы, поступающие в техподдержку. another_one, Вы также можете обратиться на support@elvees.com с более подробным описанием задачи, мы постараемся подсказать, как ее можно решить с применением наших микросхем.
  12. Можно включить в состав ядра файловую систему в виде диска c файловой системой в ОЗУ. Сделать это можно в конфигураторе ядра Linux (make menuconfig). Там же указывается путь до каталога с rootfs.
  13. Нет, утилита 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.
  14. 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. Возникающие вопросы лучше адресовать напрямую на support@elvees.com, чтобы сократить время ответа.
  15. Добрый день! Оценка производительности одного 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