DRA829V: OSPI Flash Controller for QSPI device ( MT25QU02G )

Swapna yendrapalli

Part Number: DRA829V
Other Parts Discussed in Thread: DRA821, DRA829

Hi TI Team,

We are seeing some strange issue while writing/reading QSPI memory connected to OSPI flash memory controller ( Interface OSPI1 )

ISSUE1: We are mounting QSPI flash partition with jffs2 filesystem and after restart we are missing few folders on the filesystem. It seems creating shorter folder names always disappear after reboot

[ 12.255126] jffs2: notice: (587) read_direntry: name CRC failed on dirent node at0x891b53c: read 0x4f61bd5,calculated 0x7a475847
[ 12.255178] jffs2: notice: (587) read_direntry: name CRC failed on dirent node at0x8919f4c: read 0x794dcb2b,calculated 0xefcb3bb7

[ 12.709506] jffs2: notice: (588) check_node_data: wrong data CRC in data node at 0x0891ce90: read 0x4f4196c7, calculated 0x9e82f6ff.
[ 12.709659] jffs2: notice: (588) check_node_data: wrong data CRC in data node at 0x0891cbf0: read 0x565aa786, calculated 0x9e82f6ff.

ISSUE2: Reading fewer bytes <10 from raw mtd partitions ends up in garbage data

Could you please

Review the hardware connections and let us know if there are any changes needed ?
Do we need to tweak any settings on the software side ?

Thanks,

Swapna

over 1 year ago

0 Keerthy J over 1 year ago

TI__Guru**** 155350 points

Hi Swapna,

Few questions before i check with the hardware experts:

What's the exact part number being used?
Please share the data sheet link.
Are you able to boot from the qspi flash?
Which SDK are you using?

Best Regards,

Keerthy

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Thanks Keerthy!

What's the exact part number being used?
Please share the data sheet link.
- https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_02g_cbb_0.pdf
Are you able to boot from the qspi flash?
- We are using OSPI Flash for boot and QSPI flash only for storage
- The problem seem to be related to shorter memory access ( <10 bytes or so )
Which SDK are you using?
- 8.6.03

0 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Hi Swapna,

Swapna yendrapalli said:
We are using OSPI Flash for boot and QSPI flash only for storage

Just as a quick check can you flash bootloaders to QSPI and see if you can boot just to be sure HW is fine?

- Keerthy

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Hi Keerthy,

We are using custom boards and our bootloaders are programmed at factory.

We will try changing to QSPI and see if we have any success but might be bricking our devices any other experiments or tests we can run on the QSPI Flash partitions?

As it is happening on all devices it looks like timing issue. Could you please check if the above information provided related to hardware schematics and device tree look correct to you?

Changing the clock to 25MHz and read delay to 0 ns didn't help

Thanks,

Swapna

0 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Swapna yendrapalli said:
As it is happening on all devices it looks like timing issue. Could you please check if the above information provided related to hardware schematics and device tree look correct to you?

Changing the clock to 25MHz and read delay to 0 ns didn't help

Thanks Swapna. I understand the concern. I am looping in our hardware expert on this.

- Keerthy

0 Matt Park over 1 year ago in reply to Keerthy J

TI__Intellectual 2520 points

Hi Swapna,

Swapna yendrapalli said:
As it is happening on all devices it looks like timing issue. Could you please check if the above information provided related to hardware schematics and device tree look correct to you?

It seems there are some mismatches on the MCU Flash device tree in the hardware schematic you attached above when comparing it to TI's schematic.

As shown in the screenshot above, we have a resistor attached to MCU_OSPI0_LBCLK0 and your board does not. You instead have a resistor attached to MCU_OSPI0_DQS when TI's board does not. Our board also uses a different flash which is why the rest of the schematic looks a little different, but if you want to compare and check other parts of the device tree. I have attached a link below to download TI's schematic.

https://www.ti.com/lit/zip/sprr408

Best Regards,

Matt

0 Swapna yendrapalli over 1 year ago in reply to Matt Park

Intellectual 625 points

Hi Matt,

TI board has OSPI flash only our board has both OSPI Flash and QSPI Flash.

Could you please look at MT25QU02G part above as well please?

Thanks,

