TE0803 QSPI n25q512a vs. mt25qu512a In Linux weird behaviour.

[ti-ger]

Hi,
I have 2 variants (Flash parts n25q512a vs. mt25qu512a) of the TE0803 which behave very different using the QSPI Flash.
I am trying to migrate out Design to the 2023.1 Linux Xilinx release (Linux 6.1). 
The Module with the mt25qu512a works fine, no problems so far.
The Module with the n25q512a flash parts is strange:
JTAG-Flashing and booting from QSPI works good, but the flash can't be used properly in Linux with the mtdutils.
After doing a flash_erase or flashcp on a mtd partition, the whole flash seems corrupted and I can no boot anymore (need JTAG-Reflash). I have double chekc my device-tree to mathc the 2023.1 Vitis Release.

Also Reading from Flash is not working. I have programed the user-defined header Field in the bootimage with a custom string and build date. After jtag-programming I can see corrupted data in the flash. The weird thing: In u-boot everthing looks good. Here I have some examples:
You can see the corrupted string at Offset 0x70: It should be LINUX-230807-104332

I use the TE0803 on a TEBF0808 Carrier-Board.
I get the same erro on the Xilinx ZCU102-Evalboard which uses the same n25q512a flash parts.

The TE0803 with mt25qu512a uses the same device-tree, uboot and linux image and works fine.


Boot image file:

Code: [Select]

00000000  00 00 00 14 00 00 00 14  00 00 00 14 00 00 00 14  |................|
00000010  00 00 00 14 00 00 00 14  00 00 00 14 00 00 00 14  |................|
00000020  66 55 99 aa 58 4e 4c 58  00 00 00 00 00 00 00 00  |fU..XNLX........|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 08 00 00  41 54 1a fd 00 00 00 00  |........AT......|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 20 00 00 01  |............ ...|
00000070  4c 49 4e 55 58 2d 32 33  30 38 30 37 2d 31 30 34  |LINUX-230807-104|
00000080  33 33 32 0a 00 00 00 00  00 00 00 00 00 00 00 00  |332.............|
00000090  00 00 00 00 00 00 00 00  c0 08 00 00 00 11 00 00  |................|

U-Boot:

Code: [Select]

ZynqMP> sf probe
SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB

ZynqMP> sf read 0 0x04000000 128
device 0 offset 0x4000000, size 0x128
SF: 296 bytes @ 0x4000000 Read: OK

ZynqMP> md 0 32
00000000: 14000000 14000000 14000000 14000000  ................
00000010: 14000000 14000000 14000000 14000000  ................
00000020: aa995566 584c4e58 00000000 00000000  fU..XNLX........
00000030: 00000000 00000000 00000000 00000000  ................
00000040: 00000000 00000800 fd1a5441 00000000  ........AT......
00000050: 00000000 00000000 00000000 00000000  ................
00000060: 00000000 00000000 00000000 01000020  ............ ...
00000070: 554e494c 33322d58 37303830 3430312d  LINUX-230807-104
00000080: 0a323333 00000000 00000000 00000000  332.............
00000090: 00000000 00000000 000008c0 00001100  ................
000000a0: 00000000 00000000 00000000 00000000  ................
000000b0: 00000000 00000000 ffffffff 00000000  ................
000000c0: ffffffff 00000000                    ........

Linux:

Code: [Select]

hexdump -Cv /dev/mtd2|head
00000000  00 00 00 14 00 00 00 14  00 00 00 14 00 00 00 14  |................|
00000010  00 00 00 14 00 00 00 14  00 00 00 14 00 00 00 14  |................|
00000020  66 55 99 aa 58 4e 4c 58  00 00 00 00 00 00 00 ff  |fU..XNLX........|
00000030  00 28 00 00 00 00 00 00  00 00 00 00 00 89 00 00  |.(..............|
00000040  00 89 00 00 00 08 00 00  41 1a 1a fd 00 00 00 00  |........A.......|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 20 00 00 01  |............ ...|
00000070  4c 59 4e 51 58 50 32 32  30 30 30 30 2d 5f 30 30  |LYNQXP220000-_00|
00000080  33 33 32 30 00 00 00 00  00 00 00 00 00 00 00 00  |3320............|
00000090  00 00 00 00 00 00 00 00  c0 08 00 00 00 11 00 00  |................|


My device-tree:

Code: [Select]

&qspi {
is-dual = <1>;
num-cs = <2>;
status = "okay";
flash@0 {
        compatible = "jedec,spi-nor";
        #address-cells = <1>;
        #size-cells = <1>;
        reg = <0>, <1>;
parallel-memories = /bits/ 64 <0x4000000 0x4000000>; /* 2x64MB */
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
        spi-max-frequency = <54000000>;
fpga0@0 {
label = "fpga0";
reg = <0x00000000 0x02000000>; // 32MB
};
fpga1@2000000 {
label = "fpga1";
reg = <0x02000000 0x02000000>; // 32MB
};
osimage0@4000000 {
label = "osimage0";
reg = <0x04000000 0x01000000>; // 16MB
};
osimage1@5000000 {
label = "osimage1";
reg = <0x05000000 0x01000000>; // 16MB
};
bootcfg@6000000 {
label = "bootcfg";
reg = <0x06000000 0x00100000>; // 1MB
};
reserved@1F00000 {
label = "reserved";
reg = <0x06100000 0x01F00000>; // 31MB
};
};
};

[M Kirberg]

Hi,

this seems to be a Linux driver issue then, when Xilinx Board has the same problem.

We do not use 2023.1 currently, so sorry we cannot help further.

best

[ti-ger]

I have found the solution:
there is a Bug from Xilinx.
It prevents, that Flashes which default to 3-Byte address mode, to set them to 4-Byte address mode.
The Xilinx relase code reads a variable which is not set at that time (nor->mtd.size)
Here is my bugfix: It is based on the Git tag: https://github.com/Xilinx/linux-xlnx/tree/xlnx_rebase_v6.1_2023.1   

Code: [Select]

Index: drivers/mtd/spi-nor/core.c
===================================================================
--- drivers/mtd/spi-nor/core.c
+++ drivers/mtd/spi-nor/core.c
@@ -2856,7 +2856,7 @@
  nor->addr_nbytes = 3;
  }
 
- if (nor->addr_nbytes == 3 && nor->mtd.size > 0x1000000) {
+ if (nor->addr_nbytes == 3 && params->size > 0x1000000) {
  np_spi = of_get_next_parent(np);
  if (of_property_match_string(np_spi, "compatible",
       "xlnx,zynq-qspi-1.0") >= 0) {


[M Kirberg]

Thanks for sharing