NVMe 情境練習與圖表速查：查詢路徑、欄位推導、完整解答及 Spec 位置。
read more
NVMe 圖表判讀與情境練習 07 · 維護與管理操作
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
反覆查詢 · 欄位判讀 · 原文定位
NVMe 圖表判讀與情境練習 07 · 維護與管理操作
把要求的動作、命令完成與背景操作結果分開看。韌體提交、namespace 建立和 Sanitize 接受命令，各自都還有不同的後續狀態需要核對。
先跟著一個情境讀規格
以下回傳資料均為教學假設。先看需求與已知條件，再沿閱讀路線找到相關欄位，接著一起判讀結果。完整解說直接顯示，來源細節可另外展開。
練習 03新韌體已在 slot 2，現在跑的就是它嗎？
更新工具看到 slot 2 的新版本字串，便把升級標示為已生效。請用目前與下一次啟用欄位重新判讀。
模擬回傳與已知條件
- Firmware Slot Information：CAFS=1、NAFS=2；FRS1="A100"、FRS2="B200"。
- Identify Controller.FR="A100"；FRMW.FAWR=0；沒有後續可啟用該版本的 reset 紀錄。
這個情境要連起哪些規格圖表？
下面是閱讀規格的順序；實際操作的先後與等待條件，會在情境解說中另外交代。
- 先查目前版本與啟用能力
Identify Controller 的 FR 說明目前執行的版本，FRMW 則提供韌體槽位與啟用能力。
Base 2.4 · Figure 338 - 再查目前與下次啟用槽位
由 Firmware Slot Information 的 AFI 讀 CAFS、NAFS，再對照各槽位版本字串。
Base 2.4 · Figure 215 - 接回 Commit 的動作與完成條件
查看 Firmware Commit 的 action 與完成規則，確認版本何時生效；適用的啟用步驟完成後再重新讀取版本。
Base 2.4 · Figure 187
沿著欄位一步步理解
查詢次序：Identify CNS=01h 的 FR／FRMW → Get Log Page LID=03h 的 AFI 與 slot revisions → Firmware Commit 的 action／status 與 reset 紀錄。
推導 1CAFS=1 與 FR=A100 支持目前仍執行 slot 1 的版本。FRS2=B200 證明 slot 2 有該 revision，不等於 controller 現在已執行它。
推導 2NAFS=2 指向下一次能造成啟用的 Controller Level Reset 所要啟用的 slot。FAWR=0 表示不支援無 reset 啟用；不能把任何未分類的 reset 都當作已滿足啟用條件。
推導 3完整驗證應在適用的啟用步驟之後重新讀 FR 與 CAFS，再與預期版本比對。本題只指出尚未生效的證據，不要求現在執行 reset 或下載韌體。
完整原文定位
- Base 2.4 · §5.2.13.1.4 · Figure 215 · Firmware Slot Information Log Page · 文件頁 226 · PDF 252
- Base 2.4 · §5.2.9 · Figure 187 · Firmware Commit – Command Dword 10 · 文件頁 203 · PDF 229
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · 文件頁 340–341, 354 · PDF 366–367, 380
- Base 2.4 · §5.2.9 · 文件頁 202–205 · PDF 228–231
接著看其他情境
練習 01如何查詢單一 namespace 是否支援 Overwrite Sanitize？
需求是「只清除 NSID=7，使用 Sanitize Namespace with Overwrite」。Identify 顯示 OWS=1，是否已足夠？
- NSID
- Namespace Identifier，邏輯儲存空間識別碼
模擬回傳與已知條件
- Base Revision 2.4；SANICAP.OWS=1、CES=1；假設 Commands Supported and Effects 亦回報 Sanitize Namespace 受支援。
- 需求明確限制單一 namespace，不允許把清除範圍擴大成整個 NVM subsystem。
沿著欄位一步步理解
查詢次序：先查 Base §5.2.27 允許的操作 → Identify CNS=01h 的 SANICAP → Commands Supported and Effects 的命令支援 → 目標 namespace 狀態。
推導 1這版規格的 Sanitize Namespace 只有 Crypto Erase 這一種開始清除的操作。Figure 454 的 SANACT=011b（Overwrite 在另一個命令使用的值）在此屬於 Reserved。因此原需求無法由此標準命令組合實現。
推導 2SANICAP.OWS=1 表示支援 Overwrite sanitize，不會替 Sanitize Namespace 增加新的合法 action。Subsystem Sanitize 與 Sanitize Namespace 必須先分清命令與作用範圍，再解能力。
推導 3應回報「單一 namespace 的 Overwrite Sanitize 不在此版標準命令定義內」，並請需求端決定是否接受單一 namespace Crypto Erase 等其他方式。不能偷偷改送 subsystem Overwrite，也不能用一般 Write 覆寫冒充 Sanitize 保證。
完整原文定位
- Base 2.4 · §5.2.27 · 文件頁 452–453 · PDF 478–479
- Base 2.4 · §5.2.27 · Figure 454 · Sanitize Namespace – Command Dword 10 · 文件頁 453 · PDF 479
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · 文件頁 361–362 · PDF 387–388
- Base 2.4 · §5.2.26 · Figure 451 · Sanitize – Command Dword 10 · 文件頁 450–451 · PDF 476–477
- Base 2.4 · §5.2.13.1.6 · Figure 217 · Commands Supported and Effects Data Structure · 文件頁 228–229 · PDF 254–255
練習 02一個 namespace 已清除，是否整台都清除了？
驗證程式拿 NSID=7 的成功結果，宣稱整個 subsystem 已清除，而且還能再啟動 4 個並行操作。哪些推論越過了資料範圍？
- NSID
- Namespace Identifier，邏輯儲存空間識別碼
模擬回傳與已知條件
- LID=81h、NSID=7：STNSID=7、SOS=1；MNSOIP=FFFFFFFFh。
- 另讀 subsystem target（NSID=0）的 log：MNSOIP=4；尚未盤點其他進行中的 namespace sanitize。
沿著欄位一步步理解
查詢次序：Get Log Page LID=81h，分清 NSID=0／FFFFFFFFh 的 subsystem target 與 allocated NSID 的 namespace target。
推導 1STNSID=7 確認這份回覆是 namespace 7 的狀態；SOS=1 表示相應最近 sanitize 已成功且 state machine 回到 Idle。它沒有宣告其他 namespace 也完成相同操作。
推導 2namespace target 的 MNSOIP 按規則為 FFFFFFFFh，不能解成可並行數十億次。並行上限需讀 subsystem target；其值 4 是最多同時進行 4 個，不是現在剩餘 4 個。
推導 3要算目前餘額，還需完整且時間一致的進行中操作資訊，並考慮並行管理造成的變動。即使有名額，命令被接受也仍須另查目標 log 的最終結果。
完整原文定位
- Base 2.4 · §5.2.13.1.38 · Figure 312 · Sanitize Status Log Page · 文件頁 314–319 · PDF 340–345
- Base 2.4 · §5.2.27 · 文件頁 452–453 · PDF 478–479
練習 04Format 指定 NSID，就只會影響那一個嗎？
要求是只對 NSID=7 做 secure erase；審查時看到命令 NSID=7 就放行。還少查哪一組 scope？
模擬回傳與已知條件
- OACS.FNVMS=1；FNA.FNS=0、SENS=1、FNVMBS=0。
- 擬定 Format NVM：NSID=7、SES=1；其他格式欄位均合法，本題不執行命令。
沿著欄位一步步理解
查詢次序：Identify CNS=01h 的 OACS／FNA → Format NVM 的 NSID、SES 與格式參數。
推導 1FNS 決定格式變更的範圍，SENS 決定 secure erase 的範圍。本例 FNS=0 不能抵消 SENS=1；所要求的 secure erase 會作用於 subsystem 所有 namespaces。
推導 2因此這組參數不符合「只清除 namespace 7」的需求。NSID 看起來很精確，仍須與 controller attributes 合併判讀，不能只憑命令目標欄位推定所有副作用的範圍。
推導 3FNVMBS 的位值方向也要照定義：1 表示不支援 FFFFFFFFh broadcast，不是支援。這題的重點是先做範圍判定，再決定是否有符合需求的操作方式。
完整原文定位
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · 文件頁 353, 373 · PDF 379, 399
- Base 2.4 · §5.2.11 · Figure 195 · Format NVM – Command Dword 10 · 文件頁 208–209 · PDF 234–235
- NVM Command Set 1.3 · §4.1.1 · Figure 91 · Format NVM – Command Dword 10 – NVM Command Set Specific Fields · 文件頁 63 · PDF 63
練習 05不可保存的保護狀態，reset 後就會解除嗎？
工具看到 FID=84h 的 SVBL=0，就說 reset 會解除所有 namespace write protection。請比較兩個 namespace。
模擬回傳與已知條件
- Get Features FID=84h、SEL=0：NSID=2 的 WPS=2；NSID=9 的 WPS=3。
- controller 支援這些狀態；計畫中的動作只是 Controller Level Reset，沒有斷電。
沿著欄位一步步理解
查詢次序：Identify CNS=01h 查 NWPC → Get Features FID=84h、SEL=0 查各 namespace 目前 WPS → 對照 §8.1.18 的狀態持續規則。
推導 1WPS=2 是 Write Protect Until Power Cycle，會跨沒有斷電的 Controller Level Reset 持續。因此題目的 reset 不能使 NSID=2 回到未保護；真正 power cycle 才是該狀態定義的解除條件。
推導 2WPS=3 是 Permanent Write Protect，不能把 power cycle 當解除方法。可支援某種保護、允許進入保護、目前處在什麼狀態，是三個不同問題。
推導 3SVBL=0 描述 Feature 是否接受保存要求，不改寫狀態本身的持續規則。報告應保留 NWPC、必要的 WPC 許可與 WPS，不能由單一 saveable 位推論復原行為。
完整原文定位
- Base 2.4 · §5.2.30.1.38 · Figure 541 · Write Protection – Command Dword 11 · 文件頁 512 · PDF 538
- Base 2.4 · §5.2.12 · Figure 201 · Completion Queue Entry Dword 0 when Select is set to 11b · 文件頁 212 · PDF 238
- Base 2.4 · §5.2.14.2.1 · Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent · 文件頁 375 · PDF 401
- Base 2.4 · §8.1.18 · 文件頁 664–666 · PDF 690–692
練習 06Boot protection 的 0，和 namespace 的 0 一樣嗎？
一個共用解碼器把所有 protection state=0 都顯示為未保護。用以下歷史命令與讀取結果，判斷會誤解哪裡。
模擬回傳與已知條件
- 先前 Set Features FID=85h：BP0WPS=0、BP1WPS=0，成功。
- 現在 Get Features FID=85h、SEL=0：BP0WPS=2、BP1WPS=4。
沿著欄位一步步理解
查詢次序：按 FID 區分 Namespace Write Protection（84h）與 Boot Partition Write Protection（85h），再區分 Set 要求與 Get 回報。
推導 1FID=85h 的 Set 值 0 是「不要求改變該 partition」，不是解鎖。兩個 0 的成功命令可能保持兩者原狀，不能拿它當作解除保護的證據。
推導 2目前 BP0WPS=2 表示 partition 0 為 Write Locked；BP1WPS=4 表示 partition 1 的保護由 RPMB 控制。4 是可回報的狀態，不能原樣當一般 Set 的要求值。
推導 3Get 不會以 0 表示這兩個 partition 的狀態，因此共用函式至少需要 FID 與方向。若還涉及 shared multi-domain partition，必須另查其特定限制，不能只套 namespace 的 WPS 表。
完整原文定位
- Base 2.4 · §5.2.30.1.39 · Figure 542 · Boot Partition Write Protection Config - Command Dword 11 · 文件頁 513–514 · PDF 539–540
- Base 2.4 · §5.2.30.1.38 · Figure 541 · Write Protection – Command Dword 11 · 文件頁 512 · PDF 538
01Firmware Commit：放進 slot 與啟用的差別
Base 2.4 · Figure 187 · Firmware Commit – Command Dword 10
§5.2.9 · 文件頁 203 · PDF 229
01.1 · 用途韌體已下載但版本未改變時，查 Commit Action，分辨本次是否只放入 slot、等待 reset 或立即啟用。下載與 commit 不是同一步。
01.2 · 欄位與關係FS bits2:0 指定 slot，0 讓 controller 選；CA bits5:3 的 0 為放入但不啟用、1 為放入後下次 Controller Level Reset 啟用、2 為既有 slot 下次 reset 啟用、3 為立即啟用。CA6／7 屬 Boot Partition，搭配 BPID bit31。
01.3 · 判讀與例子CA=1 命令成功後，當下 active firmware 仍可是舊版；用 Firmware Slot Information 比較目前與下次 active slot，再核對 completion 是否要求特定 reset。
回本冊圖表索引02Firmware Download：每個 chunk 的大小
Base 2.4 · Figure 191 · Firmware Image Download – Command Dword 10
§5.2.10 · 文件頁 205 · PDF 231
02.1 · 用途重建韌體下載分段時，這張表解每一段長度。整份 image 的大小不能直接填到每個 chunk 命令。
02.2 · 欄位與關係CDW10 的 NUMD bits31:0 以 Dwords 數減 1 表示本段長度，bytes=4×(NUMD+1)。還需搭配 CDW11 的 Offset 與 Identify.FWUG 要求，確認分段位置、粒度與完整性。
02.3 · 判讀與例子4096-byte chunk 的 NUMD=1023，而不是 4096。讀 trace 時要分開記錄長度與目的 image offset；正確長度仍可能因 offset 或 FWUG 條件不符而失敗。
回本冊圖表索引03Firmware Slot Log：目前版本與待啟用 slot
Base 2.4 · Figure 215 · Firmware Slot Information Log Page
§5.2.13.1.4 · 文件頁 226 · PDF 252
03.1 · 用途更新後要確認「已存放」與「正在執行」是否相同，查這份 log。某 slot 有版本字串，不代表它就是 active slot。
03.2 · 欄位與關係AFI byte0 的 CAFS bits2:0 為目前 active slot，NAFS bits6:4 為下次可造成啟用的 reset 所要啟用 slot；NAFS=0 表示未指示。FRS1～7 每個 8bytes，保存各 slot 的 revision，從 byte8 開始。
03.3 · 判讀與例子CAFS=1、NAFS=2、slot2 有新版字串，表示目前仍從 slot1 載入，slot2 等待啟用。FRS 為 0 可能是該 slot 未支援或沒有有效版本，不能單靠 0 區分兩者。
回本冊圖表索引04Device Self-test：選哪種測試或中止
Base 2.4 · Figure 177 · Device Self-test – Command Dword 10
§5.2.6 · 文件頁 199 · PDF 225
04.1 · 用途測試啟動命令的動作由 STC 決定。命令完成與測試背景流程完成是兩回事，結果應接著看 Self-test log。
04.2 · 欄位與關係CDW10 bits3:0 的 STC=1 啟動 short、2 啟動 extended、3 啟動 Host-Initiated Refresh、Eh 為廠商專屬、Fh 中止。NSID 與支援能力另決定測試對象及動作是否適用。
04.3 · 判讀與例子STC=2 成功完成提交後，若 log 仍顯示 extended 進行中，並不矛盾。不能把 Admin CQE 成功當成整個測試已通過。
- CQE
- Completion Queue Entry，佇列中的完成項目
05Self-test Log：目前進度與最近 20 筆結果
Base 2.4 · Figure 218 · Device Self-test Log Page
§5.2.13.1.7 · 文件頁 230 · PDF 256
05.1 · 用途這張表將目前正在執行的狀態與過去結果分開。查測試進度看前 2bytes；查成敗看後面的 result list。
05.2 · 欄位與關係CDSTO byte0 低 4bits 為目前 operation，CDSTC byte1 低 7bits 為完成百分比。DSTOS=0 時進度欄應忽略。從 byte4 開始保存 20 筆 28-byte 結果，第一筆是最新完成或中止的操作。
05.3 · 判讀與例子byte1 仍留 25 而 DSTOS 已為 0 時，不應報告「測試卡在 25%」。先讀最新結果，確認是完成、命令中止、reset 中止或其他原因。
回本冊圖表索引06Self-test Result：先看有效位再讀失敗位置
Base 2.4 · Figure 219 · Self-test Result Data Structure
§5.2.13.1.7 · 文件頁 231–232 · PDF 257–258
06.1 · 用途這張表用來判讀一筆 Self-test 結果，並區分「測試失敗」與「操作被中止」。後面的診斷欄位不是每筆都有意義。
06.2 · 欄位與關係DSTS byte0 高 4bits 是測試類型、低 4bits 是結果；SEGN byte1 僅特定結果有效。VDINFO byte2 分別標 NSID、FLBA、SCT、SC 是否有效；POH bytes11:4 記完成／中止時通電小時，NSID15:12 與 FLBA23:16 描述失敗對象。
- SCT
- Status Code Type，完成狀態代碼類型
06.3 · 判讀與例子VDINFO 的 FVLD=0 時，即使 FLBA bytes 全 0，也不能宣稱 LBA0 故障。DSTR=2 是 Controller Level Reset 中止，也不等於測出媒體損壞。
回本冊圖表索引07Namespace Attachment：建立後還要附加到 controller
Base 2.4 · Figure 443 · Namespace Attachment – Command Dword 10
§5.2.24 · 文件頁 445 · PDF 471
07.1 · 用途namespace 存在但某個 controller 看不到時，查 attachment 動作及 controller list。建立儲存物件與讓某 controller 存取，是不同操作。
07.2 · 欄位與關係CDW10.SEL bits3:0 的 0 表示 Attach、1 表示 Detach，其他值保留。實際 namespace 由 NSID 指定，目標 controllers 在資料 buffer 清單中。此表的 SEL 數值不能套到 Namespace Management。
07.3 · 判讀與例子Detach 不等於 Delete：它解除 controller 與 namespace 的關聯，不是直接刪除 namespace。若清單處理失敗，Error Information 可提供第一個失敗 entry 的 byte offset，不能假設後續 controllers 都已處理。
回本冊圖表索引08Namespace Management：Create、Delete 或 Restore
Base 2.4 · Figure 446 · Namespace Management – Command Dword 10
§5.2.25 · 文件頁 446–447 · PDF 472–473
08.1 · 用途這張表用來辨認主機要求改變 namespace 配置的哪一種動作。單靠 opcode 無法區分 Create 與 Delete。
08.2 · 欄位與關係CDW10.SEL bits3:0 的 0／1／2 分別為 Create、Delete、Restore Default Namespace Configuration。其餘 bits 保留；資料 buffer 與 NSID 的用途依動作而變，Create 還需搭配 CSI 選格式。
- CSI
- Command Set Identifier，命令集識別碼
08.3 · 判讀與例子Create 成功回傳的新 NSID，只證明 namespace 已建立，不保證已附加給目標 controller。Restore 是恢復預設 namespace 配置，不是任意備份 snapshot 的還原。
回本冊圖表索引09Create Namespace buffer：哪些欄位由主機填
NVM Command Set 1.3 · Figure 134 · Namespace Management – Host Specified Fields
§4.1.6 · 文件頁 112–113 · PDF 112–113
09.1 · 用途建立 NVM namespace 時，此表列出主機可以指定的 buffer 位置。它只沿用部分 Identify 欄位，不應把完整 Identify 回覆不加修改地當 Create 輸入。
09.2 · 欄位與關係NSZE 在 bytes7:0、NCAP15:8、FLBAS26、DPS29、NMIC30，後面有 ANAGRPID、NVMSETID、ENDGID。LBSTM 在 391:384，FDP 使用 NPHNDLS393:392 及從 512 開始的 Placement Handle list；保留區須按 Create 格式處理。
- FDP
- Flexible Data Placement，彈性資料放置
09.3 · 判讀與例子支援並啟用 FDP 時，placement handle 清單建立到 RUH 的對應；不支援或未啟用時不能依這些 bytes 宣稱配置有效。NSZE 與 NCAP 仍以所選格式的 blocks 為單位，不是 bytes。
- FDP
- Flexible Data Placement，彈性資料放置
10Format CDW10：格式編號與清除選項
Base 2.4 · Figure 195 · Format NVM – Command Dword 10
§5.2.11 · 文件頁 208–209 · PDF 234–235
10.1 · 用途Format 要求的是哪個資料格式、是否同時 secure erase，用此表解 CDW10。Base 先定共同外框，PI 和 metadata 語意要接 NVM 補充。
- PI
- Protection Information，資料保護資訊
10.2 · 欄位與關係LBAFL bits3:0 與 LBAFU13:12 組成 format index；LBAFU 須符合 LBAFEE 條件。SES bits11:9 的 0／1／2 分別為不要求 secure erase、User Data Erase、Cryptographic Erase。PIL8、PI7:5 與 MSET4 依 command set 解讀。
10.3 · 判讀與例子format index 是清單索引，不是 bytes 或 LBA 大小。SES=1 後資料內容不保證為零；若驗證程式只接受全 0，會把允許的其他擦除後內容誤判成失敗。
- LBA
- Logical Block Address，邏輯區塊位址
- PI
- Protection Information，資料保護資訊
11NVM Format 補充：PI 類型與 metadata 放置
NVM Command Set 1.3 · Figure 91 · Format NVM – Command Dword 10 – NVM Command Set Specific Fields
§4.1.1 · 文件頁 63 · PDF 63
11.1 · 用途這張表補上 Base Format 表留給 NVM 的三個欄位。PI type 與 Guard 位寬不是同一組選擇，不能因 Type3 就當成 64-bit Guard。
11.2 · 欄位與關係MSET bit4 選 extended LBA 或 separate buffer；PI bits7:5 的 0 停用、1／2／3 啟用對應保護類型；PIL bit8 表示 PI 位置。NVM Command Set 1.0 及後續版本要求 PIL 清 0，PI 放 metadata 尾端。
- LBA
- Logical Block Address，邏輯區塊位址
11.3 · 判讀與例子選 MSET=1、PI=1 是 extended LBA 加 Type1 保護。實際 metadata 大小與 Guard 格式，仍要讀所選 LBAF／ELBAF，而不是從這兩個值推算。
回本冊圖表索引12Subsystem Sanitize：動作與完成模式
Base 2.4 · Figure 451 · Sanitize – Command Dword 10
§5.2.26 · 文件頁 450–451 · PDF 476–477
12.1 · 用途查整個 NVM subsystem 的 Sanitize 要求時，這張表解動作、覆寫次數及後續狀態選項。命令接受與 sanitize 完成必須分開驗證。
12.2 · 欄位與關係SANACT bits2:0 選 1 退出 failure、2 Block Erase、3 Overwrite、4 Crypto Erase、5 退出 Media Verification；AUSE bit3 選完成模式。OWPASS7:4、OIPBP8 供 Overwrite 使用；NDAS9、EMVS10、PREQ11 另控制 deallocation、驗證與 purge 要求。
12.3 · 判讀與例子Overwrite 的 OWPASS=0 表示 16 次，不是 0 次。操作成功接受後應讀 LID81h 追蹤 SOS 等結果，不能把 Admin CQE success 或單一 SPROG 值當成已成功清除。
- CQE
- Completion Queue Entry，佇列中的完成項目
13Namespace Sanitize：PREQ 的 bit 位置不同
Base 2.4 · Figure 454 · Sanitize Namespace – Command Dword 10
§5.2.27 · 文件頁 453 · PDF 479
13.1 · 用途針對單一 namespace 的 Sanitize 命令有自己的 CDW10 格式。它不能直接複製 subsystem Sanitize 的所有控制位。
13.2 · 欄位與關係SANACT bits2:0、AUSE bit3、PREQ bit4、EMVS bit10 有效；開始操作的動作是 Crypto Erase=4，Block Erase 與 Overwrite 編碼在此保留。bits9:5 與 31:11 保留。
13.3 · 判讀與例子例如 CDW10=0000041Ch 包含 SANACT4、AUSE1、PREQ1 及 EMVS1。若把 PREQ 放到 subsystem 用的 bit11，這裡寫到的是保留位，不是提出 purge 要求。
回本冊圖表索引14Sanitize Status：進度、結果與目前狀態
Base 2.4 · Figure 312 · Sanitize Status Log Page
§5.2.13.1.38 · 文件頁 314–319 · PDF 340–345
14.1 · 用途這張 log 同時回答背景操作進行到哪裡、最近結果與當前 sanitize state。查詢時先確認是 subsystem 還是 namespace 目標，再套欄位語意。
14.2 · 欄位與關係SPROG bytes1:0 為進度分數，status 內 SOS 區分從未操作、成功、進行中、失敗等。SCDW10 保存啟動參數；估計時間欄位有各自的 0／FFFFFFFFh 意義。SSI 補目前 state 及 failure state，另有清除狀態與 STNSID 等目標資訊。
14.3 · 判讀與例子SPROG=FFFFh 不能單獨當成功：SOS=3 仍代表失敗。解析 SCDW10 時，也要按目標選 Figure451 或 454，尤其 PREQ 的 bit 位置不同。
回本冊圖表索引15Namespace Write Protection：目前保護狀態
Base 2.4 · Figure 541 · Write Protection – Command Dword 11
§5.2.30.1.38 · 文件頁 512 · PDF 538
15.1 · 用途寫入命令被拒絕時，查此 namespace 目前 WPS，再分辨是否可解除、需 power cycle 或永久保護。這不是 Boot Partition 的保護編碼。
15.2 · 欄位與關係CDW11 bits2:0 為 WPS：0 未保護，1 一般保護，2 直到 power cycle，3 永久保護。支援能力與進入許可另查 NWPC 及 Write Protection Control；WPS 只描述要求或回報的狀態。
15.3 · 判讀與例子已進入 WPS=2 或 3 後，直接 Set Features 要求改回 0 會得到 Feature Not Changeable。不能因 SEL=3 回 CHANG=1，就判定當前永久狀態可以反轉。
回本冊圖表索引16Boot Partition 保護：兩個 partition 的獨立欄位
Base 2.4 · Figure 542 · Boot Partition Write Protection Config - Command Dword 11
§5.2.30.1.39 · 文件頁 513–514 · PDF 539–540
16.1 · 用途Boot Partition 更新被阻擋時，查兩個 partition 各自的保護狀態。此表的 0 不是「未保護」，與 namespace WPS 不同。
16.2 · 欄位與關係BP0WPS bits2:0、BP1WPS bits5:3：0 僅供 Set 使用、表示不要求改變；1 解鎖、2 鎖定、3 鎖至 power cycle。4 表示由 RPMB 控制，只能回報，不能作 Set 要求；預設兩者都是鎖定。
16.3 · 判讀與例子要只解鎖 partition0 並保留 partition1 原狀，兩欄分別為 1 與 0，CDW11=1。不能把兩欄都清 0 當作解鎖兩個 partition；若 NVM subsystem 的 CTRATT.MDS=1，且該 Boot Partition 由多個 controller 共享，將它設成 3（鎖至 power cycle）的要求會以 Feature Not Changeable 中止。
回本冊圖表索引
Comments