TE0835 QSPI Programming on Linux Fails(linux-xlnx-2021.1)

[sagirbas]

Hello Everyone,

I have TE0835 module and have Linux kernel linux-xlnx-2021.1. I can %100 percent boot from QSPI as long as I am able to write to the QSPI. My problem is:

* Totally randomly, at some boots I can program the QSPI with flashcp
*At some boots, I can't program the QSPI and have the below error with flashcp.


flashcp -v /media/fat/ /dev/mtd2
Erasing blocks: 1/1 (100%)[   86.830116] ------------[ cut here ]------------
[   86.839060] Enabling unprepared ▒    wq
[   86.842752] WARNING: CPU: 1 PID: 528 at drivers/clk/clk.c:1011 clk_core_enable+0xa4/0xc0
[   86.850827] Modules linked in: u_dma_buf(O) tmp116(O) uio_pdrv_genirq
[   86.857272] CPU: 1 PID: 528 Comm: flashcp Tainted: G        W  O      5.10.0-xilinx-v2021.1 #1
[   86.865870] Hardware name: xlnx,zynqmp (DT)
[   86.870039] pstate: 00000085 (nzcv daIf -PAN -UAO -TCO BTYPE=--)
[   86.876036] pc : clk_core_enable+0xa4/0xc0
[   86.880124] lr : clk_core_enable+0xa4/0xc0
[   86.884211] sp : ffff800011acb5c0
[   86.887509] x29: ffff800011acb5c0 x28: 0000000000000000
[   86.892813] x27: ffff0008702cd548 x26: 0000000000000000
[   86.898116] x25: 00000014329105b9 x24: 0000000000000001
[   86.903420] x23: ffff00087113bc80 x22: ffff000871142290
[   86.908723] x21: ffff000871766000 x20: 0000000000000000
[   86.914026] x19: ffff000871766008 x18: 0000000000000030
[   86.919330] x17: 0000000000000000 x16: 0000000000000000
[   86.924633] x15: ffff000870b30690 x14: ffffffffffffffff
[   86.929937] x13: ffff8000113225a8 x12: 0000000000000522
[   86.935240] x11: 00000000000001b6 x10: ffff80001134e5a8
[   86.940544] x9 : 00000000fffff800 x8 : ffff8000113225a8
[   86.945847] x7 : ffff80001134e5a8 x6 : 0000000000000000
[   86.951151] x5 : 0000000000000001 x4 : ffff00087f7899e0
[   86.956454] x3 : 0000000000000000 x2 : 0000000000000002
[   86.961758] x1 : 6fa58d9746b89300 x0 : 0000000000000000
[   86.967061] Call trace:
[   86.969494]  clk_core_enable+0xa4/0xc0
[   86.973235]  clk_enable+0x2c/0x50
[   86.976545]  zynqmp_runtime_resume+0x24/0x84
[   86.980806]  pm_generic_runtime_resume+0x30/0x50
[   86.985414]  __genpd_runtime_resume+0x30/0xb0
[   86.989761]  genpd_runtime_resume+0x90/0x250
[   86.994023]  __rpm_callback+0xe0/0x180
[   86.997764]  rpm_callback+0x5c/0x8c
[   87.001236]  rpm_resume+0x36c/0x5f4
[   87.004708]  __pm_runtime_resume+0x54/0x7c
[   87.008797]  spi_mem_access_start.isra.0+0x30/0x80
[   87.013579]  spi_mem_exec_op+0x3b0/0x424
[   87.017496]  spi_nor_erase+0xdc/0x77c
[   87.021151]  mtd_erase+0x110/0x1c0
[   87.024543]  mtdchar_ioctl+0xb18/0xd4c
[   87.028283]  mtdchar_unlocked_ioctl+0x40/0xd0
[   87.032634]  __arm64_sys_ioctl+0xb8/0xe0
[   87.036549]  el0_svc_common.constprop.0+0x94/0x1e0
[   87.041330]  do_el0_svc+0x44/0xb0
[   87.044638]  el0_svc+0x14/0x20
[   87.047683]  el0_sync_handler+0x1a4/0x1b0
[   87.051685]  el0_sync+0x174/0x180
[   87.054990] ---[ end trace 8c9440f4ccd423db ]---
[   87.059656] zynqmp-qspi ff0f0000.spi: Cannot enable APB clock.
[   87.065539] spi_master spi0: Failed to power device: -108

While erasing blocks 0x00000000-0x00020000 on /dev/mtd2: Cannot send after transport endpoint shutdown


During the boot, I can either program the QSPI or not. Part of my device tree related to QSPI is also attached.

Thank you in advance,
Serhat Agirbas

[JH]

Hi,
as far as I know flash copy doesn't work with every Vivado version...we had a few versions where only write went but not read back and some where it didn't go at all. You'd have to ask AMD, but I think you've already done that, right? That's your post?:
https://support.xilinx.com/s/question/0D54U00006xEY3CSAW/zynqmp-qspi-programming-on-linux-failslinuxxlnx20211?language=en_US

here is some other one how say he has also problems with 21.1:
https://support.xilinx.com/s/question/0D52E00006jqsf3SAA/petalinux-20211-qspi-driver-unable-to-readback-correct-data-from-memory?language=en_US
there it looks like 18.2 works...maybe compare drivers from both version or try out newer version. 22.2 or 23.1?
br
John

[sagirbas]

Hi,

Thank you for your response. Tested with both mtd-utils 2.00(Yocto rocko-next, which is driver for Xilinx 2018.2) and mtd-utils 2.1.15(master) but the error still exists. Do you have any other possible suggestions?

BR,
Serhat

[JH]

Hi,
maybe try newer one...there are a lot of changes for QSPI drivers:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841901/Linux+ZynqMP+GQSPI+Driver

I've also checked your device tree.
on one point you set "spi-tx-bus-width = <0x4>;" and  later "spi-tx-bus-width = <0x1>;"
maybe this is the problem. Normally this part is autogenerated, we set only part of the device tree, but we didn't check flash copy functionality on any release...
Here our device tree hooks from 20.2 design: https://wiki.trenz-electronic.de/display/PD/TE0835+Test+Board#TE0835TestBoard-DeviceTree
Design includes also binaries, so you can check if flash copy works there.
br
John

[sagirbas]

Hi,

Thank you for the answer. The reason why I set  "spi-tx-bus-width = <0x1>;" is the below wiki by Xilinx,

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841901/Linux+ZynqMP+GQSPI+Driver

Also I tried with the device-tree you sent, it is the same, I have the same error randomly. Would you have any other suggestions?

Best Regards,
Serhat

[JH]

Hi,
what's happens when you use our prebuilt binaries(linux files) from the reference design download? Simple put them on SD and boot one time.
Probably you have the same problem, but would be at least a quick try.
br
John

[sagirbas]

Hi,

As for as I see from the below link, prebuilt TE0835 OS are only for 2019.2 and 2020.2, so those Images may not meet our needs since our problem is on 2021.1. Thanks for the advice, any other thoughts on that?


https://shop.trenz-electronic.de/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/6.5x9/TE0835/Reference_Design

[JH]

Hi,
idea was that you see if flash copy simple works with 2020.2 and in this case you can decide if you update maybe only to 2020.2 or you compare drivers. Or make simple version cross test(Boot.bin from 20.2 with Linux image from 22.2 and the other way around) to narrow down the problem. Attention you should only do this to isolate errors, mixing versions can sometimes have strange side effects.
Sorry, otherwise I can not think of anything right now and TE0835 is also a little further back in the design update list (unfortunately, there is currently no other way)
br
John