Loading an overlay on KR260 Ubuntu PYNQ is crashing

Support
1

I’m using the Xilinx provided Ubuntu image for the KR260.
I followed the steps here for installing PYNQ:

My Jupyter notebook attempts to load an overlay:
from time import sleep
import pynq

ol = pynq.overlay.Overlay(“gpio_bram.xsa”)
axi_gpio = pynq.mmio.MMIO(0xA0010000, length=8)

#configure the GPIO direction for output
axi_gpio.write_reg(0x4, 0x0)

state = 0
for i in range(10):
if state == 0:
state = 0xFF
else:
state = 0
axi_gpio.write_reg(0x0, state)
sleep(1)

print(‘Done’)

When I try to load an overlay in my Jupyter notebook Ubuntu crashes, here is the log:
ubuntu@kria:~$ [ 940.596872] [drm] bitstream 4bc3b1cf-f145-59be-a2ad-e2d10299de6a unlocked, ref=0
[ 940.598531] SError Interrupt on CPU2, code 0xbf000002 – SError
[ 940.598543] CPU: 2 PID: 3340 Comm: python3 Not tainted 5.15.0-1020-xilinx-zynqmp #22-Ubuntu
[ 940.598549] Hardware name: ZynqMP SMK-K26 Rev1/B/A (DT)
[ 940.598553] pstate: 60000000 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=–)
[ 940.598559] pc : 0000ffffb4168728
[ 940.598561] lr : 0000ffffb41687c0
[ 940.598563] sp : 0000fffffc5d76b0
[ 940.598565] x29: 0000fffffc5d76b0 x28: 0000ffff9c6cfb80 x27: 0000ffff9ce88aae
[ 940.598576] x26: 0000ffff9c3d5f50 x25: 0000ffffbb5a00d0 x24: 0000ffffb4402238
[ 940.598583] x23: 0000ffffbb5a00f0 x22: 0000ffffbb5a00d0 x21: 0000000000000000
[ 940.598591] x20: 0000ffffb43f8000 x19: 0000aaaad43cc470 x18: 0000000000001fe2
[ 940.598599] x17: 0000aaaaceed6ab0 x16: 0000ffffb43f74a8 x15: 000000000000003c
[ 940.598606] x14: 000000000000003c x13: 0000ffffbb5a00f0 x12: 0000aaaaceeec35c
[ 940.598614] x11: 0000000000000000 x10: 000000000000003a x9 : 0000aaaad482c790
[ 940.598622] x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000aaaacf3453a8
[ 940.598629] x5 : 0000aaaacf345870 x4 : 0000ffffb4159ef0 x3 : 0000000000000000
[ 940.598637] x2 : 0000000000000000 x1 : 0000ffffbbcefb58 x0 : 0000000000000000
[ 940.598647] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 940.598650] CPU: 2 PID: 3340 Comm: python3 Not tainted 5.15.0-1020-xilinx-zynqmp #22-Ubuntu
[ 940.598656] Hardware name: ZynqMP SMK-K26 Rev1/B/A (DT)
[ 940.598659] Call trace:
[ 940.598661] dump_backtrace+0x0/0x1f0
[ 940.598673] show_stack+0x20/0x30
[ 940.598678] dump_stack_lvl+0x68/0x84
[ 940.598686] dump_stack+0x18/0x34
[ 940.598692] panic+0x140/0x350
[ 940.598701] nmi_panic+0x94/0x9c
[ 940.598709] arm64_serror_panic+0x78/0x84
[ 940.598715] do_serror+0x30/0x6c
[ 940.598720] __el0_error_handler_common+0x3c/0xf0
[ 940.598729] el0t_64_error_handler+0x10/0x20
[ 940.598734] el0t_64_error+0x1a4/0x1a8
[ 940.598743] SMP: stopping secondary CPUs
[ 940.598752] Kernel Offset: disabled
[ 940.598754] CPU features: 0x00002001,00000846
[ 940.598758] Memory Limit: none
[ 940.790778] —[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]—
[ 947.016826] ------------[ cut here ]------------
[ 947.016829] WARNING: CPU: 2 PID: 3340 at kernel/sched/core.c:3027 set_task_cpu+0x154/0x1e0
[ 947.016840] Modules linked in: zocl binfmt_misc joydev input_leds ina260_adc tpm_tis_spi mali uio_pdrv_genirq sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua usb5744 dmaproxy ramoops pstore_blk efi_pstore reed_solomon pstore_zone ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear usbhid da9121_regulator i2c_mux_pca954x crct10dif_ce rtc_zynqmp i2c_cadence spi_zynqmp_gqspi zynqmp_dpsub aes_neon_bs aes_neon_blk aes_ce_blk crypto_simd cryptd aes_ce_cipher
[ 947.016934] CPU: 2 PID: 3340 Comm: python3 Not tainted 5.15.0-1020-xilinx-zynqmp #22-Ubuntu
[ 947.016940] Hardware name: ZynqMP SMK-K26 Rev1/B/A (DT)
[ 947.016942] pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=–)
[ 947.016948] pc : set_task_cpu+0x154/0x1e0
[ 947.016953] lr : try_to_wake_up+0x180/0x650
[ 947.016958] sp : ffff80000b76bda0
[ 947.016961] x29: ffff80000b76bda0 x28: ffff00087f77a1c0 x27: ffff00087f77a180
[ 947.016969] x26: ffff800008164300 x25: 0000000000000001 x24: 00000000000000c0
[ 947.016977] x23: ffff80000b1a2738 x22: 00000000000000c0 x21: ffff80000b19da10
[ 947.016984] x20: 0000000000000001 x19: ffff00080089de80 x18: ffffffffffffffff
[ 947.016992] x17: ffff800874d95000 x16: ffff80000b76c000 x15: 0000000000004000
[ 947.017000] x14: 797341203a676e69 x13: 2d2d2d5d20747075 x12: 727265746e492072
[ 947.017007] x11: 6f72724553207375 x10: 6f6e6f7268636e79 x9 : ffff8000080ed410
[ 947.017015] x8 : 000000000000000f x7 : 0000000000000001 x6 : 0000000000000917
[ 947.017023] x5 : ffff0008002e7e00 x4 : ffff800874d77000 x3 : 000000000000000f
[ 947.017030] x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000002
[ 947.017037] Call trace:
[ 947.017040] set_task_cpu+0x154/0x1e0
[ 947.017045] try_to_wake_up+0x180/0x650
[ 947.017050] wake_up_process+0x20/0x30
[ 947.017055] hrtimer_wakeup+0x28/0x40
[ 947.017063] __hrtimer_run_queues+0x148/0x324
[ 947.017070] hrtimer_interrupt+0xf8/0x264
[ 947.017077] arch_timer_handler_phys+0x3c/0x50
[ 947.017086] handle_percpu_devid_irq+0x90/0x1c0
[ 947.017093] handle_domain_irq+0x68/0xa0
[ 947.017101] gic_handle_irq+0x70/0xa0
[ 947.017106] call_on_irq_stack+0x28/0x34
[ 947.017112] do_interrupt_handler+0x5c/0x70
[ 947.017119] el1_interrupt+0x30/0x50
[ 947.017126] el1h_64_irq_handler+0x18/0x24
[ 947.017133] el1h_64_irq+0x7c/0x80
[ 947.017138] __delay+0x98/0xb0
[ 947.017146] __const_udelay+0x2c/0x40
[ 947.017153] panic+0x320/0x350
[ 947.017159] nmi_panic+0x94/0x9c
[ 947.017167] arm64_serror_panic+0x78/0x84
[ 947.017172] do_serror+0x30/0x6c
[ 947.017177] __el0_error_handler_common+0x3c/0xf0
[ 947.017185] el0t_64_error_handler+0x10/0x20
[ 947.017190] el0t_64_error+0x1a4/0x1a8
[ 947.017195] —[ end trace 15f24bcf0802527c ]—

