1. 項目概述從零理解MTK分區(qū)表的生成脈絡在MTK聯(lián)發(fā)科平臺的Android設備開發(fā)中scatter.txt文件是一個繞不開的核心配置文件。無論是進行固件燒錄、系統(tǒng)升級還是深度定制分區(qū)布局都離不開它。很多剛接觸MTK平臺的工程師往往直接從SDK里拿到一個現(xiàn)成的scatter.txt文件就開始用對其背后的生成邏輯和細節(jié)調(diào)整卻知之甚少。這就好比開車只會用自動擋一旦遇到復雜路況需要手動干預就束手無策。今天我就結(jié)合自己多年在MTK平臺“摸爬滾打”的經(jīng)驗深入拆解scatter.txt的生成過程讓你不僅知其然更能知其所以然真正掌握分區(qū)表配置的主動權(quán)。簡單來說scatter.txt文件定義了設備上各個分區(qū)如boot、system、userdata等在閃存通常是eMMC或UFS中的物理位置、大小和屬性。MTK提供了一套名為ptgenPartition Table Generator的工具鏈用于根據(jù)項目需求自動生成這個文件。這個過程并非簡單的文本拼接而是涉及硬件配置、產(chǎn)品定義、內(nèi)存布局規(guī)劃等一系列復雜決策的自動化體現(xiàn)。理解這個過程對于解決“分區(qū)空間不足”、“升級失敗”、“無法燒錄”等常見問題至關重要。2. scatter.txt文件結(jié)構(gòu)與核心字段解析在深入生成過程之前我們必須先徹底讀懂scatter.txt文件本身。一個典型的MTK平臺scatter.txt文件內(nèi)容看起來可能有些復雜但結(jié)構(gòu)非常清晰。2.1 文件頭與全局配置文件開頭通常是幾行注釋和全局配置。最重要的是general部分它定義了整個配置表的版本和工具信息。例如############################################################################################################ # # General Setting # ############################################################################################################ - general: MTK_PLATFORM_CFG info: - config_version: V1.1.2 - platform: MT6789 - project: k69v1_64 - storage: EMMC - boot_channel: MSDC_0 - block_size: 0x20000這里的block_size: 0x20000即128KB是eMMC閃存的擦除塊大小是后續(xù)所有分區(qū)起始地址對齊的基準。storage: EMMC指明了存儲介質(zhì)類型如果是UFS設備這里會不同其塊大小和分區(qū)屬性也會有差異。這個全局信息是后續(xù)所有分區(qū)定義的基石。2.2 分區(qū)條目詳解文件的主體是一個個分區(qū)定義。每個分區(qū)條目都包含一組關鍵的屬性字段我以一個boot分區(qū)為例進行拆解- partition_index: SYS0 partition_name: boot file_name: boot.img is_download: true type: NORMAL_ROM linear_start_addr: 0x000000000 physical_start_addr: 0x000000000 partition_size: 0x00600000 region: EMMC_USER storage: HW_STORAGE_EMMC boundary_check: true is_reserved: false operation_type: UPDATE reserve: 0x00這些字段每一個都至關重要partition_name 分區(qū)的邏輯名稱如boot,recovery,system等與編譯輸出的鏡像文件名通常對應。file_name 燒錄時使用的實際鏡像文件名。boot.img就是Android標準的啟動鏡像。is_download 該分區(qū)是否需要通過下載工具如SP Flash Tool燒錄。對于system、vendor等大型分區(qū)通常為true而像protect1、protect2這類存放安全密鑰、設備信息的隱藏分區(qū)通常會設為false禁止隨意擦寫。linear_start_addr與physical_start_addr 在絕大多數(shù)eMMC配置中這兩個地址是相同的代表分區(qū)在閃存線性地址空間中的起始偏移。地址必須按block_size對齊否則會導致燒錄失敗。0x000000000表示從閃存用戶數(shù)據(jù)區(qū)的絕對起始位置開始。partition_size 分區(qū)的大小。0x00600000即6MB這是boot分區(qū)的典型大小需要能容納內(nèi)核kernel、設備樹dtb、初始內(nèi)存磁盤ramdisk等所有內(nèi)容。region 指定分區(qū)所屬的閃存區(qū)域。EMMC_USER是最常見的用戶數(shù)據(jù)區(qū)。對于帶有RPMBReplay Protected Memory Block或引導分區(qū)boot1/boot2的設備這里會有不同的值。boundary_check 是否進行邊界檢查。強烈建議始終設為true工具會在燒錄前檢查分區(qū)是否重疊或超出存儲邊界這是防止“磚機”的重要安全閥。operation_type 操作類型。UPDATE表示該分區(qū)可通過OTA升級。有些關鍵分區(qū)如preloader可能會設為INVISIBLE或PROTECTED。注意 在手動修改或調(diào)試scatter.txt時最常出錯的點就是地址對齊和分區(qū)重疊。務必確保每個分區(qū)的linear_start_addr是block_size通常是0x20000的整數(shù)倍并且一個分區(qū)的結(jié)束地址start_addr size必須等于下一個分區(qū)的開始地址中間不能有間隙也不能重疊。一個快速檢查的方法是使用Python或Excel簡單計算一下。3. 生成工具鏈ptgen的工作流程與輸入文件MTK使用一套名為ptgen的Perl腳本工具鏈來生成scatter.txt。它的核心思想是“配置驅(qū)動生成”。我們不需要直接編寫復雜的scatter.txt而是通過修改幾個結(jié)構(gòu)更清晰的輸入文件然后讓工具自動合成最終文件。這套工具鏈通常位于SDK的device/mediatek/build/build/tools/ptgen目錄下。3.1 核心輸入文件MTxxxx_Android_scatter.txt.emm這是生成過程的藍圖文件。注意它的后綴是.emm對于eMMC或.ufs對于UFS它是一個模板文件。在這個文件中分區(qū)的定義使用了更抽象的變量和條件判斷。例如你可能會看到這樣的片段%if $PART_TABLE_FORCE_NEXT_ALIGN eq “yes”% partition_size: %$SIZE_OF_BOOTIMG% %else% partition_size: %$BOOTIMG_SIZE% %endif%以及%if $EMMC_SUPPORT eq “yes”% region: EMMC_USER %elsif $UFS_SUPPORT eq “yes”% region: UFS_LU0 %endif%這個模板文件本身并不直接使用而是由ptgen腳本讀取并結(jié)合其他配置文件中的具體變量值如$SIZE_OF_BOOTIMG、$EMMC_SUPPORT渲染生成最終的、所有變量都被替換為具體值的scatter.txt。3.2 項目配置文件ProjectConfig.mk這是產(chǎn)品定義的靈魂位于device/[vendor]/[project]/ProjectConfig.mk。在這里硬件工程師和系統(tǒng)架構(gòu)師會定義與分區(qū)相關的關鍵宏。這些宏的值會作為變量傳遞給ptgen工具。相關的配置項非常多我列舉幾個最核心的# 存儲類型 MTK_EMMC_SUPPORTyes # MTK_UFS_SUPPORTyes # 閃存總大小 (單位: MB) MTK_EMMC_SIZE0xE8000000 # 3.6GB # 關鍵分區(qū)大小定義 BOOTIMG_SIZE6M SYSTEM_IMAGE_SIZE0x60000000 # 1.5GB USERDATA_IMAGE_SIZE0x100000000 # 4GB # 是否啟用OTA升級 MTK_OTA_SUPPORTyes # OTA升級時使用的非活動系統(tǒng)分區(qū)大小 MTK_AB_OTA_UPDATERno MTK_OTA_ROM_SIZE0x60000000 # 是否啟用安全啟動相關分區(qū) MTK_SECURITY_SW_SUPPORTyes MTK_SEC_FASTBOOT_UNLOCK_SUPPORTyesptgen腳本會解析這個mk文件提取出所有這些以MTK_或特定前綴開頭的配置項將它們轉(zhuǎn)化為模板引擎可用的變量。例如BOOTIMG_SIZE6M會被處理并可能在模板中用于計算十六進制的分區(qū)大小0x600000。3.3 內(nèi)存布局定義文件除了大小分區(qū)的布局順序也至關重要。哪些分區(qū)在前哪些在后是由一個內(nèi)存布局定義文件決定的。這個文件可能是一個獨立的文本文件如partition_layout_xxx.csv也可能直接內(nèi)嵌在ptgen的Perl代碼邏輯中。它定義了一個有序的分區(qū)列表例如preloader, pgpt, proinfo, nvram, protect1, protect2, ... boot, recovery, secro, ... system, vendor, product, userdata, cache, ... , sgpt這個順序決定了最終scatter.txt中分區(qū)條目的排列順序也直接決定了每個分區(qū)的起始地址是如何累加計算的。ptgen會按照這個列表根據(jù)每個分區(qū)定義的大小依次計算它們的起始和結(jié)束地址。3.4 生成過程的串聯(lián)整個生成過程通常在編譯系統(tǒng)的某個階段被觸發(fā)例如在執(zhí)行source build/envsetup.sh和lunch選擇了項目之后編譯系統(tǒng)會準備環(huán)境變量。當執(zhí)行make命令時構(gòu)建系統(tǒng)會讀取ProjectConfig.mk生成一個包含所有配置變量的中間環(huán)境。調(diào)用ptgenPerl腳本并將配置變量傳遞給它。ptgen腳本讀取內(nèi)存布局定義確定分區(qū)種類和順序。ptgen根據(jù)存儲類型eMMC/UFS選擇對應的模板文件.emm或.ufs。腳本遍歷內(nèi)存布局中的每個分區(qū)名從配置變量中查找該分區(qū)的大小例如boot分區(qū)找BOOTIMG_SIZE。如果找不到明確配置則使用該分區(qū)類型的默認大小。根據(jù)當前累計的地址和分區(qū)大小計算該分區(qū)的linear_start_addr。將分區(qū)名、計算出的地址、大小以及其他屬性從模板邏輯和配置變量中獲取填充到模板對應的位置。渲染整個模板將所有%$VAR%替換為實際值生成最終的scatter.txt文件通常輸出在out/target/product/[project]/目錄下。4. 自定義分區(qū)從需求到實現(xiàn)的實戰(zhàn)調(diào)整理解了自動生成流程我們就能在需要時進行精準干預。最常見的需求就是調(diào)整分區(qū)大小或新增自定義分區(qū)。4.1 調(diào)整現(xiàn)有分區(qū)大小假設產(chǎn)品需求變更system分區(qū)需要從默認的1.5GB擴大到2GB以容納更多的預裝應用。修改ProjectConfig.mk 找到SYSTEM_IMAGE_SIZE這一行將其值修改為0x800000002GB的十六進制表示。計算方法是2GB 2 * 1024 * 1024 * 1024 2147483648字節(jié) 0x80000000。SYSTEM_IMAGE_SIZE0x80000000考慮連鎖反應system分區(qū)之后通常是vendor、userdata等分區(qū)。system分區(qū)擴大后其結(jié)束地址會后移這會擠壓后續(xù)所有分區(qū)的空間。你必須確保后續(xù)分區(qū)有足夠的空間可以向后“推移”。最終所有分區(qū)的總大小不能超過MTK_EMMC_SIZE定義的閃存總?cè)萘?。通常userdata分區(qū)是最后一個大分區(qū)且大小可能被設置為“剩余所有空間”。在這種情況下擴大system會自動壓縮userdata的空間。你需要評估userdata剩余空間是否仍能滿足需求。重新生成 執(zhí)行一次完整的編譯或至少觸發(fā)scatter.txt重新生成的目標如make scatterimage檢查新生成的scatter.txt中system分區(qū)大小是否已變?yōu)?x80000000并核對后續(xù)分區(qū)的起始地址是否正確更新。4.2 新增一個自定義分區(qū)假設我們需要增加一個名為oem的分區(qū)用于存放客戶定制的一些只讀數(shù)據(jù)大小為128MB。確定分區(qū)位置 這是最關鍵的一步。你需要決定把oem分區(qū)放在哪里。常見的做法是放在system和userdata之間或者放在vendor之后。假設我們決定放在vendor和userdata之間。修改內(nèi)存布局定義 找到定義分區(qū)順序的文件可能是ptgen目錄下的一個Perl數(shù)組或CSV文件在vendor和userdata之間插入oem。... vendor, product, oem, userdata, cache ...在ProjectConfig.mk中定義大小 添加一行配置。OEM_IMAGE_SIZE0x8000000 # 128MB在模板文件中添加分區(qū)定義 找到MTxxxx_Android_scatter.txt.emm模板文件在合適的位置通常在其他分區(qū)定義塊附近添加oem分區(qū)的模板塊。你需要參考其他分區(qū)的格式定義其partition_name,file_name,type,region,operation_type等屬性。例如可以模仿product分區(qū)的定義。%if $NEED_OEM_PARTITION eq yes% - partition_index: SYSxx # 分配一個未使用的索引號 partition_name: oem file_name: oem.img is_download: true type: NORMAL_ROM linear_start_addr: %$OEM_PARTITION_START% # ptgen會自動計算這個地址 physical_start_addr: %$OEM_PARTITION_START% partition_size: %$OEM_IMAGE_SIZE% region: EMMC_USER storage: HW_STORAGE_EMMC boundary_check: true is_reserved: false operation_type: INVISIBLE # 或 PROTECTED根據(jù)需求定 reserve: 0x00 %endif%注意這里用了一個條件判斷$NEED_OEM_PARTITION你需要在ProjectConfig.mk中也定義這個變量來控制是否生成此分區(qū)。讓ptgen識別新分區(qū) 可能需要修改ptgen的Perl腳本讓它知道在計算地址時遇到oem分區(qū)時去讀取OEM_IMAGE_SIZE這個變量并將其納入地址累計計算。這一步的難度因SDK版本和ptgen實現(xiàn)而異有時只需要在布局文件中添加名字即可工具會自動查找同名_SIZE變量。生成與驗證 重新生成scatter.txt檢查oem分區(qū)是否出現(xiàn)其起始地址、大小是否正確且沒有引起其他分區(qū)地址錯誤或重疊。實操心得 新增分區(qū)是高風險操作務必在編譯后仔細核對生成的scatter.txt。一個有效的驗證方法是寫一個簡單的腳本讀取scatter.txt按順序打印每個分區(qū)的名稱、起始地址、結(jié)束地址和大小人工檢查地址是否連續(xù)且無重疊。首次嘗試時強烈建議在一個虛擬的或備份的設備上進行燒錄測試避免真機變磚。5. 高級議題AB分區(qū)、動態(tài)分區(qū)與安全啟動隨著Android系統(tǒng)演進分區(qū)方案也變得更加復雜ptgen也需要處理這些新特性。5.1 AB系統(tǒng)分區(qū)A/B Seamless Update為了支持無縫OTA更新Android引入了A/B分區(qū)方案。這意味著會有兩套boot、system、vendor等分區(qū)分別標記為slot_a和slot_b。在scatter.txt中這會體現(xiàn)為分區(qū)名的后綴。配置 在ProjectConfig.mk中需要設置MTK_AB_OTA_SUPPORTyes。生成邏輯ptgen在生成時會對指定列表中的分區(qū)如boot,system,vendor創(chuàng)建兩份。它們的partition_name會變?yōu)閎oot_a/boot_bfile_name可能對應boot.img當前活動槽和boot_other.img。兩套分區(qū)的大小必須完全一致且緊密排列。這要求ptgen在計算地址時進行雙倍的空間分配和更復雜的布局規(guī)劃。5.2 動態(tài)分區(qū)Dynamic PartitionsAndroid 10以后引入了動態(tài)分區(qū)特別是將system、vendor、product等只讀分區(qū)合并到一個super分區(qū)中在設備啟動時動態(tài)創(chuàng)建邏輯分區(qū)。這徹底改變了分區(qū)表的靜態(tài)特性。對scatter.txt的影響 在啟用動態(tài)分區(qū)后scatter.txt中不再有獨立的system、vendor等分區(qū)條目取而代之的是一個巨大的super分區(qū)。scatter.txt的定義變得相對簡單但額外的super分區(qū)鏡像super.img內(nèi)部包含了一個名為super分區(qū)表的元數(shù)據(jù)描述了system、vendor等邏輯分區(qū)在super內(nèi)部的布局。ptgen的適配 此時ptgen的角色有所變化。它仍然生成基礎的scatter.txt主要包含boot、dtbo、vbmeta、super等。而super分區(qū)內(nèi)部邏輯分區(qū)的大小和布局則由另一個配置文件如dynamic_partitions_list.txt和lpmake工具在編譯super.img時決定。ptgen需要與這套新機制協(xié)同工作。5.3 安全啟動相關分區(qū)MTK平臺的安全啟動Secure Boot會引入一系列受保護的分區(qū)例如proinfo 存放設備出廠信息如IMEI、SN等。protect1/protect2 存放安全相關的密鑰、設備鎖狀態(tài)等。secro 存放只讀的安全相關數(shù)據(jù)。vbmeta 用于驗證啟動鏡像的完整性Android Verified Boot。在scatter.txt中這些分區(qū)的is_download屬性通常為falseoperation_type可能是PROTECTED或INVISIBLE以防止通過常規(guī)下載工具被擦寫。ptgen在生成時會根據(jù)MTK_SECURITY_SW_SUPPORT等配置開關決定是否包含以及如何配置這些分區(qū)。它們的起始地址通常緊挨著pgpt主GPT頭之后處于閃存最前端受保護的區(qū)域內(nèi)。6. 常見問題排查與調(diào)試技巧實錄在實際開發(fā)和維護中遇到scatter.txt相關的問題在所難免。下面是我總結(jié)的一些典型問題及其排查思路。6.1 燒錄失敗“S_BROM_CMD_STARTCMD_FAIL”這是SP Flash Tool燒錄時最常見的錯誤之一通常與分區(qū)表有關。可能原因1scatter.txt與設備不匹配。你使用的scatter.txt文件不是針對當前設備型號和閃存容量生成的。解決 務必使用與設備完全對應的原廠或自己編譯生成的scatter.txt?？赡茉?地址不對齊。某個分區(qū)的linear_start_addr不是block_size如0x20000的整數(shù)倍。解決 用計算器檢查scatter.txt中每個分區(qū)的起始地址?？梢允褂眠@個Python腳本快速驗證block_size 0x20000 with open(scatter.txt, r) as f: lines f.readlines() for i, line in enumerate(lines): if linear_start_addr: in line: addr_str line.split(:)[1].strip() addr int(addr_str, 16) if addr % block_size ! 0: print(fLine {i1}: Address {addr_str} is not aligned to {hex(block_size)}!)可能原因3分區(qū)重疊或間隙。一個分區(qū)的結(jié)束地址超過了下一個分區(qū)的開始地址或者兩者之間有空隙雖然空隙不一定導致失敗但浪費空間。解決 編寫或使用工具腳本按順序計算并打印每個分區(qū)的結(jié)束地址與下一個分區(qū)的起始地址對比。6.2 系統(tǒng)升級失敗OTA包驗證錯誤或空間不足可能原因1分區(qū)大小不符。OTA升級包在安裝時會檢查目標分區(qū)的大小是否足夠。如果設備上的system分區(qū)小于OTA包中system鏡像的預期大小升級會失敗。解決 檢查設備當前scatter.txt中system分區(qū)的大小并與編譯OTA包時使用的system鏡像大小對比。確保設備分區(qū)表版本與OTA包匹配。可能原因2動態(tài)分區(qū)大小未更新。對于動態(tài)分區(qū)即使scatter.txt中的super分區(qū)大小足夠但super內(nèi)部的邏輯分區(qū)如system大小定義在dynamic_partitions_list.txt中可能不足。解決 需要更新設備上的super分區(qū)表元數(shù)據(jù)這通常包含在OTA包中但需要確保刷寫過程正確。6.3 編譯錯誤ptgen執(zhí)行失敗可能原因1ProjectConfig.mk中存在語法錯誤或未定義的變量引用。例如在模板中引用了$CUSTOM_SIZE但ProjectConfig.mk中沒有定義CUSTOM_SIZE。解決 仔細檢查ptgen工具輸出的錯誤信息它會指出在哪一行遇到了未定義的變量。去ProjectConfig.mk中補全定義或檢查變量名拼寫?？赡茉?分區(qū)布局文件中的分區(qū)名在模板中找不到定義。解決 確保內(nèi)存布局文件中列出的每一個分區(qū)名在模板文件.emm中都有對應的定義塊。如果新增了分區(qū)必須在模板中添加。6.4 調(diào)試技巧手動驗證與修改技巧1使用十六進制編輯器查看閃存頭部。通過讀取設備閃存最開始的幾個扇區(qū)可以查看實際的GPT分區(qū)表并與scatter.txt進行比對。這能最直接地確認分區(qū)表是否已正確燒錄。但此操作有風險需謹慎。技巧2反推計算。當你拿到一個現(xiàn)成的scatter.txt但不確定其布局是否合理時可以手動從第一個分區(qū)通常是preloader開始將其分區(qū)大小累加起來看總和是否接近閃存總?cè)萘縈TK_EMMC_SIZE。這能幫你快速理解整體布局。技巧3制作對比工具。寫一個簡單的腳本比較兩個不同版本或不同配置生成的scatter.txt文件高亮顯示有差異的分區(qū)大小和地址。這在追蹤分區(qū)布局變更時非常有用。理解scatter.txt的生成過程本質(zhì)上是在理解MTK平臺設備存儲空間的規(guī)劃邏輯。它連接了硬件規(guī)格閃存大小、產(chǎn)品需求分區(qū)大小、系統(tǒng)特性A/B、動態(tài)分區(qū)和燒錄升級工具。掌握了這套流程你就擁有了在系統(tǒng)層面進行深度定制的鑰匙無論是解決棘手的空間不足問題還是實現(xiàn)特殊的產(chǎn)品功能需求都能做到心中有數(shù)手中有策。