Jump to content

    
Sign in to follow this  
Barbarossa

Quartus 19.1 под Windows - у кого-нибудь нормально работает?

Recommended Posts

Приветствую, спрошу здесь, ибо грабли, видимо, те же.

Поставил версию 20.1 и, вроде бы, всё что надо дополнительно, включая эклипсу, WSL+Ubuntu 18.04. Пытаюсь для проверки реанимировать проект с НИОС, который был сделан в 18.1 в январе 2019г.

Компиляция, конечно, сразу наткнулась на увядший за год НИОС (если кто-то даст свежие ключики, буду рад), но это пол дела. Странно, но автоматом платформ-дизайнер не обновил систему, хотя вручную регенерировал без моего участия. А далее я перешёл к софту. Проекты BSP и приложения создал заново, иначе не компилировались (но это, вроде, как и обещали). После этого BSP собрался без проблем, а вот проект приложения не собирается. Чего-то не хватает, каких-то путей или ещё чего? Лог в эклипсе такой:

Quote

wsl make all
wslpath: hal_bsp: No such file or directory
Info: Building /mnt/d/Projects/PLM/Altera/niosprog/software/Board_bsp/
make --no-print-directory -C /mnt/d/Projects/PLM/Altera/niosprog/software/Board_bsp/
[BSP build complete]
Info: Linking CountBinary.elf
nios2-elf-g++.exe  -T'D:/Projects/PLM/Altera/niosprog/software/Board_bsp/linker.x' -msys-crt0='D:/Projects/PLM/Altera/niosprog/software/Board_bsp/obj/HAL/src/crt0.o' -msys-lib= -LD:/Projects/PLM/Altera/niosprog/software/Board_bsp   -Wl,-Map=CountBinary.map   -O0 -g -Wall   -mno-hw-div -mhw-mul -mno-hw-mulx -mgpopt=global  -o CountBinary.elf obj/default/count_binary.o -lm -msys-lib=m
nios2-elf-g++.exe: error: missing argument to '-msys-lib='
make: *** [CountBinary.elf] Error 1
Makefile:1010: recipe for target 'CountBinary.elf' failed

Система 2004. Ubuntu в ней запускается без проблем. Смонтированный путь /mnt/d/Projects/PLM/Altera/niosprog/software/Board_bsp/ верный. Непонятно какой путь компилятор не видит.

Ещё непонятно, какую версию WSL надо было ставить, 1 или 2? Я поставил пока версию 1.

Ещё нашёл настройку "Linux Tools Path", которая стоит в "Использовать системный путь", но где такой путь я не знаю. В переменных окружения не нашёл.

Share this post


Link to post
Share on other sites
19 часов назад, Dimonira сказал:

Нашёл решение здесь.

Хм... А у меня и с родным Makefile все собирается...

Проблема под виндами  в другом - создаются ли у Вас hex-файлы при выполнении  mem_init_generate?

Мне это побелить не удалось. Под виндами откатился на v18.1.1, а v20.x использую под линуксом.

Share this post


Link to post
Share on other sites
6 hours ago, StewartLittle said:

Хм... А у меня и с родным Makefile все собирается...

Проблема под виндами  в другом - создаются ли у Вас hex-файлы при выполнении  mem_init_generate?

Мне это побелить не удалось. Под виндами откатился на v18.1.1, а v20.x использую под линуксом.

Про mem_init_generate не скажу, не использую пока. У меня проблема в том, что не работают никакие ехе-шники из папки nios2eds\bin, которые теперь сделаны под винду. Из-за этого не работает nios2-flash-programmer-gui.exe. Причём он ничего плохого не сообщает, просто не делает никаких файлов кроме скрипта. Например, sof2flash.exe пишет такое:

Quote

sof2flash --input="D:/Projects/PLM/Altera/niosprog/output_files/niosprog.sof" --output="D:/Projects/PLM/Altera/niosprog/flash/niosprog_epcs_flash.flash" --epcs
07.09.2020 18:11:25 - (SEVERE) sof2flash: failed while launching conversion utilities.
07.09.2020 18:11:25 - (SEVERE) sof2flash: Error creating intermediate files, exiting

