TE0745 QSPI NOR access from Linux

[th-oc]

I have issue getting QSPI NOR flash to init on linux on a TE0745 SOM:

Code: [Select]

[    1.588781] spi-nor spi0.0: can't select read settings supported by both the SPI controller and memory.
[    1.598242] spi-nor: probe of spi0.0 failed with error -22
the max speed supported by the NOR flash chip is 54MHz. if I put that as the spi-max-frequency I get the above message. if i put as the spi-max-frequency 100MHz in the device tree it is able to select a read setting but the device does not read the JEDEC ID as obviously the speed is too high. Can anyone suggest a change to the device tree? I am using linux 5.4.0

Code: [Select]

&qspi{
status = "okay";
num-cs = <1>;
flash@0 {
compatible = "micron,n25q512a", "jedec,spi-nor";
reg = <0x0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <1>;
spi-max-frequency = <50000000>;
#address-cells = <1>;
#size-cells = <1>;
partition@qspi-spl-header {
label = "qspi-spl-header";
reg = <0x0 0x40000>; // 256KB
};
partition@qspi-boot-fat {
label = "qspi-boot-fat";
reg = <0x40000 0x1000000>; // 16MB - 256KB
};
partition@qspi-minimal-rootfs-fat {
label = "qspi-minimal-rootfs-fat";
reg = <0x1000000 0x2000000>; // 16 MB
};
};
};


[JH]

Hi,
we have a reference design with prebuilt binaries and source code:
https://wiki.trenz-electronic.de/display/PD/TE0745+Test+Board

Can you try out prebuilt binaries?
br
John

[th-oc]

I tried the device tree section for the qspi listed in that page but I get the following error.

Code: [Select]

[    1.588734] spi_master spi0: /amba/spi@e000d000/flash@0 has no valid 'spi-max-frequency' property (-22)
[    1.598196] spi_master spi0: Failed to create SPI device for /amba/spi@e000d000/flash@0
I do not think it is a hardware issue. Just need to configure Linux correctly. We require to use kernel 5.4.0 for some features we are using.

[JH]

do you use petalinux build enviroment or yocto or own make files and cross compiler?

petalinux 2020.2 use kernel 5.4:
https://www.xilinx.com/support/answers/75775.html

TE0745 is 19.2 at the moment, but we have TE0720 on 20.2. Device tree of the qspi was not changed, or changes are here(Xilinx automatic generated part is not included):
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board#TE0720TestBoard-DeviceTree
https://wiki.trenz-electronic.de/display/PD/TE0745+Test+Board#TE0745TestBoard-DeviceTree

br
John

[th-oc]

We use buildroot with the mainline 5.4.0 kernel.

[JH]

Hi,
I can't help much in this case. We use only petalinux.
We have some additional information here:
https://wiki.trenz-electronic.de/display/PD/PetaLinux+KICKstart

Maybe you generate linux at first with petalinux and switch later to your one, in this case you can compare differences.

br
John

[th-oc]

I have now tried the xilinx-v2020.1 kernel, which is their fork of v5.4. This allows the qspi nor flash to be detected as shown below

Code: [Select]

[    1.540000] spi-nor spi0.0: mt25qu512a (n25q512a) (65536 Kbytes)
[    1.540000] 3 fixed-partitions partitions found on MTD device spi0.0
[    1.550000] Creating 3 MTD partitions on "spi0.0":
[    1.560000] 0x000000000000-0x000000040000 : "qspi-spl-header"
[    1.560000] 0x000000040000-0x000001040000 : "qspi-boot-fat"
[    1.570000] 0x000001000000-0x000003000000 : "qspi-minimal-rootfs-fat"
I install some of the mtd tools to allow read / write from the mtd device. I try to write the uboot spl boot.bin to the mtd partition 0 as shown below, but verifying does not work.

Code: [Select]

# flashcp -v /media/boot.bin /dev/mtd0
Erasing blocks: 21/21 (100%)
Writing data: 82k/82k (100%)
Verifying data: 10k/82k (12%)File does not seem to match flash data. First mismatch at 0x00000000-0x00002800
Also when using flash_erase it indicates that the partition has erased successfully, but upon reading out the partition using dd all the bytes are 0 instead of the expected ff.

[JH]

Hi,

we get some information form customer that 2021.1 has problems with  S25FL127S  flash(your TE0745 has other one but maybe it's similar problem).

S25FL127S has  SFDP and the mtd driver switches to 4-byte addressing and 512-byte pages. 4-byte addressing is not implemented in the zynq qspi driver. 512-byte pages simply don’t fit in the FIFOs and data is truncated.

It looks like Xilinx work on an workaround:
Xilinx workaround for 4-byte addressing by disabling it (2021.2): https://github.com/Xilinx/linux-xlnx/commit/d515de41cb61216d8b02b35da64cbf0b9df7217d
Xilinx workaround for 4-byte addressing by using EAR: https://github.com/Xilinx/linux-xlnx/commit/bd78733fffb5720020ae1b7a120d344a6d63af96

But maybe your problem is different on your side. I don't have that much experience with QSPI drivers to be able to help you directly.
Maybe you should write one time on Xilinx forum. community is much bigger there.

br
John

[th-oc]

Thanks for the help John!

I applied a patch to disable parsing the SFDP_4BAIT_ID similar to the first link you sent. Now we can read and write from the flash.

Code: [Select]

---
 drivers/mtd/spi-nor/spi-nor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 7acf4a93b592..89d06a417755 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4135,7 +4135,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
  break;
 
  case SFDP_4BAIT_ID:
- err = spi_nor_parse_4bait(nor, param_header, params);
+ // err = spi_nor_parse_4bait(nor, param_header, params);
  break;
 
  default:
--
2.25.1

[JH]

Hi,
good to hear that you has find a solution for you and thanks for sharing this information!

br
John