跳转至

Sigmastar eMMC_debugsop手册

REVISION HISTORY

Revision No.
Description
 Date
1.0
  • Initial release
    		•  02/21/2024

    1. 无法正常识别eMMC设备

    图1-1 eMMC设备识别失败定位思维导图
    流程 方法 出口条件 下一步 需提供给SWRD的资料 相关可参考FAQ
    A 1.使用万用表确认eMMC的vcc电压初始化阶段是否3.3v
    2.确认缺省情况下clk-line为低电平，cmd/data-line为高电平
    3.确认eMMC的vccq电压是否为1.8/3.3v范围    		 出口条件1:
    1.初始化阶段eMMC的vcc供电与3.3v差距较大，
    2.或bus-line的缺省状态不对，
    3.或eMMC的vccq供电未在1.8/3.3v有效范围内
    > 供电问题
    出口条件2:
    供电正常    >无问题    		 出口条件1:
    >流程结束
    出口条件2:
    >B    		 出口条件1:
    ==>寻求CAE协助
    B 1.确认eMMC的padmux配置是否和与开发板对应，pad是否与其他mode有冲突方法:
    cd
    vim arch/arm/boot/dts/iford_xxxx-padmux.dtsi
    emmc padmux mode会带有'EMMC4B_MODE'或'PM_SDIO_MODE'关键字，对应的gpio pad需要重点确认与其他模块是否存在复用的情况
    2.确认eMMC的dts相关配置是否和当前使用槽位配套方法:
    cd
    vim arch/arm/boot/dts/iford.dtsi
    相关配置项含义请参阅，重点关注：
    2.1 no-sdio/no-sd/no-mmc，此三项配置接入哪种类型设备则注释对应项，并配置另外两种，比如:接入emmc卡，则注释no-mmc，并配置no-sdio/no-sd
    2.2 reg/cifd-reg/pwr-save-reg，此为所用IP对应的bank地址，分non-pm和pm，non-pm的base为0x1F282600，pm的base为0x1F008400
    2.3 ip-order/interrupts/clocks，此三者的一一对应关系，比如使用ip-order=0，则interrupts和clocks对应槽位的中断和时钟选项要和当前槽位保持一致。non-pm ip-order配为0，pm ip-order配为1    		 出口条件1:
    1.padmux未正确配置或者存在与其他mode冲突情况
    2.dts中eMMC的相关配置项与当前使用的槽位不匹配
    > 配置错误问题
    出口条件2:
    配置正常    > 无问题    		 出口条件1:
    >流程结束
    出口条件2:
    >C    		 出口条件1:
    ==>寻求CAE确认当前开发板使用的padmux情况，然后按照实际情况配置正确的padmux和dts
    C 1.确认硬件是否存在问题
    1.1.场景1-接错槽位:开发板使用外挂eMMC，且有多个槽位时，要根据实际情况接入
    1.2.场景2-IC pin脚输出不稳定:使用万用表或者示波器量测近IC侧与近Device侧信号，不应该出现信号不稳定现象
    1.3.场景3-eMMC颗粒虚焊:eMMC是内置在开发板情况时，排查其他条件均无问题时，可以考虑冲焊eMMC颗粒    		 出口条件1:
    1.确认外挂eMMC放错槽位
    > 插入正确槽位即可
    出口条件2:
    IC pin脚输出不稳定，导致信号质量差
    > 更换新IC
    出口条件3:
    eMMC颗粒虚焊，导致信号质量差
    > 重新焊接eMMC
    出口条件4:
    硬件正常
    > 无问题    		 出口条件1:
    >流程结束
    出口条件2:
    >流程结束
    出口条件3:
    >流程结束
    出口条件4:
    >G    		 出口条件2:
    >寻求CAE协助
    出口条件3:
    >寻求CAE协助
    G 1.更换相同规格eMMC再次测试是否正常识别
    2.更换开发板测试相同规格eMMC是否正常识别
    3.在其他平台测试相同规格eMMC是否正常识别    		 出口条件1:
    更换相同规格eMMC后可以正常识别
    > eMMC设备问题
    出口条件2:
    更换开发板测试后可以正常识别
    > 开发板问题
    出口条件3:
    在其他平台测试后可以正常识别
    ==>驱动存在问题    		 出口条件1:
    >流程结束
    出口条件2:
    >流程结束
    出口条件3:
    ==>流程结束    		 出口条件3:
    >1.提供串口log
    >2.使用LA或者示波器抓取初始化整个过程的波形
    ==>3.在linux控制台下通过riu命令dump eMMC IP的相关bank信息：
    non-pm:0x1413/0x1038/0x103C/0x1033
    pm:0x42/0xE/0x3F

    2. eMMC读写失败问题

    图2-1 eMMC读写失败定位思维导图
    流程 方法 出口条件 下一步 需提供给SWRD的资料 相关可参考FAQ
    A 出错时根据关键字"[sdmmc"检索debug log，主要关注error num：
    1.(E: 0x0001):读CRC
    2.(E: 0x0002):写CRC
    3.(E: 0x0010):CMD CRC
    3.(E: 0x0100):驱动报Timeout
    4.(E: 0x0008):IP报Device No Rsp    		 出口条件1:
    1.cmd 12/13/17/18/23/24/25等读写相关命令，执行报CRC错误
    出口条件2:
    1.cmd 12/13/17/18/23/24/25等读写相关命令，执行报Timeout错误
    出口条件3:
    1.cmd 12/13/17/18/23/24/25等读写相关命令，执行报device不响应错误    		 出口条件1:
    >B
    出口条件2:
    >C
    出口条件3:
    ==>D
    B CRC问题本质是信号质量差，可根据CRC报错类型并结合《eMMC使用参考》选择pad最佳驱动能力 出口条件1:
    1.CRC报错类型是RX CRC，即读取时报错
    出口条件2:
    1.CRC报错类型是TX CRC，即写入时报错
    出口条件3:
    1.其他CRC报错类型    		 出口条件1:
    >E
    出口条件2:
    >F
    出口条件3:
    ==>G
    C 1.驱动读写操作报超时问题，第一时间抓取波形确认是否传输性能存在问题
    2.查阅波形并无问题情况下，判断eMMC MIE中断是否正常上报或接收，判断方法见<附录5>
    3.检查eMMC Timing是否存在异常，常见Timing问题见<附录5>
    4.以上情况均无问题，考虑eMMC Device是否异常    		 出口条件1:
    1.根据波形查看当前工作频率低于预期
    出口条件2:
    1.检查bus width是与预期不符
    出口条件3:
    1.根据Debug log显示出错时相关event没有正常触发
    出口条件4:
    1.eMMC Timing异常
    出口条件5:
    1.eMMC Device原因 导致card busy情况    		 出口条件1:
    >I
    出口条件2:
    >J
    出口条件3:
    >K
    出口条件4:
    >G
    出口条件5:
    ==>L
    D 1.eMMC IP报Device 无响应问题，可以抓取波形确认是否CMD发出后没有收到响应
    2.参考<1：无法正常识别eMMC设备>，检查相关配置是否正确
    3.优先检查硬件电气通路是否正常，运行环境是否加干扰测试(比如打静电、高低温等)
    4.检索Debug log查找"SAR1 SDMMC WARN trigger"关键字，判断是否存在掉电保护被误触发情况
    5.检查eMMC Timing是否存在异常
    6.以上情况均无问题，考虑eMMC Device是否异常    		 出口条件1:
    1.检查配置无问题，波形显示CMD发出后，未接收到Device响应
    出口条件2:
    1.检查CHIP到eMMC 子板之间的电气通路存在明显信号衰减
    出口条件3:
    1.运行环境当前正在进行打静电或高低温等压力测试
    出口条件4:
    1.检索Log，发现eMMC在未断电情况下，出现掉电保护被触发现象
    出口条件5:
    1.eMMC Timing异常
    出口条件6:
    1.eMMC Device原因导致不响应情况
    出口条件7:
    1.波形显示Device有响应，但是IP判断为未响应    		 出口条件1:
    >流程结束
    出口条件2:
    1.请CAE协助排查问题
    出口条件3:
    >流程结束
    出口条件4:
    >流程结束
    出口条件5:
    >G
    出口条件6:
    >L
    出口条件7:
    >流程结束    		 出口条件1:
    1.dump debug log以及DTS配置文件
    出口条件3:
    出口条件4:
    1.dump debug log
    出口条件7:
    1.预计CHIP设计缺陷
    E 参考《eMMC使用参考》 出口条件1:
    1.根据实际情况设置data driving档位后恢复正常
    出口条件2:
    1.尝试所有data driving档位后仍然报CRC错误    		 出口条件1:
    >流程结束
    出口条件2:
    >G
    F 参考《eMMC使用参考》 同"E" 同"E"
    G 1.参考《eMMC使用参考》综合调节CLK/CMD line的驱动能力
    2.调节CLK相位，具体操作可参考《eMMC使用参考》
    3.根据TMUX表以及eMMC REG表调整时钟信号采样模式
    4.trans-mode使用DMA时，需要设置reg_dma_rd_clk_stop避免造成丢数据
    5.使用LA或示波器抓取出问题阶段的完整波形    		 出口条件1:
    1.通过综合调节信号线的驱动档位后恢复正常
    出口条件2:
    1.通过调节CLK的四相位或八相位后恢复正常
    出口条件3:
    1.通过调节时钟信号采样模式后恢复正常
    出口条件4:
    1.DMA Mode传输模式场景下，设置offset:0xb bit7后恢复正常
    出口条件5:
    1.以上措施均无效果，波形与正常情况下的波形存在差异，比如上升沿采样锁定时间不达标、cmd overlap、cmd 最小interval不达标等
    出口条件6:
    1.确认以上设定均正常，波形无异常    		 出口条件1:
    出口条件2:
    出口条件3:
    出口条件4:
    >流程结束
    出口条件5:
    >流程结束
    出口条件6:
    ==>H/L    		 出口条件5:
    1.dump整个过程的完整debug log，包括从emmc init开始到出现问题期间的日志
    2.抓取异常场景的完整波形，最好有相同条件下正常场景的波形作为对比
    3.在linux控制台下通过riu命令dump eMMC IP的相关bank信息：
    non-pm:0x1413/0x1038/0x103C/0x1033
    pm:0x42/0xE/0x3F
    H 1.外挂eMMC情况，可以先参考<1：无法正常识别eMMC设备>的交叉验证章节
    2.在Default状态下(即无数据交互情况)使用万用表或示波器点测eMMC的CLK/CMD/DATA Line的电信号是否符合预期
    3.在通信触发情况下(即数据交互情况)使用万用表或示波器分别点测近芯片端与近Device端的电信号是否存在明显信号差异
    4.通过增加上拉电阻等手段，尝试从硬件角度增强驱动能力    		 出口条件1:
    1.交叉验证后，通信恢复正常
    出口条件2:
    1.在缺省条件下，不满足CLK line为低电平，CMD/DATA line为高电平状态
    出口条件3:
    1.IC端与Device端的电信号存在衰减等异常现象
    出口条件4:
    1.通过硬件上调整电信号质量后，通信恢复正常
    出口条件5:
    1.电信号无异常，硬件上调整无效果    		 出口条件1:
    >流程结束
    出口条件2:
    1.检查padmux配置与当前eMMC使用槽位是否一致
    2.在linux下配合使用LA或示波器手动上下拉eMMC的pin gpio，看是否符合预期
    出口条件3:
    出口条件4:
    出口条件5:
    >流程结束
    		 出口条件3:
    1.寻求CAE协助
    出口条件5:
    1.同步硬件条件，帮助RD搭建复现环境
    I 1.根据手册明确当前槽位eMMC IP使用的版本
    1.1 eMMC4.3最高支持48MHz
    1.2 eMMC5.0 HS200/HS400最高支持200MHz
    2.在IP允许的频率范围内确认是否已经是最高一档
    3.读取bank 0x1038 offset 0x43/bank 0x42 offset 0x24确认CLK是否按照预期设置成功    		 出口条件1:
    1.调整CLK到最高档，通信恢复正常
    出口条件2:
    1.调整CLK无效果或者已经是最高档
    出口条件3:
    1.CLK设定与寄存器读取数值不符    		 出口条件1:
    >流程结束
    出口条件2:
    >J
    出口条件3:
    ==>流程结束    		 出口条件3:
    1.non-pm dump 0x1038/0x1133寄存器信息
    pm dump 0xe寄存器信息
    2.提供dts配置文件
    3.提供Debug Log
    J 1.根据SPEC文档，对于不同的速率模式有对应支持的总线位宽
    1.1 eMMC4.3 可使用1bit/4bit/8bit Buswidth
    1.2 eMMC5.0 HS200可使用4bit/8bit位宽
    1.3 eMMC5.0 HS400仅支持8bit位宽
    2.读取bank 0x1413/0x42 offset 0xb[2:1]确认    		 出口条件1:
    1.调整Buswidth到对应速率模式的最大位宽，通信恢复正常
    出口条件2:
    1.调整Buswidth无效果或者已经是该速率模式下最大位宽
    出口条件3:
    1.Buswidth设定与寄存器读取数值不符    		 出口条件1:
    >流程结束
    出口条件2:
    >K
    出口条件3:
    ==>流程结束    		 出口条件3:
    1.dump 0x1413/0x42寄存器信息
    2.提供dts配置文件
    3.提供Debug Log
    K 1.读取bank 0x1413 0ffset 0x0[1:0]判断读写完成event是否举起
    2. 如果event已经被触发但是驱动仍然报超时，优先检查CPU Loading和中断触发次数情况    		 出口条件1:
    1. 在驱动超时时间内，event没有被举起
    出口条件2:
    1.event已经被举起，且CPU Loading高或中断大量触发
    出口条件3:
    1.event正常举起，且环境无其他异常    		 出口条件1:
    >流程结束
    出口条件2:
    排查CPU Loading高的进程是哪个，尝试将eMMC MIE中断处理绑核到CPU1
    出口条件3:
    >G    		 出口条件1:
    1.公版尝试复现，帮助RD搭建环境
    L 1.先确认eMMC使用寿命是否已到:
    cd /sys/kernel/debug/mmc/mmc:xxxx
    cat ext_csd
    其中第537~538位标识life time，具体参阅SPEC
    2.参考<1：无法正常识别eMMC设备>的交叉验证章节
    3.重新补焊eMMC颗粒    		 出口条件1:
    1.eMMC life time已经超过最大值或者使用寿命接近最大值
    出口条件2:
    1.交叉验证或补焊后，通信恢复正常
    出口条件3:
    1.确认eMMC设备正常    		 出口条件1:
    >更换eMMC
    出口条件2:
    >流程结束
    出口条件3:
    ==>流程结束    		 出口条件3：
    1.公版尝试复现，帮助RD搭建环境
    M 1.使用万用表或示波器对CHIP到eMMC 子板整个通路进行点测，主要观测近CHIP端与eMMC子板端信号是否存在较大差异 出口条件1:
    1.近CHIP端与eMMC子板端电信号有明显衰减现象
    出口条件2:
    1.电气通路正常    		 出口条件1:
    1.请CAE协助排查
    出口条件2:
    ==>N
    N 1.与客户明确运行环境是否存在外界干扰，比如正在进行打静电、高低温等压测 出口条件1:
    1.正在进行压测，附加有打静电、高低温等手段
    出口条件2:
    1.无外界干扰，正常运行环境    		 出口条件1:
    >流程结束
    出口条件2:
    >O    		 出口条件1:
    1.抓取Debug log和波形
    2.协调CAE一同定位
    O 1.在明确运行环境非断电情况下，检测Debug log中是否存在"SAR1 SDMMC WARN trigger"关键字
    2.检测过滤是否包含与eMMC驱动相关的"retry"、"reset"关键字    		 出口条件1:
    1.检测Debug log，存在eMMC触发掉电保护或者retry操作
    出口条件2:
    1.环境未被重置或者误触发eMMC掉电保护情况    		 出口条件1:
    >流程结束
    出口条件2:
    >G    		 出口条件1:
    1.eMMC误触发掉电保护
    2.如果环境有被触发重置操作，则抓取Debug log

    3. eMMC读写过程成功，但BUF中数据存在问题

    图3-1 eMMC读写成功但内存数据异常定位思维导图
    流程 方法 出口条件 下一步 需提供给FAE的资料 相关可参考FAQ
    A 1.查阅规格文档确认eMMC IP可使用的Dram地址空间，进而确认传递到eMMC IP的物理地址偏移是否合法，即bank 1413/42 offset 0x3/0x4组成的地址. 
    2.Linux 可用地址空间是从0x20000000开始，eMMC IP是使用减去了0x20000000地址偏移的物理地址，也就是0ffset 0x3/0x4是填充的物理地址，从0开始到最大可用偏移，该偏移需要向FAE确认    		 出口条件1:
    1.传递到eMMC IP的物理地址偏移超出了有效范围
    出口条件2:
    1.传递给eMMC IP的物理地址偏移合法有效    		 出口条件1:
    >流程结束
    出口条件2:
    >B    		 出口条件1:
    1.使用系统提供的标准地址空间分配接口申请buf
    B 1.构造测试pattern，确认source pattern与读/写得到的pattern差异是否存在规律性，利用fio工具指定pattern 出口条件1:
    1.pattern错误明显具有规律性，总是以eMMC驱动 Cache-line大小出错
    出口条件2:
    1.pattern出错并无明显规律    		 出口条件1:
    >流程结束
    出口条件2:
    >C    		 出口条件1:
    1.确认是否使用eMMC标准读写接口，若否，进一步确认buf是否non-cache
    2.提供公板复现环境
    C eMMC驱动读写过程正常，在IP内部搬运数据过程出现异常，主要考虑以下几点：
    1. dma burst length是否设置到8，即bank 1413/42 offset 0x2[5:4]
    2.读写是否未考虑Cache操作或者处理不正确
    3.现代CPU乱序执行导致的数据同步问题    		 出口条件1:
    1.dma burst length未设置到最大
    出口条件2:
    1.运行环境Cache-on情况下，buf读写时未进行invalid和flush操作，导致取到的数据不一致
    出口条件3:
    1.对于需要同步调用的逻辑未进行内存屏障处理，导致乱序执行
    出口条件4:
    1.其他问题    		 出口条件1:
    1.尝试手动设置dma burst到最大值8
    出口条件2:
    1.尝试在写操作执行flush操作，在读操作后执行invalid操作
    出口条件3:
    出口条件4:
    ==>流程结束    		 出口条件3:
    出口条件4:
    1.确认客户分支以及打过的patch现状
    2.提供公板复现环境

    4. eMMC Boot问题

    图4-1 eMMC Boot问题定位思维导图
    流程 方法 出口条件 下一步 需提供给SWRD的资料 相关可参考FAQ
    A 首先检索Debug Log判断eMMC Boot出错时卡在哪个阶段
    1. 在ROM阶段就失败则Log不会出现IPL及之后阶段的关键字
    2.在ROM阶段之后失败，可以根据最后一个出现的关键字判断是IPL/IPL_CUST/UBOOT的哪个阶段，然后具体分析问题    		 出口条件1:
    1.eMMC Boot在ROM阶段失败
    出口条件2:
    1.eMMC Boot在ROM之后的阶段失败    		 出口条件1:
    >B
    出口条件2:
    >G
    B 在ROM启动阶段就失败，首先检查开发板上boot strap是否和isptool烧录时选择一致，当前最新版isptool已经可以自动匹配，对于老版本工具，需要注意选项板的'Bus Width'和开发板的boot strap选择一致 出口条件1:
    1.isptool烧录时选择的Bus width与boot strap选择的类型不一致
    出口条件2:
    1.两者配置一致    		 出口条件1:
    修正isptool烧录时Bus width
    出口条件2:
    ==>C
    C SPEC规定，Boot Ack机制在cmd0发出后最大50ms内会在Dat0 line回复Ack信息，抓取波形确认是否有开启Boot Ack机制或者有违背SPEC规定的现象，一般可以通过uboot烧录命令'mmc partconf'第一个参数确定，为0- disable Ack; 1- enable Ack 出口条件1:
    1.Boot ACK机制开启，且Ack信息出现在其他data line
    出口条件2:
    1.Boot Ack未配置开启    		 出口条件1:
    关闭Boot Ack机制，即 ExtCSD[179]bit6置为0
    出口条件2:
    ==>D
    D 抓取eMMC Boot波形，确认波形是否有响应Boot分区数据 出口条件1:
    1.cmd0发送后未响应Boot分区数据，查询ECSD[179]bit[5:3]发现卡未使能Boot mode
    出口条件2:
    1.cmd0发送后未响应Boot分区数据，且根据波形看不满足进入Boot mode条件    		 出口条件1:
    >E
    出口条件2:
    >F
    E 参考<2. eMMC读写失败问题>的流程L，读取ECSD[179]bit[5:3]寄存器，并根据SPEC解析eMMC卡是否使能Boot mode 出口条件1:
    1.eMMC卡未使能Boot mode
    出口条件2:
    1.eMMC卡已使能Boot mode    		 出口条件1:
    1.使用isptool重新烧录，并且不勾选disable part
    出口条件2:
    ==>F
    F SPEC规定，eMMC卡Boot mode包含三个状态:
    1.pre-idle state，有三种方式可以进入该状态:
    1.1 power on后;
    1.2 cmd0(arg:0xf0f0f0f0)命令
    1.3 hw reset by host
    2.pre-boot state：
    power on或reset后且在发送第一个命令cmd1之前，cmd line至少保持74个clock周期低电平
    3.boot state:
    进行boot分区数据读取，主要方式:
    3.1 cmd line低电平
    3.2 cmd0(arg:0xfffffffa)，当前eMMC使用的方式    		 出口条件1:
    1.进入pre-idle state失败，即当前eMMC使用的HW reset或者cmd0(arg:0xf0f0f0f0)对eMMC卡无效
    出口条件2:
    1.eMMC Timing时序有问题    		 出口条件1:
    1.尝试切换HW reset/SW reset方式解决
    出口条件2:
    ==>流程结束    		 出口条件2:
    1.抓取eMMC Boot波形及Dump log
    2.协助RD搭建复现环境
    G 参考<1. 无法正常识别eMMC设备>的流程B，检查eMMC Padmux配置是否正确 出口条件1:
    1.eMMC Padmux配置有问题
    出口条件2:
    1.eMMC Padmux配置正确    		 出口条件1:
    1.根据实际运行环境配置正确
    出口条件2:
    ==>F

    5. 附录

    5.1 eMMC设备初始化流程


    >>>emmc go idle: cmd0让卡进入idle状态

    初始化会重新上下电，设备进入idle state


    >>>获取OCR寄存器信息: 获取卡的OCR信息并等待卡ready

    in idle state，host会获取OCR寄存器，并等待卡完成power up routine finish，即
    cmd1响应的bit31置为1代表卡已ready


    >>>sd go idle again: cmd0让卡进入idle状态

    获取OCR后，host会重新做reset动作


    >>>cmd1: 本次会加上host能力并重新获取OCR

    host结合第一次获取的OCR，发送自身能力集，因为是重新上下电，所以仍然需要等待ready标记


    >>>cmd3/cmd9/cmd7: host获取emmc card RCA地址并根据地址获取CSD寄存器信息和选择卡操作

    根据RCA选择emmc卡后，会使卡进入trans-state状态


    >>>获取EXT-CSD寄存器信息: emmc重要扩展寄存器信息


    >>>cmd6+cmd13 switch操作: 进行一系列设置和开启功能操作

    读取ext-csd信息后是一系列cmd6+cmd13搭配的switch操作，注意cmd6 rsp是r1b类型，device status反映在其后面的cmd13 rsp。
    有时也会搭配assert busy signal(data0 拉低) + r1方式响应cmd6，如上图，switch操作主要包括以下:
    1. enable erase group
    2. ext-csd[179] boot partion enable
    3. Switch to high-speed, 此步骤后clock为48MHz
    4. Switch bus width 并通过发送cmd8获取一遍确认
    5. Select power class 确认供电电压
    6. Switch cache ctrl 开启cache功能
    以上步骤完成后，因为card device生成，会和card driver匹配，生成block设备节点。


    >>>emmc card识别成功

    5.2 eMMC常见错误波形及日志


    >>>reg_emmc status


    >>>reg_emmc event


    >>>cmd no rsp

    host已经发出cmd request并且clock正常打出，但是在8T时间内没有等到device响应
    驱动会印出SD_STS:0x0F08错误码，错误码均关注低8位，对照reg_sdio表的offset:0xd解释


    >>>cmd crc

    host正常发出cmd17/18/24/25写命令后，data line有数据响应回复，写命令dat0的最后5个bit是device标识的CRC状态确认。正确为'00101'，错误为'01011'
    读命令的CRC为IP内部校验
    驱动会印出SD_STS:0x0F01(读CRC)/SD_STS:0x0F02(写CRC)错误码，错误码均关注低8位，对照reg_sdio表的offset:0xd解释


    >>>cmd timeout


    cmd超时，是驱动层面的判断，所以波形一般是正常的，主要体现在驱动的debug err log上
    驱动会印出(FAIL)= 0100错误码，为驱动设定的等待时间已经到达，但event未能接收，参考《2.eMMC通讯过程问题》
    此处可以关注驱动预埋的关键信息打印，'eventnum=3'标识需要等待带data的读cmd，'MIE_EVENT[00]=0x42'标识只等到cmd rsp，但是dat_end事件没有等到
    另外还可以关注'SD_STS[0D]=0xe00'即sd status寄存器的高8位，如果是非全1状态，代表data line有拉低情况，一般是data还在传输或被拉低


    >>>cmd6 执行switch func error

    cmd6命令比较特殊，其rsp是r1b类型，cmd6命令本身执行出错，需要紧接着的cmd13响应反馈错误状态
    图中便是switch error，cmd13 rsp状态显示为'980'，即device switch error


    >>>emmc boot

    spec规定emmc boot使用cmd0(ARG:0xfffffffa)请求boot data，需要在规定的1s时间内回传数据给host，否则判定为发生异常


    >>>emmc isptool

    老版本的isptool会需要人为选择bus width，这里应该和开发板上boot strap的盖帽选择保持一致，新版本tool已经自动保持一致


    >>>emmc boot ack

    emmc boot ack enable情况下，device会在cmd0发出后的50ms内发送acknowledge pattern '010'来标识卡已经进入boot mode


    >>>常见timing问题1: cmd打出时，clk被关闭


    >>>常见timing问题2: cmd打出时，clk异常，导致cmd不能被正常识别


    >>>常见timing问题3: 打静电/高低温等外界干扰，导致clk异常


    >>>常见timing问题4: clk几乎无采样建立时间，容易造成误判

    timing问题，一般比较复杂，需要硬件FAE介入提供方案，常见的sw手段一般包括调节phase，改善驱动能力，展频等