U-Boot Ultrazed-EG QSPI NOR access issues (data corruption)

[Igor Opaniuk]

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
-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk
Embedded Software Engineer
T:  +380 938364067
E: igor.opaniuk at foundries.io
W: www.foundries.io
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 231338 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211109/358f86fb/attachment-0001.png>