TDA4VM: Linux dd command write to emmc, causes EMMC boot block in SBL

Part Number: TDA4VM
Other Parts Discussed in Thread: CSD

Tool/software:

hi expert, 

My project using TDA4 VM + SDK 9.1 + EMMC boot. Emmc device type is MTFC32GASAQHD-AAT.

EMMC boot is normal without special operations.But emmc boot gets stuck when I do the following operation,These operations are for the first time to brush the soc image into emmc.

1、Use the sd card to start loading the main domain image. And log into the A72 linux environment, run the dd command to brush the soc image to the emmc. 

dd command is as follows:

#!/bin/bash

device=/dev/mmcblk0
devices=/dev/mmcblk0p

dd if=./atf_optee.appimage of=/dev/mmcblk0p2 seek=0 bs=512K count=2 conv=sync
dd if=./atf_optee.appimage of=/dev/mmcblk0p3 seek=0 bs=512K count=2 conv=sync
dd if=./tidtb_linux.appimage of=/dev/mmcblk0p6 seek=0 bs=512K count=2 conv=sync
dd if=./tidtb_linux.appimage of=/dev/mmcblk0p7 seek=0 bs=512K count=2 conv=sync
dd if=./tikernelimage_linux.appimage of=/dev/mmcblk0p8 seek=0 bs=512K count=52 conv=sync
dd if=./tikernelimage_linux.appimage of=/dev/mmcblk0p9 seek=0 bs=512K count=52 conv=sync
dd if=./lateapp1 of=/dev/mmcblk0p10 seek=0 bs=512K count=64 conv=sync
dd if=./lateapp1 of=/dev/mmcblk0p11 seek=0 bs=512K count=64 conv=sync
dd if=./lateapp2 of=/dev/mmcblk0p12 seek=0 bs=512K count=64 conv=sync
dd if=./lateapp2 of=/dev/mmcblk0p13 seek=0 bs=512K count=64 conv=sync
dd if=./rootfs.bin of=/dev/mmcblk0p16 seek=0 bs=512K count=1536 conv=sync
dd if=./rootfs.bin of=/dev/mmcblk0p17 seek=0 bs=512K count=1536 conv=sync

2、Power off the device immediately after the dd command is executed.

3、Switch to emmc boot,Then SBL is blocked  in follows position.

SBL Log:

SBL Revision: 01.00.10.01 (Sep 24 2024 - 14:06:31)

Using Lauterbach debug found the code stuck at the follows position.

The SBL program failed to read the tifs file through emmc. Specifically, the mmcsd_send_cmd23 function returns a failure.

We have made a preliminary analysis of this problem.If dd writes large files, the emmc background operation mode is triggered. If the background operation mode is not completed, the EMMC power off immediately will trigger this problem. Our soc image size is around 2G. If dd comand  operation is done.And powered off after 1 to 2 minutes, this problem does not occur again.

Our questions are as follows:

1、Please analyze the root causes of problems and provide effective solutions.

2、Why ROM program can read tiboot3.bin by emmc, But tiboot3.bin can't read tifs.bin by emmc? 

