Interrup numbers of Arria 10 EDAC

Question

Hi,I try to enable the Error Detection and Correction (EDAC) for EMAC1 on my Arria 10 SoC device.I found the device tree entries for EMAC0 in the Linux kernel sources:emac0-rx-ecc@ff8c0800 {
  compatible = "altr,socfpga-eth-mac-ecc";
  reg = &lt;0xff8c0800 0x400&gt;;
  altr,ecc-parent = &lt;&amp;gmac0&gt;;
  interrupts = &lt;4 IRQ_TYPE_LEVEL_HIGH&gt;,
  &lt;36 IRQ_TYPE_LEVEL_HIGH&gt;;
};

emac0-tx-ecc@ff8c0c00 {
  compatible = "altr,socfpga-eth-mac-ecc";
  reg = &lt;0xff8c0c00 0x400&gt;;
  altr,ecc-parent = &lt;&amp;gmac0&gt;;
  interrupts = &lt;5 IRQ_TYPE_LEVEL_HIGH&gt;,
    &lt;37 IRQ_TYPE_LEVEL_HIGH&gt;;
};Where do I find the interrupts used for EMAC1? Is there any documentation available?And does it require some changes in my Quartus project as well or is it fully covered by the Linux drivers?

fawazj_altera · Answer

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 = &lt;3&gt;;            interrupt-controller;            reg = &lt;0xffffd000 0x1000&gt;,                  &lt;0xffffc100 0x100&gt;;      }; soc {            #address-cells = &lt;1&gt;;            #size-cells = &lt;1&gt;;            compatible = "simple-bus";            device_type = "soc";            interrupt-parent = &lt;&amp;intc&gt;;            ranges;            :     eccmgr: eccmgr {                  compatible = "altr,socfpga-a10-ecc-manager";                  altr,sysmgr-syscon = &lt;&amp;sysmgr&gt;;                  #address-cells = &lt;1&gt;;                  #size-cells = &lt;1&gt;;                  interrupts = &lt;0 2 IRQ_TYPE_LEVEL_HIGH&gt;,                             &lt;0 0 IRQ_TYPE_LEVEL_HIGH&gt;;                  interrupt-controller;                  #interrupt-cells = &lt;2&gt;;                    sdramedac {                        compatible = "altr,sdram-edac-a10";                        altr,sdr-syscon = &lt;&amp;sdr&gt;;                        interrupts = &lt;17 IRQ_TYPE_LEVEL_HIGH&gt;,                                   &lt;49 IRQ_TYPE_LEVEL_HIGH&gt;;                  };                   l2-ecc@ffd06010 {                        compatible = "altr,socfpga-a10-l2-ecc";                        reg = &lt;0xffd06010 0x4&gt;;                        interrupts = &lt;0 IRQ_TYPE_LEVEL_HIGH&gt;,                                   &lt;32 IRQ_TYPE_LEVEL_HIGH&gt;;                  };                                               :          };}; 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.

suec_altera · Answer

Hi Silvan,There are not dedicated interrupts for ECC.  Please review the ECC chapter in the Arria 10 Technical Reference Manual.Please let us know if you have further questions.Sue

silvan · Answer

Hi SueThank you for the quick replay.Then I do not understand the interrupts entry in the device tree blob, where interrupt 4, 36 for emac0 rx and 5, 37 for emac0 tx is declared. Can you explain me the four numbers? And which are the valid configuration for EMAC1?I see for all ECC entries in the device tree a configured interrupt number: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/intel/socfpga/socfpga_arria10.dtsi?h=linux-6.6.y#n723Where is the link of this numbers to the hardware? Or do I misunderstand something? Are the numbers some how related with the System Manager? I mean, the documentation says that "The ECC controller has the ability to generate single- and double-bit error interrupts to the System Manager."see here: https://www.intel.com/content/www/us/en/docs/programmable/683711/22-3/ecc-controller-interrupts.htmlThank you,Silvan

silvan · Answer

@SueC_Altera wrote:Hi Silvan,There are not dedicated interrupts for ECC.  Please review the ECC chapter in the Arria 10 Technical Reference Manual.Please let us know if you have further questions.SueHi Sue,I followed this documentation and instruction to enable the ECC: https://www.rocketboards.org/foswiki/Documentation/EnableL2CacheECCInLinuxUnfortunately, after following the steps of this documentation, the kernel is not able to boot anymore. It prints the following error messages in the console output:[   21.099148] rcu: INFO: rcu_sched self-detected stall on CPU
[   21.104715] rcu:     0-...!: (2100 ticks this GP) idle=003c/1/0x40000004 softirq=9/9 fqs=0
[   21.112697] rcu:     (t=2100 jiffies g=-1183 q=36 ncpus=2)
[   21.117903] rcu: rcu_sched kthread timer wakeup didn't happen for 2099 jiffies! g-1183 f0x0 RCU_GP_WAIT_FQS(5) -&gt;state=0x402
[   21.129073] rcu:     Possible timer handling issue on cpu=0 timer-softirq=4
[   21.135744] rcu: rcu_sched kthread starved for 2100 jiffies! g-1183 f0x0 RCU_GP_WAIT_FQS(5) -&gt;state=0x402 -&gt;cpu=0
[   21.145962] rcu:     Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[   21.154879] rcu: RCU grace-period kthread stack dump:
[   21.160143] rcu: Stack dump where RCU GP kthread last ran:So are you able to share the information how to enable the ECC in Linux on the Arria 10 SoC device?This is my further question to you and i would be happy if you can support me in this case! In addition to the meaning of the interrupt numbers in the dtb (see the other Reply https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/Interrup-numbers-of-Arria-10-EDAC/m-p/1703150#M3178 )Thank you and best regards, Silvan

silvan · Answer

Hi Fawaz,Thank you for your detailed explanation! The hint and information to the bit field helped to understand the entries...I updated the device tree according to your description and added the ECC node for EMAC1:			emac1-rx-ecc@ff8c1000 {
				compatible = "altr,socfpga-eth-mac-ecc";
				reg = &lt;0xff8c1000 0x400&gt;;
				altr,ecc-parent = &lt;&amp;gmac1&gt;;
				interrupts = &lt;6 IRQ_TYPE_LEVEL_HIGH&gt;,
					     &lt;38 IRQ_TYPE_LEVEL_HIGH&gt;;
			};

emac1-tx-ecc@ff8c1400 {
				compatible = "altr,socfpga-eth-mac-ecc";
				reg = &lt;0xff8c1400 0x400&gt;;
				altr,ecc-parent = &lt;&amp;gmac1&gt;;
				interrupts = &lt;7 IRQ_TYPE_LEVEL_HIGH&gt;,
					     &lt;39 IRQ_TYPE_LEVEL_HIGH&gt;;
			};However for some reason, the kernel is still not booting anymore with the active EMAC driver. As said I followed the documentation: https://www.rocketboards.org/foswiki/Documentation/EnableL2CacheECCInLinux?erpm_id=6579622_ts1753093952709 which results in the failure.I tried two things. First, exactly according to the documentation. In another test, I just enabled the Altera SOCFPGA ECC driver (without any of the sub-drivers). But in both cases, the kernel is not booting anymore.What is wrong with the settings? Is there any other changes required?

Forum Discussion

Interrup numbers of Arria 10 EDAC

9 Replies

Recent Discussions

Unique ID registers in Cyclone V

Audio interface with Agilex 5 A5ED065BB32AI4S

Operating system kernel-level FPGA bridge communication

Routing PL DDR to PS

Validating ECC Functionality on Custom Agilex 5 SOM in Linux Kernel