ContributionsMost RecentMost LikesSolutionsRe: jtagd memory leaks on Ubutnu 20.04 I do not think any picture can help just do the same steps like me use command "top" to see the memory usage, you can find the memory of jtagd continually increase PR NI VIRT RES SHR %CPU %MEM TIME+ COMMAND 20 0 1029476 993.8m 3696 S 0.3 1.6 68:40.40 jtagd jtagd memory leaks on Ubutnu 20.04 When using nios2-terminal to receive output data of nios2 through jtag-uart, the memory continues to increase until the system memory is exhausted. It seems the jtagd not free the old data received by usb-blaster2 OP system: Ubutnu 20.04 Quartus Prime Pro Version: 20.04 Bug report -- Platform Designer generate .regmap with all peripherals' Address set 0x00000000 the baseAddress in .regmap file generated by *.sopcinfo using Platform designer is not right. it always has these content in every peripheral node: <peripheral> ... <baseAddress>0x00000000</baseAddress> ... </peripheral> the baseAddress should be set use the real base address in sopcinfo rather than just copy from the .svd file specified by SVD_PATH in *_hw.tcl. .regmap can be very usefull when debugging nios2, if the baseAddress set correctly,. Re: baseAddress is 0x00000000? i think it is a bug about paltform designer, i report it in https://community.intel.com/t5/Intel-Quartus-Prime-Software/bd-p/quartus-prime-software Re: baseAddress is 0x00000000? yep, the.sopcinfo file is correct, but the generated .regmap file is not. Re: baseAddress is 0x00000000? I had read these docs before, and i am sure the baseAddress in the generated .regmap file is 0x00000000, the baseAddress should be substituded with real base address of every avalon-mm interface during generating. the .regmap can be used for nios2 software debugging, but if the baseAddress is not right, this file would be useless. Re: baseAddress is 0x00000000? you did not got it . "*.regmap" file is generated after you set the component base address use platform designer and click the generate button. you can set address range manually or use auto address assignment, but i am not talk about how to set base address. regmap file is generated by *.svd file specified by ```set_interface_property [interface name] CMSIS_SVD_FILE [svd file path]``` in *_hw.tcl baseAddress is 0x00000000? regmap file generated by platform designer has these contents <baseAddress>0x0000000</baseAddress> i think it is not right, baseAddres should be generated with real peripheral base address Fix Newlib compile error on Windows Platform [Version > 18.1 Use WSL] copy tool chain "H-x86_64-pc-linux-gnu" from linux platform and edit "niso2_command_shell.sh" like this: # if grep -q Microsoft /proc/version; then if [ -d "${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-mingw32/bin" ]; then env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-mingw32/bin else env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-i686-mingw32/bin fi # else if [ -d "${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-pc-linux-gnu/bin" ]; then env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-pc-linux-gnu/bin else env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-i686-pc-linux-gnu/bin fi # fi comment if-else-if and doses not need edit any thing in "nios2-newlib-gen" Be brief: there are two methods to solve these issues caused by wsl enviroment: 1. just use nios2eds with Qurtus 18.1 pro, which use cygwin shell enviroment, works perfect on windows platform. 2. copy tool chain "H-x86_64-pc-linux-gnu" form linux version's Quartus Pro to directory "niso2eds/bin/gnu/", so in makefile, use tool chain "H-x86_64-mingw32" and when compile newlib, use "H-x86_64-pc-linux-gnu" by itself. [Advice]: it is too complicated to use var WINDOWS_EXE, If Qurtus really want try WSL or WSL2, WHY NOT JUST MINGRATE LINUX TOOL CHAIN AND ERVERY RELATED SCRIPT to WSL enviroment and DISCARD "H-x86_64-mingw32" TOOL CHAIN!!!!!!!! OR JUST rollback to cygwin! these issues had been existed for three years since quartus discarded cygwin and started to use WSL. CAN ANYBODY FIX IT ? some other issues can be solved by add sed -i "s/^APP_LDFLAGS += -msys-lib=\$(call adjust-path-mixed\,\$(SYS_LIB)).*/APP_LDFLAGS += -msys-lib=\$(SYS_LIB)/g" Makefile to your own auto-build script Re: Can you fix stupid scripts error from 19.1 to 20.3? I had tried before, not work. I am pretty sure, the function build_newlib() in this script file is not right. the STAGE_WRAPPER file not generated correctly. STAGE_WRAPPER=$BLDDIR/build-newlib-stage-wrapper in file " build-newlib-stage-wrapper" #!/bin/bash # # A script to intercept and short-circuit the --print-multi-lib option # ORIGINAL_ARGS=$(echo $* | sed -e 's,/cygdrive/\([a-zA-Z]\)/,\1:/,g') CUSTOM= if [ "x$1" = "xnios2-elf-gcc" ] then CUSTOM=" -O3 -g -Wall -mno-hw-div -mhw-mul -mno-hw-mulx -mgpopt=global -fno-math-errno -mcustom-fabss=224 -mcustom-fadds=253 -mcustom-fcmpeqs=227 -mcustom-fcmpges=228 -mcustom-fcmpgts=229 -mcustom-fcmples=230 -mcustom-fcmplts=231 -mcustom-fcmpnes=226 -mcustom-fdivs=255 -mcustom-fixsi=249 -mcustom-floatis=250 -mcustom-fmuls=252 -mcustom-fnegs=225 -mcustom-fsubs=254 " fi while [ $# -gt 0 ] do case "$1" in --print-multi-lib) echo ".;" exit 0 ;; *) ;; esac shift done eval $ORIGINAL_ARGS $CUSTOM error log : [my private path]/newlib-build-tmp/build-newlib-stage-wrapper: line 23: nios2-elf-cc: command not found it shows that the suffix is missing in build-newlib-stage-wrapper, when use command "STAGE_WRAPPER {cmd}" but if I change the var ORIGINAL_ARGS and add suffix ".exe" in file "nios2-newlib-gen" ##add suffix for WSL uname=$(uname -r) uname=$(echo ${uname} | tr 'A-Z' 'a-z') if [[ "${uname}" =~ "microsoft" ]] then cat >>"$STAGE_WRAPPER" <<"EOF" echo "ORIGINAL_ARGS = ${ORIGINAL_ARGS}" #ORIGINAL_ARGS=$(echo ${ORIGINAL_ARGS} | sed -e "s,-B, -B,g") #ORIGINAL_ARGS=$(echo ${ORIGINAL_ARGS} | sed -e "s,-i, -i,g") #ORIGINAL_ARGS=$(echo ${ORIGINAL_ARGS} | sed -e "s,^nios2-elf-cc,nios2-elf-gcc,g") echo "ORIGINAL_ARGS = ${ORIGINAL_ARGS}" cmd=$(echo $ORIGINAL_ARGS | awk 'NR==1{print $1}') echo "cmd = $cmd" ORIGINAL_ARGS=$(echo ${ORIGINAL_ARGS} | sed -e "s,^$cmd,$cmd.exe,g") EOF fi it still not work. in newlib tmporary config.log shows that it still not add suffix .exe when configure call nios2-elf-gcc So, it is complicated to fix script bugs to compile newlib in wsl by using mingw32 tool chain because newlib configure not add suffix for command even throught add suffix in STAGE_WRAPPER file! I doubt! Why Quartus not just migrate tool chain for linux platform and just remove mingw32 tool chain which has annoying suffix ".exe" because of using WSL , nearly a real linux enviroment!!!!! So, I copy tool chain "H-x86_64-pc-linux-gnu" from linux platform and edit "niso2_command_shell.sh" like this: # if grep -q Microsoft /proc/version; then if [ -d "${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-mingw32/bin" ]; then env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-mingw32/bin else env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-i686-mingw32/bin fi # else if [ -d "${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-pc-linux-gnu/bin" ]; then env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-x86_64-pc-linux-gnu/bin else env_var_prepend ${SOPC_KIT_NIOS2}/bin/gnu/H-i686-pc-linux-gnu/bin fi # fi comment if-else-if and doses not need edit any thing in "nios2-newlib-gen" Be brief: there are two methods to solve these issues caused by wsl enviroment: 1. just use nios2eds with Qurtus 18.1 pro, which use cygwin shell enviroment, works perfect on windows platform. 2. copy tool chain "H-x86_64-pc-linux-gnu" form linux version's Quartus Pro to directory "niso2eds/bin/gnu/", so in makefile, use tool chain "H-x86_64-mingw32" and when compile newlib, use "H-x86_64-pc-linux-gnu" by itself. [Advice]: it is too complicated to use var WINDOWS_EXE, If you really want try WSL or WLS2, WHY NOT JUST MINGRATE LINUX TOOL CHAIN AND ERVERY RELATED SCRIPT to WSL enviroment and DISCARD "H-x86_64-mingw32" TOOL CHAIN!!!!!!!! OR rollback to use cygwin! these issues had been existed for three years since you discarded cygwin and started to use WSL. CAN ANYBODY FIX IT ?