thanks !

  • Hi yang,

    Can you provide more details like:

    • Are you using emmc boot0 as a boot media or UDA partition?
    • Are you able to reproduce the same issue on EVM?
      • .If dd writes large files, the emmc background operation mode is triggered. If the background operation mode is not completed, the EMMC power off immediately will trigger this problem
      • Seems emmc is going into some bad state , have you checked with emmc vendor on this i am assuming we are not getting the response from the emmc device.

    Regards
    Diwakar

  • Hello Diwakar,

    1. yes, we use emmc boot0 as boot media storing tifs and tiboot3 image.

    2. project board is same as EVM. please directly reproduce this issue.

    Have a nice day.

  • Hi Diwakar,

    Update more information that it will work normally if wait the BKOPS_STATUS bit[1:0](EXT_CSD Byte[246])change from 0x2/0x3 to 0x0 after DD command. Switch to Emmc boot will be stuck if BKOPS_STATUS bit[1:0] is 0x2/0x3 to power off board.

    It will be stuck serval minutes and go to work normally when the issue reproduced.

  • Hi Yunhang,

    As Kangjia stated, if the BKOPS_STATUS bit is 0x2/0x3,the Emmc gets stuck.This 0x2/0x3 indicates that the background operations running in the EMMC are critical(0x3) or perfomance affecting(0x2). Hence ,when the device is suddenly powered off after dd command,the device goes into some bad state and it completely depends on the firmware running on the device and not on the the host.Hence,a solution to this would be to discuss with the vendors on what the firmware does when the device is abruptly shut down.Another solution,that I would suggest would be to wait until this bit gets cleared before powering off the device so that the critical/perfomance affecting background operations gets completed,because when this bit is set to 0x2/0x3,emmc device will not accept the data from the host as the busy bit will be set so we need to wait for background operation to get completed first.

  • Hello Diwakar,

    1、We cannot wait for the background operation to complete before powering off. The waiting time for the background operation is related to the size of the dd file. The waiting time is 1-2 minutes, which is too long.And there is no way to solve the abnormal power-off scenario.

    2、Power off the device immediately after the dd command is executed. Why ROM program can read tiboot3.bin by emmc, But sbl can't read tifs.bin by emmc? Whether ROM code emmc driver logic is different?Does TI have a software modification solution?

  • Hi Yang,

    1、We cannot wait for the background operation to complete before powering off. The waiting time for the background operation is related to the size of the dd file. The waiting time is 1-2 minutes, which is too long.And there is no way to solve the abnormal power-off scenario.

    Background operation is related to the emmc device, there is nothing which we can do from the host side.We suggest you to check with emmc vendor regarding this behaviour.

    2、Power off the device immediately after the dd command is executed. Why ROM program can read tiboot3.bin by emmc, But sbl can't read tifs.bin by emmc? Whether ROM code emmc driver logic is different?Does TI have a software modification solution?

    What is the speed mode you using in SBL , ROM configure the emmc in legacy speed mode.

    Regards
    Diwakar

  • Our emmc driver code is native SDK9.1, has not been modified, the default emmc read tifs speed mode is high.Whether TI has made any new progress on this issue?

  • HI Yang,

    As said earlier the behaviour is with respect to emmc device, host can't do anything on that . Have you checked this with the emmc vendor ?

    Our emmc driver code is native SDK9.1, has not been modified, the default emmc read tifs speed mode is high.Whether T

    Question related to speed was raised because there may be the case emmc is still responding if we use lower speed mode.As ROM uses legacy speed mode it may be able to read TIFS but if we use high speed inside SBL it is not responding properly.

    Regards
    Diwakar

  • has update information for this issue?

    1. do you reproduce this issue by register BKOPS_EN?

    2. have you printed emmc command during startup?

  • Hi Wang,

    We doing that experiment we are trying to enable the BKOPS and see if we are able to reproduce the issue, will update you once we have results. In the meantime can you get the traces using emmc trace analyser, so that we can be sure whether we are doing any write operation or not while reading the TIFS.

    From the code during read operation we send CMD23 and then CMD18, before sending CMD23 we also do check whether emmc is in transfer state or not.

    Regards
    Diwakar

  • Hi wang,

    Could you share the steps which you followed to create each of the partitions along with the filesystem used in each of the partition and the steps followed to create the filesytem for each partition.

    We tried reproducing the issue by creating 2 rootfs partitions using the steps below:

    # STEP 1 On host generate the uid
    uuidgen
    # STEP 2 On device set the uid
    setenv uuid_gpt_rootfs_2 <genrated_uid_key>
    # STEP 3 Set partition topology
    setenv partitions uuid_disk=\${uuid_gpt_disk}\;name=rootfs,start=6150MiB,size=30MiB,uuid=\${uuid_gpt_rootfs}\;name=rootfs_2,start=0,size=6144MiB,uuid=\${uuid_gpt_rootfs_2}
    # STEP 4 save env
    saveenv
    # STEP 5 create partion table
    gpt write mmc 0 ${partitions}
    # STEP 6 Reboot the device
    reboot
    # STEP 7 Now you will be able to see two partion use command "lsblk" to confirm
    # Now we will make fs type as ext4
    mkfs.ext4 /dev/mmcblk0p1 //rootfs_1
    mkfs.ext4 /dev/mmcblk0p2 //rootfs_2

    # STEP 8 create a mount handle
    mkdir /mnt/rootfs_1
    mkdir /mnt/rootfs_2

    # STEP 9 mount
    mount dev/mmcblk0p1 /mnt/rootfs_1
    mount dev/mmcblk0p2 /mnt/rootfs_2

    After doing so,we set the BKOPS_EN AUTO EN bit in EXT_CSD register manually using mmc write  command

    We then tried to copy 2 files of 2 MB and 2 GB to rootfs_1 and rootfs_2 partitions respectively using the ddcommand  using seek argument as 0 in the dd command.However ,on doing so the filesystem was getting corrupted and it is showing that the both the partitions are entirely used even though the files copied are less than 50 % of the partition sizes.

    Secondly,we tried the same experiment with seek at a particular offset as given in the below image:

    However,although dd command is showing success,none of the file is copied to the respective partitions.I am attaching the snapshots of that as well below:

  • Hi Gokul Praveen:

    1、We use SBL boot, not SPL boot.The problem can be repeated only after the SBL boot.

    2、No special partition is required to reproduce this problem.You can use the dd command like " dd if=rootfs /dev/mmcblk0 seek=xx bs=512K count=2 conv=sync" copy image to emmc. And /dev/mmcblk0 is unpartitioned device file.

  • Hi yang.

    I tried the same thing as you suggested to reproduce the problem,however,no issue was found.The AUTO_EN bit was set in BKOPS_EN bit to enable automatic background operations,before the dd command was passed.

    The below image shows was captured after the dd command was executed,however,the BKOPS_STATUS bit was not getting set.