AM625: spi nor flash driver

Dear Tom.

Would you please give more detail about the issue?

1. which SDK? MCU_PLUS SDK or Linux SDK?

2. which driver do you report the issue with? MCU_PLUS SDK or Linux SDK?

3. which API and corresponding input parameters?

4. please share code change you made for new flash if possible.

5. please clarify the error signal, especially EN. which PIN is this EN? better to provide the wave captured by Logic analyzer with introduction.

thanks a lot!

yong

Hi Yong:

flash_driver.zip

Linux SDK.

we use flash_torture to test. flash_torture -c 56 -r /dev/mtd1

As show in pictures,  we read 0x10000.  range is 0x80000-0x8FFFF.

When finish read, it still get 36 bytes.

Dear Tom

thanks for more detail.

there is no similar issue on SK-AM62-LP which equipped an OSPI flash.

please help check in below ways.

1. capture the wave on CS/CLK/D0/D1/... to do the comparison.

2. please help dump OSPI0 controller register on your board and also SK-AM62-LP EVM for comparison.

TRM:

...

thanks a lot!

yong

Hi Tom,
For testing purpose, can we set FSAS_SYSCONFIG[7]=DISXIP to "1" before running your flash read test?
Note FSAS_SYSCONFIG register addr is 0x0FC10004
Best,
-Hong

Hi Tom,
From the quick test by running "flash_torture..." on target board during our debug call, the issue was not observed after setting DISXIP to "1".
Let's run more test, and keep us updated with the test result.
You'll find more details on FSAS_SYSCONFIG[7]=DISXIP in <14.8.4.2.2.1 FSAS_SYSCONFIG Register> in AM62x TRM.
Best,
-Hong

sync status in this morning meeting.

initial test with falsh_torture works well. Please verify more with the modification and provide status to us later.

please also help check if can provide OSPI flash SPEC to us.

thanks a lot!

yong

My SDK version is 10.01.10.04.

We use jffs2 to mount some mtd, but when it mount ,it always show crc error.

The test cmd is:

      mtd_debug erase /dev/mtd1 0x0 0x300000

      mount -t jffs2 /dev/mtd1 /mnt

      echo "1234" > /mnt/test.txt

      umount /mnt

      mount -t jffs2 /dev/mtd1 /mnt

when I dmesg, it show me crc error: Node header CRC failed at 0x360080(ffff,ffff,fff,ffff)

The code is in readinode.c jffs2_get_inode_nodes , it do u.hdr_crc check.

Then I add some debug log in jffs2 crc check and cqspi dma

I found when it read some place, the data after finishing dma is 0xFF.

I Also use logic analyzer to capture the data . The data nor flash send is right which is not 0xFF. And I dump the data on flash at the same offset it also not 0xFF

So the data on flash and send to soc is right, but sometimes after dma transfer , the data in buf will be 0xFF.

If I add read again , the buf which dma transfer will get the right data.

The log I upload is I add shows the log that I add read twice when do  u.hdr_crc check.

But you can see when it read 0x330080 fisrt time, the data in jffs2 buffer is 0xFF. I also dump the data in buffer finish dma transfer is 0xFF.

But when read again ,it get the right data.

The configs for jffs2 in kernel is as follows:
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
#CONFIG_JFFS2_FS_WRITEBUFFER is not set

#CONFIG_JFFS2_FS_WBUF_VERIFY is not set

#CONFIG_JFFS2_SUMMARY is not set

CONFIG_JFFS2_FS_XATTR=y

CONFIG_JFFS2_COMPRESSION_OPTIONS=y

CONFIG_JFFS2_ZLIB=y

CONFIG_JFFS2_RTIME=y

Could you please help us check if these configs cause the issue?

Also, in dts, I found a value in the node of flash@0

cdns,read-delay = <2>；

Does this value cause the issue?

Or is there any other settings need to set in some registers?

Thanks.3618.jffs2_error.zip

Hi Tom,
1/. Have we set FSAS_SYSCONFIG[7]=DISXIP to "1" when running the latest JFFS2 test showing CRC error?
2/. As we discussed in our call yesterday, what is the stress test result from running "flash_torture..." after setting FSAS_SYSCONFIG[7]=DISXIP to "1"?
Best,
-Hong

