• State Resolved
  • Locked Locked
  • Replies 24 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 2976 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA829V: OSPI Flash Controller for QSPI device ( MT25QU02G )

Swapna yendrapalli
Intellectual 625 points

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

  • 0
    TI__Guru**** 170480 points

    Hi Swapna,

    Few questions before i check with the hardware experts:

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

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Intellectual 625 points

    Thanks Keerthy!

  • 0 in reply to Swapna yendrapalli
    TI__Guru**** 170480 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 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 in reply to Swapna yendrapalli
    TI__Guru**** 170480 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 in reply to Keerthy J
    TI__Expert 3150 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 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 in reply to Swapna yendrapalli
    TI__Expert 3150 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 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 in reply to Swapna yendrapalli
    TI__Expert 3150 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 in reply to Swapna yendrapalli
    TI__Guru**** 170480 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

    &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 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 in reply to Swapna yendrapalli
    TI__Guru**** 170480 points

    Hi SWapna,

    So 0x47050000 instead of 0x47040000.

    - Keerthy

  • 0 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 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 in reply to Swapna yendrapalli
    TI__Guru**** 170480 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 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 in reply to Swapna yendrapalli
    TI__Guru**** 170480 points

    Hi Swapna,

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

    - Keerthy

  • 0 in reply to Keerthy J
    TI__Guru**** 170480 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 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 in reply to Swapna yendrapalli
    TI__Guru**** 170480 points

    Hi Swapna,

    In the kernel can you try reverting the below:

    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 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 in reply to Keerthy J
    Intellectual 625 points

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