cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
bhig
Contributor
Contributor
509 Views
Registered: ‎09-01-2017

GQSPI driver problem 2019.1

Hello,

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.

Any ideas?

Thanks!

 

0 Kudos
3 Replies
bhig
Contributor
Contributor
506 Views
Registered: ‎09-01-2017

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.

0 Kudos
bhig
Contributor
Contributor
478 Views
Registered: ‎09-01-2017

A couple more observations:
1. Writing with the 2018.3 and 2018.2 (tested the avent “out of box” prebuilt files which are 2018.2 as a sanity check) versions of u-boot via “sf write” also don’t work, but reading does work.
2. The 2018.3 versions were actually using the previous driver “zynqmp_qspi.c”, not the zynqmp_Gqspi.c so I’ll have to go through the changes between them too.
0 Kudos
bhig
Contributor
Contributor
384 Views
Registered: ‎09-01-2017

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:

linux/drivers/spi/spi-zynqmp-gqspi.c

vs

uboot/drivers/spi/zynqmp_gqspi.c

Anyone else run into this before?

Thanks,

Bryan

0 Kudos