sdcard_sdio_debugsop手册

REVISION HISTORY

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

    1. SD/SDIO卡识别过程问题

    图1-1 SD/SDIO卡识别过程问题定位思维导图

    流程 方法 出口条件 下一步 需提供给FAE的资料
    A 1.使用万用表确认sd卡的vcc电压初始化阶段是否3.3v；根据sdio设备使用手册确认vccq(io)电压是否符合规定,一般sdio设备可以支持1.7v~3.6v范围，vcc电压则根据sdio设备实际情况决定，厂商会给出使用手册
    2.确认缺省情况下clk-line为低电平，cmd/data-line为高电平
    3.确认sd/sdio的vccq电压是否为1.8/3.3v范围    		 出口条件1:
    1.初始化阶段sd卡的vcc供电与3.3v差距较大，或者sdio卡的vcc供电不符合手册规定
    2.或bus-line的缺省状态不对，
    3.或sd/sdio卡的vccq供电未在1.8/3.3v有效范围内
    > 供电问题
    出口条件2:
    供电正常
    > 无问题    		 出口条件1:
    >流程结束
    出口条件2:
    >B    		 出口条件1:
    ==>寻求硬件协助
    B 1.确认sd/sdio的padmux配置是否与开发板对应，pad是否与其他mode有冲突，确认方法:
    cd kernel_path
    vim arch/arm/boot/dts/pcupid_xxxx-padmux.dtsi
    sd/sdio padmux mode会带有'SD_BOOT_MODE'或'SDIO_MODE'关键字，对应的gpio pad需要重点确认与其他模块是否存在复用的情况
    2.确认sd/sdio的dts相关配置是否和当前使用槽位配套方法:
    cd kernel_path
    vim arch/arm/boot/dts/pcupid.dtsi
    相关配置项含义请参阅《SDMMC使用参考》，重点关注：
    2.1 no-sdio/no-sd/no-mmc，此三项配置接入哪种类型设备则注释对应项，并配置另外两种，比如:接入sd卡，则注释no-sd，并配置no-sdio/no-mmc
    		 出口条件1:
    1.padmux未正确配置或者存在与其他mode冲突情况
    2.dts中sd/sdio的相关配置项与当前使用的槽位不匹配
    > 配置错误问题
    出口条件2:
    配置正常
    > 无问题    		 出口条件1:
    >流程结束
    出口条件2:
    >C    		 出口条件1:
    ==>寻求硬件确认当前开发板使用的padmux情况，然后按照实际情况配置正确的padmux和dts
    C 1.确认硬件是否存在问题
    1.1.场景1-接错槽位:开发板有多个槽位时，要根据实际padmux配套接入
    1.2.场景2-ic pin脚输出不稳定:使用万用表或者示波器量测近ic侧与近device侧信号，不应该出现信号不稳定现象
    1.3.场景3-sd卡座虚焊:排查其他条件均无问题时，可以先尝试同一槽位的sd小卡座，如果无问题，则尝试重新焊sd卡座    		 出口条件1:
    1.确认sd卡插错槽位
    > 插入正确槽位即可
    出口条件2:
    IC pin脚输出不稳定，导致信号质量差
    > 更换新IC
    出口条件3:
    sd卡座虚焊，导致信号质量差
    > 重新焊接sd卡座
    出口条件4:
    硬件正常
    > 无问题    		 出口条件1:
    >流程结束
    出口条件2:
    >流程结束
    出口条件3:
    >流程结束
    出口条件4:
    >G    		 出口条件2:
    >寻求硬件协助
    出口条件3:
    >寻求硬件协助
    G 1.更换相同规格sd/sdio卡再次测试是否正常识别
    2.更换开发板测试相同规格sd/sdio卡是否正常识别
    3.在其他平台测试相同规格sd/sdio卡是否正常识别    		 出口条件1:
    更换相同规格sd/sdio卡后可以正常识别
    > sd/sdio设备问题
    出口条件2:
    更换开发板测试后可以正常识别
    > 开发板问题
    出口条件3:
    在其他平台测试后可以正常识别
    ==>驱动存在问题    		 出口条件1:
    >流程结束
    出口条件2:
    >流程结束
    出口条件3:
    ==>流程结束    		 出口条件3:
    >1.提供串口log
    >2.使用LA或者示波器抓取初始化整个过程的波形
    ==>3.在linux控制台下通过riu命令dump sdio IP的相关bank信息：
    0x1413/0x1038/0x103C/0x103E

    2. SD/SDIO通讯过程问题

    图2-1 SD/SDIO通讯过程问题定位思维导图

    流程 方法 出口条件 下一步 需提供给FAE的资料
    A 出错时根据关键字"[sdmmc"检索debug log，主要关注error num：
    1.(E: 0x0001):读crc
    2.(E: 0x0002):写crc
    3.(E: 0x0010): cmd rsp crc
    3.(E: 0x0100):驱动报timeout
    4.(E: 0x0008):IP报device no rsp    		 出口条件1:
    1.cmd 12/13/17/18/23/24/25/52/53等读写相关命令，执行报crc错误
    出口条件2:
    1.cmd 12/13/17/18/23/24/25/52/53等读写相关命令，执行报timeout错误
    出口条件3:
    1.cmd 12/13/17/18/23/24/25/52/53等读写相关命令，执行报device不响应错误    		 出口条件1:
    >B
    出口条件2:
    >C
    出口条件3:
    ==>D
    B crc问题本质是信号质量差，可根据crc报错类型并结合调整driving(GPIOE这组pad范围为0-1,GPIOA这组pad范围为0-3)选择pad最佳驱动能力 出口条件1:
    1.crc报错类型是rx crc，即读取时报错
    出口条件2:
    1.crc报错类型是tx crc，即写入时报错
    出口条件3:
    1.其他crc报错类型    		 出口条件1:
    >E
    出口条件2:
    >F
    出口条件3:
    ==>G
    C 1.驱动读写操作报超时问题，第一时间抓取波形确认是否传输性能存在问题
    2.查阅波形并无问题情况下，判断sdmmc MIE中断是否正常上报或接收
    3.检查sdmmc timing是否存在异常
    4.以上情况均无问题，考虑sd/sdio device是否异常    		 出口条件1:
    1.根据波形查看当前工作频率低于预期
    出口条件2:
    1.检查bus width是与预期不符
    出口条件3:
    1.根据debug log显示出错时相关event没有正常触发
    出口条件4:
    1.sdmmc timing异常
    出口条件5:
    1.sd/sdio device原因 导致card busy情况    		 出口条件1:
    >I
    出口条件2:
    >J
    出口条件3:
    >K
    出口条件4:
    >G
    出口条件5:
    ==>L
    D 1.sdmmc IP报device无响应问题，可以抓取波形确认是否cmd发出后没有收到响应
    2.参考本篇《1：sd/sdio卡识别过程问题》，检查相关配置是否正确
    3.优先检查硬件电气通路是否正常，运行环境是否加干扰测试(比如打静电、高低温等)
    4.检索debug log查找"SAR1 SDMMC WARN trigger"关键字，判断是否存在掉电保护被误触发情况
    5.检查sdmmc timing是否存在异常
    6.以上情况均无问题，考虑sd/sdio device是否异常    		 出口条件1:
    1.检查配置无问题，波形显示cmd发出后，未接收到device响应
    出口条件2:
    1.检查chip到sd/sdio设备子板之间的电气通路存在明显信号衰减
    出口条件3:
    1.运行环境当前正在进行打静电或高低温等压力测试
    出口条件4:
    1.检索log，发现sdmmc在未断电情况下，出现掉电保护被触发现象
    出口条件5:
    1.sdmmc timing异常
    出口条件6:
    1.sd/sdio 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 调整driving(GPIOE这组pad范围为0-1,GPIOA这组pad范围为0-3)> 出口条件1:
    1.根据实际情况设置data driving档位后恢复正常
    出口条件2:
    1.尝试所有data driving档位后仍然报crc错误    		 出口条件1:
    >流程结束
    出口条件2:
    >G
    F 调整driving(GPIOE这组pad范围为0-1,GPIOA这组pad范围为0-3) 同"E" 同"E"
    G 1.调整driving(GPIOE这组pad范围为0-1,GPIOA这组pad范围为0-3)综合调节clk/cmd line的驱动能力
    2.调节clk相位，具体操作可咨询FAE
    3.根据tmux表以及HW FAE是否支持调整时钟信号采样模式
    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，包括从sd/sdio init开始到出现问题期间的日志
    2.抓取异常场景的完整波形，最好有相同条件下正常场景的波形作为对比
    3.在linux控制台下通过riu命令dump sdmmc IP的相关bank信息：<br/0x1413/0x1038/0x103C/0x103E
    H 1.先参考本篇《1：sd/sdio卡识别过程问题》的交叉验证章节
    2.在default状态下(即无数据交互情况)使用万用表或示波器点测sd/sdio的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配置与当前sd/sdio使用槽位是否一致
    2.在linux下配合使用LA或示波器手动上下拉sd/sdio的pin gpio，看是否符合预期
    出口条件3:
    出口条件4:
    出口条件5:
    >流程结束
    		 出口条件3:
    1.寻求硬件协助
    出口条件5:
    1.同步硬件条件，帮助FAE搭建复现环境
    I 1.根据手册明确当前槽位sd/sdio IP使用的版本
    1.1 sd/sdio 2.0最高支持48MHz
    1.2 sd/sdio 3.0最高支持200MHz
    2.在IP允许的频率范围内确认是否已经是最高一档
    3.读取bank 0x1038 offset 0x43/bank 0x42 offset 0x24确认clk是否按照预期设置成功
    4.使用dd命令或fio工具测试速率，提供速率信息给FAE确认    		 出口条件1:
    1.调整clk到最高档，通信恢复正常
    出口条件2:
    1.调整clk无效果或者已经是最高档
    出口条件3:
    1.clk设定与寄存器读取数值不符    		 出口条件1:
    >流程结束
    出口条件2:
    >J
    出口条件3:
    ==>流程结束    		 出口条件3:
    1.dump 0x1038/0x1133寄存器信息
    2.提供dts配置文件
    3.提供debug Log
    J 1.根据SPEC文档，对于不同的速率模式有对应支持的总线位宽
    1.1 sd/sdio 2.0可使用1bit/4bit Buswidth
    1.2 sd/sdio 3.0仅可使用4bit位宽
    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高的进程是哪个，尝试将sdmmc MIE中断处理绑核到cpu1
    出口条件3:
    >G    		 出口条件1:
    1.公版尝试复现，帮助FAE搭建环境
    L 1.参考本篇《1：sd/sdio卡识别过程问题》的交叉验证和sd卡座虚焊章节
    		 出口条件1:
    1.交叉验证或补焊后，通信恢复正常
    出口条件2:
    1.确认sd/sdio设备正常    		 出口条件1:
    >更换sd/sdio设备
    出口条件2:
    >流程结束    		 出口条件2：
    1.公版尝试复现，帮助FAE搭建环境
    M 1.使用万用表或示波器对从chip到sd/sdio子板整个通路进行点测，主要观测近ic端与sd/sdio子板端信号是否存在较大差异 出口条件1:
    1.近ic端与sd/sdio子板端电信号有明显衰减现象
    出口条件2:
    1.电气通路正常    		 出口条件1:
    1.请CAE协助排查
    出口条件2:
    ==>N
    N 1.与客户明确运行环境是否存在外界干扰，比如正在进行打静电、高低温等压测 出口条件1:
    1.正在进行压测，附加有打静电、高低温等手段
    出口条件2:
    1.无外界干扰，正常运行环境    		 出口条件1:
    >流程结束
    出口条件2:
    >O    		 出口条件1:
    1.抓取debug log和波形
    2.协调硬件一同定位
    O 1.在明确运行环境非断电情况下，检测debug log中是否存在"SAR1 SDMMC WARN trigger"关键字
    2.检测过滤是否包含与sdmmc驱动相关的"retry"、"reset"关键字    		 出口条件1:
    1.检测debug log，存在emmc/sdmmc触发掉电保护或者retry操作
    出口条件2:
    1.环境未被重置或者误触发掉电保护情况    		 出口条件1:
    >流程结束
    出口条件2:
    >G    		 出口条件1:
    1.emmc误触发掉电保护，可咨询HW FAE
    2.如果环境有被触发重置操作，则抓取debug log

    3. SD/SDIO通讯结束数据搬运过程问题

    图3-1 SD/SDIO通讯结束数据搬运过程问题定位思维导图

    流程 方法 出口条件 下一步 需提供给SWRD的资料
    A 1.根据SPEC的sd/sdio host modes可以将整个sd/sdio协议系统抽象为host、bus、device
    2.通过确认padmux设定正确且对应当前运行环境、LA/示波器显示波形和timing均正常，但是dma_end event一直等不到
    3.结合host mode可以排除host cmd发送、bus通信和device异常，考虑在host端IP内部的数据搬运出现异常    		 出口条件1:
    1.FAE协助解读debug bus，提供给RD 分析
    出口条件2:
    1.sdmmc IP正常    		 出口条件1:
    >流程结束
    出口条件2:
    >B
    B 1.查阅规格文档确认sdmmc IP可使用的dram地址空间，进而确认传递到sdmmc IP的物理地址偏移是否合法，即bank 1413/42 offset 0x3/0x4组成的地址 出口条件1:
    1.传递到sdmmc IP的物理地址偏移超出了有效范围
    出口条件2:
    1.传递给sdmmc IP的物理地址偏移合法有效    		 出口条件1:
    >流程结束
    出口条件2:
    >C    		 出口条件1:
    1.使用系统提供的标准地址空间分配接口申请buf
    C 1.构造测试pattern，确认source pattern与读/写得到的pattern差异是否存在规律性 出口条件1:
    1.pattern错误明显具有规律性，总是以sdmmc驱动 cache-line大小出错
    出口条件2:
    1.pattern出错并无明显规律    		 出口条件1:
    >流程结束
    出口条件2:
    >D    		 出口条件1:
    1.确认是否使用sdmmc标准读写接口，若否，进一步确认buf是否non-cache
    2.协助FAE搭建复现环境
    D sdmmc驱动读写过程正常，在IP内部搬运数据过程出现异常，主要考虑以下几点：
    1. dma burst length是否设置到8，即bank 1413/42 offset 0x2[5:4]
    2.读写是否未考虑cache操作或者处理不正确
    3.现代CPU乱序执行导致的数据同步问题    		 出口条件1:
    1.dma burst length未设置到最大
    出口条件2:
    1.运行环境dcache-on情况下，buf读写时未进行invalid和flush操作，导致取到的数据不一致
    出口条件3:
    1.对于需要同步调用的逻辑未进行内存屏障处理，导致乱序执行
    出口条件4:
    1.其他问题    		 出口条件1:
    1.尝试手动设置dma burst到最大值8
    出口条件2:
    1.尝试在写操作执行flush操作，在读操作后执行invalid操作
    出口条件3:
    出口条件4:
    ==>流程结束    		 出口条件3:
    出口条件4:
    1.确认客户分支以及打过的patch现状
    2.协助FAE搭建复现环境
    ---

    4. SD卡热插拔相关问题

    图4-1 SD卡热插拔相关问题定位思维导图

    流程 方法 出口条件 下一步 需提供给FAE的资料
    A 1.cdz中断触发原理:
    xor(src, polarity)之后的结果，即：
    1.1.当cdz src的电平是0的时候，polarity level(0->1) 会有中断
    1.2.当cdz src的电平是1的时候，polarity level(1->0) 会有中断
    2.在系统wdt_rst或STR后，会有cdz中断满足触发条件    		 出口条件1:
    1.确认系统有在做wdt_rst或STR操作
    出口条件2:
    1.系统正常运行，未执行wdt_rst或STR操作    		 出口条件1:
    >E
    出口条件2:
    >D
    B 1.首先检查cdz相关配置项，是否正确开启cdz中断
    2.配置无问题，优先检查sd卡座硬件是否故障，cdz pad供电是否正常
    3.根据A中cdz触发原理，排查code中是否存在src与polarity未匹配情况    		 出口条件1:
    1.cdz相关配置未正确配置
    出口条件2:
    1.sd卡座出现故障导致cdz pad供电异常
    出口条件3:
    code逻辑问题    		 出口条件1:
    >D
    出口条件2:
    >F
    出口条件3:
    ==>流程结束    		 出口条件3:
    1.提供sdk版本信息给FAE
    C 1.首先确认是cdz中断本身引起的系统异常，还是由于插拔动作产生后的逻辑引发系统不正常
    2.检查cdz相关配置项，是否存在cdz padmux配置错误情况
    		 出口条件1:
    1.cdz相关配置未正确配置
    出口条件2:
    1.确认是cdz中断本身频繁触发引起系统卡顿
    出口条件3:
    1.确认是插拔卡之后的逻辑造成系统卡死    		 出口条件1:
    >D
    出口条件2:
    >G
    出口条件3:
    ==>流程结束    		 出口条件3:
    1.协助FAE搭建复现环境排查
    D 1.确认sd/sdio的cdz padmux配置是否和与开发板对应，pad是否与其他mode有冲突，确认方法:
    cd kernel_path
    vim arch/arm/boot/dts/pcupid_xxxx-padmux.dtsi
    2.确认sd/sdio的cdz相关配置是否正确:
    cd kernel_path
    vim arch/arm/boot/dts/pcupid.dtsi
    主要排查'fake-cdz'和'rev-cdz'配置项是否正确;'cdz_slot0_irq'中断配置是否正确    		 出口条件1:
    1.cdz padmux未正确配置;
    2.cdz相关配置项错误配置
    出口条件2:
    1.cdz配置无问题    		 出口条件1:
    1.根据padmux和实际运行环境正确配置
    >流程结束
    出口条件2:
    >F
    E 1.未插入sd卡时，系统在wdt_rst后，满足A中1.2条件会有cdz中断产生
    2.未插入sd卡时，系统如果操作STR，在resume阶段同样会满足A中1.2条件会有cdz中断产生    		 出口条件1:
    1.确认系统有触发reset操作
    出口条件2:
    1.系统正常运行，未有触发相关reset操作    		 出口条件1:
    1.求助FAE提供方案屏蔽此非应用预期中断
    出口条件2:
    ==>流程结束    		 出口条件2:
    1.协助FAE搭建复现环境
    F 1.cdz pad设计用于sd卡热插拔使用，default状态是外部3.3v电压上拉的高电平状态，当sd/sdio卡插入卡槽，抵触拨片接地变为低电平状态
    2.cdz中断是边缘双向触发，随着插拔卡导致cdz pad的电平状态变更，根据A中原理就会触发cdz中断
    3.cdz相关配置正确情况下，可以用LA或示波器观测cdz pad电平是否存在波动    		 出口条件1:
    1.观测到cdz pad电平波动幅度过大，达到cdz触发阈值;
    出口条件2:
    1.cdz pad电平正常    		 出口条件1:
    1.寻求硬件协助排查
    出口条件2:
    ==>E/G
    G 1.能够进入控制台情况下:
    linux: cat /proc/interrupts |grep cdz
    rtos: echo cli intrstat > /proc/dualos/rtos
    查看cdz中断触发次数
    2.采用tvtool工具查看bank:0x1009对应cdz中断的触发情况    		 出口条件1:
    1.cdz中断异常频繁触发，通过umask irq后，系统恢复正常
    出口条件2:
    1.cdz中断正常，符合插拔次数    		 出口条件1:
    >流程结束
    出口条件2:
    >流程结束    		 出口条件1:
    出口条件2:
    1.协助FAE搭建复现环境

    5. 附录

    5.1 SDIO设备初始化流程

    >>>cmd52协议格式 上: request/下: response

    无论是哪一种类型的命令，重点关注请求和响应命令的中间32位内容即可。


    >>>sdio soft reset: cmd52读写CCCR寄存器完成

    sdio设备会通过cmd52操作CCCR寄存器0x06地址，即I/O ABORT寄存器的bit3，完成reset enable操作。一般情况下，
    一开始的这两个cmd52会正常完成，也经常出现cmd52报0x8 no rsp err("详情可参阅第2章节")。根本原因是sdio device
    没有完成上电初始化程序。解决这个问题，一般是通过配置dtsi中的'pwr-off-delay'延时到150ms以上。


    >>>device go idle: 对于带存储的sdio卡有效

    对于带存储的sdio card才有意义，一般情况下，使用的sdio wifi card只是I/O only，实际的soft reset是由前面的 cmd52完成。


    >>>check sd card: 对于带存储的sdio卡有效

    该命令对于sdio device是可选的，并且理论上使用sdio device，在dtsi应该配置'no-sd'和'no-emmc'不会进行该步骤


    >>>cmd5: 获取sdio card支持的工作电压范围

    sdio device初始化，cmd5才是关键，前面cmd52/0/8都可以报错往下继续走，原因在于sdio device上电到ready需要
    一定的时间，但是cmd5命令失败，意味着通信真的出现异常。
    第一次ARG:0x00000000，主要获取sdio device的电压支持范围
    第二次ARG:0x00100000, 发送host端支持的电压，并触发device init动作。
    host会根据cmd5的响应，测试ARG: bit31位是否置1(device ready)，来轮询等待


    >>>cmd3/cmd7: host获取sdio card RCA地址并根据地址选择卡进行操作

    host获取sdio card新设置的RCA寄存器，并且通过cmd7命令和cmd3返回的地址来选择操作该sdio device。


    >>>获取CIA信息: func0的CCCR/CIS信息

    host与device建链完毕后，开始获取device的基础信息。通过访问func0，来读取CCCR设备通用控制寄存器信息。每个device
    都有func0，CCCR和每个FBR都有256字节，init flow会获取其中一些关键信息。
    ARG:0x00000000, 读取func0(CCCR)的0x0地址，即CCCR/SDIO revision版本信息
    ARG:0x00001000, 读取func0(CCCR)的0x8地址，即Card Capability信息，响应为:0x00001013代表device支持
    1.do CMD52 while data transfer
    2.do multi-block xfers
    3.interrupt during 4-bit CMD53
    ARG:0x00002400, 读取func0(CCCR)的0x12地址，即power control信息，响应为:0x00001001代表device支持host 进行power control
    ARG:0x00002600, 读取func0(CCCR)的0x13地址，即bus speed select信息，响应为:0x00001001代表device支持 High-Speed mode
    CIS区域提供device更加详细的信息
    ARG:0x00001200/0x00001400/0x00001600 三个命令获取func0(CCCR)的0x9-0xb地址，即CIS pointer信息，以访问 CIS区域信息
    ARG:0x00200000/.../0x00202000 一系列命令即是在读取Common CIS区域的信息
    至此，card相关的func0基础信息，host已经获取完毕。


    >>>bus speed/bus width: 切换速率和位宽

    ARG:0x00002600, 读取func0(CCCR)的0x13地址，即bus speed select信息
    ARG:0x80002603, 写入func0(CCCR)的0x13地址，即bus speed enable high speed
    ARG:0x00000E00, 读取func0(CCCR)的0x7地址，即bus interface control信息
    ARG:0x80000E02, 写入func0(CCCR)的0x7地址，即bus interface control enable 4bit
    至此，sdio card 会切换到4bit 48MHz工作环境


    >>>获取CIA信息: func1的FBR/CIS信息

    host通过访问func0，来读取设备通用控制寄存器信息。之后会根据sdio card实际情况读取func1-func7的每个func对应FBR/CIS
    信息。FBR/CIS信息读取与上述func0的CCCR/CIS通用信息读取完全一致，只是cmd52中func number变更为对应func，一般sdio card
    会支持func1功能
    ARG:0x00020000, 读取func1的0x100地址，即func1 sdui function interface code信息
    ARG:0x00021600, 读取func1的0x10b地址，即func1 的CIS pointer地址最后一项
    此处省略描述，0x100-0x10b之间的cmd52
    ARG:0x00220000/.../0x00226000 一系列命令即是在读取func1 CIS区域的信息
    至此，sdio card初始化流程涉及的核心命令结束。
    >>>sdio card识别成功

    5.2 SD卡初始化流程


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

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


    >>>host同步support voltage: 让卡确认是否支持host提供的voltage列表

    获取卡的电压支持范围，图例显示为2.7~3.6v范围


    >>>获取OCR信息：第一次不用管卡的状态

    probe时第一次发送cmd41: 目的时获取卡的OCR寄存器信息，不管卡的状态


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

    根据卡的ocr调整host的support，重新上下电，设备进入idle state


    >>>host同步更新后support voltage: 让卡确认是否支持host提供的voltage列表


    >>>host同步能力集并确认OCR信息

    一直polling卡的状态，等待device init ready，测试ARG: bit31位是否置1(device ready)


    >>>host获取卡CID信息: 卡出厂设置的MID/OID等标识信息


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


    >>>acmd51: 读取SCR寄存器信息

    SCR寄存器是对CSD寄存器的补充信息，例如其中的spec version信息等


    >>>acmd13: 获取device status信息，通过data line传递512字节寄存器信息


    >>>host获取check func信息并执行switch func信息

    ARG:0x00FFFFF0, bit31为0，check switch-able func信息，主要涉及四组: 1.access mode 2.command system 3.driver strength 4.power limit
    ARG:0x80FFFFF1, bit31为1，switch func操作，switch access mode的func1为high-speed
    此步骤结束后sd clock会调整到48MHz


    >>>acmd6: 调整device bus width

    set bus width操作，将总线位宽调整到4bit
    该步骤后，因为card device生成，会和card driver匹配，生成block设备节点

    >>>sd card识别成功

    5.3 SD/SDIO常见错误波形及日志


    >>>cmd no rsp

    host已经发出cmd request并且clock正常打出，但是在8T时间内没有等到device响应
    驱动会印出SD_STS:0x0F08错误码


    >>>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)错误码


    >>>cmd timeout


    cmd超时，是驱动层面的判断，所以波形一般是正常的，主要体现在驱动的debug err log上
    驱动会印出(FAIL)= 0100错误码，为驱动设定的等待时间已经到达，但event未能接收，参考《2.SD/SDIO通讯过程问题》


    >>>cmd6 执行switch func error

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