R6L-025

Тоже натыкался на эту проблему. Я в тот момент только один выход нашел - эвакуировать исходники, удалить проект, создать заново, перенсти исходники в него. Это косяк самой IDE, по видимому. Что-то в какой-то произвольный момент там ломается и все перестает работать. Еще один вариант - отказаться от эклипса совсем. Не помню сейчас уже детали, но получилось повыковыривать из эклипса отдельные скрипты которые тот вызывал, и использовать их отдельно. Собирать проекты кастомным makefile, дебаджить через ручной запуск gdb. Вот в таком варианте больше ничего не падало.

знака "=" не должно быть, и ";" в конце тоже уберите. Ну и путь в `include <...> должен быть понятным синтезатору. В квартусе у меня пути идут относительно директории где лежит файл проекта квартуса

Так инклюдами же. Они в обычном Verilog есть. В файле через define определяем параметры, например, `define MY_DEF 42, и инклюдим через `include "path/to//file"

Сделать обычный файл с объявлением парметров и заинклюдить его в нужных местах. На SV я в отдельном файле package делал и так же подключал через import в нужных файлах

EMIO просто будут торчать портами из PS в PL, ну то что к ним подключается будет доступно сразу как загрузится PL часть. Ибо до этого это будет шиной ведущей в пустоту, т.к. битстрим еще не залит. Или не в этом был вопрос?

Я с 7000 не работал, но у MPSoC есть такой скрипт: Vitis/2020.2/scripts/vitis/util/zynqmp_utils.tcl. В нем есть функции типа "clear_rpu_reset". Я ими ресетил R5 ядро на MPSoC. P.S. попробуй еще спросить тут: https://t.me/fpgasystems_embd

Кстати, к слову. Есть вот такая интересная статья на тему реверс инженеринга программатора от Digilent An_Example_of_PCB_Reverse_Engineering_Reconstruction_of_Digilent.pdf

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

Вот. Правда там с цветами немного беда из-за того что у меня цветовая схема темная, а лист получился белым при печати в pdf. Брал основой для схемы реализацию встроенного программатора на zcu104 (US+ mpsoc). Проект в kicad делал, скинул бы его, но там зависимости от библиотек которые я куда-то засунул. Сейчас немного нет времени искать, но если кому-то понадобится, то по факту попробую раскопать. ftdi_programmer.pdf

Понятно. Ну, схему я уже откуда-то передрал, Даже собрал и на виваде работает. Если надо - могу скинуть. На счет старой вивады/ISE... может старые софтины не знают об этой лицензии. Тогда надо с более старых программаторов снимать дампы

Так заработало после замены порядка байт? Я не помню как именно этот бинарник снимал, может перепутал чего. Я эксперементировал, и может не тот файл приложил... даже не знаю. Попробуйте этот бинарник digilent_jtag_uart.bin Кстати, я только под VIvado проверял, может на ISE что-то по другому

В linux дистрах есть утилита "ftdi_eeprom". Я через нее клонировал. Про виндовозную официальную от ftdi говорят что вроде как повреждает память при чтении. С линуховой не замечал такого

Ну еще есть старый сишный трюк когда после крайнего полезного элемента перечисления вставляется еще один. Т.к. перечисление стартует с 0, то номер этого последнего элемента будет равен количеству всех элементов. Т.е. [Num0, Num1, CounOfNums]. CounOfNums будет равен 2. Что и нужно

Я не под Ubuntu, под Arch с ним работал - иногда после перетыкивания программатора он перестал определятся, тогда помогало перезапустить вручную jtagserver pkill jtagd jtagconfig Помогало. Может еще частоты jtag стоит покрутить. Ну и перенос с одной системы на другую без пересборки... На стабильность прошивки то не должно влиять, но мало-ли что там может из-за этого быть

А нет возможности прокинуть их через PL часть?

Есть под рукой плата Digilent genesysZU, там стоит 4232 камень. Схема На плату упоротая, и куска с ftdi я вообще не нашел. Но судя по FT_prog там 2 uart'а и кроме jtag еще один порт с кастомной конфигурацией. eeprom.bin ftdi_prog_template.xml

Давно дело было, всего не помню, но - когда надо было прописать клок, то обычно не вдавался в детали присвоения имен альетры, а тупо копировал путь из timeQuest или SignalTap. Там в фильтре можно задать маску имени, например, my_pll. В выхлопе программы поиска выбрать соответствующие пути до самих клоков. Не вдаваясь в детали имен

Можно. с IP ядрами так иногда и происходит, что они написаны на verilog, но подключаются к vhdl и т.п. Главное с ширинами портов не перепутать ничего

Например, берем фал *.v сгенеренный megawizrd. Он начинаться будет как-то так: `timescale 1 ps / 1 ps module alterapll_fd ( input wire refclk, // refclk.clk input wire rst, // reset.reset output wire outclk_0, // outclk0.clk output wire locked // locked.export ); Берем имя модуля "alterapll_fd", его порты, и пишем такой instance в твоем top модуле: alterapll_fd alterapll_fd_inst ( .refclk (in_clock ), .rst (in_reset ), .outclk_0 ( ), .locked (out_lock ) ); Имя "alterapll_fd_inst" это имя экземпляра модуля (оно должно быть уникальным, по крайней мере в пределах модуля). Сигналы в скобках должны быть объявлены, и первые два иметь источники. Ну а третий, собственно, выход pll.

Да про ОЗУ то знает. Я имел в виду память доступную по i2c и т.д. Но, как потом понял - fsbl это просто некоторый код для APU/RPU под baremetall. И если позволяет размер исходника (он из TCM, кажется, работает, а она не большая по объему) - то можно что угодно написать. Было бы желание писать самому, или готовые baremetall драйвера для внешней памяти типа i2c/qspi и т.п.

Спасибо, интересная штука - baikal. А Вы его как используете, для сборка метрик производительности? На счет openAMP, libmetal - конечно интересно было бы посмотреть что там не так. Я дней пять убил на то чтоб запустить libmetal-echo из из UG. Не вышло. openAMP как-то сразу заработал, но там, судя по документации ограничение на размер пакета 512 byte. Пока что пришел к тому что забил на эту пару, и сел писать свой драйвер для управления со стороны APU модулем IPI. Но, было бы интересно посмотреть что за баг в openAMP/libmetal

Благодарю! Посмотрю. Вспоминал про openOCD, но не думал что он будет тут работать

UPD: нашел строчку в главе про IPI из TRM про то что да, каналы могут использоваться как и кем угодно, кроме 4х каналов жестко привязанных к PMU. Но почему не работает всеравно не понятно

Всем доброго времени суток! Проблема - надо поднять взаимодействие между ядрами APU и RPU. На первой группе Linux, на второй - freeRTOS. Пробовал запустить example openAMP, залить через remoteproc эльфа - все работает. Но хочется заиспользовать libmetal. А вот тут оказалось все сложнее. Собираю примеры из ug1186 (Libmetal and OpenAMP UG). При попытке запуска приложения тестирования под linux вываливаются ошибки типа "VFIO: No IOMMU group for device". До этого vfio жаловался на отсутствие драйвера reset'a, но получилось подавить это через передачу нужного параметра при загрузке модуля vfio. Есть подозрение что я как-то не так настраиваю IPI в DeviceTree. В UG для приема блоком APU сообщений от RPU применяется 7 канал (адрес 0x3ed40000 выше) IPI модуля. Что мне непонятно, так это то что в документации он помечен как канал PL0, для работы с FPGA. Или же там без особой разницы кто управляет каналами, и можно использовать их по своему усмотрению? Пробовал использовать другие каналы - ничего особенного не изменилось. Никто не сталкивался с такой проблемой? Или может есть рабочие куски deviceTree с которыми нормально это все работает

А через что отлаживаете? Ну, я имею в виду что в качестве дебаг сервера используется под R5 ядрами? Я только xsct понял как приспособить. Ну и вроде как можно TCF agent отдельно прицепить, но это извращение какое-то. А я выкрутился с IDE - перенес нужные проекты под cmake (в vitis максимум сгенерить ld скрипт, и платформенные библиотеки xilinx + freertos линкуемые отдельно к cmake проекту), к нему подключаю кросс-компилятор из состава petalinux.