TDA4VM-Q1: flashcp does not work on TDA4VM.

Below is "mtdinfo /dev/mtd0" result.

mtd0
Name:                           ospi.tiboot3
Type:                           nor
Eraseblock size:                4096 bytes, 4.0 KiB
Amount of eraseblocks:          128 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:0
Bad blocks are allowed:         false
Device is writable:             true

Hi Keerthy. Thanks for your reply.

I used the mtd_debug command as instructed.

I did it like this:

1. mtd_debug erase /dev/mtd0 0x0 0x80000
-> Because the size of mtd0 is 80000

2-1. mtd_debug write /dev/mtd0 0x0 0x80000
-> Because the size of mtd0 is 80000
2-2. mtd_debug write /dev/mtd0 0x0 0x48138
-> Because our tiboot3.bin file size is 295,224 bytes

3. mtd_debug read /dev/mtd0 0x0 0x80000 ./read_mtd0

Afterward, to check whether tiboot3.bin written to mtd0 was correctly written, the read read_mtd0 file and tiboot3.bin were compared, but the files read_mtd0 and tiboot3.bin were different in both attempts 2-1 and 2-2.

When reading the read_mtd0 file, the hex values "04" are recorded, suggesting that it was not written properly.

I have little experience with OSPI flashing and little related knowledge, so I am asking a summary question.

1. When the mtd device is searched using the "cat /proc/mtd" command, the ospi.tiboot3, ospi.tispl, ospi.~ ... partitions set in the kernel are searched. Is it correct to write the files corresponding to each partition? (For example, write the tiboot3.bin file to the ospi.tiboot3 partition)

2. Since the partition is searched when the "cat /proc/mtd" command is used, can it be said that the Nor Flash memory is recognized correctly?

3. Is the process of writing using the mtd_debug command different from writing using the dd command?

4. Is using the mount command impossible for flash memory like a regular eMMC (or SD Card)?

Thanks

Hi,

What is the erase size of your flash? Have you checked the data sheet?
Please try with smaller sizes like 256 bytes or 1024. See if you read what was written correctly.

- Keerthy

Hi Keerthy.

My flash memory is the Micron MT35X series, with a minimal subsector erase of 4KB.

"try with smaller sizes like 256 bytes or 1024."

I didn't understand what you meant by your suggestion to try a smaller size.

Is there a way to write or read by modifying the erase size?

Below is the result of "mtd_debug info"

root@j721e-hs-evm:~# mtd_debug info /dev/mtd0

mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 524288 (512K)
mtd.erasesize = 4096 (4K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0

Kim, 

What i am asking is to check if you can write a small file of size 4KB and read that back. I have tested that worked fine. 

So your erase size is 4K as per the debug info. Your erase size has to be multiples of 4K.

Regards, 

Keerthy 

Thanks for the kind explanation.

It shows the same when I write a 3KB (3,168 Byte) text file on my /dev/mtd0.

Below is the "mtd_debug read /dev/mtd0 0x0 0xC60 FILE" result after write.

The same dummy value is read no matter what data or file is written. (Of course, the file size differs, but the content is similar)

Is this attempt(I mean write boot files to nor-flash on runtime Linux) itself wrong?

When I look at the SDK guide document, it is introduced to write these files in the nor-flash area using "sf" and "tftp" in u-boot.

But I try this method cause I'm in an environment where Ethernet is unavailable.

Thanks.

Hi,

I am able to write/read back data whatever I had written. Can you share the output logs of the above commands?
Can you confirm that U-Boot sf commands work as exepected?

- Keerthy

Hi Keerthy.

I also tested reading/writing files ​​to flash memory using the mtd_debug command in SK-TDA4VM EVM.

I confirmed that it was working normally there. I suspect there is probably a problem with my environment.

Here is the output on my custom board.

root@j721e-hs-evm:/boot# ls -l
total 29838
-rwxr-xr-x    1 root     root             0 Jan  1  1980 B?(
-rwxr-xr-x    1 root     root       1605954 Oct  2  2044 B?.B??
-rwxr-xr-x    1 root     root             0 Jan  1  1980 C?(
-rwxr-xr-x    1 root     root       1605955 Oct  3  2044 C?.C??
drwxr-xr-x    3 root     root          2048 Apr  5  2011 EFI
-rwxr-xr-x    1 root     root      16640512 Apr  5  2011 Image
drwxr-xr-x    2 root     root          2048 Jul  1  2024 System Volume Information
drwxr-xr-x    2 root     root          2048 Jul  1  2024 bak
-rwxr-xr-x    1 root     root       7420702 Apr  5  2011 fitImage
-rwxr-xr-x    1 root     root        278254 Jun 14  2024 sysfw.itb
-rwxr-xr-x    1 root     root        295224 Jun 14  2024 tiboot3.bin
-rwxr-xr-x    1 root     root       1072539 Jun 28  2024 tispl.bin
-rwxr-xr-x    1 root     root        295224 Apr 28 17:47 tmp
-rwxr-xr-x    1 root     root       1319523 Jun 28  2024 u-boot.img
-rwxr-xr-x    1 root     root           574 Apr  5  2011 uEnv.txt
root@j721e-hs-evm:/boot#
root@j721e-hs-evm:/boot# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00001000 "ospi.tiboot3"
mtd1: 00200000 00001000 "ospi.tispl"
mtd2: 00400000 00001000 "ospi.u-boot"
mtd3: 00020000 00001000 "ospi.env"
mtd4: 00020000 00001000 "ospi.env.backup"
mtd5: 00100000 00001000 "ospi.sysfw"
mtd6: 037c0000 00001000 "ospi.rootfs"
mtd7: 00020000 00001000 "ospi.phypattern"
root@j721e-hs-evm:/boot#
root@j721e-hs-evm:/boot# mtd_debug erase /dev/mtd0 0x0 0x80000
Erased 524288 bytes from address 0x00000000 in flash
root@j721e-hs-evm:/boot#
root@j721e-hs-evm:/boot# mtd_debug write /dev/mtd0 0 295224 tiboot3.bin
Copied 295224 bytes from tiboot3.bin to address 0x00000000 in flash
root@j721e-hs-evm:/boot# mtd_debug read /dev/mtd0 0 295224 tmp
Copied 295224 bytes from address 0x00000000 in flash to tmp
root@j721e-hs-evm:/boot# ls -l tmp
-rwxr-xr-x    1 root     root        295224 Apr 28 18:04 tmp
root@j721e-hs-evm:/boot#
root@j721e-hs-evm:/boot# diff tmp tiboot3.bin
Files tmp and tiboot3.bin differ
root@j721e-hs-evm:/boot#

When I open the read file with VI, it goes like this.

Thanks!

Below is the output of the 680 byte writing/reading result.

root@j721e-hs-evm:~# ls -l
total 4
-rw-r--r--    1 root     root           680 Apr 28 18:12 temp.txt
root@j721e-hs-evm:~#
root@j721e-hs-evm:~# cat temp.txt
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras cursus tellus at
lectus varius, id sagittis metus posuere. Pellentesque sed euismod sem.
Phasellus aliquet metus non lacus viverra, eget ultricies urna iaculis.
Pellentesque semper, nisl a aliquet vulputate, metus urna ultricies ipsum, ut
euismod leo odio nec urna. Praesent interdum turpis erat, non iaculis diam
consectetur facilisis. Maecenas non tincidunt nibh, vel ornare libero. In non
libero non diam convallis ullamcorper vel non ante. Orci varius natoque
penatibus et magnis dis parturient montes, nascetur ridiculus mus. In hac
habitasse platea dictumst. Cras iaculis diam augue, id volutpat lorem
iaculisac
root@j721e-hs-evm:~#
root@j721e-hs-evm:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00001000 "ospi.tiboot3"
mtd1: 00200000 00001000 "ospi.tispl"
mtd2: 00400000 00001000 "ospi.u-boot"
mtd3: 00020000 00001000 "ospi.env"
mtd4: 00020000 00001000 "ospi.env.backup"
mtd5: 00100000 00001000 "ospi.sysfw"
mtd6: 037c0000 00001000 "ospi.rootfs"
mtd7: 00020000 00001000 "ospi.phypattern"
root@j721e-hs-evm:~#
root@j721e-hs-evm:~# mtd_debug info /dev/mtd0
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 524288 (512K)
mtd.erasesize = 4096 (4K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0

root@j721e-hs-evm:~#
root@j721e-hs-evm:~# mtd_debug erase /dev/mtd0 0 0x80000
Erased 524288 bytes from address 0x00000000 in flash
root@j721e-hs-evm:~#
root@j721e-hs-evm:~# mtd_debug write /dev/mtd0 0 680 temp.txt
Copied 680 bytes from temp.txt to address 0x00000000 in flash
root@j721e-hs-evm:~#
root@j721e-hs-evm:~# mtd_debug read /dev/mtd0 0 680 temp_read.txt
Copied 680 bytes from address 0x00000000 in flash to temp_read.txt
root@j721e-hs-evm:~#
root@j721e-hs-evm:~# diff temp.txt temp_read.txt
Files temp.txt and temp_read.txt differ

Open temp_read.txt with VI

Same as writing tiboot3.bin.

But this test worked well on SK TDA4VM EVM, like writing tiboot3.bin there.

If you need more information about my environment, please reply.

Thanks.

Hi Kim,

Thanks for trying it out on TI board. We have tested and works well at our end as well. One thing to check if there's a bit shift in the data that you read vs written. That will clearly point towards read delay being insufficient. Can you check that? 

Also try increasing the read-delay in device tree if you see the data is bit shifted while reading. 

Best Regards,

Keerthy 

Hi Keerthy,

I cannot find any information about read-delay on my nor-flash datasheet, but I just tried 4 and 8 read-delay.

cdns,read-delay = <4>;

or

cdns,read-delay = <8>;

However, It doesn't make a difference.

But I found something about this problem. I tried using the "sf" command in my u-boot, and it works well.

=> sf probe
k3-navss-ringacc ringacc@2b800000: Ring Accelerator probed rings:286, gp-rings[96,20] sci-dev-id:235
k3-navss-ringacc ringacc@2b800000: dma-ring-reset-quirk: disabled
SF: Detected mt35xu01g with page size 256 Bytes, erase size 128 KiB, total 128 MiB
=> load mmc 1:1 ${addr_fit} tiboot3.bin
295224 bytes read in 50 ms (5.6 MiB/s)
=> sf update ${addr_fit} 0x0 295224
device 0 offset 0x0, size 0x295224
393216 bytes written, 2314788 bytes skipped in 0.644s, speed 4279314 B/s

    # I CHANGE BOOT-MODE TO OSPI AND REBOOT THE BOARD #

U-Boot SPL 2023.04-gb0d717b732 (Dec 06 2023 - 15:11:45 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.2--v09.01.02 (Kool Koala)')
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -121
U-Boot SPL 2023.04-gb0d717b732 (Dec 06 2023 - 15:11:45 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.2--v09.01.02 (Kool Koala)')
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -121
Trying to boot from SPI
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Then, I changed my boot mode to SD Card and booted to reading the "/dev/mtd0" space.

I did this to check whether the "mtd_debug read" command worked or not.

But when I read "/dev/mtd0" using mtd_debug, It still shows strange data like the one below.

Even though the tiboot3.bin file was normally written to nor-flash in u-boot, and OSPI booting was successful,

I do not understand why these data is still read.

One more interesting thing is that the "mtd_debug erase" command seems to work well.

After I use "mtd_debug erase /dev/mtd0 0 0x80000" and change the boot mode to OSPI, my board does not boot up.

Is there a possible reason the "erase" command works but "write" and "read" do not?

Thanks!

We confirmed that the "mtd_debug erase" command works well by reading the corresponding area in u-boot.

1. read 0x0~0x80000 after "sf update" in u-boot. 

=> sf read ${addr_fit} 0 0x80000
device 0 offset 0x0, size 0x80000
SF: 524288 bytes @ 0x0 Read: OK
=> md ${addr_fit}
90000000: d0068230 b8048230 010203a0 11140202  0...0...........
90000010: 9e9592df 72dd1f85 34e9e17b 25afc8b2  .......r{..4...%
90000020: 30319f05 2a09060d f7864886 0d01010d  ..10...*.H......
90000030: 81300005 300b319d 55030609 02130604  ..0..1.0...U....
90000040: 0b315355 03060930 0c080455 31585402  US1.0...U....TX1
90000050: 060d300f 07045503 6144060c 73616c6c  .0...U....Dallas
90000060: 25302731 04550306 541e0c0a 73617865  1'0%..U....Texas
90000070: 736e4920 6d757274 73746e65 636e4920   Instruments Inc
90000080: 6f70726f 65746172 30133164 55030611  orporated1.0...U
90000090: 0a0c0b04 636f7250 6f737365 13317372  ....Processors1.
900000a0: 03061130 0c030455 2049540a 70707553  0...U....TI Supp
900000b0: 3174726f 061b301d 48862a09 010df786  ort1.0...*.H....
900000c0: 0e160109 70707573 4074726f 632e6974  ....support@ti.c
900000d0: 1e306d6f 34320d17 32303730 37313031  om0...2407021017
900000e0: 175a3431 3034320d 31313038 31373130  14Z..24080110171
900000f0: 81305a34 300b319d 55030609 02130604  4Z0..1.0...U....

2. read 0x0~0x80000 after "mtd_debug erase" on linux.

=> sf read ${addr_fit} 0 0x80000
device 0 offset 0x0, size 0x80000
SF: 524288 bytes @ 0x0 Read: OK
=> md ${addr_fit}
90000000: ffffffff ffffffff ffffffff ffffffff  ................
90000010: ffffffff ffffffff ffffffff ffffffff  ................
90000020: ffffffff ffffffff ffffffff ffffffff  ................
90000030: ffffffff ffffffff ffffffff ffffffff  ................
90000040: ffffffff ffffffff ffffffff ffffffff  ................
90000050: ffffffff ffffffff ffffffff ffffffff  ................
90000060: ffffffff ffffffff ffffffff ffffffff  ................
90000070: ffffffff ffffffff ffffffff ffffffff  ................
90000080: ffffffff ffffffff ffffffff ffffffff  ................
90000090: ffffffff ffffffff ffffffff ffffffff  ................
900000a0: ffffffff ffffffff ffffffff ffffffff  ................
900000b0: ffffffff ffffffff ffffffff ffffffff  ................
900000c0: ffffffff ffffffff ffffffff ffffffff  ................
900000d0: ffffffff ffffffff ffffffff ffffffff  ................
900000e0: ffffffff ffffffff ffffffff ffffffff  ................
900000f0: ffffffff ffffffff ffffffff ffffffff  ................

Also, we confirmed in the same way that the "mtd_debug write" command does not work.

it still read "ffff" after "mtd_debug write".

Thanks!

K Kim said:

Also, we confirmed in the same way that the "mtd_debug write" command does not work.

This is only on the custom board right & not on the TI board?

- Keerthy

On our custom board.

- Kim