read problem with nor flash

[xiuqi_huang]

Hi Team:

    When I use the mtd_debug tool to read memory from nor flash, the first seven bytes of every 128 bytes in the output result are zero.

    following are mtd commands：

     #mtd_debug erase /dev/mtd0 0x5a0000 0x200000

     #mtd_debug read /dev/mtd0 0x5a0000 0x200000 /data/erase.img

    If I change dummy.nbytes to 8 in function spi_nor_create_read_dirmap() in drivers/mtd/spi-nor/core. c, the 7-byte zero will disappear, but occasionally the first, third, and fourth data lines will be delayed by one cycle when pulled up. Therefore the first byte in the output will become F2 or FE or F8

    The read protocol I am using is STR_1_1_8, the clock frequency is 200MHz 

    How can I solve this problem?

Huang

[eldorr]

Gents,

I have a (very) similar issue with my FLEX SPI NOR Flash on my custom i.MX9 board; I.e. unstable SPI NOR Flash read/write that every time results in segfault - e.g.

[root@imx93evk /mnt/swbank]# flashcp -A ./mxImage /dev/mtd3
[ 1156.397511] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
[ 1156.405704] Modules linked in:
[ 1156.408751] CPU: 1 PID: 760 Comm: flashcp Not tainted 6.1.55-g2cb8508dd2db #6
[ 1156.415872] Hardware name: NXP i.MX93 11X11 EVK board (DT)
[ 1156.421342] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1156.428291] pc : __memcpy_fromio+0x58/0xb0
[ 1156.432390] lr : nxp_fspi_exec_op+0x89c/0xe50
[ 1156.436741] sp : ffff80000aa8b670
[ 1156.440043] x29: ffff80000aa8b6b0 x28: 0000aaaade35f2d0 x27: ffff80000aa8bdc0
[ 1156.447167] x26: ffff00000c1d49c0 x25: ffff0000084dd880 x24: ffff0000084dd580
[ 1156.454291] x23: ffff0000084dd000 x22: 0000000008000000 x21: ffff0000084dd5e8
[ 1156.461415] x20: 0000000000000800 x19: ffff80000aa8ba10 x18: 0000000000000000
[ 1156.468539] x17: 0000000000000000 x16: 00000000000001a0 x15: 0000000000000000
[ 1156.475663] x14: 0000000000000000 x13: 0000000000000002 x12: ffff000027e019a0
[ 1156.482787] x11: 0000000000000004 x10: 000000000000001d x9 : 00000000ffffff00
[ 1156.489911] x8 : 000000000000320a x7 : 0000000000000001 x6 : 0000000000000800
[ 1156.497035] x5 : 00ffffffffffffff x4 : ffff80000cdf0000 x3 : ffff000008870800
[ 1156.504159] x2 : 0000000000000800 x1 : ffff80000cdf0000 x0 : ffff000008870000
[ 1156.511284] Call trace:
[ 1156.513720] __memcpy_fromio+0x58/0xb0
[ 1156.517462] spi_mem_exec_op+0x39c/0x3f0
[ 1156.521380] spi_mem_no_dirmap_read+0xa0/0xc0
[ 1156.525730] spi_mem_dirmap_read+0xd4/0x140
[ 1156.529908] spi_nor_read_data+0x114/0x180
[ 1156.533990] spi_nor_read+0xb4/0x160
[ 1156.537552] mtd_read_oob_std+0x78/0x90
[ 1156.541382] mtd_read_oob+0x8c/0x150
[ 1156.544944] mtd_read+0x68/0xb0
[ 1156.548073] mtdchar_read+0x224/0x2a0
[ 1156.551730] vfs_read+0xc4/0x2c0
[ 1156.554954] ksys_read+0x74/0x110
[ 1156.558256] __arm64_sys_read+0x1c/0x30
[ 1156.562078] invoke_syscall+0x48/0x110
[ 1156.565823] el0_svc_common.constprop.0+0x44/0xf0
[ 1156.570520] do_el0_svc+0x2c/0xd0
[ 1156.573822] el0_svc+0x2c/0x90
[ 1156.576872] el0t_64_sync_handler+0x114/0x120
[ 1156.581214] el0t_64_sync+0x18c/0x190
[ 1156.584868] Code: 927df0c6 910020c6 8b060003 d503201f (f9400085)
[ 1156.590950] ---[ end trace 0000000000000000 ]---
Segmentation fault

