[AMD Official Use Only - AMD Internal Distribution Only] The issue is you now have a PL that is likely returning an AXI SLVERR or DECERR. Uboot/Linux may or may not decide to crash when it receives this.
Consider adding an ILA to the PL to observe the error in HW. Does the read generate a SLVERR/DECERR? You can also try to connect via JTAG and make the access via XSDB or other debugger and reproduce it and separate from software at all. Perhaps there is a user PL reset issue. ________________________________ From: [email protected] <[email protected]> on behalf of Mike Looijmans via lists.yoctoproject.org <[email protected]> Sent: Tuesday, November 4, 2025 11:50 PM To: [email protected] <[email protected]> Subject: Re: [meta-xilinx] Writing to PL Crash after Reprogramming PL, issue after Upgrading OS to v2024.2 Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. Check if the clocks are running. If your devices don't explicitly acquire and enable clock sources, the clocks will remain disabled. On 10/30/25 18:56, enoy via lists.yoctoproject.org wrote: Hello, I have recently worked on upgrading the OS for a custom board/firmware from Xilinx rel-v2020.2 to rel-v2024.2. This is a continuation of the upgrade mentioned in this thread<https://lists.yoctoproject.org/g/meta-xilinx/topic/110863138>, and the issues posted there have been fully solved. The new OS boots fine and works, and writing/reading to the PL works fine except for the following issue: After reprogramming the PL, an AXI bus write causes a crash (the same PL .bit is programmed as was already there, so the program is not the issue): ________________________________ root@gfex-prototype4:~# devmem2 0xA0010010 w 0x00000000 /dev/mem opened. Memory mapped at address 0xffff831bb000. Read at address 0xA0010010 (0xffff831bb010): 0x00000000 Write at address 0xA0010010 (0xffff831bb010): 0x00000000, readback 0x00000000 *JTAG Reprogramming* root@gfex-prototype4:~# devmem2 0xA0010010 /dev/mem opened. Memory mapped at address 0xffff95e14000. Read at address 0xA0010010 (0xffff95e14010): 0x00000000 root@gfex-prototype4:~# devmem2 0xA0010010 w 0x00000000 /dev/mem opened. Memory mapped at address 0xffff9d8b5000. Read a[ 105.395161] SError Interrupt on CPU3, code 0x00000000bf000000 -- SError [ 105.395178] CPU: 3 PID: 399 Comm: devmem2 Not tainted 6.6.40-xilinx-g8703df42d988 #1 [ 105.395186] Hardware name: Xilinx ZynqMP (DT) [ 105.395189] pstate: 00000000 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 105.395197] pc : 0000ffff9d715d80 [ 105.395199] lr : 0000ffff9d72e78c [ 105.395201] sp : 0000ffffce18e280 [ 105.395203] x29: 0000ffffce18e830 x28: 0000000000000000 x27: 0000ffffce18e9a8 [ 105.395214] x26: 0000ffff9d8615e8 x25: 0000ffff9d8b5010 x24: 0000000000000000 [ 105.395222] x23: 0000000000000003 x22: 0000000000000000 x21: 00000000a0010010 [ 105.395230] x20: 0000000000001000 x19: 0000ffffce18e878 x18: 0000000000000003 [ 105.395238] x17: 0000ffff9d7b0250 x16: 0000aaaac755ff20 x15: 0000ffff9d8b3d00 [ 105.395246] x14: 0000000000000000 x13: 000000000000002f x12: 0000ffffce18e990 [ 105.395255] x11: 00000000ffffff80 x10: 000000000000000a x9 : 0000000000000010 [ 105.395262] x8 : 0000000000000006 x7 : 0000ffffce18e8b0 x6 : 0000ffffce18ea28 [ 105.395270] x5 : 0000ffffce18e9a8 x4 : 0000000000000020 x3 : 0000000000000006 [ 105.395278] x2 : 0000ffffce18e850 x1 : 0000aaaac7541440 x0 : 0000ffffce18e878 [ 105.395288] Kernel panic - not syncing: Asynchronous SError Interrupt [ 105.395291] CPU: 3 PID: 399 Comm: devmem2 Not tainted 6.6.40-xilinx-g8703df42d988 #1 [ 105.395297] Hardware name: Xilinx ZynqMP (DT) [ 105.395300] Call trace: [ 105.395302] dump_backtrace+0x90/0xe8 [ 105.395314] show_stack+0x18/0x24 [ 105.395320] dump_stack_lvl+0x48/0x60 [ 105.395331] dump_stack+0x18/0x24 [ 105.395339] panic+0x31c/0x384 [ 105.395348] nmi_panic+0x8c/0x90 [ 105.395356] arm64_serror_panic+0x6c/0x78 [ 105.395362] do_serror+0x28/0x68 [ 105.395368] __el0_error_handler_common+0x40/0xa4 [ 105.395375] el0t_64_error_handler+0x10/0x1c [ 105.395381] el0t_64_error+0x190/0x194 [ 105.395389] SMP: stopping secondary CPUs [ 105.395399] Kernel Offset: disabled [ 105.395401] CPU features: 0x0,00000008,00020000,0000420b [ 105.395405] Memory Limit: none [ 105.584226] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- ________________________________ As you can see, this only happens with writes, as reads don't crash the system (however they return 0s, which could suggest that a read is not really occurring and that these are dummy values). I have confirmed that with the previous version of the OS, this crash has not happened. I have also tested this issue in U-Boot in order to rule out just a kernel issue, and the same issue occurs: ________________________________ ZynqMP> md 0xa0010000 1 a0010000: 00000000 .... ZynqMP> mw 0xa0010000 0x101 ZynqMP> md 0xa0010000 1 a0010000: 00000101 .... *JTAG Reprogramming* ZynqMP> md 0xa0010000 1 a0010000: 00000000 .... ZynqMP> mw 0xa0010000 0x101 "Error" handler, esr 0xbf000000 elr: 0000000008033120 lr : 00000000080337a8 (reloc) elr: 000000007feab120 lr : 000000007feab7a8 x0 : 0000000000000000 x1 : 0000000000000000 x2 : 0000000000000004 x3 : 000000007be07b75 x4 : 0000000000000100 x5 : 0000000000000000 x6 : 000000007ff68196 x7 : 0000000000000044 x8 : 0000000000000010 x9 : 0000000000000001 x10: 000000000000000d x11: 0000000000000006 x12: 000000007bde7e18 x13: 000000007bde7f70 x14: 0000000000000008 x15: 000000007bde7bb1 x16: 000000007fe97550 x17: 0000000000000000 x18: 000000007bdf7d70 x19: 0000000000000000 x20: 000000000000000b x21: 0000000000000000 x22: 000000007be07c50 x23: 0000000000000001 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 000000000000000b x28: 000000007be07bc0 x29: 000000007bde7d00 Code: b00008e0 91260000 f90057e0 b4000576 (b9401ec0) Resetting CPU … ### ERROR ### Please RESET the board ### ________________________________ The same sequence in u-boot the old OS does not cause a crash, and the writes occur. I have tried many fixes, including trying to look for differences in device trees, but have yet to have any luck. Any idea where this could come from? Met vriendelijke groet / kind regards, Mike Looijmans System Expert [thumb_TOPIC logo email.gif] TOPIC Embedded Products B.V. Materiaalweg 4 5681 RJ Best T: +31 (0) 499 33 69 69 The Netherlands E: [email protected]<mailto:[email protected]> W: www.topic.nl<http://www.topic.nl> L: LinkedIn<https://www.linkedin.com/company/topic-embedded-systems> Please consider the environment before printing this e-mail
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5797): https://lists.yoctoproject.org/g/meta-xilinx/message/5797 Mute This Topic: https://lists.yoctoproject.org/mt/116034770/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
