這一篇是整個 Linux MMC 驅(qū)動系列里我拖得最久的一篇也是我實際項目里踩坑最多的一段。前五篇我們把 host 控制器注冊、MMC core 框架、SD 卡初始化鏈路、塊設備層對接這些內(nèi)容基本過了一遍按道理說框架已經(jīng)清楚了。但你會發(fā)現(xiàn)真正到了嵌入式板子上調(diào) eMMC 或者 MMC 類型卡的時候情況完全不是“照著代碼讀一遍”就能搞定的。這也是我為什么要在第六篇專門把 MMC type card 這條分支單獨拉出來講透——從卡檢測、類型識別、ext_csd 解析到 block 設備掛載再到 HS200/HS400 的切換和調(diào)試排障整條鏈路里面藏著大量“文檔上不會寫、但代碼里就是如此”的細節(jié)。這篇適合誰看已經(jīng)在看 MMC 驅(qū)動源碼、想把 eMMC 初始化流程徹底搞明白的驅(qū)動開發(fā)者或者正在調(diào)板子、發(fā)現(xiàn)卡識別不穩(wěn)定、速度上不去、老是在某個狀態(tài)機卡住的人。說句實話純讀內(nèi)核文檔是學不會 MMC 驅(qū)動的真正能讓你少熬夜的是那些在代碼里翻來覆去比對后得到的經(jīng)驗值。這篇就把我積累的這些值都放出來。1. MMC type card 在 Linux 驅(qū)動棧中的位置1.1 三層四層type card 到底屬于哪一層很多剛開始讀 MMC 驅(qū)動的人會被層數(shù)搞暈。舊內(nèi)核里習慣叫“三層”host 層、core 層、card 層。后來 4.x 之后內(nèi)核把 card 層的塊設備邏輯抽到了 block 層實際變成四層host 控制器層、core 通用層、card 類型層、block 層。但 MMC type card 這個概念不太等于某一層而是一條橫跨 core 和 block 的完整數(shù)據(jù)路徑。具體說當你插入一張 MMC 卡注意不只是傳統(tǒng)的 MMC 卡還包括絕大多數(shù) eMMC 板載存儲內(nèi)核首先由 host 層觸發(fā)檢測進入 core 層的 mmc_rescan然后在 core 里根據(jù)卡的協(xié)議特征區(qū)分出是 MMC_TYPE_MMC、MMC_TYPE_SD 還是 MMC_TYPE_SDIO。type card 這個詞強調(diào)的就是 MMC 類型區(qū)別于 SD 類型的卡。它在 core 層對應的是 mmc_attach_mmc 這個分支在 block 層對應的是 mmc_blk_probe 這個驅(qū)動綁定邏輯。所以你在代碼里找 MMC type card 的入口第一站就是 drivers/mmc/core/mmc.c 里的 mmc_attach_mmc第二站就是 drivers/mmc/core/block.c。而真正決定卡會不會被識別成 MMC 類型的是它響應命令時的協(xié)議特征。1.2 幾種卡類型的區(qū)分別把 SD 當 MMC在實際項目中最容易被忽略的就是“明明插的是 SD 卡卻走進了 SD 分支插的是 eMMC卻沒進 MMC 分支”。這背后其實是協(xié)議層的差異決定的。我把典型的類型區(qū)分整理一下卡類型內(nèi)核分支入口典型場景識別關鍵點MMC_TYPE_MMCmmc_attach_mmceMMC 板載存儲、傳統(tǒng) MMC 卡響應 CMD1 時 OCR 狀態(tài)、無法通過 CMD8/SD 識別流程MMC_TYPE_SDmmc_attach_sdSD、microSD 卡CMD8 能拿到有效的 R7 響應MMC_TYPE_SDIOmmc_attach_sdioWiFi/BT 組合模塊CMD5 能得到 SDIO OCR 響應MMC_TYPE_HOSTmmc_attach_busloopback 自測、虛擬卡host 自己注冊時指定SD 卡在協(xié)議上兼容了部分 MMC 命令但 SD 卡會先響應 CMD8然后再走 ACMD41 這個流程。MMC 類型卡不一樣它不認識 CMD8 或?qū)?CMD8 響應方式不同內(nèi)核只能回到 CMD1 去拉 OCR、看電壓匹配。內(nèi)核代碼里這個“退回”邏輯也非常有意思它不會一上來就斷定你是 MMC而是依次嘗試 SD、SDIO、MMC 三個分支。這個順序本身就是卡識別過程里最值得注意的細節(jié)。1.3 為什么單獨把 type card 拉出來講我的實際體會是MMC 類型卡和 SD 卡的分水嶺不僅僅是協(xié)議上的更是工程調(diào)試上的。SD 卡插拔頻繁要考慮卡檢測中斷、寫保護開關、熱插拔。MMC 類型卡特別是 eMMC不插拔、固定焊在板子上要考慮的是電源上電時序、啟動時 boot partition 的處理、HS200/HS400 的高速切換、以及系統(tǒng)休眠喚醒時的狀態(tài)保持。這些差異直接決定你在調(diào)試時看什么文件、查什么寄存器、加什么打印。如果你拿 SD 卡的調(diào)試經(jīng)驗去套 eMMC大概率會被“啟動時偶爾失敗、休眠喚醒后掛在 IO 上”這類問題折磨到懷疑人生。2. 從卡插入到類型確定的完整流程2.1 檢測起點mmc_rescan 的狀態(tài)機卡檢測的起點是 mmc_rescan。這個函數(shù)在 core.c 里無論是輪詢方式還是 gpio 中斷方式最終都會調(diào)用到它。大概的執(zhí)行路徑是判斷 host 是不是在恢復、是不是已經(jīng)在 rescan 中如果 host 沒有卡嘗試 mmc_attach_* 系列如果已有卡且檢測到移除調(diào)用 mmc_detach_bus 和 mmc_remove_card如果已有卡且還在則可能進入重新初始化流程。這里一個典型的坑是mmc_rescan 內(nèi)部有延時和狀態(tài)判斷如果在中斷上下文頻繁觸發(fā)可能出現(xiàn)重復檢測。內(nèi)核里通過 host-rescan_disable 和 host-detect_change 配合把檢測請求延遲到 workqueue 里執(zhí)行。你自己調(diào)試時如果發(fā)現(xiàn) dmesg 里反復出現(xiàn)“Card removed during transfer”可以重點查一下是不是中斷觸發(fā)的 detect 邏輯導致了重復掃描。我個人建議你在改驅(qū)動時千萬不要直接在中斷回調(diào)里調(diào)用 mmc_detect_change而要用它自帶的工作隊列機制。原因是 MMC 初始化過程中的命令交互非常耗時一次 card detect 往往要執(zhí)行好幾條命令每條命令都涉及 complete 等待和超時計時放在中斷上下文里直接把系統(tǒng)調(diào)度搞死。2.2 OCR、CID、CSD 這些寄存器怎么讀卡類型確定之后真正讓內(nèi)核“認識”這張卡靠的是一組寄存器讀取。MMC 卡最關鍵的三個寄存器是 OCR、CID、CSD。OCR 寄存器表示卡支持的電壓范圍和工作狀態(tài)。內(nèi)核通過 mmc_send_op_cond 來發(fā) CMD1并從響應中解析 OCR。代碼里這一步會反復發(fā)送 CMD1直到 busy 位被清零然后再把 host 支持的電壓范圍和卡支持的電壓范圍做交集只有交集非空才會繼續(xù)。CID 寄存器是卡的唯一標識里面包含廠商 ID、產(chǎn)品名、生產(chǎn)時間等。CMD2 用來獲取 CID之后所有卡都會用這組數(shù)據(jù)做區(qū)分。CSD 寄存器描述卡的容量、最大傳輸速度、塊大小、讀/寫時序參數(shù)通過 CMD9 讀取。讀取這些寄存器的輔助函數(shù)在 mmc_ops.c 里都能找到比如 mmc_send_cid、mmc_send_csd。我調(diào)試時最常用的操作是cat /sys/block/mmcblk0/device/cid cat /sys/block/mmcblk0/device/csd cat /sys/block/mmcblk0/device/ocr如果這三項能讀出來說明卡的基本命令通路是通的剩下的問題基本都在高速模式切換或者傳輸階段。2.3 關鍵結(jié)構(gòu)體與初始化關系卡一旦被識別就會創(chuàng)建一個 struct mmc_card 來承載整個生命周期。這個結(jié)構(gòu)體你一定要熟悉因為后面幾乎所有調(diào)試都繞不開它。關鍵字段我列一下type卡類型文章開頭提到的那幾種state卡的當前狀態(tài)包括卡是否在線、是否就緒ocr從 OCR 寄存器讀出的電壓信息cid/csd/ext_csd寄存器信息緩存sector_count容量從 CSD 或者 ext_csd 計算得出csd.capacity塊數(shù)ext_csd.revext_csd 版本號決定了卡支持的特性quirks驅(qū)動針對某些卡的特殊處理。從命名上你應該能看出struct mmc_card 就是把一張硬件卡抽象成內(nèi)核里的一個對象。它由 mmc_add_card 向內(nèi)核注冊由 mmc_remove_card 注銷。整個生命周期管理得清楚不容易出問題真正出問題的是結(jié)構(gòu)體字段被某個私有驅(qū)動寫錯之后隨機崩潰。3. 核心代碼路徑mmc_attach_mmc 到 mmc_blk_probe3.1 真正分清 MMC 與 SD 的分水嶺mmc_attach_mmc 位于 drivers/mmc/core/mmc.c已經(jīng)發(fā)展為 mmc_init_card 和 mmc_attach_bus 的組合流程。關鍵的初始化步驟大致如下。第一步是 mmc_attach_bus設置 host 的總線操作函數(shù)也就是把 host-bus_ops 指向 mmc_ops。這時候總線起草能力已經(jīng)綁定到 mmc 類型。第二步是 mmc_init_card這個函數(shù)內(nèi)部做了大量工作再次發(fā)送 CMD1確認卡就緒讀取 CID讀取 CSD讀取 ext_csd根據(jù) ext_csd 支持的能力設置卡的屬性如果有必要執(zhí)行卡進入 high speed 模式的 switch 操作。在整個過程中對 MMC 類型卡影響最大的是 ext_csd。這可以說是 MMC/eMMC 特有的一把鑰匙。通過 ext_csd驅(qū)動能知道卡是否支持 HS200、HS400、DDR、是否支持 CMDQ、boot 分區(qū)大小、安全寫保護區(qū)域等。我可以負責任地說調(diào)試 eMMC 啟動失敗時你在 ext_csd 上花的時間一定是最多的。比如 read_ext_csd 失敗那你根本看不到卡支持什么模式所有高速切換都無從談起。3.2 從 card 到 block 的對接初始化完成之后mmc_add_card 會把卡注冊到設備模型里生成 /sys/block/mmcblkX 對應的設備。重點在 mmc_driver 和 mmc_blk_probe 的匹配過程。簡單理解mmc_add_card 把一個 mmc_card 設備添加到總線上然后 mmc_blk 驅(qū)動通過 mmc_bus_match 判斷設備類型是 MMC/SD就會調(diào)用 mmc_blk_probe。mmc_blk_probe 里面的動作很關鍵分配 struct mmc_blk_data初始化工作隊列、請求隊列從卡的分區(qū)表里讀取分區(qū)信息為每個分區(qū)注冊一個 gendisk最終你會看到 /dev/mmcblk0、/dev/mmcblk0boot0、/dev/mmcblk0boot1 這些節(jié)點。對于 eMMCboot 分區(qū)尤其重要因為系統(tǒng) bootloader 通常在 boot0 或 boot1 里。我在實際項目里見過因為 boot 分區(qū)沒設置到位導致系統(tǒng)升級后 bootloader 損壞又無法從備份分區(qū)啟動的案例。這類問題建議你直接用 mmc bootpart enable 操作來恢復我在后面的排查章節(jié)會細說。3.3 request 到 command 的映射塊設備層發(fā)起讀寫請求后最終要變成一組 MMC 命令在總線上跑。這里的轉(zhuǎn)化路徑是bio request → mmc_blk_rw_rq_prep → 構(gòu)造 mmc_request → mmc_wait_for_req → host 層執(zhí)行 → 中斷完成回調(diào)mmc_request 里最核心的成員是 cmd、stop、data分別對應命令、停止命令、數(shù)據(jù)傳輸塊。對于 MMC 類型卡而言read 操作通常對應 CMD17/CMD18write 操作對應 CMD24/CMD25。CMD18 和 CMD25 是多塊傳輸需要在結(jié)束的時候發(fā) CMD12 停止傳輸。這里我強調(diào)一個工程上容易出問題的地方多塊傳輸?shù)慕Y(jié)束方式分為 open-end 和預定義塊數(shù)MMC 卡通常支持預定義塊數(shù)也就是你在 data 里設置 blocks硬件會按塊數(shù)自動停止。但如果 host 控制器驅(qū)動沒有按這個邏輯設置容易傳著傳著多傳或少傳一塊然后 CRC 錯誤滿天飛。操作單塊命令多塊命令停止命令讀CMD17CMD18CMD12寫CMD24CMD25CMD12從實際性能角度講單塊命令只適合小文件或元數(shù)據(jù)訪問真正吞吐量上來還得靠多塊命令加 request 合并不然性能連普通 U 盤都比不過。4. 設備樹配置與實際移植經(jīng)驗4.1 一個能跑起來的 dts 節(jié)點該怎么寫默認情況下如果 host 控制器驅(qū)動支持標準設備樹綁定你把 MMC 設備節(jié)點加到 dts 里之后Linux 就能枚舉卡。但枚舉和“穩(wěn)定工作”完全是兩回事。我建議至少保證這樣的節(jié)點配置mmc0 { status okay; bus-width 8; non-removable; cap-mmc-highspeed; mmc-hs200-1_8v; mmc-hs400-1_8v; vmmc-supply vcc_3v3; vqmmc-supply vcc_1v8; pinctrl-names default, state_uhs; pinctrl-0 mmc0_pins_default; pinctrl-1 mmc0_pins_uhs; };有幾個屬性的理解值得展開說一下。bus-width 是數(shù)據(jù)線數(shù)量eMMC 一般至少 4 位常見 8 位。錯了會導致數(shù)據(jù)線上信號錯位癥狀是最開始能識別但讀取大塊數(shù)據(jù)時不穩(wěn)定。non-removable 表示這是板載存儲內(nèi)核不會輪詢檢測卡移除。千萬別小看這個屬性如果沒配系統(tǒng)會周期性地給 eMMC 發(fā)檢測命令影響休眠喚醒。cap-mmc-highspeed 使能 MMC 的 high speed mode如果缺失eMMC 大概率被限制在 26MHz 或者更低的默認頻率。4.2 HS200/HS400 的時序選擇HS200 和 HS400 是 eMMC 的兩種高速模式。HS200 是單數(shù)據(jù)速率 8 位接口下跑 200MHz 時鐘HS400 是 DDR 模式 8 位接口同樣是 200MHz 時鐘但等效吞吐翻倍。要把這兩種模式跑起來光是 dts 里寫 mmc-hs200-1_8v 是不夠的還需要卡本身在 ext_csd 中聲明支持 HS200/HS400host 控制器支持對應的時序模式信號完整性要過關尤其是 HS400 對信號質(zhì)量非常敏感必要的時候需要做 tuning也就是通過發(fā)送 tuning block 來尋找最佳采樣點。實際調(diào)試中最常見的問題是把頻率提上去之后 CRC 錯誤暴增或者干脆卡住。這時候先別急著改驅(qū)動用示波器看一眼信號眼圖再看 host 是否支持 DLL delay 調(diào)節(jié)。很多國產(chǎn) SoC 的 MMC host 在 HS400 下需要配合特定 DLL 配置不開的話采樣點不對必掛。4.3 雙電壓與信號電平的關系eMMC 引腳上有一路主電源 vmmc通常是 3.3V一路 IO 電源 vqmmc可能是 1.8V 或 3.3V。高速模式HS200/HS400一般要求 1.8V 信號電平所以在切高速之前內(nèi)核會先通過 host 的 start_signal_voltage_switch 回調(diào)把 vqmmc 從 3.3V 切換到 1.8V。如果切換失敗或者穩(wěn)壓器不支持動態(tài)調(diào)壓內(nèi)核就會放棄高速模式退回 legacy 模式。我見過一種奇葩情況dts 里配置了 mmc-hs400-1_8v但 vqmmc 對應的 regulator 沒有配置 set_voltage 操作內(nèi)核調(diào) switch 時返回 -EINVAL然后整個初始化流程回退。如果你看到 dmesg 里出現(xiàn) “signal voltage switch failed”先查 regulator 而不是卡。5. 常見問題排查與調(diào)試實錄5.1 啟動卡在 mmc0: error -110-error 110 是 ETIMEDOUT也就是命令超時。這個錯誤我遇到最多但原因卻五花八門。最常見的原因是 vmmc 或 vqmmc 沒供電。有些板子的 eMMC 電源由一個 GPIO 控制dts 里 if 沒正確把 regulator 和 GPIO 關聯(lián)或者時序上供電晚于 host 時鐘卡自然不回命令。第二個常見原因是 CMD1 一直 busy卡上電后需要時間完成內(nèi)部初始化。標準做法是反復發(fā)送 CMD1 直到 busy 位釋放但如果你板子的時鐘頻率太低卡在內(nèi)部初始化期間響應窗口就會變長可能導致 host 超時。第三個原因比較隱蔽host 控制器時鐘沒開啟。MMC host 控制器本身需要兩路時鐘一路是卡時鐘一路是控制器接口時鐘。如果接口時鐘沒使能發(fā)命令后控制器根本沒動作也會表現(xiàn)為超時。排查思路我一般遵循示波器量時鐘 → 量 vmmc/vqmmc → 看 CMD 線是否有時序 → 再查 dmesg。這條路徑省了我不少時間。5.2 CID 能讀出但 CSD 失敗怎么辦這種情況很詭異說明卡的命令通路基本是通的CMD2 能響應但 CMD9 讀不到正確的 CSD。如果 CSD 返回 CRC 錯誤先懷疑頻率。MMC 類型卡在識別階段數(shù)據(jù)傳輸模式還沒建立過高的時鐘會讓數(shù)據(jù)線上的信號質(zhì)量變差CRC 錯誤的概率自然上升。你可以先把 host 的 max_bus_clk 調(diào)低比如從 200MHz 降到 52MHz 甚至 26MHz測一下能不能穩(wěn)定讀出來。另一個原因是 1.8V 信號切換時序沒對齊。有些卡的 CSD 讀取要求在信號電壓切換之后進行如果你提前讀取會返回亂碼?？梢钥匆幌?host-ios.timing 和 ios.signal_voltage 的值確認當前狀態(tài)。我最后加一個經(jīng)驗CSD 偶爾失敗一次不要緊但反復失敗一定不要忽略。它往往預示著硬件鏈路不穩(wěn)定在高溫或者低電壓下會演變成大規(guī)模讀寫失敗。5.3 用 mmc-utils 工具快速定位問題調(diào)試 MMC 類型卡內(nèi)核日志只是第一步真正好用的是 mmc-utils 這套用戶態(tài)工具。常用命令如下# 查看 ext csd重點看卡支持特性 mmc extcsd read /dev/mmcblk0 # 讀取卡狀態(tài) mmc status get /dev/mmcblk0 # 設置 boot 分區(qū) mmc bootpart enable 1 1 /dev/mmcblk0 # 設置 boot bus mmc bootbus set single_backward x1 x8 /dev/mmcblk0調(diào)試的時候我會重點看 extcsd 里的 DEVICE_TYPE、BOOT_INFO、RPMB_SIZE、CACHE_SIZE、ERASE_GROUP_DEF 這些字段。比如 DEVICE_TYPE 顯示不支持 HS400但 dts 里寫了 mmc-hs400-1_8v那工作模式自然切不過去白費功夫。bootpart enable 這個命令值得單獨強調(diào)。很多板子第一次燒錄 bootloader 前eMMC 的 BOOT_BUS_WIDTH 和 PARTITION_ACCESS 配置不是期望值導致 bootloader 啟動不了。這時候用 mmc bootpart enable 1 1 把 boot 分區(qū)對齊到物理分區(qū)再配合 bootbus 設置能解決一批“代碼燒進去了但起不來”的問題。5.4 用 tracepoint 看命令級耗時如果你想把問題定位到“哪條命令慢了”這個粒度最簡單的方法是用內(nèi)核的 MMC tracepoint。內(nèi)核開啟以下配置后可以在 ftrace 里看到完整的 mmc 請求流程CONFIG_MMC_DEBUGy CONFIG_FTRACEy CONFIG_TRACEPOINTSy然后cd /sys/kernel/debug/tracing echo mmc:* set_event echo 1 tracing_on cat trace_pipe通過 trace你能看到 mmc_request_start 和 mmc_request_done 之間的時間差確認每條命令的實際耗時從而判斷是否超時、是否 retry。這個手段比 dmesg 里的“某某命令超時”要精細得多因為它能看到是哪一步慢的甚至能發(fā)現(xiàn)多塊命令之間的間隙過大導致的性能問題。6. 一些容易被忽略但很實用的點6.1 塊層合并對性能的影響很多人調(diào)試 MMC 性能時只盯著 host 控制器頻率忽略了塊層的 bio 合并機制。MMC 驅(qū)動通過 mmc_blk_set_queue 初始化請求隊列時會設置 queue 的合并參數(shù)比如 max_segments、max_segment_size。這些參數(shù)如果沒有和 host 的 SGMII/DMA 能力匹配就會產(chǎn)生大量碎片化請求吞吐打折。一個直觀表現(xiàn)是順序讀 100MB/s順序?qū)懼挥?40MB/s而且 dmesg 里沒有任何錯誤。這種時候去看 blktrace往往是因為每次寫請求很小沒有合并成大的 segment。合理的做法是確認 host 控制器支持 multi-block DMA 傳輸并調(diào)整 queue 的參數(shù)讓內(nèi)核一次下發(fā)盡量大的請求。比如設置 max_segments 為 64 或 128max_segment_size 為 1MB都能有效提升順序讀寫性能。6.2 電源域和 runtime pm 的配合MMC host 控制器的電源管理是 MMC 類型卡低功耗設計的重頭戲。特別是板載 eMMC系統(tǒng)休眠時要把時鐘關掉、電源可以保持也可以關斷但喚醒時不能直接訪問卡必須先重新初始化鏈路。內(nèi)核里通過 mmc_runtime_suspend/mmc_runtime_resume 來實現(xiàn)。有些平臺會出現(xiàn)休眠喚醒后第一個 IO 訪問超時就是因為喚醒流程中 host 的時鐘恢復和卡的狀態(tài)重建沒有同步。我調(diào)試下來的經(jīng)驗是先確認 host 是否有 PM runtime 回調(diào)再確認卡在恢復時是否重新執(zhí)行了 init。如果喚醒后直接調(diào)用 mmc_blk_read卡可能還處于休眠狀態(tài)或者狀態(tài)寄存器里的電源狀態(tài)不對導致首個請求失敗。大部分平臺會在 runtime_resume 里調(diào)用 mmc_power_up mmc_init_card這一步不能省。6.3 關于 CMDQ 的一些經(jīng)驗較新版本內(nèi)核在 MMC 類型卡上支持 command queueingCMDQ典型實現(xiàn)是 mtk 和某些平臺的 emmc 控制器。CMDQ 的好處是能同時下發(fā)多條命令提高并發(fā)度但它的實現(xiàn)復雜度明顯上升。如果你只是想穩(wěn)定、穩(wěn)妥不追求極限性能可以先不加 CMDQ 支持。因為 CMDQ 模式下隊列深度、標簽管理、錯誤恢復都變得更加復雜。一旦出錯恢復路徑要處理的情況非常多調(diào)試成本遠高于性能收益。我的建議是先把無 CMDQ 的模式調(diào)穩(wěn)定性能不夠再考慮引入。結(jié)尾部分聊聊個人體會。我在實際調(diào)試中最大的體會是MMC type card 的驅(qū)動并不復雜復雜的是它跟硬件時序、電源管理、塊層調(diào)度這些外部因素交錯時的表現(xiàn)。你可能花三天時間查一個時好時壞的 bug最后發(fā)現(xiàn)是某個 GPIO 的上電時序晚了幾毫秒。也可能糾結(jié)了很久的寫入性能問題最后把 request queue 參數(shù)一調(diào)就解決。所以我一直建議項目里專門留一份 MMC 相關的調(diào)試 checklist把電壓、時鐘、dts 屬性、ext_csd 狀態(tài)、tracepoint 這些工具全部串起來而不是等出了問題再從頭摸索。最后再分享一個小技巧無論遇到什么詭異現(xiàn)象先把頻率降到最低、關掉高速模式、關掉 runtime pm能穩(wěn)定出來再一項一項開回去。這個方法能幫你快速確定問題出在高速特性上還是出在基本通路里。希望這篇能幫你少走一些彎路。