- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Tags:
- soc
Link Copied
0 Replies

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page