My .dts patched as follows:

+ pinctrl_flexspi1: flexspi1grp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__FLEXSPI1_A_SCLK 0x51e
+ MX93_PAD_SD3_CMD__FLEXSPI1_A_SS0_B 0x51e
+ MX93_PAD_SD3_DATA0__FLEXSPI1_A_DATA00 0x51e
+ MX93_PAD_SD3_DATA1__FLEXSPI1_A_DATA01 0x51e
+ MX93_PAD_SD3_DATA2__FLEXSPI1_A_DATA02 0x51e
+ MX93_PAD_SD3_DATA3__FLEXSPI1_A_DATA03 0x51e
+ >;

and

+&flexspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi1>;
+ assigned-clock-rates = <80000000>;
+ status = "okay";
+
+ flash: mt25ql02g@0 {
+ compatible = "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <80000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+
+ /* 2 MByte */
+ spl: partition@0 {
+ label = "uboot appl";
+ reg = <0x00000000 0x00200000>;
+ }; //end partition@00000000 (uboot_appl)

etc. etc. with some more partitions

My QSPI NOR Flash is of type (from dmesg):

[ 0.179377] spi-nor spi0.0: mt25ql02g (262144 Kbytes)
[ 0.179540] 5 fixed-partitions partitions found on MTD device 425e0000.spi
[ 0.179546] Creating 5 MTD partitions on "425e0000.spi":
[ 0.179552] 0x000000000000-0x000000200000 : "uboot appl"
[ 0.180579] 0x000000200000-0x000000210000 : "uboot env"
[ 0.181407] 0x000000210000-0x000006210000 : "mx image 1"
[ 0.182233] 0x000006210000-0x00000c210000 : "mx image 2"
[ 0.183095] 0x00000c210000-0x000010000000 : "fs"

I have tried out 133MHz (max) and now running at 80MHz - still same issue.

Based on your testing ... did you figure out the root cause, and a possible solution?

Thanks.

/Eldor

[Daniel-Aguirre]

Hi,

Which BSP version are you using? Also, have you tried lowering the frequency? Do you have the same problem?

Please, let us know.

[xiuqi_huang]

Hi Daniel，

        The BSP version is BSP32. I have tried to lower the frequency to 166 MHz or below, but the same problem still occurs.

        Additionally I tried to use protocol 1_1_1 at normal read mode, and lower the frequency to 40MHz, at which point the read output is correct, but sometimes segmentation fault may occur.

pc : __memcpy_fromio+0x58/0xb0

lr : s32gen1_exec_op+0x10c/0x284

sp : ffffffc0158b3750

x29: ffffffc0158b3750 x28: ffffff8002dd4080

x27: ffffffc0158b3e20 x26: 0000007fa9994010

x25: ffffffc011845000 x24: 00000000030f004c

x23: 000000000000000a x22: ffffff8002e74600

x21: 0000000000000000 x20: ffffffc0158b3b10

x19: ffffff8002e70600 x18: 0000000000000000

x17: 0000000000000000 x16: 0000000000000000

x15: 0000000000000000 x14: 0000000000000000

x13: 0000000000000000 x12: ffffffc0114f9b28

x11: 0000000000000001 x10: 0000000000000001

x9 : ffffffc01082206c x8 : 000000006f2d9830

x7 : 0007a12000000000 x6 : 0000000000200000

x5 : ffffffffffffffff x4 : ffffffc0215a07f8

x3 : ffffff8015000000 x2 : 0000000000200000

x1 : ffffffc0215a0000 x0 : ffffff8014e007f8

Call trace:

 __memcpy_fromio+0x58/0xb0

 spi_mem_exec_op+0x39c/0x3f4

 spi_mem_dirmap_read+0x160/0x1bc

 spi_nor_spimem_read_data+0xc8/0x154

 spi_nor_read+0xe8/0x180

 mtd_read_oob_std+0x80/0x90

 mtd_read_oob+0x8c/0x150

 mtd_read+0x54/0x90

 mtdchar_read+0xdc/0x294

 vfs_read+0xb8/0x1ec

 ksys_read+0x74/0x100

 __arm64_sys_read+0x28/0x34

 el0_svc_common.constprop.0+0x9c/0x1f0

 do_el0_svc+0x78/0xa0

 el0_svc+0x20/0x30

 el0_sync_handler+0x1a4/0x1b0

 el0_sync+0x180/0x1c0

Code: 927df0c6 910020c6 8b060003 d503201f (f9400085)

---[ end trace 13cb3c0a44f3c8b6 ]---

Segmentation fault

I also tried some other methods：

1、protocol 1_1_1 at 200MHz, dummy.nbytes=0

     commands: #mtd_debug write dev/mtd0 0x5a0000 0x200000 /data/test.img

                        #mtd_debug read /dev/mtd0 0x5a0000 0x200000 /data/read.img

    the first bytes in read.img is FF, which is not the same with the test.img

2、FAST READ protocol 1_1_1 at 200 MHz with DQS signal, dummy.nbytes=8

     Segmentation fault is no longer occur, but sometimes hundrands of bytes in the middle of read.img will be wrong, and the lower the clock frequency, the higher the frequency of errors occurring.

3、STR_1_1_8 at 200MHz with DQS signal, and changed the dummy.nbytes to 8 at the function  spi_nor_spimem_read_data() 

         If I using following commands, the outcome is correct. 

                mtd_debug read 0x5a0000 0x1000 /data/erase.img

        Once I set 0x1000 to 0x200000, the same segmentation fault will occur

[Daniel-Aguirre]

Hi,

Thanks for feedback.

We will comment this out with the internal team, to see if they have any recommendations on this regard.

Also, forgot to ask, are you using an NXP provided platform? Or is it a custom board?

Please, let us know.

[xiuqi_huang]

Hi Daniel，

    I'm sorry for taking so long to reply.

    I'm using a customized board based on NXP provided platform, the flash chip model is mt35xu512aba. Now I use SNOR_PROTO_1_1_1 to read data from memory without DQS signal at 40MHz, the output is perfectly right. It seems that the DQS signal caused the segmentation fault.

    However, the SNOR_PROTO_1_1_8 and SNOR_PROTO_8_8_8_DTR still have the same problems like I posted before.

[Daniel-Aguirre]

Hi,

No problem. Thanks for your feedback.

We will send this information to our internal team. Also, the internal team provided some comments on regards of the previous information:

"I have not used the mtd_debug tool. but It is not a usage issue and It would be caused by the QSPI configuration.

Firstly, the different flash chip has different configuration. And different frequencies also need different QSPI configurations. As customer side. "I tried to use protocol 1_1_1 at normal read mode, and lower the frequency to 40MHz, at which point the read output is correct". We understand that the configuration of QSPI and the flash chip is on the SDR with low frequency/clock, and if the customer wants to use the high frequency/clock to operate the flash they should configure the QSPI controller and switch the mode of the Flash chip.

So If customers want to use the high frequencies of QSPI, customer should know how to configure the QSPI parameter for different modes. Please let the customer refer to the AN S32G Quad Serial Peripheral Interface (QSPI) Deep Dive at firstly"

Please, let us know.

[xiuqi_huang]

Hi Daniel，

    Thank you for your suggestion. Does this mean taht I need to modify the configurations of some registers in drivers/spi/s32gen1-qspi.c, such as LUT[0]? Is there a relevant guide of how to support and use a new flash chip in linux kernel. And what's the default QSPI configurations in linux kernel at BSP32.

[Daniel-Aguirre]

Hi,

The NOR Flash itself needs to be reconfigured to be able to use a wider bus, DDR or even higher frequencies. This needs to be done prior to attempting any access in a different way than the default NOR Flash configuration is shipped with.

As for new chips, the only information available under S32G2 is the AN13563, which is the QSPI Deep Dive mentioned by our internal team.

As for specific instruction on how to do it on Linux, we did not seem to find anything, we apologize.

Please, let us know.