AM625: Issues Using mt35xu02g OSPI device.

Hello Mike,
Will you let us know which TI Linux SDK version was based off in your testing?
Best,
-Hong

Hi Hong,

We are running a yocto build based on processor-sdk-08.04.01.03.  We've tried updating the kernel version we are using to version 5.10.153 based on TI's linux-5.10.y branch (08.05.00.006 tag) from  git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git.

With regards,

Mike

Hi Hong,

We have ordered an mt35xu512aba device (same as the EVM uses) with the intent to swap it with the mt35xu02g in an attempt to isolate the issue to the hardware design or software.  I'm assuming that if the mt35xu512aba works, then it's probably not a hardware design issue.  It nothing more, this will be an additional datapoint.  I will update this thread with the results later this week.

If your team has any suggestions how to isolate, we'll make the necessary measurements.

With regards,

Mike

Hello Mike,
Please share the test result once available with the MT35XU512ABA.
Fyi: AM62x Linux SDK 8.5 is released Dec-2022.
Best,
-Hong

Hi Hong,

With the TI EVM and our custom board with the s28hs512t swapped in for the mt35xu02g, the attached script runs successfully over 10 iterations.

With our custom boards (we've tried a couple) using the mt35xu02g, the attached script fails.  Typically, we see failures every attempt, with a small run of 0xFF's (we've seen runs of 8, 16, all the way up to 128). somewhere in the ~56MB transfer.  If we skip the erase and rerun the write/read, the resulting files match (a "pass").  Just attempting to re-read results in failure, so it appears to be a write problem.

It would seem that there appears to be some issue with the write command using the mt35xu02g with the AM62x and the reference HW/SW design.

Some observations:

1. We used the same partitioning for both devices (leaving the upper area unused).  We have not flashed the training pattern in any of the partitions, so I don't think the training pattern is being used (and it is not attempted on the mt35xu02g by the driver).

2. The times to perform the erase and writes between the two devices, for the same amount of data/area, appear significantly different:

3. We are using essentially the same device tree and clock settings for both configurations (the device ID is probed during bootup).

 Here is the test script (I couldn't figure out how to upload it)

#!/bin/bash

part=mtd5
part_size=$(mtd_debug info /dev/$part | awk '/mtd.size/ { print $3 }')
part_erasesize=$(mtd_debug info /dev/$part | awk '/mtd.erasesize/ { print $3 }')
part_blocks=$((part_size / $part_erasesize))
echo erase blocks = $part_blocks

test_flash() {
  echo "erasing"
  time mtd_debug erase /dev/$part 0 $part_size
  if [ ! -f tmp_write.bin ]
  then
   echo creating test file
   dd if=/dev/urandom of=tmp_write.bin bs=$part_erasesize count=$part_blocks
  fi
  echo writing
  time mtd_debug write /dev/$part 0 $part_size tmp_write.bin
  echo reading
  time mtd_debug read /dev/$part 0 $part_size tmp_read.bin
  echo comparing
  cmp tmp_read.bin tmp_write.bin && echo Success
}

for i in $(seq 1 10)
do
  echo $i
  test_flash
done

On our failures, this is a typical failure:

root@mitysom-am62x:~# ADDR=5230145; diff -u <(hexdump -C -s $ADDR -n 10000 tmp_write.bin) <(hexdump -C -s $ADDR -n 10000 tmp_read.bin)
--- /dev/fd/63
+++ /dev/fd/62
@@ -1,15 +1,6 @@
-004fce41 c5 34 68 84 6d 83 dc 5d 49 92 f4 10 03 1f 9e 3b |.4h.m..]I......;|
-004fce51 40 12 60 e1 d2 99 64 c4 fa 30 70 82 59 ae 5e 5b |@.`...d..0p.Y.^[|
-004fce61 57 a8 71 42 7f ce 07 4c 01 d4 44 f1 ec b7 8d 81 |W.qB...L..D.....|
-004fce71 ca c8 c7 73 c6 2c d5 c4 09 43 d3 01 f4 fc 8e 6d |...s.,...C.....m|
-004fce81 be bd ce 18 b7 06 16 c6 e9 d9 aa 0b 8f 4b e9 1a |.............K..|
-004fce91 d4 7b 6b c5 2c 01 d5 6a 79 91 9f c3 14 a3 bd 37 |.{k.,..jy......7|
-004fcea1 bb 99 aa ad 77 ec f8 c6 a4 5b fe 7d 9b 35 70 c1 |....w....[.}.5p.|
-004fceb1 df b6 23 68 68 3a 2a c9 d7 d6 18 bf d6 44 2b c9 |..#hh:*......D+.|
-004fcec1 15 34 4a e6 4f 7d 32 61 87 58 1b 0d 89 2c 3f 6c |.4J.O}2a.X...,?l|
-004fced1 b9 fd 66 21 75 60 dd 40 c8 0f 17 9c cc e3 71 6a |..f!u`.@......qj|
-004fcee1 fe d9 d3 5c 2d 4c cb a2 22 82 3e a5 41 c3 28 0d |...\-L..".>.A.(.|
-004fcef1 4a 86 83 ff a8 9a b8 eb 51 50 13 e9 38 98 83 d1 |J.......QP..8...|
+004fce41 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
+*
+004fcef1 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d1 |................|
004fcf01 c6 53 c2 05 d7 88 7f 1a 2e c4 97 70 f8 a3 6c b8 |.S.........p..l.|
004fcf11 c0 9e f3 41 7f 0c b7 33 7c b3 18 8b 3e ae a8 c0 |...A...3|...>...|
004fcf21 70 0b 8d 7d 8d d0 4e 0f 33 6e 91 20 0c 48 2a d9 |p..}..N.3n. .H*.|

The only bytes that are incorrect are the '0xff' bytes.  If we rerun the mtd_debug write and mtd_debug read (without the erase), generally the files will match.  E.g., a second write attempt gets the data there.  Back to back mtd_debug read calls show the same error in the same location.

Not sure what to make of this, but it would seem that there is something different with the mt35xu02g device logic that may be causing troubles.

With regards,

Mike

Hi Hong,

I lost a post here:

Sorry for the confusion, we are using s28hs512t (same as the EVM), not MT35XU512ABA, to replace the mt35xu02g device on our board.

-Mike

Hi Hong,

We've been able to get the test script to work with the following 2 changes:

1. kernel change:

diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index c224e59820a1..ed2d0cb1bada 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -127,7 +127,11 @@ static const struct flash_info micron_parts[] = {
          .fixups = &mt35xu512aba_fixups},
        { "mt35xu02g", INFO(0x2c5b1c, 0, 128 * 1024, 2048,
                            SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
-                           SPI_NOR_4B_OPCODES) },
+                           SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ |
+                           SPI_NOR_OCTAL_DTR_PP |
+                           SPI_NOR_IO_MODE_EN_VOLATILE)
+         .fixups = &mt35xu512aba_fixups},
+
 };

