User Profile
User Widgets
Contributions
Re: Preloader/U-Boot Compilation Failure
Hi IOzan , So, the 'sed: cannot rename .../sedXXXXXX: Permission denied' error still occurs after all. Since this error is typically caused by environment‑specific factors within the Cygwin layer on Windows — such as file‑locking behavior, antivirus interference, or permission propagation — it is hard to offer a certain solution, unfortunately. That said, try a few additional tests ? Create a new spl_bsp directory in a location where you have full read/write permissions, preferably in a new folder on C: drive, and run make. Does this attempt generate exactly the same error log? (Try this several times.) ( Alternatively, you might consider abandoning Cygwin on your Windows environment and building it in a Linux environment instead.... ) Thanks, Sho17Views0likes0CommentsRe: Preloader/U-Boot Compilation Failure
Hi IOzan , Thank you for sending the tool information, your work details, and the error logs. First, I would like to note that the version you are using, 18.1std, has already reached the end of support, and it is recommended to use the latest version, 25.1std. (However, I understand that there may be cases where you need to use this older version for various reasons...) I believe the root cause of the issue you are facing is that an error is occurring in the tar command. tar: Error opening archive: Failed to open '/cygdrive/c/intelFPGA/....' To address this root cause, please try modifying the Makefile as follows: 1. Re‑generate the spl_bsp folder and start from the original Makefile. 2. On the line following line 93, which contains ifeq ($(HOSTOS),cygwin), add the following one line: UNTAR := $(SOCEDS_DEST_ROOT)/host_tools/cygwin/bin/tar zxf Then run make. This modification does not change the value of the TGZ variable; rather, it explicitly forces the build process to use the tar command installed in the SoC EDS Cygwin environment. Please let me know if this Makefile modification resolves the issue. Thanks, Sho21Views0likes0CommentsRe: How to properly register a custom PHY (Analog Devices ADIN1300) in TSE driver
Hi moranFarcas1 I reviewed the PHY initialization process in the TSE driver. And it looks ADIN1300 PHY supports the standard MDIO specification. I believe it will work by just adding alt_tse_system_phy_struct for that PHY and calling alt_tse_phy_add_profile() in alt_tse_phy_add_profile_default() function. So ADIN1300 PHY should also be supported simply by using the altera_avalon_tse.c you attached. If you haven't done so yet, please try it. If you encounter any issues, please share them. Thanks, ShoH83Views0likes2CommentsRe: Nios-V alt_epcq_controller_write() Problem
Hi Balerion, Regading to avl_mem slave: If you also place avl_mem slave in Peripheral Region, you can use the current altera_epcq_controller.c file as is. However, you may want to place avl_mem slave in cacheable (non-Peripheral) region to take advantage of the cache for read accesses. In that case, cache maintenance needed for flash memory write operation in Nios V/g system. Here is a code example (= not fully validated) to achieve this attached (please replace the file extension from ".txt" to ".c"). At the end of the alt_epcq_controller_write_block() function, cache flush function call and error checking are added. Thanks, ShoH98Views1like1CommentRe: Ahsling RiscFree IDE 25.1.1: Unresolved inclusion
Hi Frank, I can't attach XML file, so I'll just paste the contents of include_search_path_25.1.1_win.xml. Use this as the contents of the .xml file. Again, the xml file is an example for 25.1.1 RiscFree running on Windows PC, so named as include_search_path_25.1.1_win.xml. <?xml version="1.0" encoding="UTF-8"?> <cdtprojectproperties> <section name="org.eclipse.cdt.internal.ui.wizards.settingswizards.IncludePaths"> <language id="org.eclipse.cdt.core.g++" name="C++ Source File"> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0\backward</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include-fixed</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include</includepath> </language> <language id="org.eclipse.cdt.core.gcc" name="C Source File"> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0\backward</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include-fixed</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include</includepath> </language> </section> <section name="org.eclipse.cdt.internal.ui.wizards.settingswizards.Macros"> <language id="org.eclipse.cdt.core.g++" name="C++ Source File"/> <language id="org.eclipse.cdt.core.gcc" name="C Source File"/> </section> </cdtprojectproperties> Note: If you installed RiscFree in non-default folder, edit the attached xml with a text editor and replace path names accordingly. Also If you are running on Linux platform, need to change it as your Linux install folder and path format. Thanks, Sho26Views1like1CommentRe: Ahsling RiscFree IDE 25.1.1: Unresolved inclusion
Hi Frank, FvM First, As you may already know, RiscFree is based on Eclipse C/C++ Development Toolkit (CDT), and these "unresolved inclusion" messages are from Indexer, which is a component of Eclipse. Indexer parses and analyzes your project files to help your source code exploration in GUI. So these warnings are not related the build process for your binary and the build process can be successfully completed regardless the messages. (Back to the main topic) As you pointed out, fully automatic resolution of Indexer search path settings is not supported yet in RiscFree today, unfortunately. However, We can resolve "unresolved inclusion" issue by manually setting the search path for Indexer. To search files in BSP project: After you have imported both the application and BSP project: Right-click on the application project in Project Explorer Select Properties Navigate to the Project References tab Check the option box for the BSP project, then click Apply and Close To search C/C++ libraries: (This is how I workaround...) Add the default RISC-V gcc include file search paths into project properties. To do this, import the xml explained in my next post with the following steps. The xml file is an example for 25.1.1 RiscFree running on Windows PC, so named as include_search_path_25.1.1_win.xml. Right-click on the application project in Project Explorer Select Import... Select C/C++ -> C/C++ Project Settings, then click Next Click Browse..., then select the attached xml file: include_search_path_25.1.1_win.xml Click Finish After these setup, there is no "unresolved inclusion" in my RiscFree. Hope this helps, Sho1View1like2CommentsRe: Ahsling RiscFree IDE 25.1.1: Unresolved inclusion
Hi Frank, In case you want to create your own xml file (or to create an xml for different version of tool etc.), How the xml file was created: 1. Right-click on the application project in Project Explorer 2. Select Properties 3. Navigate to the "C/C++ General -> Paths and Symbols" tab 4. Select "Includes" tab in the "Paths and Symbols" pain on the right side 5. Click "Add...", then added the default riscv32 gcc include paths. 6. Click "Export Settings..." , and export your settings with an adequate filename. How to find the default riscv32 gcc include paths: In niosv-command-shell, run the command Windows : riscv32-unknown-elf-gcc -x c++ -v -E NUL Linux : riscv32-unknown-elf-gcc -x c++ -v -E /dev/null This command shows various info. Extract lines from "#include <...> search starts here:" to "End of search list." .... #include <...> search starts here: C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... End of search list. .... Or if Linux, you can use awk command to extract necessary lines, like this: riscv32-unknown-elf-gcc -x c++ -v -E /dev/null 2>&1 | awk '/ <...> search starts here/{flag=1} flag {print} /End/{flag=0}' Regards, Sho6Views1like0CommentsRe: Nios-V alt_epcq_controller_write() Problem
Hi Balerion, Yes, disable caching(0Kilobytes of cache) is another option and a good choice when you use Tightly Coupled Memories(TCMs). (In my design, I usually disable cache when I can use sufficient size of TCMs.) There is no difference between Peripheral A and Peripheral B for the core. You may use ether one. When you feel convenient with two separeate peripheral region, you can use both. These allow you to use separate regions for Peripheral. Accessing TCM always bypasses cache memory(=Cache is never used for TCM accesses). So you don't need to worry about peripheral region for TCM. https://www.intel.com/content/www/us/en/docs/programmable/683632/25-3/accessing-tightly-coupled-memory.html "peripheral access must be non-cached" : Caches store copies of data, and accessing peripheral registers through a cache can result in reading "stale" data, or a write could be held in the cache and never write to the peripheral hardware. Please note that this is due to the way CPU caches work and is not specific to Nios V. Please let me know if disabling cache or caring peripheral region helps to resolve the QSPI access issue. Thanks, ShoH28Views0likes4Comments