U-Boot Ultrazed-EG QSPI NOR access issues (data corruption)
Michal Simek
michal.simek at xilinx.com
Mon Nov 15 15:09:56 CET 2021
Hi, +Ashok
On 11/9/21 18:10, Igor Opaniuk wrote:
> 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
I am not quite sure about these versions. Xilinx is using 2021.1 or
2021.2 versions. Above versions look weird.
Upstream should support only single configuration not anything else.
> 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
Ashok: Can you please take a look at it?
Thanks,
Michal
More information about the U-Boot
mailing list