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.
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:
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
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
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