Linux S32G2 qspi mt35x nor flash read issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Linux S32G2 qspi mt35x nor flash read issue

368 Views
gse31
Contributor III

Hi,

I have a board with s32g2 and micron nor flash (mt35xu512aba).
Linux BSP38 is running.

Expected read in the nor flash is :
xxd -l0x10 fip.s32
00000000: d101 0060 0000 0000 0000 0000 0000 0000

The 7 first read bytes of a qspi transfer are always 0:
~ # xxd -l0x10 /dev/mtd1
00000000: 0000 0000 0000 00d1 0100 6000 0000 0000

All the others bytes are correct. This is just a 7 bytes shift.

It seems to be related to dummy cycles of the mt35xu in 8-8-8 fast read mode.

When I change the op->dummy.nbytes to 8 (instead of 1?) in the linux qspi driver, I have this:
~ # xxd -l0x10 /dev/mtd1
00000000: d001 0060 0000 0000 0000 0000 0000 0000

Only the first byte is not correct: d0 instead of d1.

When reading more, the first byte of all 1kb block are not read correctly (@0, @0x400, @0x800...). Each time the right nibble of the 1st byte is not correct.

QSPI frequency is 133M or tested at 55M, no change.

Is it related to qspi or ahb buffering ?

Thanks for your help.

0 Kudos
Reply
3 Replies

316 Views
chenyin_h
NXP Employee
NXP Employee

Hello, @gse31

Thanks for the feedback.

Regarding to the Linux issue on using s32g2 with mt35 flash, there would some updates on the Linux driver layer, the following several patches could be a reference:

  1. https://github.com/nxp-auto-linux/linux/commit/b1f0e6d5c51a2ae812dbbe166451e140ef8d5699
  2. https://github.com/nxp-auto-linux/linux/commit/ae670dc97873848577d5a9ff835108fbcb9cad27 
  3. https://github.com/nxp-auto-linux/linux/commit/e52cb49a0777c628928ceab3fcbb5b2ea06bdcaa 
  4. https://github.com/nxp-auto-linux/linux/commit/0a4da87996dedc9fac6d11d329b4f44712c036c8 
  5. https://github.com/nxp-auto-linux/linux/commit/5d8b6b129a49e3d289db8f4577c80d942584499b 

However, the above patches are based on kernel version 5.4, as a result, it is only a reference and cannot be directly applied on your own board with BSP38, you may reference them and then re-implement or port it to the 5.15.x to have a full test.

Hope it helps.

 

Best Regards

Chenyin

0 Kudos
Reply

339 Views
chenyin_h
NXP Employee
NXP Employee

Hello, @gse31

Thanks for the question and sorry for the delay.

I mentioned that you ever posted a flash related issues with the following link:

https://community.nxp.com/t5/S32G/S32G2-uboot-mt35xu-flash-nor-read-issue/td-p/1789686

I understand that previously you have fixed the sf read issue under uboot with BSP38 after applying the patches provided.

May I know if your new issue is triggered only under Linux?  Are there similar issue found under uboot while reading from the flash?

 

Best Regards

Chenyin

0 Kudos
Reply

332 Views
gse31
Contributor III

Hi Chenyin,

This issue appears only in linux.
bootROM always reads correctly ATF/uboot.
uboot always reads correctly linux image (with the patches mentionned on the other link).
Further tests under linux show that in addition to the right nibble of the first byte of each 1k block which is not read correctly, some random (random location) bytes are not read at the same value between 2 consecutive reads.

It looks like the LUT programmed in the qspi controller is not correct for the octal read operation. Where can I change the LUT sequence used by the qspi driver?

Thanks

0 Kudos
Reply