Hi Michal,
I'm currently observing QSPI NOR access issues, for instance both read/write operations return invalid data (even using sf read for the images flashed from Linux using mtd-utils/flashcp). I was able to reproduce this issue on both Xilinx downstream U-Boot xilinx-v2022.01-bsp, xilinx-v2021.07-bsp and U-Boot mainline. This issue doesn't reproduce in Linux using mtd-utils (using flashcp and mtd_debug, both writing/reading work perfectly):
# flashcp u-boot0001.itb /dev/mtd3 # mtd_debug read /dev/mtd3 0x0 0x6D95B9 /mnt/u-boot0001.itb.dump Copied 7181753 bytes from address 0x00000000 in flash to /mnt/u-boot0001.itb.dump # md5sum u-boot0001.itb 730a86e2677dd082f72d5c3f6d20458a u-boot0001.itb # md5sum u-boot0001.itb.dump 730a86e2677dd082f72d5c3f6d20458a u-boot0001.itb.dump
However when I dump the same image from U-Boot after reboot: sf probe; mmc dev ${bootseq}; sf read ${loadaddr} 0x100000 0x6d9be1; fatwritemmc ${bootseq}:1 ${loadaddr} u-boot0001.itb.dump 0x6D95B9; and then md5summ: # md5sum u-boot0001.itb.dump 841f088fdfd9fd12d080711030faecdd
Check the attached screenshot of binary diff (usually around 3-4% of dumped file is randomly filled with zeros instead of correct data). I've also tried to lower QSPI clock frequency and check if it has any impact - same corruption issues are reproduced.
btw, I noticed different capabilities (erase block size, 128 vs 64kb, I guess in U-Boot dual spi mode is not selected for some reason) reported in Linux and U-Boot: # mtdinfo /dev/mtd0 mtd0 Name: spi0.0 Type: nor Eraseblock size: 131072 bytes, 128.0 KiB Amount of eraseblocks: 512 (67108864 bytes, 64.0 MiB) Minimum input/output unit size: 1 byte Sub-page size: 1 byte Character device major/minor: 90:0 Bad blocks are allowed: false Device is writable: true
U-Boot: ZynqMP> sf probe; SF: Detected n25q256ax1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
board: Avnet Ultrazed-EG SoM + Ultrazed-EG IO Carrier defconfig: xilinx_zynqmp_virt_defconfig device tree: zynqmp-zcu102-rev1.0.dts is used
Have you ever noticed similar issues on this/other boards with this SoC? Any ideas what could be a root cause?
Looking forward for you reply
Regards, Igor