Hi Hong:

1.yes, we have set FSAS_SYSCONFIG[7]=DISXIP to "1", but still CRC error

2.run flash_torture test, it seems not failed. But as  logic analyzer shows ,when read atfer 1 block , it still send more 4 bytes data. But flash_torture test run ok

Hi Tom,

tom zhang said:

2.run flash_torture test, it seems not failed. But as  logic analyzer shows ,when read atfer 1 block , it still send more 4 bytes data. But flash_torture test run ok

it looks like serial-nor read/write/erase etc... works fine with FSAS_SYSCONFIG[7]=DISXIP to "1" which disables DMA prefetch.

tom zhang said:

1.yes, we have set FSAS_SYSCONFIG[7]=DISXIP to "1", but still CRC error

I'd recommend cross-checking JFFS2 filesystem creation/operation etc...where JFFS2 is maintained by community. As you know UBI/UBIFS is verified in TI Linux SDK.

1/. have we tested serial-NOR @u-boot level with "sf..." cmd, for example "sf test..."?
2/. I'm attaching a kernel patch to disable DMA for OSPI in case you want to test it w/o DMA.

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 33c60f719dc2..20d5d6bf6c3f 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -3711,7 +3711,7 @@ static const struct cqspi_driver_platdata k2g_qspi = {
 
 static const struct cqspi_driver_platdata am654_ospi = {
        .hwcaps_mask = CQSPI_SUPPORTS_OCTAL,
-       .quirks = CQSPI_NEEDS_WR_DELAY,
+       .quirks = CQSPI_NEEDS_WR_DELAY | CQSPI_DISABLE_DAC_MODE,
 }; 

Best,
-Hong

We add read twice to get right data.
But another issue is that if we read less than 8 bytes data from a address, the data we get is all 0xFF

We use  logic analyzer, found that ,if spi reads a address ,the len  less than 8 bytes, the address which send to flash is 0xEEEEEEEE， the address is invalid

So the data is 0xFF

I have tried the pacth to disable DMA ,but it still cat 0xFF

The read differences is that:

if len < 8bytes, means the op->addr.nbytes < 8bytes. it runs cqspi_command_read

if len >= 8bytes, means the op->addr.nbytes >= 8bytes, it runs cqspi_read

Now:

we add read twice when do mtd_read in jffs2_read

remove op->data.nbytes <= CQSPI_STIG_DATA_LEN_MAX, let it run cqspi_read

And jffs2 can work normally.

But we want to know why? Could you please help us analyz this?

Hi Tom,
Please have a look at this kernel commit on how to disable STIG mode for another HW platform.
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/spi/spi-cadence-quadspi.c?h=11.01.12&id=4b1ccdfe589e478b7c8542bd43f3777b11ea7257
I'd recommend check with your SPI-NOR flash vendor, and if you need to add a quirks to disable STIG mode as the above commit on your setup.
Best,
-Hong

In the commit, the flag about CQSPI_DISABLE_STIG_MODE is added in struct socfpga_qspi

I think socfpga_qspi is not used, should I add this flag in am654_ospi?

I add this commit and add CQSPI_DISABLE_STIG_MODE in am654_ospi, the jffs2 can mount without crc error.

And the data in jffs2 can be read correctly.

This the patch we changed.As Yong suggested, can you help us have a check?

disable_STIG_mode.zip

Hi Hong:

Another question is that:

We have set FSAS_SYSCONFIG[7]=DISXIP to "1" , but there is still more 4 bytes when finish reading ,but flash_torture test no error.

We wants to confirm why there is still more 4 bytes?

And why we need to do read twice when do mtd_read in jffs2? The 1st time read from dma, the data are all 0xFF?

Hi Hong:

We have checked with flash vendor, they think flash is the slave device, it doesn't care whether STIG mode is disabled.

Also, as the data logic analyzer get, flash sends the correct data.

They think if need to disable STIG mode should be checked by SOC

Hi Tom,

tom zhang said:

I add this commit and add CQSPI_DISABLE_STIG_MODE in am654_ospi, the jffs2 can mount without crc error.

And the data in jffs2 can be read correctly.

This the patch we changed.As Yong suggested, can you help us have a check?

yes, the patch on disabling SITG mode looks good to me, and it is good to know the patch helps...
Best,
-Hong

Hi Hong：

Could you help us check another question?

Hi Tom,

We added & tested three changes:
- FSAS_SYSCONFIG[7]=DISXIP to "1" to disables DMA prefetch
- the kernel driver patch to disable DMA for OSPI in case you want to test it w/o DMA
- the kernel driver patch to disable SITG mode

With these changes, the serial-nor stress test by running "flash_torture" works without error.
What else abnormal observation do we have now?

Best,
-Hong

Hi Hong：

Now,we have added the three changes.

The flash torture test is ok.

But there is a question we want to check.

We use  logic analyzer to get signal.If the flash do erase and write, the sizes are both 64K(0x10000)

The total read size is also 64K.But It was divided into two parts.The 1st part is 516 bytes（0x204）, the 2nd part is 65020 bytes (0xFDFB)

Can you help us explain this?

flash_touture_read.zip

-the kernel driver patch to disable DMA for OSPI in case you want to test it w/o DMA

So the patch will disable DMA?

Hi Tom,

tom zhang said:

The flash torture test is ok.

But there is a question we want to check.

We use  logic analyzer to get signal.If the flash do erase and write, the sizes are both 64K(0x10000)

The total read size is also 64K.But It was divided into two parts.The 1st part is 516 bytes（0x204）, the 2nd part is 65020 bytes (0xFDFB)

Can you help us explain this?

The flash torture test passed, correct?
Also the flash torture is a community maintained utility tool, and the question would be better clarified by community.

tom zhang said:

-the kernel driver patch to disable DMA for OSPI in case you want to test it w/o DMA

So the patch will disable DMA?

Yes, the intention is to disable DMA in case you want to test it w/o DMA.

Best,
-Hong

Hi Hong:

The flash torture test passed, correct?

-Yes.

But not only flash torture, when we do flash read, it also divided into two parts.

Another is we don't want to disable DMA, which may cause a decrease in CPU performance

Hi Tom,

tom zhang said:

But not only flash torture, when we do flash read, it also divided into two parts.

have we tested "sf read..." @u-boot?
Best,
-Hong

Dear Tom.

may I ask your help to clarify the latest problem now?

tom zhang said:

I add this commit and add CQSPI_DISABLE_STIG_MODE in am654_ospi, the jffs2 can mount without crc error.

And the data in jffs2 can be read correctly.

1. what kind of modification you have applied when jffs2 read data successfully?

2. what is the new problem after that?

thanks a lot!

yong

Hi Yong:

The changes were as:

1.- FSAS_SYSCONFIG[7]=DISXIP to "1" to disables DMA prefetch                       fix spi nor read more 36 bytes
2. -add read twice when do mtd_read in jffs2_read                                                 fix jffs2 get indoe nodes error(the data in dma buffer are FF when 1st read)
3.- remove op->data.nbytes <= CQSPI_STIG_DATA_LEN_MAX                            fix jffs2 check node data error

Above 2 and 3, were our solutions.

Then you gave us these patch:

a.the kernel driver patch to disable DMA for OSPI

b.disable STIG mode

Above b can fix the jffs2 check node data error, so we use patch b to replace solution 3.

But a will disable DMA so we don't want to use it.

Now, I remove solution 2 in kernel, when I test jffs2 mount, there is no jffs2 get inode nodes error.

And the changes are now as:

1.- FSAS_SYSCONFIG[7]=DISXIP to "1" to disables DMA prefetch                       fix spi nor read more 36 bytes

2.-disable STIG mode                                                                                              fix jffs2 check node data error

So I think the patch disable STIG mode works and fix all the jffs2 error issue.

Dear Tom.

So the conclusion is that jffs2 works on your side (read/write/erase) w/ below two modification. right?

1.- FSAS_SYSCONFIG[7]=DISXIP to "1" to disables DMA prefetch                       fix spi nor read more 36 bytes

2.-disable STIG mode                                                                                              fix jffs2 check node data error

please let us know if there is new problem? and what is the problem if there it is?

thanks a lot!

yong

Hi Yong:

Yes, jffs2 can works with the 2 solutions.

Another path will disable DMA ,so we don't use it.