Swapna

0 Matt Park over 1 year ago in reply to Swapna yendrapalli

TI__Intellectual 2520 points

Hi Swapna,

Swapna yendrapalli said:
TI board has OSPI flash only our board has both OSPI Flash and QSPI Flash.

I actually looked back at the schematic for the SOM + EVM and we do have the same flash parts just different capacities I believe.

Swapna yendrapalli said:
Could you please look at MT25QU02G part above as well please?

For the QSPI Flash MT25QU02G, it seems the only difference is that we don't have MCU_OSPI1_DQS and MCU_OSPI1_LBCLKO connected to anything. Whereas in your board you have it connected to some resistors.

Best Regards,

Matt

0 Swapna yendrapalli over 1 year ago in reply to Matt Park

Intellectual 625 points

Hi Matt,

Please find comment from our hardware team below:

[https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1135731/dra829v-qspi-iclk-and-errata-i2307/4360254?tisearch=e2e-sitesearch&keymatch=dra829V%2525252520ospi#4360254 . This e2e talks about the OSPI lbk clk and the errata. Now that I reread it, it may be only for booting, and when you run the clock at higher speeds (after booting). Anyways the QSPI does have the loopback done correctly.

Please let us know if we are missing anything.

Could you please also share linux device tree for QSPI flash node?

Is tuning needed for QSPI?

Thanks,

Swapna

0 Matt Park over 1 year ago in reply to Swapna yendrapalli

TI__Intellectual 2520 points

Hi Swapna,

Yes this E2E is a good reference. I believe you have everything needed.

Swapna yendrapalli said:
Is tuning needed for QSPI?

No, tuning is not needed for QSPI.

Swapna yendrapalli said:
Could you please also share linux device tree for QSPI flash node?

Looping Keerthy back in for linux device tree.

Best Regards,

Matt

0 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Swapna yendrapalli said:
Could you please also share linux device tree for QSPI flash node?

Please check: arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
&ospi1 {
    pinctrl-names = "default";
    pinctrl-0 = <&mcu_fss0_ospi1_pins_default>;
    flash@0 {
        compatible = "jedec,spi-nor";
        reg = <0x0>;
        spi-tx-bus-width = <1>;
        spi-rx-bus-width = <4>;
        spi-max-frequency = <40000000>;
        cdns,tshsl-ns = <60>;
        cdns,tsd2d-ns = <60>;
        cdns,tchsh-ns = <60>;
        cdns,tslch-ns = <60>;
        cdns,read-delay = <2>;
        partitions {
            compatible = "fixed-partitions";
            #address-cells = <1>;
            #size-cells = <1>;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

&ospi1 {
	pinctrl-names = "default";
	pinctrl-0 = <&mcu_fss0_ospi1_pins_default>;

	flash@0 {
		compatible = "jedec,spi-nor";
		reg = <0x0>;
		spi-tx-bus-width = <1>;
		spi-rx-bus-width = <4>;
		spi-max-frequency = <40000000>;
		cdns,tshsl-ns = <60>;
		cdns,tsd2d-ns = <60>;
		cdns,tchsh-ns = <60>;
		cdns,tslch-ns = <60>;
		cdns,read-delay = <2>;

		partitions {
			compatible = "fixed-partitions";
			#address-cells = <1>;
			#size-cells = <1>;

			partition@0 {
				label = "qspi.tiboot3";
				reg = <0x0 0x80000>;
			};

			partition@80000 {
				label = "qspi.tispl";
				reg = <0x80000 0x200000>;
			};

			partition@280000 {
				label = "qspi.u-boot";
				reg = <0x280000 0x400000>;
			};

			partition@680000 {
				label = "qspi.env";
				reg = <0x680000 0x20000>;
			};

			partition@6a0000 {
				label = "qspi.env.backup";
				reg = <0x6a0000 0x20000>;
			};

			partition@6c0000 {
				label = "qspi.sysfw";
				reg = <0x6c0000 0x100000>;
			};

			partition@800000 {
				label = "qspi.rootfs";
				reg = <0x800000 0x37c0000>;
			};

			partition@3fe0000 {
				label = "qspi.phypattern";
				reg = <0x3fe0000 0x20000>;
			};
		};
	};
};

Best Regards,
Keerthy

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Thanks Keerthy!

Could you please share the offset for OSPI1 interface. OSPI0 configuration registers are at 0x4704_0000h

0 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Hi SWapna,

So 0x47050000 instead of 0x47040000.

- Keerthy

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Thanks Keerthy!

Are there any known OSPI issues/errata's that TI is aware of where reading fewer bytes from mtd partition ends up with corrupted data?

Any tests available in SDK we can run?

0 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Swapna,

Errata document: https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.ti.com/lit/pdf/sprz455&ved=2ahUKEwiBjeWboquEAxW_rlYBHT7ZDvQQFnoECBsQAQ&usg=AOvVaw1_1QR3ifmkloK71zur3YGS

Are you seeing issues or you wanted to look at the erratas in general?

Best Regards,

Keerthy

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Hi Keerthy,

We are seeing issues where reading smaller number of bytes(<10) from raw mtd partition ends up in corrupted data we need to read larger number bytes(>10) to get correct data

Any particular registers we need to look into that might have caused this issue?

Thanks,

Swapna

0 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Hi Swapna,

Can you share the exact commands to reproduce the issue? Are you trying to read from U-Boot or Linux?

Best Regards,

Keerthy

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Hi Keerthy,

We made a simple program that reproduces the issue with below sequence

Sequence 1

nbytes=1 to 8

Erase one block on mtd partition
write nbytes at offset 0
readback nbytes from offset 0 and compare

Sequence 2

nbytes > 8

Erase one block on mtd partition
write nbytes at offset 0
readback nbytes from offset 0 and compare

Sequence 1 always fails

Commands to reproduce the issue

#!/bin/bash

flash_erase /dev/mtd14 0 1

size=3

# Create a file with 3 bytes of random data
head -c $size /dev/urandom > file.bin

# Write the file to the mtd nor partition (assuming /dev/mtd0)
mtd_debug write /dev/mtd14 0 $size file.bin

# Read the file back from the partition
mtd_debug read /dev/mtd14 0 $size file_copy.bin

# Verify that the files are identical
cmp -l file.bin file_copy.bin

# Check the exit status of the cmp command
if [ $? -eq 0 ]; then
echo "PASS: The files are identical"
else
echo "FAIL: The files differ"
# Print the expected and read bytes in hexadecimal
echo "Expected bytes: $(hexdump -v -e '/1 "%02X "' file.bin)"
echo "Read bytes: $(hexdump -v -e '/1 "%02X "' file_copy.bin)"
fi

Please let us know if there is any limitations on number of bytes we can read from the OSP1 interface. >8 bytes always pass <= 8 fail.

Thanks,

Swapna

0 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Hi Swapna,

First of all thanks for the test case! I will check internally and get back to you on this.

- Keerthy

0 Keerthy J over 1 year ago in reply to Keerthy J

TI__Guru**** 155350 points

Hi Swapna,

I tried first checking the same on U-Boot. Copy a text file with data say "1234" which is 4bytes(< 8 Bytes) to the boot partition of your MMC SD Card.

Boot to U-Boot prompt.

mw 0x84000000 0x0 0x8
md 0x84000000 8

You should see all 0s.

Now write the file from MMC SD to loadaddr:

fatload mmc 1 ${loadaddr} file.txt

5 bytes read in 1 ms (4.9 KiB/s)

Now write the contents from loadaddr to OSPI 0x0 address.

sf update $loadaddr 0x0 $filesize

Read back to DDR address 0x84000000 which was earlier zeroed out

sf read 0x84000000 0x0 $filesize

I am able to read back 4 bytes correctly. So I believe Hardware is okay. Can you try and let me know from U-Boot?

- Keerthy

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Thanks Keerthy!

We are able to reproduce the issue in uboot with our hardware.

//set the 16 bytes in DDR memory content at 0x80000000 with
a known pattern.

=>md.b 0x80000000
80000000: 78 56 34 12 01 ef cd ab f7 ff ff ff 00 00 00 00 xV4.............

Step1: ERASE
=>sf probe 1:0 ; sf erase 0x0 0x20000

Step2: WRITE
=>sf write 0x80000000 0x0 0x20

Step 3: READ 3 bytes

=>sf read 0xb0000000 0x0 0x3
=>md.b 0xb0000000
b0000000: 99 33 ff 20 00 ff ff ff ff ff ff ff ff 00 00 6f .3. ...........o

Step 4: READ 16 bytes
=>sf read 0xA0000000 0x0 0x10

=>md.b 0xa0000000
a0000000: 78 56 34 12 01 ef cd ab f7 ff ff ff 00 00 00 00 xV4.............

reading 3bytes, ends up in wrong data and 16 bytes is ok

My colleague looked at which command is failing and reported "FR CMD(0x6c)" fails when we see this issue so it appears read didn't happen and hence the issue.

For bytes less than or equal to 8 we are using STIG_READ instead of normal READ and it doesn't seem to work.

We are using SDR mode at 33.3MHz

Could you please help us with below information

What is the frequency of the OSPI interface?
What is the Flash memory part you are you using ?
Which version of the uboot code are you using ?

Thanks,

Swapna

+1 Keerthy J over 1 year ago in reply to Swapna yendrapalli

TI__Guru**** 155350 points

Hi Swapna,

In the kernel can you try reverting the below:

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
commit de04540ad08719381d37e574895c8f7bc10f53ef (HEAD -> ti-linux-6.1.y)
Author: Vaishnav Achath <vaishnav.a@ti.com>
Date:   Thu Feb 22 11:58:55 2024 +0530
    Revert "spi: cadence-quadspi: use STIG mode for small reads"
    
    This reverts commit 001555e7be121557a29fdccfc1b0c9e6e044247c.
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 77c3c017b0d6..5babcf5a23a8 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -2101,13 +2101,7 @@ static int cqspi_mem_process(struct spi_mem *mem, const struct spi_mem_op *op)
        cqspi_configure(f_pdata, mem->spi->max_speed_hz);
 
        if (op->data.dir == SPI_MEM_DATA_IN && op->data.buf.in) {
-       /*
-        * Performing reads in DAC mode forces to read minimum 4 bytes
-        * which is unsupported on some flash devices during register
-        * reads, prefer STIG mode for such small reads.
-        */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

commit de04540ad08719381d37e574895c8f7bc10f53ef (HEAD -> ti-linux-6.1.y)
Author: Vaishnav Achath <vaishnav.a@ti.com>
Date:   Thu Feb 22 11:58:55 2024 +0530

    Revert "spi: cadence-quadspi: use STIG mode for small reads"
    
    This reverts commit 001555e7be121557a29fdccfc1b0c9e6e044247c.

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 77c3c017b0d6..5babcf5a23a8 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -2101,13 +2101,7 @@ static int cqspi_mem_process(struct spi_mem *mem, const struct spi_mem_op *op)
        cqspi_configure(f_pdata, mem->spi->max_speed_hz);
 
        if (op->data.dir == SPI_MEM_DATA_IN && op->data.buf.in) {
-       /*
-        * Performing reads in DAC mode forces to read minimum 4 bytes
-        * which is unsupported on some flash devices during register
-        * reads, prefer STIG mode for such small reads.
-        */
-               if (!op->addr.nbytes ||
-                   op->data.nbytes <= CQSPI_STIG_DATA_LEN_MAX)
+               if (!op->addr.nbytes)
                        return cqspi_command_read(f_pdata, op);
 
                return cqspi_read(f_pdata, op);

Swapna yendrapalli said:
What is the Flash memory part you are you using ?

Which version of the uboot code are you using ?

I was trying on DRA821 on 8.5 SDK which has the Cypress flash (S28HS512TGABHM010).

Let us know if reverting the above patch helps in kernel.

- Keerthy

0 Lawrence Lee2 over 1 year ago in reply to Keerthy J

Prodigy 180 points

We are using DRA829, Flash are mt35xu02g and mt25qu02g.

UBOOT is based from 2021.01 SDK.

0 Swapna yendrapalli over 1 year ago in reply to Keerthy J

Intellectual 625 points

Thank you Keerthy! This patch worked and issues with filesystem and raw partition issues are resolved

Processors

Processors forum

DRA829V: OSPI Flash Controller for QSPI device ( MT25QU02G )