10-27-2019 05:39 PM
We just upgraded our U-Boot and Kernel to the 2019.1 tags from the Xilinx github and are having problems with QSPI access. When loading with 2018.3, we observe the following from u-boot:
ZynqMP> sf probe 0 && sf read 0x01000000 0 20 SF: Detected n25q256a with page size 256 Bytes, erase size 64 KiB, total 32 MiB device 0 offset 0x0, size 0x20 SF: 32 bytes @ 0x0 Read: OK ZynqMP> md 0x01000000 20 01000000: 14000000 14000000 14000000 14000000 ................ 01000010: 14000000 14000000 14000000 14000000 ................ 01000020: aa995566 584c4e58 00000000 fffc0000 fU..XNLX........ 01000030: 00002800 0001fae0 0001fae0 000192f8 .(..............
I then switched the BOOT.bin to the 2019.1 u-boot and got the following:
ZynqMP> sf probe 0 && sf read 0x01000000 0 20 SF: Detected n25q256a with page size 256 Bytes, erase size 64 KiB, total 32 MiB device 0 offset 0x0, size 0x20 SF: 32 bytes @ 0x0 Read: OK ZynqMP> md 0x01000000 20 01000000: 00001400 00001400 00001400 00001400 ................ 01000010: 00001400 00001400 00001400 55661400 ..............fU 01000020: 4e58aa99 0000584c 00000000 2800fffc ..XNLX.........( 01000030: fae00000 fae00001 a3e00001 a3e00001 ................
As you can see, it appears the readback is missing 2 bytes at the end. I looked through the GQSPI driver code and the only thing that looks like it changed was related to the Tap delays. I tried reverting those lines to match the 2018.3 driver code but there was no change in the output.
We are using the Avnet UltraZed-EV SOM which has the n25q256a flash chip in dual parallel mode. I've tried lowering the spi-max-frequency, changing is-dual to 0, playing with different "compatible" strings, nothing seems to work.
10-27-2019 05:41 PM
I should also mention, running from Linux also fails, when trying "flashcp" to write to a /dev/mtdX partition the verification step always fails immediately.
10-27-2019 08:30 PM
11-19-2019 05:23 PM
Finally circling back to this, we successfully can read/erase/write the qspi flash from U-boot using sf commands. As another post suggested, we lowered our clock speed way down and it now works.
However, "flashcp" from petalinux to any of our "mtd" partitions still always fails verification immediately. Our device tree is the same between u-boot and petalinux, so now i really don't know why its failing from linux. My only guess is that the drivers are radically different:
Anyone else run into this before?