Arria 10 SoC devkit: adding a bridge to external memory

[Altera_Forum]

Hello all, 

 I am working on an accelerator design that references a large amount of data that I would like to move to external memory. I would like to use the HPS to recieve the data from the NIC or some external disk and move it over the bridge to the FPGA external memory so that the accelerator can process it. To do this, I am following the recommended practice of modifying the GHRD to incorporate the FPGA external memory and a bridge to it from the HPS. Since I am new to the SoC FPGA development flow, I am using a simple on-chip memory attached to the HPS bridge to store the data to try to understand how to use the tools. The issue is that it seems like no matter where I attach the memory, the linux image becomes unstable and experiences frequent and unpredictable kernel panic. The version with the memory connected to the lightweight AXI does not boot at all and fails a DRAM test in U-Boot, causing it to restart continuously. One episode of the kernel panic is shown below, but bear in mind that the output differs between episodes:  root@arria10:/sys/class# Unable to handle kernel paging request at virtual address 00006010 pgd = c0004000 *pgd=00000000 Internal error: Oops: 17 SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.78-ltsi-06654-g6fdee61# 1 Hardware name: Altera SOCFPGA Arria10 task: c0b06ac0 task.stack: c0b00000 PC is at timerqueue_add+0x34/0xd4 LR is at enqueue_hrtimer+0x58/0xc4 pc : lr : psr: 200e0193 sp : c0b01d80 ip : 00006004 fp : c0b01d9c r10: c0195d90 r9 : 00000001 r8 : c0b0302c r7 : ef7ccc40 r6 : ef7ccc8c r5 : ef7cce88 r4 : 00006000 r3 : ee8cdf00 r2 : 4ee76de0 r1 : 00000030 r0 : 4f5e2480 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 2e86004a DAC: 00000051 Process swapper/0 (pid: 0, stack limit = 0xc0b00218) Stack: (0xc0b01d80 to 0xc0b02000) 1d80: ef7cce88 ef7cce88 ef7ccc80 ef7ccc40 c0b01dbc c0b01da0 c0184040 c042c9c0 1da0: ef7cce88 c0b00000 ef7ccc80 ef7ccc40 c0b01e14 c0b01dc0 c0184aa8 c0183ff4 1dc0: c0b01e14 ffffe000 4ec591da 00000030 00000001 c0b72398 c0b723c0 c0b723ac 1de0: 4ec591da 00000030 c018336c ef7ccc40 c0a76c40 ef7ccc54 ef7cccd8 ef7cccb8 1e00: 00000003 ffffffff c0b01e6c c0b01e18 c0184da8 c01848f0 ef7cccf8 00000001 1e20: 4ec591da 00000030 00000007 2ed56000 ef7cccf8 7fffffff 4ec591da 00000030 1e40: c0b01eb4 00000001 00000000 ef01c200 00000001 c0b03a3c 00000010 00000001 1e60: c0b01e84 c0b01e70 c0110fb0 c0184cf4 ef027d40 00000000 c0b01eb4 c0b01e88 1e80: c0173450 c0110f7c c01733b8 c0a78484 00000000 00000000 00000001 ef020000 1ea0: f0803100 00000001 c0b01ec4 c0b01eb8 c016df08 c01733c4 c0b01eec c0b01ec8 1ec0: c016e504 c016dee0 c0b47bb0 c0b03a3c f080210c c0b01f18 f0802100 f0803100 1ee0: c0b01f14 c0b01ef0 c0101504 c016e4a4 c0108c34 600e0013 ffffffff c0b01f4c 1f00: c0b71cca c0b00000 c0b01f74 c0b01f18 c010d58c c01014b8 00000000 ef7cc368 1f20: 00050714 c011ba80 c0b00000 c0b0302c 00000001 c0b0307c c0b71cca c08c7dbc 1f40: 00000001 c0b01f74 c0b01f78 c0b01f68 c0108c30 c0108c34 600e0013 ffffffff 1f60: 00000051 00000000 c0b01f84 c0b01f78 c073cd7c c0108bf8 c0b01f9c c0b01f88 1f80: c0163958 c073cd58 c0b74dcc ffffffff c0b01fac c0b01fa0 c0737fe0 c0163880 1fa0: c0b01ff4 c0b01fb0 c0a00d24 c0737f68 ffffffff ffffffff 00000000 c0a00704 1fc0: 00000000 c0a51a30 00000000 c0b74f94 c0b03018 c0a51a2c c0b07e04 0000406a 1fe0: 414fc091 00000000 00000000 c0b01ff8 0000807c c0a009ac 00000000 00000000 (timerqueue_add) from (enqueue_hrtimer+0x58/0xc4) (enqueue_hrtimer) from (__hrtimer_run_queues+0x1c4/0x320) (__hrtimer_run_queues) from (hrtimer_interrupt+0xc0/0x220) (hrtimer_interrupt) from (twd_handler+0x40/0x50) (twd_handler) from (handle_percpu_devid_irq+0x98/0x24c) (handle_percpu_devid_irq) from (generic_handle_irq+0x34/0x44) (generic_handle_irq) from (__handle_domain_irq+0x6c/0xc4) (__handle_domain_irq) from (gic_handle_irq+0x58/0x9c) (gic_handle_irq) from (__irq_svc+0x6c/0x90) Exception stack(0xc0b01f18 to 0xc0b01f60) 1f00: 00000000 ef7cc368 1f20: 00050714 c011ba80 c0b00000 c0b0302c 00000001 c0b0307c c0b71cca c08c7dbc 1f40: 00000001 c0b01f74 c0b01f78 c0b01f68 c0108c30 c0108c34 600e0013 ffffffff (__irq_svc) from (arch_cpu_idle+0x48/0x4c) (arch_cpu_idle) from (default_idle_call+0x30/0x3c) (default_idle_call) from (cpu_startup_entry+0xe4/0x150) (cpu_startup_entry) from (rest_init+0x84/0x88) (rest_init) from (start_kernel+0x384/0x390) Code: e3a03000 ea000006 e1c501d0 e284c004 (e1c421d0) ------ Kernel panic - not syncing: Fatal exception in interrupt CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.9.78-ltsi-06654-g6fdee61# 1 Hardware name: Altera SOCFPGA Arria10 (unwind_backtrace) from (show_stack+0x20/0x24) (show_stack) from (dump_stack+0x8c/0xa0) (dump_stack) from (handle_IPI+0x2b0/0x2cc) (handle_IPI) from (gic_handle_irq+0x98/0x9c) (gic_handle_irq) from (__irq_svc+0x6c/0x90) Exception stack(0xef11bf58 to 0xef11bfa0) bf40: 00000000 ef7da368 bf60: 0005010e c011ba80 ef11a000 c0b0302c 00000002 c0b0307c c0b71cca c08c7dbc bf80: 00000001 ef11bfb4 ef11bfb8 ef11bfa8 c0108c30 c0108c34 600e0013 ffffffff (__irq_svc) from (arch_cpu_idle+0x48/0x4c) (arch_cpu_idle) from (default_idle_call+0x30/0x3c) (default_idle_call) from (cpu_startup_entry+0xe4/0x150) (cpu_startup_entry) from (secondary_start_kernel+0x15c/0x164) (secondary_start_kernel) from (0x10194c) ---[ end Kernel panic - not syncing: Fatal exception in interrupt   My qsys design with the memory connected to the lightweight AXI is shown here:  https://alteraforum.com/forum/attachment.php?attachmentid=14893&stc=1   and the design connected to the regular AXI is here:  https://alteraforum.com/forum/attachment.php?attachmentid=14894&stc=1   I have also tried recompiling the kernel, device tree, u-boot device tree, and regenerating the u-boot binary, none of which have affected the result. Any insight is welcome.