В чём конкретно проблема не ясно, в лицензии или в чём-то другом. На форумах интела видел, что такое может быть и-за несоответствия версии формата .sof файла и версии самой утилиты sof2flash. Сделал в 20.1 проект с нуля - не помогло.

Share this post


Link to post
Share on other sites
5 часов назад, Dimonira сказал:

Из-за этого не работает nios2-flash-programmer-gui.exe.

Нынче пользоваться ниосовским флэшпрограммером не кошерно :)

Теперь нужно делать так:

  • использовать в qsys'е (или как он там сейчас называется - Platform Designer'е) модуль epcq_controller2,
  • в настройках процессора вектор сброса указывать на этот контроллер, причем обязательно со смещением, большим чем размер битстрима для ПЛИС,
  • в NiosII SBT правильно настроить bsp, скомпилировать код и выполнить mem_init_generate (в соответствующей папке повится файл epcq_conteoller2.hex),
  • в квартусе запустить Convert Programming File и сделать jic из sof'а и полученного в предыдущем пункте hex'а (правлитное смещение hex'а подставиться автоматически - это моно рссматривать, как своеобразную проверку),
  • прошить конфигуратор полученным jic'ом при помощи квартусовского программера.

Я здесь, ЕМНИП, про это уже докладывал.

 

Цитата

07.09.2020 18:11:25 - (SEVERE) sof2flash: failed while launching conversion utilities.

Вот-вот, оно самое. Не работают эти exe-шники под WSL. Про это я тоже здесь уже писал, не так давно.

Причем Intel'у об этой проблеме известно, в KDB он рекомендует запускать exe-шники вручную из-под шелла. Только при этом они все равно не работают.

Потому-то я переполз под Linux сo Standard v19.x/v20.x - под Linux в этих версиях все работает, как положено.

 

P.S. Ну или под виндами -  забить на v19.x/v20.x и откатиться на v18.1 (там cygwin, и все работает, как и раньше).

Тем более, что в v19.x/v20.x относительно v18.1 никаких улучшений нет. Скорее даже наоборот - в новых версиях Standard убрали несколько полезных опций (DSP Builder, HLS, OpenCL).

Share this post


Link to post
Share on other sites

Кое с чем разобрался в 20.1. Программы из nios2eds\bin (в частности, sof2flash и elf2flash) заработали в этих условиях:

- запускать надо было из 'Nios II Command Shell' (в эклипсе на проекте приложения->Nios II->Nios II Command Shell)

- запускать надо было, обязательно добавив в имя .exe (об этом и в quartus_install.pdf написано, в начале стр.7)

Типа такого:

Quote

sof2flash.exe --input=niosprog.sof --output=niosprog.flash --epcs --verbose

Кроме того, у меня возникло подозрение, что Flash Programmer (nios2eds\sdk2\bin\nios2-flash-programmer-gui.exe) не работает по той же причине - в логе команд, которые он готовит внутри себя для запуска, как раз не добавлено .exe. Более детально с ним пока не разбирался.

Но в итоге, когда я подготовил и прошил .jic по аналогии с тем, как я его делал в 18.1, проект не заработал (не стартует). По сравнению со старым, приложение стало на 4588 байт больше. Возможно, я о чём-то забыл и не так сделал. Если в 20.1 прошить старый .jic, то всё работает. Буду пробовать на чистом проекте (это был обновлённый из 18.1).

19 minutes ago, StewartLittle said:

Нынче пользоваться ниосовским флэшпрограммером не кошерно :)

