Jump to content

    

shurikman

Участник
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Обычный

About shurikman

  • Rank
    Участник

Контакты

  • ICQ
    Array

Recent Profile Visitors

1131 profile views
  1. Как я понял, исходный dts для кастомной платы был создан на основе keystone-k2hk-evm.dts идущим с SDK. Файл keystone-k2hk-evm.dts имеет инклюды, например: #include "keystone.dtsi" #include "keystone-k2hk.dtsi" #include "k2hk-evm-cmem.dtsi" #include "keystone-uio.dtsi" #include "k2hk-uio.dtsi" Также в этот файл были внесены правки с учетом используемых интерфейсов. Далее при сборке ядра получается один файл dts(уже с цифровыми значениями), который преобразуется в dtb. Могу приложить файл dts, получившийся после сборки ядра. Самой системой сборки не обладаю и что в итоге за dts до компиляции ядра использовался не могу сказать. Т.е. у меня есть железка на базе TCI6636K2H с работающим Linux + набор неких интерфейсов, поддерживаемых Linux. Можно ли имея что имея настроить CMEM, подстроить файл rsc_table_dsp.h под имеющуюся конфигурацию Linux.
  2. Как оказалось числовые значения там появились после компиляции ядра. В каком месте, не могу уловить вашу мысль на что обратить внимание
  3. Аааа, понял)) видимо всё таки декомпилёж, ко мне он уже попал с числовыми значениями. dmesg.txt
  4. Правится файл dts, из dts делается dtb dtc -I dts /boot/keystone-k2hk-evm.dts -O dtb -o /boot/keystone-k2hk-evm.dtb в u-boot устанавливается set name_fdt keystone-k2hk-evm.dtb далее boot и загрузка идет с использованием keystone-k2hk-evm.dtb За это не скажу, dts брался из SDK Что конкретно выводить?
  5. Это относится к примеру transportQmssDspEpK2HC66TestProject, там не получилось выделить буфер больше 4096 через HeapBufMP_create, да и скорость передачи не особо удовлетворила, даже на этом размере буфера, использовалась технология TransportQmss.
  6. Приветствую. Имеется плата на базе TCI6636K2H(ARM + DSP). На ARM крутится Linux, на DSP - SYS/BIOS. Из пакета pdk_k2hk_4_0_9 интересовали примеры для обмена между ARM и DSP в частности transportQmssDspEpK2HC66TestProject, после его допиливания обмен удалось запустить, но там есть ограничения на размер буфера. Далее в пакете processor_sdk_rtos_k2hk_4_03_00_05 перешли к примеру bigdataipc. Поправив все нужные пути и переменные окружения данный пример был собран для версии с Linux. Сразу не запустился, команда mpmcl load dsp0 server_dsp.xe66 завершалась с ошибкой, но после манипуляций из e2e пример стал грузиться. При выполнении следующей команды mpmcl run dsp0 в консоль вываливается ошибка remoteproc remoteproc0: Failed to process resources: -22. Эта ошибка является следствием рассогласования содержимого одного из следующих файлов: 1. файл dts со стороны Linux 2. файл mpm_config.json со стороны Linux 3. файл rsc_table_dsp.h со стороны DSP В файле rsc_table_dsp.h инициализируется структура ti_ipc_remoteproc_ResourceTable, которая используется при вызове команды mpmcl run dsp0 и проверяет её на соответствие первым двум файлам. Если использовать ti_ipc_remoteproc_ResourceTable по умолчанию, т.е. где не происходит выделения области CMEM для DSP, пример запускается, но падает при попытке обмена, что естественно. Привожу кусок листинга используемого файла dts: Файла mpm_config.json: Файл rsc_table_dsp.h: Файл config.bld: Адрес и размер области cmem в файле dts менял на адреса DDR, дефайны DSP_CMEM_IOBUFS, PHYS_CMEM_IOBUFS, DSP_CMEM_IOBUFS_SIZE из файла rsc_table_dsp.h делал соответствующие, но вызов команды mpmcl run dsp0 приводит к ошибке remoteproc remoteproc0: Failed to process resources: -22. Пока не могу выявить четкого соответствия между этими файлами для запуска. Может кто сталкивался, отпишитесь. Спасибо
  7. Можете кусок кода чтения/записи из убута выложить. Больше запись интересует. В автономном режиме зависает в процессе операции записи. Спасибо.
  8. Вот мой алгоритм: 1. В версии для Jtag инициализирую небольшой кусок с конца QSPI записью известной последовательности чисел. 2. Делаю версию проги, которая зашивается в QSPI для автономного запуска. Её назначение считать и проверить эти данные. При этом запись утилитой quartus_hps вроде как всю QSPI не стирает. 3. Включаю питание, загрузчик грузится, прога стартует, данные не валидны.
  9. Столкнулся со следующей проблемой. Для приема/отправки данных со стороны HPS используются соответствующие глобальные буферы. Для начала необходимо было организовать поддержку сети на уровне ответов на ARP запросы. Так вот, после формирования ARP ответа, я копирую эти данные в выходной буфер, используемый mSGDMA для отправки, но в вайшарке 0. Тормозил дебагером, буфер заполнен тем что надо. Смотрел примеры для ниоса, там обычно буфера в кеше защёлкиваются, а что в HPS делать в этом случае???
  10. По поводу автономной загрузки приложения из QSPI вопрос решился, с адресами разобрался. Но появилась потребность, помимо загрузки из QSPI, выделить, например в конце этой памяти, некую небольшую область для хранения параметров. По Jtag всё пишется и читается и данные валидные. Если по Jtag заполнить эту область тестовыми данными и в QSPI зашить программу(для автономного пуска из QSPI), которая эти данные читает, то данные получаются не валидными. Т.е. то что было записано в конец QSPI не соответсвует тому что считывается при автономном старте из QSPI. Может у кого было такое.
  11. Добавлен приём пакетов и прерывания. Немного причёсан код и разложено всё по папкам. Приём кстати работает на обоих портах, а вот отсылка только с TSE0. Будем разбираться дальше. hps_tse.rar
  12. Поставил на тест погонять. Всё таки за час в вайшарке около 20 пакетов накопилось со второго порта.
  13. В качестве кода для копипаста были выбраны исходники Linux для TSE и mSGDMA, а также исходники Modular SGDMA с altera wiki. Были перепилены функции записи/чтения в регистры под HPS. Пока работает только передача, приём будет, но позже. Особенность данной реализации подразумевает использование обоих портов(система с двумя TSE). Для теста были сгенирированы два UDP пакета с соответствующими (разными) заголовками и правильными чек суммами. Далее всё это соединил простеньким свичём с компом. Так вот, оба порта инитятся нормально, но передача идёт только с первого порта, при этом светодиод передачи на втором порту мигает, но в вайшарке пусто. Пробовал инитить только второй порт, таже ерунда(в вайшарке пусто). Пробовал без свича, напрямую в комп, тоже самое. Может есть кому что сказать? Спасибо. hps_2x_tse.rar
  14. Добрый день. Есть задача поднять на этом ките TSE под управлением HPS без Linux. Реализация стека TCP/IP не обязательна, достаточно прием/передача буфера, соединение точка-точка. Вкачестве отправной точки воспользовался похожей темой, но про Nios. С уважаемым vadimuzzz уже обсудили кое какие детали реализации задуманного. Для тех кто поднимал TSE схема вроде как понятная: TSE + 2xmSGDMA (один на прием, другой на передачу) + прерывание при приёме. Со стороны HPS добавляется LWH2F AXI мост для доступа к регистрам TSE и mSGDMA. Если есть кто прошёл этот путь, отписывайтесь, приоритет данной задачи пока высок. Постараюсь тему не бросать, а довести до конца с выкладыванием всех исходников.
  15. sonycman, спасибо. Скачал 16 версию,там есть пример Altera-SoCFPGA-HardwareLib-MPL, как раз то о чём Вы говорите. Но опять же сделал упор на прошивку QSPI из README.txt. В итоге после всех телодвижений и прошивки QSPI в консоль вывалилось следующее: INIT: MPL build: Aug 19 2016 14:22:49 INIT: Initializing board. INIT: MPU clock = 925 MHz INIT: DDR clock = 400 MHz INIT: Initializing successful. MPL: SDRAM Size is 1048576KB. MPL: Booting from QSPI. QSPI: Initializing QSPI. QSPI: Start loading image. QSPI: Image loaded successfully. MPL: SDRAM ECC Clearing is enabled. MPL: SDRAM Boot Region: 0x01000000 to 0x02000000. ERROR: Boot Image at 0x00200000+0x3d0 is outside of Boot Region. ERROR: Adjust BSP settings or re-link Application. ERROR: Error in boot process. Halting. Надо разбираться с mpl.c, т.к. эти ошибки из этого исходника (функция prepare_launch()). У Альтеры есть ещё видео на тему MPL. Вариант с SD картой пока не попробовал, но если заведется, может и останемся на нём, хотя SD карта в автономном приборе не очень хорошее решение.