Dimonira 0 6 сентября, 2020 Опубликовано 6 сентября, 2020 · Жалоба Приветствую, спрошу здесь, ибо грабли, видимо, те же. Поставил версию 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", которая стоит в "Использовать системный путь", но где такой путь я не знаю. В переменных окружения не нашёл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimonira 0 6 сентября, 2020 Опубликовано 6 сентября, 2020 · Жалоба Нашёл решение здесь. Заменил в Makefile строку Quote APP_LDFLAGS += -msys-lib=$(call adjust-path-mixed,$(SYS_LIB)) на Quote APP_LDFLAGS += -msys-lib=hal_bsp Всё собралось без ошибок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
StewartLittle 41 7 сентября, 2020 Опубликовано 7 сентября, 2020 · Жалоба 19 часов назад, Dimonira сказал: Нашёл решение здесь. Хм... А у меня и с родным Makefile все собирается... Проблема под виндами в другом - создаются ли у Вас hex-файлы при выполнении mem_init_generate? Мне это побелить не удалось. Под виндами откатился на v18.1.1, а v20.x использую под линуксом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimonira 0 7 сентября, 2020 Опубликовано 7 сентября, 2020 · Жалоба 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 проект с нуля - не помогло. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
StewartLittle 41 7 сентября, 2020 Опубликовано 7 сентября, 2020 · Жалоба 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). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimonira 0 7 сентября, 2020 Опубликовано 7 сентября, 2020 · Жалоба Кое с чем разобрался в 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 8 8 сентября, 2020 Опубликовано 8 сентября, 2020 · Жалоба 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 зачем? Все равно квартус программер будет шить его с помощью загружаемого собственного проекта-прошивальщика. Или я чего-то не понимаю? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
StewartLittle 41 8 сентября, 2020 Опубликовано 8 сентября, 2020 · Жалоба 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimonira 0 8 сентября, 2020 Опубликовано 8 сентября, 2020 · Жалоба Поставил 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, т.е. не обновлять. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
