ContributionsMost RecentMost LikesSolutionsRe: Nios V: niosv-download reports "no harts found" on Agilex 5 board Hello, We have tested the Github ready-to-test files, and they are working on boards. I would like to know if you are using a development kit or customer kit. Also, what is your device OPN. Furthermore, can you program the .sof file, then use Nios V command shell and type the following command: jtagconfig -n Send me the output of this command. Thank you, Fawaz Re: I compiled using the nios2 command shell. How do I debug it using the nios2 EDS tool? Hello Michael, I am glad to help you. Fawaz. Re: I compiled using the nios2 command shell. How do I debug it using the nios2 EDS tool? Hello Michael, The "wsl make all" is expected since you run Nios II environment on Windows using wsl. Unfortunately, I couldn't replicate this issue on my computer under Windows environment due to some technical difficulties, I will try t find an alternative for this. The only replication I did was based on Linux environment. The setup is different between the two environments. I would suggest either: 1- Use one environment for building the project. Lets say, build using Nios II command shell, and debug using Nios II IDE. 2- If you want to build and debug using the IDE environment, try to start creating the project from the IDE itself instead of the command shell. Side note: when you import the app and bsp directories into your IDE environment, try to check the option that clears the builds. This will import the projects as "cleared", so you can build it inside the Nios II IDE. I will let you know if I can replicate on a Windows system. Thank you, Fawaz. Re: Nios V: niosv-download reports "no harts found" on Agilex 5 board Hello, Can you try to reduce the JTAG Speed using the command below: jtagconfig --setparam 1 JtagClock 6M After that, download the Nios V elf file: niosv-download -g -r app.elf I will test the Github design on board, and I will let you know my findings. Thank you, Fawaz. Re: I compiled using the nios2 command shell. How do I debug it using the nios2 EDS tool? Hello, In case you built your application and BSP folders using the Nios II command line, and you want to use Nios II IDE for debugging, kindly follow the steps below: 1- Make sure you have installed Eclipse along with Nios II Plugin. If not installed, follow the steps in this guide: 3.1. Installing Eclipse IDE into Nios® II EDS 2- Open Nios II IDE from Nios II command shell using eclipse-nios2 command. This ensures all the required env paths are available for the tool. 3- From File -> Import -> Nios II Software Build Tools Project -> Import Custom Makefile for Nios II Software Build Tools Project 4- Select the Project location. Do this twice to include the APP and BSP folders. 5- You should see the included directories inside the Project Explorer Thank you, Fawaz. Re: Can the NIOS be used outside the DE10 LIte? Hello, We do not provide the source code of Nios V outside Quartus Prime tools. You can use it with Altera FPGA products. Thank you Re: Nios V: niosv-download reports "no harts found" on Agilex 5 board Greetings, This seems to be a reset issue. The Reset Release IP is missing from your platform. You may refer to the Nios V application note: https://www.intel.com/content/www/us/en/docs/programmable/784468/current/an-985-processor-tutorial.html You can follow the steps in 1.2.1 section (1.2.1.1.2.4. Adding Reset Release Intel® FPGA IP). Furthermore, you may refer to the design examples available for Agilex 5 development kit: 1- Agilex™ 5 - Hello World on Nios® V/g Processor Design Example 2- altera-fpga/agilex5e-nios-ed: Nios V Processor example designs targeting Altera Agilex 5 Development Kits Thank you, Fawaz. Re: Interrup numbers of Arria 10 EDAC Hello Silvan, Can you share with me the complete boot log? this will help me in debugging the boot procedure. In the meantime, I will try to replicate the scenario with my dev kit for further debugging. Thank you, Fawaz. Re: Interrup numbers of Arria 10 EDAC Hello, If we look at the example section below of the device tree, we can state the following: intc: interrupt-controller@ffffd000 { compatible = "arm,cortex-a9-gic"; #interrupt-cells = <3>; interrupt-controller; reg = <0xffffd000 0x1000>, <0xffffc100 0x100>; }; soc { #address-cells = <1>; #size-cells = <1>; compatible = "simple-bus"; device_type = "soc"; interrupt-parent = <&intc>; ranges; : eccmgr: eccmgr { compatible = "altr,socfpga-a10-ecc-manager"; altr,sysmgr-syscon = <&sysmgr>; #address-cells = <1>; #size-cells = <1>; interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>, <0 0 IRQ_TYPE_LEVEL_HIGH>; interrupt-controller; #interrupt-cells = <2>; sdramedac { compatible = "altr,sdram-edac-a10"; altr,sdr-syscon = <&sdr>; interrupts = <17 IRQ_TYPE_LEVEL_HIGH>, <49 IRQ_TYPE_LEVEL_HIGH>; }; l2-ecc@ffd06010 { compatible = "altr,socfpga-a10-l2-ecc"; reg = <0xffd06010 0x4>; interrupts = <0 IRQ_TYPE_LEVEL_HIGH>, <32 IRQ_TYPE_LEVEL_HIGH>; }; : }; }; intc node corresponds to the node related to the GIC in the Arria10 devices. The interrupt-controller; filed indicates that this is an interrupt controller and the #interrupt-cells indicates that the interrupts defined here will receive 3 parameters: the interrupt type, the interrupt number and the interrupt trigger. The possible value for interrupt type are: The interrupt number parameter describes the peripheral ID that causes the interrupt, but since the 1st parameter (interrupt type) already defines the type, this seems to be using an offset 0 instead of 32 or 16. If we look into the table 88 in the TRM at https://www.intel.com/content/www/us/en/docs/programmable/683711/22-3/gic-interrupt-map-for-the-arria-10-soc-hps.html it defines the interrupt mappings for the SPI interrupt type, but we need to use the interrupt number as (interrupt ID - 32). The last parameter (interrupt trigger) defines how the interrupt is triggered like rising/falling edge or high/low level. The soc node indicates that this is an interrupt child of the intc node as indicated in the interrupt-parent field, so any node defined under this that doesn’t include an interrupt-parent field, will inherit the interrupt controller of this. The eccmgr node is a child of the soc node and inherits the intc and its interrupt controller. In this node are defined 2 SPI interrupts with interrupt-number of 0 and 2 (IDs 32 and 34). Looking at the table 88 in the TRM, these are System Manager related interrupts used to capture DERR/SERR maybe derived from ECC errors coming from different devices. Also observe in the last column in table 88 that the trigger of these interrupts Level, so this matches the definition in the interrupts as its indicated as IRQ_TYPE_LEVEL_HIGH. In this node we also see interrupt-controller field which indicates that this node is also considered as a interrupt-controller, but in this case seems that this is used to indicate different possible sources that could generate the interrupt. These normally have some kind of status register that indicates the source of the interrupt triggering. This also defines that any child of this node will inherits this interrupt controller and will use 2 parameters through the #interrupt-cells field. The 2 parameters that this interrupt controller receives are the interrupt ID (a bit in a mask that indicates the source of the interrupt) and the trigger type of the interrupt. For the ECC manager, seems that these bits are defined in the ecc_intmask_value register under the System Manager:https://www.intel.com/content/www/us/en/programmable/hps/arria-10/hps.html#topic/sfo1429890615426.html The sdramedac, l2-ecc and other nodes are child of the eccmgr node which also have as the eccmgr as interrupt controller parent. These defines their own interrupts with 2 parameters. For example, in the case of sdramedac it defines the interrupt number 17 and 49. The 17 seems to be related to ddr0 as indicated in the ecc_intmask_value register. I am not sure about the 2nd interrupt defined, but the value of this one corresponds to the 1st value + 32. Not sure if the 1st one targets CPU0 and the 2nd one targets CPU1. Same thing with the l2-ecc node, in which defines the interrupt number of 0 and 32. Also, the bit 0 corresponds to the l2 in the ecc_intmask_value register and the 2nd interrupt has an offset of 32 compared with the 1st one. These seems to match to all the nodes under the eccmgr node. Hope this might help. Fawaz. Re: sopc-create-header-files appears to have broken on SoC EDS 19.1 under Windows Hello, Can you try the steps in this link to create the header files: https://github.com/altera-opensource/u-boot-socfpga/blob/socfpga_v2019.04/doc/README.socfpga Which soc device are you using?