2

Hi Kevin,

Can you isolate whether it is the first or second line that is causing the crash. Put each line in its own cell then retry. I am more concerned about your 2nd line. I would not use a hard address like you have in that MMIO line. Instead take a look at how to use ol.ip_dict. Try that in its own cell and interrogate the dictionary and locate your gpio block. PYNQ gives you a driver for axi_gpio cores so if your module is a GPIO I would use that instead of the MMIO.

If in fact it was the first line reading the xsa file then we can try something else and isolate why the XSA is giving you issues.

Let me know what you find after those steps.

-Regards,

Nathan

1 Like
3

Thank you for your help.
It looks like the pynq.overlay.Overlay is not the problem.

My design does have an AXI GPIO, see the ip_dict results below.
I need to use the MMIO in order to demonstrate how we communicate with our custom AXI4Lite slaves.

  • :arrow_forward:

ip_dict:

  • :arrow_forward:

axi_gpio_0:
* type:“xilinx.com:ip:axi_gpio:2.0”
* mem_id:“S_AXI”
* memtype:“REGISTER”
* gpio:{}
* interrupts:{}
* :arrow_forward:

parameters:
* C_FAMILY:“zynquplus”
* C_S_AXI_ADDR_WIDTH:“9”
* C_S_AXI_DATA_WIDTH:“32”
* C_GPIO_WIDTH:“8”
* C_GPIO2_WIDTH:“32”
* C_ALL_INPUTS:“0”
* C_ALL_INPUTS_2:“0”
* C_ALL_OUTPUTS:“0”
* C_ALL_OUTPUTS_2:“0”
* C_INTERRUPT_PRESENT:“0”
* C_DOUT_DEFAULT:“0x00000000”
* C_TRI_DEFAULT:“0xFFFFFFFF”
* C_IS_DUAL:“0”
* C_DOUT_DEFAULT_2:“0x00000000”
* C_TRI_DEFAULT_2:“0xFFFFFFFF”
* Component_Name:“k26_base_gpio_bram_axi_gpio_0_0”
* USE_BOARD_FLOW:“true”
* GPIO_BOARD_INTERFACE:“Custom”
* GPIO2_BOARD_INTERFACE:“Custom”
* EDK_IPTYPE:“PERIPHERAL”
* C_BASEADDR:“0xA0010000”
* C_HIGHADDR:“0xA001FFFF”
* DATA_WIDTH:“32”
* PROTOCOL:“AXI4LITE”
* FREQ_HZ:“99999001”
* ID_WIDTH:“0”
* ADDR_WIDTH:“9”
* AWUSER_WIDTH:“0”
* ARUSER_WIDTH:“0”
* WUSER_WIDTH:“0”
* RUSER_WIDTH:“0”
* BUSER_WIDTH:“0”
* READ_WRITE_MODE:“READ_WRITE”
* HAS_BURST:“0”
* HAS_LOCK:“0”
* HAS_PROT:“0”
* HAS_CACHE:“0”
* HAS_QOS:“0”
* HAS_REGION:“0”
* HAS_WSTRB:“1”
* HAS_BRESP:“1”
* HAS_RRESP:“1”
* SUPPORTS_NARROW_BURST:“0”
* NUM_READ_OUTSTANDING:“8”
* NUM_WRITE_OUTSTANDING:“8”
* MAX_BURST_LENGTH:“1”
* PHASE:“0.0”
* CLK_DOMAIN:“k26_base_gpio_bram_zynq_ultra_ps_e_0_0_pl_clk0”
* NUM_READ_THREADS:“1”
* NUM_WRITE_THREADS:“1”
* RUSER_BITS_PER_BYTE:“0”
* WUSER_BITS_PER_BYTE:“0”
* INSERT_VIP:“0”
* :arrow_forward:

registers:
* driver:“<class ‘pynq.lib.axigpio.AxiGPIO’>”
* device:“<pynq.pl_server.embedded_device.EmbeddedDevice object at 0xffff8f63f070>”
* state:null
* bdtype:null
* phys_addr:2684420096
* addr_range:65536
* fullpath:“axi_gpio_0”

4

It’s the axi_gpio.write_reg that is causing the crash.
I don’t understand why it’s crashing, ip_dict shows that I’m using the correct base address for the AXI GPIO

5

Try something like this to manipulate into an IP that you create, but use the GPIO one like you are doing. You will want to have the datasheet open the axi_gpio so you can see the register map. But here is something simple to read it…

from pynq import MMIO
myIP_base = ol.ip_dict[“gpio_control/axi_gpio_fifoflush”][“phys_addr”]
myIP_range = ol.ip_dict[“gpio_control/axi_gpio_fifoflush”][“addr_range”]
ipmmio = MMIO(myIP_base, myIP_range)
ipmmio.read(0x0004)

You can change the address 0x0004 to anything that is in that IP’s register space. You can then use the .write method to write back. Of course, you already that if you use HLS, the HLS IP will give you its registers and populare this for PYNQ too…

Regards,

-Nathan

6

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.