[XSDK 2018.2] program_flash fails to flash QSPI NOR flash

[mnsgs]

Hi,

I am trying to flash a custom zynqmp based HW using program_flash (XSDK 2018.2) through JTAG. The flash device is Micron mt25ql02g (dual_parallel) and appears correctly identified by u-boot embedded into the program_flash executable. The file is the following:

martin@dell:~/work/z7000-distro_sumo/build/tmp/deploy/images/nanomind-ultra-zu6eg-uv1$ file nanomind-recovery-image.cpio.gz.u-boot
nanomind-recovery-image.cpio.gz.u-boot: symbolic link to nanomind-recovery-image-nanomind-ultra-zu6eg-uv1-20180709121936.rootfs.cpio.gz.u-boot

martin@dell:~/work/z7000-distro_sumo/build/tmp/deploy/images/nanomind-ultra-zu6eg-uv1$ ls -laH nanomind-recovery-image.cpio.gz.u-boot
-rw-r--r-- 2 martin martin 13845455 Jul 10 12:12 nanomind-recovery-image.cpio.gz.u-boot

and from the output of u-boot it seems to flash correctly 105*0x20000 bytes and the 0x143cf remainder:

ZynqMP> sf write FFFC0000 2020000 20000
device 0 offset 0x2020000, size 0x20000
SF: 131072 bytes @ 0x2020000 Written: OK
ZynqMP> 100%
sf write FFFC0000 2040000 143CF
device 0 offset 0x2040000, size 0x143cf
SF: 82895 bytes @ 0x2040000 Written: OK
ZynqMP> Program Operation successful.

However the verification seems to operate outside the above region which looks suspicious to me:

ZynqMP> sf read FFFC0000 2030000 10000
device 0 offset 0x2030000, size 0x10000
SF: 65536 bytes @ 0x2030000 Read: OK
ZynqMP> cmp.b FFFC0000 FFFD0000 10000
Total of 65536 byte(s) were the same
ZynqMP> sf read FFFC0000 2040000 10000
device 0 offset 0x2040000, size 0x10000
SF: 65536 bytes @ 0x2040000 Read: OK
ZynqMP> cmp.b FFFC0000 FFFD0000 10000
Total of 65536 byte(s) were the same
ZynqMP> 100%
sf read FFFC0000 2050000 43CF
device 0 offset 0x2050000, size 0x43cf
SF: 17359 bytes @ 0x2050000 Read: OK
ZynqMP> cmp.b FFFC0000 FFFD0000 43CF
byte at 0x00000000fffc43ce (0xb3) != byte at 0x00000000fffd43ce (0x2)
Total of 17358 byte(s) were the same
ZynqMP> INFO: [Xicom 50-44] Elapsed time = 134 sec.
Verify Operation unsuccessful.

Log file attached as log_failure.

The file written is an initramfs which fails CRC check upon load and it thus looks like data is in fact not written successfully:

## Loading init Ramdisk from Legacy Image at 01100000 ...
Image Name: nanomind-recovery-image-nanomind
Image Type: AArch64 Linux RAMDisk Image (uncompressed)
Data Size: 13845391 Bytes = 13.2 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalid

Appending an amount of data, according to the below, to the file causes it to succeed:

dd if=/dev/zero bs=975 count=1 >> nanomind-recovery-image.cpio.gz.u-boot

Log file of this is attached as log_success, from which is can be seen that write and verify operation succeeds. The initramfs is furthermore successfully loaded by u-boot.

Is this the right place for reporting what looks to be a bug?

Br,
Martin

[ibaie]

Hi @mnsgs

Thanks for reporting the issue, it seems that something is going wrong with the file (I guess related somehow to the size). I will report it internally to the development team in order to investigate and fix if so.

Could you share the ramdisk image? I mean, it might be easier to reproduce the issue if it is related to some specific size.

Regards

Ibai

[mnsgs]

Hi @ibaie,

Sorry for the late reply and thanks for your feedback.

I prefer not to distribute the ramdisk in a public forum, however can I somehow send it to you in a private thread? The size is of ~13MB, I guess it can be distributed as an email attachment. Otherwise I could upload to a secure FTP server and send you credentials in a private thread.

Thanks,

Martin

[mnsgs]

Hi @ibaie,

Any update on the topic:

1) Did you receive the provided artifacts?

2) Did you manage to reproduce the issue?

3) Can we expect it resolved in 2018.3?

Thanks,

Martin