NVMe 自問自答題庫：Firmware Update 與 Boot Partition
read more
NVMe 自問自答題庫：Firmware Update 與 Boot Partition
NVMe · Q1–328
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
Q136–Q148
Firmware Update 與 Boot Partition
先分清下載、提交與啟用，再把 Boot Partition 的讀取和切換放在旁邊比較。資料已傳入 controller，不代表新韌體或新開機映像已開始使用。
每個問題都接著完整解說，依內容帶讀欄位、比較機制或追蹤流程。先看本冊總覽，再沿問題閱讀；必要條件與正常路徑直接顯示。所有數字案例均為教學假設；Status 以 SCT/SC 表示，代碼後的 h 代表十六進位。
- SCT
- Status Code Type，完成狀態代碼類型
從映像資料到真正啟用
Slot、pending activation 與目前 running revision 各描述一個階段。
| 階段 | 查哪些欄位 | 此時能說什麼 |
|---|---|---|
| Download | OFST、NUMD、完整映像 | 資料已傳送，不等於啟用 |
| Commit | FS、CA、CQE | 依 Action 存入或安排啟用 |
| Activation | 所需 reset、FR、CAFS | 確認目前實際版本 |
| Boot Partition | ABPID、BRS、FID85h | 判斷映像讀取及保護 |
- CQE
- Completion Queue Entry，佇列中的完成項目
舉例看懂：CA=2 是安排既有 slot 在指定啟用時機生效；若還沒做該步驟，Identify.FR 不必提前改變。Boot 的 CA=7 則是選 Active Partition，不能直接等同一般 Firmware Activation。
來源：Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §3.1.4 (BPINFO, BPRSEL, BPMBL) · Base 2.4 §5.2.30.1.39
需要時回顧本篇名詞
- Controller / namespace
- controller 接收命令並管理存取；namespace 是命令可指定的一份邏輯儲存空間。NVM subsystem 則包含 controller 與非揮發儲存資源，同一 subsystem 可以有多個 controller。
- SQ / CQ / SQE / CQE
- Submission Queue（SQ）是提交佇列，Completion Queue（CQ）是完成佇列；SQE 與 CQE 分別是其中的一筆命令及完成項目。QID 識別 queue，CID 區分同一 SQ 中尚未完成的命令，NSID 則識別 namespace。
- Register / Identify / Feature / Log
- Register 提供可存取的控制或狀態資訊；Identify 查詢物件的能力與屬性；Feature 用來讀取或變更工作設定；Log Page 回報特定種類的狀態或紀錄。FID、LID、CNS、CSI 則分別用來選擇 Feature、Log Page、Identify 資料結構及命令集。
- index / offset / zero-based
- index 指出清單中的第幾筆，通常從 0 起算；offset 表示與起點相隔多遠，解讀時必須確認單位。若數量欄位採 zero-based 編碼，實際數量等於欄位值加 1；但不是所有欄位看到 0 都要加 1。Dword 是 4 bytes，1 byte 是 8 bits。
- Scope / reset / retention
- scope 表示操作影響哪些物件；retention 表示狀態是否保留。清除 CC.EN 所觸發的 Controller Reset，是 Controller Level Reset（CLR）的一種。同屬 CLR 的不同觸發方式，仍可能採用不同的 Register 保留規則。
本冊題目
- Q136 · Firmware Slot 的數量、唯讀限制與使用狀態從哪裡查？
- Q137 · Firmware Image Download 如何使用 OFST 與 NUMD？
- Q138 · 下載重疊、缺漏、順序與無效 Image 如何處理？
- Q139 · Firmware Commit 的 FS 與 CA 如何選？
- Q140 · 立即啟用與等待不同 Reset 啟用有何差別？
- Q141 · Firmware Activation Starting 何時產生？
- Q142 · Download、Commit 或 Activation 中發生 Reset／斷電如何處理？
- Q143 · Firmware 載入失敗後如何回復？
- Q144 · Activation 後如何確認版本、Slot 與 Command Effects？
- Q145 · Activation 後哪些設定應保留，哪些需要重新探索？
- Q146 · Boot Partition 支援、狀態與 Active ID 如何確認？
- Q147 · Boot Partition 如何下載、提交與切換 Active？
- Q148 · Boot Partition 更新與 Controller Firmware 更新有何不同？
Q136 Firmware Slot 的數量、唯讀限制與使用狀態從哪裡查？
跟著解說理解
要同時讀 Identify 與 Firmware Slot Information Log：Identify.FRMW 提供 slot 數量及 slot 1 是否唯讀，Log 則提供各 slot 的內容與啟用狀態。
1. 要查哪個對象、哪份資料
Firmware slots 由同一 domain 的 controllers 共用；查詢前先確認是哪個 domain 的更新。
OACS 宣告 firmware download/commit 支援；FRMW 宣告 slot 數、slot1 唯讀與無 Reset 啟用能力。
LID03h 中 CAFS 是目前 Active slot，NAFS 是預定下一次適用 Reset 啟用的 slot；FRS1～7 是各 slot 的 revision。
2. 查詢順序與回覆判讀
先讀 FRMW，再讀 LID03h，選可寫且符合更新計畫的 slot；不要透過嘗試覆寫 slot1 來探測它是否唯讀。
能分清「存在幾個 slot」、「哪個已有映像」、「目前執行哪個」與「下次準備啟用哪個」。
3. 證據不足或不一致時怎麼判斷
某 slot revision 全為 0 可表示沒有有效映像或不支援，不能只靠 Log 反推 slot 數。非法或唯讀 slot 可回 Invalid Firmware Slot。
Identify.FR 應回報目前執行的韌體版本。NAFS 指向的是待啟用 slot，須等啟用完成後，再核對它與執行版本的關係。
先查 FRMW，避免把尚未使用的 slot 當成不存在。
來源：Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q137 Firmware Image Download 如何使用 OFST 與 NUMD？
跟著解說理解
分段下載讓 Host 不必一次提供完整映像，但每段的位置與長度必須能正確重組。
1. 先確認資料的來源與範圍
OFST 相對於整份待更新映像，不是相對於這一段的 Host buffer。
檢查 FWUG 的對齊／粒度限制與 MDTS 等傳輸限制。FWUG 特殊值要依欄位解讀，不能一律當成一般倍數。
2. 欄位、單位與判讀例子
OFST 以 Dword 為單位；NUMD 為零起算 Dword 數。位元組起點=OFST×4，長度=(NUMD+1)×4。
假設每段 4096 bytes，第一段 OFST=0、NUMD=1023，第二段 OFST=1024、NUMD=1023；每段 buffer 都指向該段實際資料。
Download Success 只表示該段下載完成，還沒有 Commit，也沒有啟用新映像。
3. 判讀時要保留的條件
不符合 FWUG 時 controller 可回 Invalid Field；重疊範圍可回 Overlapping Range。單位錯誤會同時造成錯誤位移與資料缺口。
用每段的起點、終點與長度核對完整覆蓋，並與原始映像內容比對。
來源：Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q138 下載重疊、缺漏、順序與無效 Image 如何處理？
跟著解說理解
需要區分分段傳輸錯誤與整份映像驗證失敗。每段成功，仍可能因資料缺漏或格式錯誤而不能 Commit。
1. 先區分是哪一種失敗
同一更新流程應只處理一份映像，並使用同一 controller；不要將兩份 firmware 或 Boot Partition 的下載交錯。
Firmware pieces 可以亂序；Boot Partition pieces 必須由映像開頭依序提交。Overlapping Range 與 MUD 是不同資訊，前者檢查範圍，後者報告更新流程重疊。
重疊可回 1/14h；Commit 驗證不合法可回 1/07h。多個更新流程重疊的結果可能未定義，不能要求固定錯誤碼來補救 Host 違反建議。
2. 用哪些資料確認原因
確認 FWUG、映像需求與支援時的 Multiple Update Detected 能力。
在 Host 建立段落清單，確認無缺口、無重疊且全部成功，再 Commit；一份流程結束後才開始下一份。
3. 結果與後續驗證
有效完整映像應能進入適用 Commit 流程；不能要求每一段都單獨驗證整份映像。
保留 Download 範圍與 Commit CQE，區分傳輸完成、資料完整與映像可啟用。
- CQE
- Completion Queue Entry，佇列中的完成項目
先檢查是否把 Boot 的必須依序規則誤套到一般 firmware，或反過來。
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q139 Firmware Commit 的 FS 與 CA 如何選？
跟著解說理解
Commit 可以只保存、安排下次啟用，或立即啟用；選擇取決於更新計畫與裝置能力，不是每次都用同一個 CA。
1. 操作前先準備什麼
FS 選 firmware slot；Boot 操作用 BPID，不能把 BPID 當成更多的 firmware slots。
讀 FRMW、目前 slot、pending slot 與 MTFA，確認無 Reset 啟用是否適合。
CA0=保存不啟用；CA1=保存並在下次 CLR 啟用；CA2=下次 CLR 啟用既有 slot；CA3=立即啟用。FS=0 讓 controller 選 slot1～7。
2. 先後順序與完成條件
先完成需要的 Download，再送選定的 Commit；如果只啟用既有映像，就不必先下載相同內容。
CA0 成功不改 running version；CA1／2 需等待適用 Reset；CA3 的 Commit 保持執行中直到啟用成功或失敗。
3. 未符合條件時如何處理
唯讀／非法 slot 回 Invalid Firmware Slot；非法映像回 Invalid Firmware Image；需更強 Reset 的回覆表示 Commit 已保存但啟用還缺步驟。
用 CA 解釋 FR、CAFS 與 NAFS 的預期變化，不要求所有 CA 都立即更新 FR。
來源：Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q140 立即啟用與等待不同 Reset 啟用有何差別？
跟著解說理解
立即啟用可保留 controller 操作環境，但映像變更可能要求 Reset 才能安全切換。Host 必須尊重 Commit 指定的 Reset 類型。
1. 差別在哪裡
啟用影響同一 domain 的 controllers；Reset 本身的範圍可能再涵蓋更多 controller。
1/0Bh 要 Conventional Reset，1/10h 要 Subsystem Reset，1/11h 要 CLR；1/12h 表示立即啟用需超過 MTFA，映像已 Commit 但未啟用。
2. 如何選擇與確認
看 FRMW 的無 Reset 啟用能力、MTFA 與 Commit Status；能力支援不保證每一份映像都可立即啟用。
CA3 若成功就查新版本；若回要求 Reset，安排對應 Reset 再初始化與查版本。只做較小 Reset 不能滿足明定的較大 Reset 要求。
CA1／2 回 Success 時，任一適用 CLR 方法即可啟用；若特別回要求 Conventional 或 Subsystem Reset，則等待那種類型。
3. 比較時要保留的條件
例如要求 Conventional Reset 後只清 CC.EN，controller 應繼續執行原映像，不能以 FR 沒變判違規。
同時記錄 CA、Status、實際 Reset 來源與恢復後 FR，才能判斷啟用是否符合規範。
來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q141 Firmware Activation Starting 何時產生？
跟著解說理解
這個事件讓 Host 知道 controller 將進行不經 Reset 的韌體啟用，可能暫停處理；它不是啟用已成功的通知。
1. 事件何時成立、由誰觀察
受新映像影響的 controllers 各自依通知設定回報，並不只限於提交 Commit 的 controller。
確認 Firmware Activation Notices 已啟用、AER 已掛入，以及 FRMW／MTFA 等啟用資訊。
AER 的 Notice 類型、Firmware Activation Starting 資訊及 LID03h 引導 Host 查 slot；CSTS.PP 表示處理暫停狀態。
2. 通知、讀取與確認的關係
Commit CA3 開始啟用時處理通知，依 PP 觀察恢復，再查 Commit 結果與 FR。不要在收到 Starting 後立即把新版本列為成功。
成功證據是適用 Commit 完成與實際 running revision；Starting 只證明已開始相應流程。
3. 沒有通知或紀錄時怎麼判斷
沒有啟用通知或沒有可完成的 AER 時，不能期待同樣的即時 CQE。載入失敗則另有 Firmware Image Load Error。
比較事件時間、PP 與 Commit 完成，辨別真正卡住與 Host 尚未處理通知。
先查 AEC 的 Firmware Activation Notices，而不是只看是否送過任意 AER。
4. Asynchronous Event 的通知條件
開始不經 Reset 的韌體啟用時，受影響 controller 在 Firmware Activation Notices 啟用下回報 Firmware Activation Starting。 完整條件見本冊說明
來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.30.1.6 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §5.2.30.1.6 · Base 2.4 §3.1.4 (CC, CSTS, NSSR) · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q142 Download、Commit 或 Activation 中發生 Reset／斷電如何處理？
跟著解說理解
更新有暫存下載、保存到 slot、啟用三個階段，各自的持久性不同；復原時先定位中斷在哪一階段。
1. 先界定觸發方式與影響對象
保存與啟用的範圍是 domain；中斷也可能讓所有共享 controllers 同時失去通訊。
保存最後完成的 Download／Commit、CA、FS、FR 及 slot Log，恢復後再次讀取。
2. 哪些狀態改變，恢復後怎麼處理
CLR 發生在 Download 與 Commit 完成之間時，controller 必須丟棄下載部分。啟用 Commit 期間進入 D3cold，恢復可使用原映像或新映像。
恢復通道後查實際版本與 slot；未完成 Commit 的映像重新下載，不從原暫存 offset 自行續傳。
已知目前執行版本、pending 狀態與可用能力後，才能決定重試、重新 Commit 或已完成。
3. 重設或斷電時，要確認什麼
| 觸發方式 | 這項操作或狀態會如何變化 |
|---|---|
| Controller Reset 後是否保留或繼續？ | Download 後、Commit 完成前若發生 Controller Level Reset，已下載的暫存映像部分必須丟棄。已完成 Commit 的 slot 與待啟用安排則依 CA 及回傳的必要 Reset 類型判斷；不能只因任何 Reset 就假設新映像會啟用。 |
| NVM Subsystem Reset 後是否保留或繼續？ | Subsystem Reset 會影響其涵蓋的 controllers，並可滿足明確要求此 Reset 的待啟用映像。恢復後重新查 FR、slot 及能力；未完成 Commit 的暫存下載不能沿用。 |
| Power Cycle 後是否保留或繼續？ | 若在要求啟用的 Commit 尚未完成時進入 D3cold，恢復後可使用原映像或該次新映像，必須實際查證。已完成下載但尚未完成 Commit 的暫存部分，不能當成跨斷電保存的有效 slot。 |
4. 如何驗證保留或恢復結果
沒有 CQE 時不能補造成功或失敗碼。新版本未啟用可能是合法保留原版本，而不是必然毀損。
使用 PEL Commit 與 Reset Event 補足歷史，但 NFR 只記要求版本，仍須與 FR 比對。
先查最後一筆真正完成的 Commit，而不是最後一段已下載的資料。
來源：Base 2.4 §3.7.1–3.7.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q143 Firmware 載入失敗後如何回復？
跟著解說理解
裝置需要在新映像無法載入時恢復可運作映像，但可回復到什麼內容仍取決於先前有效 slot 或 baseline 是否存在。
1. 先保留哪些證據
失敗與回復影響該映像涵蓋的 controllers；不應以單一 slot 的內容推論整個更新歷史。
查 FR、CAFS／NAFS、各 slot revision、Firmware Image Load Error 與 PEL。
新映像無法載入時，controller 必須回復至最近已啟用 slot 的映像，或可用的 baseline 唯讀映像，並回報 Firmware Image Load Error。
2. 依什麼順序排除原因
先查 Active slot 是否曾被覆寫，這會直接影響可回復映像。
恢復後讀實際 FR，確認是否回到可用映像，再檢查失敗的 Commit／activation 狀態；不要立即反覆啟用同一失敗映像。
3. 把觀察結果接回規格條件
controller 可恢復舊版本運作，同時保留更新失敗的證據；舊版本運作不表示前次更新成功。
如果 Host 已覆寫 Active slot，舊映像可能不再存在，因此不能保證永遠回到某個特定歷史版本。
核對實際 slot 內容與可用 baseline，避免測試把不存在的舊映像當成必須回復的對象。
來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.2 (PCIe-applicable events) · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q144 Activation 後如何確認版本、Slot 與 Command Effects？
跟著解說理解
啟用完成後可能改變能力與命令效果，Host 必須更新快取，不能只看版本字串就沿用所有舊設定假設。
1. 操作前先準備什麼
查詢涵蓋受影響 domain 的 controller 與 namespaces，並保留相同身分以便前後比較。
讀 Identify.FR、FRMW、CAP、Firmware Slot Information，並重新取得適用 CSI 的 Commands Supported and Effects。
- CSI
- Command Set Identifier，命令集識別碼
CAFS 表示現行 slot，NAFS 表示待啟用安排，FR 是 running revision；Effects 的 CSUPP／CCC／NCC／NIC 等說明支援及可能影響。
2. 先後順序與完成條件
先確認啟用真的完成，再重新查能力，最後依新宣告重新驗證需要使用的命令與格式。
FR、目前 slot revision 與啟用結果應能互相解釋；pending slot 尚未啟用時，不應要求 FR 提前更新。
3. 未符合條件時如何處理
查詢失敗先看 Ready／media 限制與新能力，不直接判定映像損壞。
比較有效欄位與真正變更，避免把保留欄位或不適用 CSI 的資料列當成不一致。
- CSI
- Command Set Identifier，命令集識別碼
來源：Base 2.4 §5.2.13.1.6 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.13.1.6 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q145 Activation 後哪些設定應保留，哪些需要重新探索？
跟著解說理解
不能要求整份 Identify、Feature 與所有 bytes 都不變。韌體可更新能力；但使用者資料、namespace 配置及各功能的持久性仍需遵守其規則。
1. 先界定觸發方式與影響對象
先區分不經 Reset 的啟用與實際執行 Reset；後者會另外觸發 queue、Feature 與 Register 的重設規則。
比較 Feature 的 Saved／Current／持續性、namespace 身分／attachment，以及新 Identify 能力與 UUID List。
2. 哪些狀態改變，恢復後怎麼處理
FR 預期反映 running image；Current Feature 不可僅依版本字串推論。UUID slot 的不相容變更可能要求 Reset，避免舊 UUID Index 指向另一個意思。
建立更新前基準，記錄 CA 與實際 Reset，更新後按每項功能的保留規則分類比對，再重新配置必要的 Host 狀態。
結果應符合所執行的更新與 Reset 路徑；正常能力變更與不應遺失的資料／配置要分開驗證。
3. 如何驗證保留或恢復結果
不能只用「版本變了所以全部可重設」合理化遺失；也不能用「只是更新」要求 I/O queues 跨真正 Reset 有效。
把差異逐項對應來源要求，記錄新能力、應保留值及必須重建值。
先確認是否真的發生 CLR，再判斷 Feature 與 queue 的預期。
來源：Base 2.4 §4.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §8.1.31.1–8.1.31.2 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §4.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §8.1.31.1–8.1.31.2 · NVM Command Set 1.3 §4.1.5.1–4.1.5.4 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q146 Boot Partition 支援、狀態與 Active ID 如何確認？
跟著解說理解
Boot Partition 可讓 Host 在建立 queue 或啟用 controller 前，透過簡化介面讀取開機映像。它不是一般 namespace 的 LBA 區間。
- LBA
- Logical Block Address，邏輯區塊位址
1. 要查哪個對象、哪份資料
支援時有兩個等大的 partitions，ID=0／1；多個 controllers 可能共用它們。
先讀 CAP.BPS，再讀 BPINFO 的 ABPID、BPSZ、BRS；保護能力看 Identify.BPC，支援時也可讀 Boot Partition Log15h。
BPMBL 提供 Host buffer 位址，BPRSEL 指定 BPID、讀取 offset 與大小；BPINFO.BRS 回報進行中、成功或錯誤。
2. 查詢順序與回覆判讀
配置實體連續 buffer，確認沒有讀取進行中，設定位址與讀取選擇，再等待 BRS 完成。讀取中不得 Reset、Shutdown 或變更相關傳輸屬性。
BRS=10b 表示要求內容已傳到 buffer；11b 表示傳輸錯誤。這個 Register 讀取流程沒有 NVMe CQE。
3. 重設或斷電時，要確認什麼
| 觸發方式 | 這項操作或狀態會如何變化 |
|---|---|
| Controller Reset 後是否保留或繼續？ | Boot Partition 內容不是隨 CLR 清除的 queue 資料；但 Host 不得在 Register 讀取進行中執行 Reset。重設後重新檢查屬性與 BRS，不能沿用未完成讀取的成功假設。 |
4. 證據不足或不一致時怎麼判斷
不要為 BPRSEL 寫入指定 Invalid Field CQE。Log 路徑才按 Get Log Page 的參數與完成規則判讀。
將 CAP、ABPID、size、BRS 與實際讀回內容一起確認，不能只靠 ABPID 就宣告映像有效。
先確認使用 Register 還是 Log 讀取介面，避免混用 offset、完成與錯誤表示。
5. 回報方式與共享對象
Register 讀取流程沒有 CQE，因此沒有 DNR／More；若使用 LID15h 則解讀該 Get Log Page 的 CQE。
- DNR
- Do Not Retry，命令重試的狀態提示
Register 路徑以 BPINFO.BRS 回報讀取狀態，不會產生 Firmware Slot Log 更新。Get Log Page 路徑則回傳選定 Boot Partition 的資料；讀取失敗依其 CQE 與錯誤記錄條件判斷。
多個 controllers 可共用 Boot Partitions。查詢時確認目前 controller 的 CAP、BPINFO 與共享關係，不以某台 controller 的讀取完成推論其他台的獨立 buffer 也已完成。
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §3.1.4 (BPINFO, BPRSEL, BPMBL) · Base 2.4 §5.2.13.1.21 · Base 2.4 §5.2.30.1.39 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §3.1.4 (BPINFO, BPRSEL, BPMBL) · Base 2.4 §5.2.13.1.21 · Base 2.4 §5.2.30.1.39 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q147 Boot Partition 如何下載、提交與切換 Active？
跟著解說理解
兩個 partitions 讓 Host 可以先更新非 Active 的一份，讀回確認後才切換，減少中斷更新造成不可用開機映像的風險。
1. 操作前先準備什麼
BPID 指定要寫入或標為 Active 的 partition；保護狀態必須由所有共享它的 controllers 一致執行。
確認 CAP.BPS、BPC、目前 ABPID 與有效保護機制；FID85h 與 RPMB 不一定同時掌控狀態。
先用 Firmware Image Download 依序送整份映像；Commit CA6 寫入 BPID，CA7 才標為 Active 並更新 ABPID。
2. 先後順序與完成條件
完成下載，解除目標寫入鎖定，CA6 提交，讀回驗證，CA7 切換，最後恢復合適的寫入保護。
CA6 成功表示寫入該 partition；不代表 ABPID 已切換。CA7 成功後再確認 ABPID。
3. 未符合條件時如何處理
被鎖定而嘗試改寫時回 Boot Partition Write Prohibited。寫入中 Reset／斷電可能留下新舊混合內容，不能直接標為 Active。
分別比較下載內容、讀回內容及 ABPID，避免「切換成功」掩蓋「映像內容錯誤」。
4. 回報方式與共享對象
以 Commit CQE、BPINFO.ABPID、Boot Partition 讀回資料及 FID85h 核對更新。一般 Firmware Slot Information 描述 firmware slots，不是 Boot Partition 映像清單。
Boot partitions 可由多個 controllers 共用；更新與保護需要在所有共享者之間協調，不能只鎖住一條 Host 路徑。
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §5.2.30.1.39 · Base 2.4 §3.1.4 (BPINFO, BPRSEL, BPMBL) · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §5.2.30.1.39 · Base 2.4 §3.1.4 (BPINFO, BPRSEL, BPMBL) · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q148 Boot Partition 更新與 Controller Firmware 更新有何不同？
跟著解說理解
Boot Partition 保存供 Host 開機使用的映像；controller firmware 是 SSD controller 執行的程式。共用下載命令，不代表用途、順序與啟用方式相同。
1. 差別在哪裡
Boot 用 BPID0／1；firmware 用 slots1～7 與 domain 範圍。兩者不是同一份儲存清單。
Firmware Download 可亂序，CA0～3 管理保存與啟用；Boot Download 必須依序，CA6／7 管理替換與 Active ID。
2. 如何選擇與確認
Boot 看 CAP.BPS／BPC／BPINFO；firmware 看 OACS／FRMW／MTFA 與 LID03h。
先決定更新對象，再選對能力、下載順序、Commit Action 與驗證方法。不要交錯兩種更新流程。
Firmware 成功以 running FR／slot 驗證；Boot 成功以內容及 ABPID 驗證。更新 Boot 不要求 Identify.FR 改變。
3. 重設或斷電時，要確認什麼
| 觸發方式 | 這項操作或狀態會如何變化 |
|---|---|
| Controller Reset 後是否保留或繼續？ | CLR 會丟棄尚未 Commit 的暫存下載。已 Commit 的 firmware 按 CA 與所需 reset 啟用；Boot 寫入中斷則可能留下混合內容，需重新讀回確認。 |
| Power Cycle 後是否保留或繼續？ | Firmware 啟用中失電後需查實際執行映像及可能的回復結果；Boot Commit 失電可留下新舊混合內容。兩者都不能只因重新上電就宣告更新成功。 |
4. 比較時要保留的條件
Boot Commit 斷電可能混合新舊內容；Firmware load failure 有回復映像的規則。不能將其中一套保證套到另一套。
測試報告按對象記錄狀態與持久性，避免把 CA7 的 Active 與 firmware CAFS 混為一談。
5. 回報方式與共享對象
不經 Reset 的 controller firmware 啟用，依啟用設定回報 Firmware Activation Starting；Boot CA6／CA7 不屬於這種啟用，不要求相同通知。
Firmware 更新讀 LID03h 與 Identify.FR；Boot 更新讀 ABPID、內容與保護狀態。失敗時各自保留 Commit CQE 及可關聯的 Error Information。
Firmware 以共享 slot 的 Domain 為主要範圍；Boot 以共享該 partition 的 controllers 為範圍。更新時先找出所有共用者，不能只協調提交命令的那條路徑。
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §5.2.30.1.39 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §8.1.3–8.1.3.3.3 · Base 2.4 §5.2.30.1.39 · Base 2.4 §3.11–3.11.1, 5.2.9–5.2.10 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.2.1 · Base 2.4 §5.2.13.1.14.2.2, 5.2.13.1.14.2.4 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
共用規則：各題連到的完整解釋
這些規則在本冊只完整說明一次。返回剛才的題目可用瀏覽器「上一頁」；特定命令或 Feature 的明文例外優先。
本主題的共用條件 · 是否產生 Asynchronous Event？
開始不經 Reset 的韌體啟用時，受影響 controller 在 Firmware Activation Notices 啟用下回報 Firmware Activation Starting。載入失敗另有 Firmware Image Load Error；Download 每一段成功不會各自觸發啟用通知。
原文定位與既有圖表判讀
Base 的文件頁碼等於 PDF 頁碼減 26；NVM 與 PCIe 兩份規格的文件頁碼則與 PDF 頁碼相同。以下依提供的 PDF 本文列出章節、頁碼及 Figure 編號。若同一頁包含其他主題，只引用本題需要的定義，不納入 Fabrics 或 PCIe Link、封包內容。
- Base 2.4 · §3.1.4 (CC, CSTS, NSSR)
文件頁 60–66 · PDF 86–92 · Figure 41–43 - Base 2.4 · §3.1.4 (BPINFO, BPRSEL, BPMBL)
文件頁 69–70 · PDF 95–96 · Figure 49–51 - Base 2.4 · §3.7.1–3.7.4
文件頁 120–124 · PDF 146–150 - Base 2.4 · §3.11–3.11.1, 5.2.9–5.2.10
文件頁 135–138, 202–206 · PDF 161–164, 228–232 · Figure 187–193 - Base 2.4 · §4.2.3
文件頁 145–155 · PDF 171–181 · Figure 101–105 - Base 2.4 · §4.4
文件頁 166–169 · PDF 192–195 · Figure 126–127 - Base 2.4 · §5.2.2
文件頁 183–190 · PDF 209–216 · Figure 150–156 - Base 2.4 · §5.2.2 (PCIe-applicable events)
文件頁 183–191 · PDF 209–217 · Figure 150–160 - Base 2.4 · §5.2.13.1.2
文件頁 218–220 · PDF 244–246 · Figure 212 - Base 2.4 · §5.2.13.1.4
文件頁 225–226 · PDF 251–252 · Figure 215 - Base 2.4 · §5.2.13.1.6
文件頁 226–229 · PDF 252–255 · Figure 216–217 - Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
文件頁 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253 - Base 2.4 · §5.2.13.1.14.2.2, 5.2.13.1.14.2.4
文件頁 252–255 · PDF 278–281 · Figure 238, 240–241 - Base 2.4 · §5.2.13.1.21
文件頁 283–284 · PDF 309–310 · Figure 279–280 - Base 2.4 · §5.2.14.2.1
文件頁 340–387 · PDF 366–413 · Figure 338–341 - Base 2.4 · §5.2.30.1.6
文件頁 466–468 · PDF 492–494 · Figure 474 - Base 2.4 · §5.2.30.1.39
文件頁 512–514 · PDF 538–540 · Figure 542 - Base 2.4 · §8.1.3–8.1.3.3.3
文件頁 586–592 · PDF 612–618 · Figure 679–683 - Base 2.4 · §8.1.31.1–8.1.31.2
文件頁 737–738 · PDF 763–764 · Figure 782 - NVM Command Set 1.3 · §4.1.5.1–4.1.5.4
文件頁 84–107 · PDF 84–107 · Figure 123–130
需要看欄位圖時
以下連結可開啟對應的圖表教學，查閱欄位及判讀方式。每張圖保留固定的教學位置，方便之後反覆查詢。
- Base 2.4 Figure 101 · Completion Queue Entry: Status Field
- Base 2.4 Figure 104 · Status Code – Command Specific Status Values
- Base 2.4 Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
- Base 2.4 Figure 41 · Offset 14h: CC – Controller Configuration
- Base 2.4 Figure 42 · Offset 1Ch: CSTS – Controller Status
- NVM Command Set 1.3 Figure 123 · Identify – Identify Namespace Data Structure, NVM Command Set
使用的原始文件
- NVM Express Base Specification · Revision 2.4 · 2026-07-31
NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf - NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf - NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf
Comments