Теперь нужно делать так:

  • использовать в qsys'е (или как он там сейчас называется - Platform Designer'е) модуль epcq_controller2,
  • в настройках процессора вектор сброса указывать на этот контроллер, причем обязательно со смещением, большим чем размер битстрима для ПЛИС,
  • в NiosII SBT правильно настроить bsp, скомпилировать код и выполнить mem_init_generate (в соответствующей папке повится файл epcq_conteoller2.hex),
  • в квартусе запустить Convert Programming File и сделать jic из sof'а и полученного в предыдущем пункте hex'а (правлитное смещение hex'а подставиться автоматически - это моно рссматривать, как своеобразную проверку),
  • прошить конфигуратор полученным jic'ом при помощи квартусовского программера.

Я здесь, ЕМНИП, про это уже докладывал.

Спасибо, посмотрю. На моей платке EPCS4.

Share this post


Link to post
Share on other sites
3 hours ago, StewartLittle said:

Теперь нужно делать так:

  • использовать в qsys'е (или как он там сейчас называется - Platform Designer'е) модуль epcq_controller2,
  • в настройках процессора вектор сброса указывать на этот контроллер, причем обязательно со смещением, большим чем размер битстрима для ПЛИС,
  • в NiosII SBT правильно настроить bsp, скомпилировать код и выполнить mem_init_generate (в соответствующей папке повится файл epcq_conteoller2.hex),
  • в квартусе запустить Convert Programming File и сделать jic из sof'а и полученного в предыдущем пункте hex'а (правлитное смещение hex'а подставиться автоматически - это моно рссматривать, как своеобразную проверку),
  • прошить конфигуратор полученным jic'ом при помощи квартусовского программера.

А не растолкуете, зачем в целевой проект добавлять epcq_controller2 (если, например, не нужно ничего читать в основном рабочем режиме из EPCQ)? Когда пользуешься ниосовским флэшпрограммером - это понятно (можно воспользоваться целевым проектом в качестве проекта-прошивальщика, которым будет управлять ниос флэшпрограммер). А при использовании jic зачем? Все равно квартус программер будет шить его с помощью загружаемого собственного проекта-прошивальщика. Или я чего-то не понимаю?

Share this post


Link to post
Share on other sites
6 часов назад, Raven сказал:

А не растолкуете, зачем в целевой проект добавлять epcq_controller2 (если, например, не нужно ничего читать в основном рабочем режиме из EPCQ)? Когда пользуешься ниосовским флэшпрограммером - это понятно (можно воспользоваться целевым проектом в качестве проекта-прошивальщика, которым будет управлять ниос флэшпрограммер). А при использовании jic зачем? Все равно квартус программер будет шить его с помощью загружаемого собственного проекта-прошивальщика. Или я чего-то не понимаю?

epcq_controller2 и jic - это гвозди от разных стенок.

epcq_controller2 нужен в разных случаях:

  • Например, если сегмент исполняемого кода расположен во внешнем ОЗУ, и это ОЗУ нужно проинициализировать при включении питания.
  • Или, если хочется исполнять код непосредственно их конфигурационного ПЗУ.
  • Ну или если хочется использовать конфигуратор как энергонезависимую память для храниния каких-либо данных приложения.

Использование в проекте epcq_controller2 не имеет никакого отношения к jic'у.

 

А использование jic'а в данном контексте позволяет забить на nios_flash_programmer (со всеми его глюками).

 

P.S. Вот здесь я докладывал про проблему работы с ниосом под wsl: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=157679&tab=comments#comment-1703505

 

 

11 часов назад, Dimonira сказал:

Но в итоге, когда я подготовил и прошил .jic по аналогии с тем, как я его делал в 18.1, проект не заработал (не стартует). По сравнению со старым, приложение стало на 4588 байт больше. Возможно, я о чём-то забыл и не так сделал.

Проверьте настройки hal.linker  в bsp (allow_code_at_reset, enable_alt_load и т.п.).

Вот моя переписка по поводу старта из ниоса из коефигуратора:

nios_epcq_start.txt

Share this post


Link to post
Share on other sites

Поставил 18.1.1, но криво генерируется проект эклипсы из шаблона (в 18.1.0 такого не было). Генерация проектов не доходит до конца - валится с сообщением о невозможности доступа к Makefile проекта CountBinary. Так что скрипт создания проекта CountBinary прерывается. Дальше компиляция проекта BSP проходит успешно, а CountBinary выдаёт сообщение:

Quote

make all
Cannot run program "make": Launching failed

Error: Program "make" not found in PATH

Я посмотрел, оказывается у папки проекта CountBinary создаются кривые права доступа. В результате файл Makefile "занят другим процессом" и доступа к нему нет. Права то поправить можно (включив наследование от папки выше), но проект кривой. Как запустить скрипт create-this-app? Хотя, это же он создаёт кривизну. Как-то это лечится?

Проверил на втором компе - то же самое.

 

Нашёл решение здесь . Обалдеть, предлагается использовать 18.1.0, т.е. не обновлять.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this