2. Updated device tree, set cdns,read-delay = <2>, previously 4.

I am not 100% certain what the mt35xu512aba_fixups() are doing, but the mt35xu512aba and the mt35xu02g are of the same family, and the datasheets look pretty much identical.  In our testing, both 1 and 2 were necessary for the device to properly probe and pass the tests.

When I apply the fixups, the OSPI driver will attempt to perform the calibration when it sees the mt35xu02g, and the test script performs the same as it does with the s28hs512t loaded on the EVM.

This may resolve this issue (at least for me).  Might want to push the patch from #1 upstream if that makes sense....

With regards,

Mike

Hello Mike,
It is good to know you've made very good progress on validating "mt35xu02g" on your AM62x design.
As you know, "mt35xu02g" is currently not in TI K3 SoC (i.e. AM64x, AM62x...) reference boards.
Here I want to share with you some data points from one of external K3 SoC projects with "mt35xu02g".
The two u-boot changs done by them to support "mt35xu02g" are listed below for your reference ONLY:

1. "/arch/arm/dts/k3-am625-sk.dts" OSPI-NOR DT
git.ti.com/gitweb
cdns,tslch-ns = <60>;
- cdns,read-delay = <4>;
+ cdns,read-delay = <0>;
cdns,phy-mode;

2. "u-boot/drivers/mtd/spi/spi-nor-core.c"
git.ti.com/gitweb
#ifdef CONFIG_SPI_FLASH_MT35XU
- if (!strcmp(nor->info->name, "mt35xu512aba"))
+ if (!strcmp(nor->info->name, "mt35xu512aba") || !strcmp(nor->info->name, "mt35xu02g"))
nor->fixups = &mt35xu512aba_fixups;
#endif

Best,
-Hong