NVMe Base 2.4：Firmware Update 與 LID 03h 驗證

00.01.韌體更新包含傳送映像、保存至 slot 與切換執行版本。這篇說明 Firmware Image Download、Firmware Commit 和 Firmware Slot Information 如何一起完成這件事，並分清楚每一步改變了什麼狀態。

這篇的主軸

能力與更新單位

01-01確認可用 slots、寫入限制及下載片段的粒度。

下載與啟用

02-01理解映像範圍、Commit Action 與 reset 的關係。

執行版本

03-01以目前與預定 active slot 區分已保存和正在執行的版本。

00.02.Firmware slot 是保存韌體映像的位置；有版本字串不代表該映像正在執行。控制器的能力查詢、命令完成與 slot 資訊必須分別理解。

把主軸連起來

00.03.更新韌體可分成能力確認、映像傳輸、保存與啟用、結果確認。這個順序連接了 Identify 的能力資訊、Download 的長度與偏移、Commit 的選擇，以及 LID 03h 的目前與待啟用版本。

LID 03h: Firmware Slot Information log page 的 identifier 03h。
LID: Log Page Identifier；指定要讀取哪一種 log page 的編號。

00.04.本篇只以 Firmware Slot Information 完成更新結果的閱讀，不延伸成所有 log 的介紹。學完應能解釋為什麼下載成功還不等於新版本正在執行，並能用實際的分段長度與 slot 狀態走完一個例子。

01 更新前的能力與限制

01.01.Firmware update 不是固定 command recipe。FRMW 決定 slot 與 activation 能力，FWUG 決定 download chunk 的 granularity／alignment，MTFA 與 MPTFAWR 決定 host 能等待多久，MDS／DID 則決定結果影響哪一組 controllers。

MPTFAWR: Maximum Processing Time for Firmware Activation Without Reset，立即 activation 不需要 reset 時的最大處理時間。
FRMW: Firmware Updates，Identify Controller 中回報 slot 數、slot 1 read-only 與 activation 能力的欄位。
FWUG: Firmware Update Granularity，download portion 的 granularity／alignment 能力欄位。
Host: 主機；執行作業系統並送出 NVMe 命令的一端。
MTFA: Maximum Time for Firmware Activation，activation 可能暫停 command processing 的最長時間。
DID: Domain Identifier，辨識 NVM subsystem 內 domain 的 identifier。
MDS: Multiple Domain Subsystem，指出 NVM subsystem 是否包含多個 domains 的能力 bit。

01.02.FRMW 的 SMUD、FAWR、NOFS 與 FFSRO 分別表示重疊 update 偵測、免 reset activation、domain 支援的 slot 數（1 到 7）以及 slot 1 是否 read-only。

來源：Base 2.4 §5.2.14.1

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 354, PDF 頁 380

更新前的能力與限制
更新能力	決定哪項選擇	何時使用這項資訊
FRMW	可用 slots、slot 1 read-only、activation 能力	選 FS 與 CA 前先讀
FWUG	download portion 的粒度與對齊	先換成 bytes，再切 image
MTFA／MPTFAWR	可能暫停與立即 activation 的時間界線	timeout 不可寫死
MDS／DID	firmware slots 的共享 domain	不可只用 PCI Function 當 scope

portion: 傳輸分段；一次 firmware download 所送的一段連續資料。
CA: Commit Action，Firmware Commit 中選擇 replace、activate 與 reset policy 的欄位。
FS: Firmware Slot，Firmware Commit 中選擇目標 slot 的欄位。

02 Download 的長度、偏移與分段

02.01.Firmware Download 的 NUMD 是 zero-based 長度，OFST 是從 image 起點計算的 dword offset。用 index-offset 對比來讀：index 選哪個項目，offset 表示離起點多遠；兩個數值都不能脫離欄位定義換算。

index-offset: index-offset 對比；index 選取項目，offset 計算位置。例如從 0 起算的 Format Index=2 選第 3 個格式，而 OFST=256 表示從 image 起點位移 256 個 Dwords。
zero-based: zero-based；數值從 0 開始計算，因此 raw=3 代表第 4 個項目或 4 個單位，實際含義仍要看欄位定義。
offset: offset；從指定起點算出的位移。它回答「離起點多遠」，不等於 index。
Dword: Dword（Double word）；32 bits，也就是 4 bytes。對比 word=16 bits；例如 zero-based dword count=3 代表 4 個 Dwords，也就是 16 bytes。
index: index；用來選取清單中的項目或格式。它回答「選哪一項」，不是「離起點多遠」。
NUMD: Number of Dwords，0's-based transfer dword count；實際 bytes = (NUMD + 1) × 4。
OFST: Offset，Firmware Image Download 中以 dword 為單位的 image-relative offset。

02.02.Firmware Image Download 可分成多個 portions，firmware image portions 可不依序送達；host 宜（should）避免 ranges 重疊並符合 FWUG。Boot Partition portions 則必須（shall）依序提交。

來源：Base 2.4 §5.2.10

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, 文件頁 205-206, PDF 頁 231-232

Download 的長度、偏移與分段
傳輸欄位	描述哪段位置或長度	從 bytes 如何換算
DPTR	本筆 transfer 的 host buffer	地址有效不代表 length 正確
NUMD	本筆 dword 數的 0's-based encoding	4096 bytes → 1024 dwords → 03FFh
OFST	image 起點的 dword offset	第二個 4 KiB portion 為 1024 dwords
FWUG	每段映像的起點對齊與長度粒度要求	全 image 與每筆 portion 分開檢查

0's-based: 0's-based encoding，以 0 表示實際數量 1；依欄位換算公式通常是欄位值加 1。
DPTR: Data Pointer，SQE 中指出 command data buffer 的欄位。

03 Commit 的儲存與啟用選擇

03.01.Commit Action（CA）不是成功／失敗旗標；它同時決定 replace、activate 與 reset boundary。Firmware Slot（FS）選擇目標 slot，CQE status 決定下一步是驗證、執行特定 reset、等待，還是停止。

CQE: Completion Queue Entry，CQ 中的一筆完成結果資料結構。

下載、保存與啟用分別改變什麼

Firmware Image Download：傳送映像的各個片段。
Firmware Commit：依 CA 選擇保存至 slot 與啟用方式。
需要 reset 的啟用：在指定 reset 發生後切換執行版本。
Firmware Slot Information：分開查看目前執行 slot 與下次預定 slot。

下載完成、映像已保存、版本正在執行，是不同狀態。

03.02.Firmware Commit 驗證最後下載的 image、把它放入 firmware slot，並依 Commit Action 決定只放置、在後續 Controller Level Reset activation，或立即 activation。成功 commit 不等於當下已 active。

來源：Base 2.4 §5.2.9

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 202-203, PDF 頁 228-229

Commit 的儲存與啟用選擇
Commit 欄位或結果	選擇或確認的動作	如何判斷啟用階段
CA	replace 與 activation 行為	不可只記十進位值
FS	目標 firmware slot	0 可能代表 controller 選 slot，依定義判讀
SCT／SC	成功、reset scope 或失敗原因	0Bh、10h、11h 的 reset scope 不同
MUD	重疊 update sequence 證據	即使 abort 也可能有效

controller: controller，實作 NVMe 介面、取走 command 並回報 completion 的控制實體。
MUD: Multiple Update Detected，completion 中指出 controller 偵測到 overlapping firmware update sequence 的 bit。
SCT: Status Code Type；指定完成狀態碼所屬類別，需與 SC 一起解讀。
SC: Status Code；指定所選 SCT 類別中的完成結果。

04 LID 03h 的目前與待啟用版本

04.01.Get Log Page 先用 common command 欄位建立 512-byte transfer，再以 LID=03h 選 Firmware Slot Information。AFI 同時拆成 CAFS 與 NAFS，FRS1-FRS7 表示各 slots 的 revision；最後還要用 Identify.FR 與 domain scope 交叉確認。

CAFS: Current Active Firmware Slot，AFI 低三 bits，指出目前正在執行的 firmware slot。
NAFS: Next Active Firmware Slot，AFI bits 6:4，指出下一次 reset 後預定啟用的 slot；0 表示未排定。
AFI: Active Firmware Info，LID 03h 中同時包含目前 active slot 與下一次 reset 後預定 active slot 的 byte。

04.02.讀 LID 03h 時，未使用 namespace，因此 NSID 必須（shall）為 0h；DPTR 以 PRP 指向 512-byte destination buffer。必要的 CDW10-CDW14 slice 為 LID=03h、LSP=0、RAE=0、NUMDL/NUMDU 表示 512 bytes、LSI=0、LPOL/LPOU=0、OT=0、UIDX=0；CSI 對 LID 03h 不使用，controller 依 Figure 208 規則忽略。

namespace: namespace，主機透過 controller 存取的一份已格式化非揮發性容量。
NUMDL: Number of Dwords Lower，Get Log Page 的 NUMD 低 16 bits。
NUMDU: Number of Dwords Upper，Get Log Page 的 NUMD 高 16 bits。
LPOL: Log Page Offset Lower，Get Log Page byte offset 的低 32 bits。
LPOU: Log Page Offset Upper，Get Log Page byte offset 的高 32 bits。
NSID: Namespace Identifier，controller 用來指向 namespace 的數值 handle；identifier 不等於 namespace 物件本身。
UIDX: UUID Index，指向 UUID List 位置的 index；0 表示未指定 UUID。
CDW: CDW（Command Dword）；命令中的 32-bit 欄位單位，例如 CDW10 的 10 是欄位 index，不是 byte offset。
CSI: I/O Command Set Identifier；選擇 I/O 命令集，NVM Command Set 使用 00h。
LSI: Log Specific Identifier，意義由所選 log page 定義的 identifier。
LSP: Log Specific Field，意義由所選 log page 定義的 command selector。
PRP: Physical Region Page，以 memory page 為單位描述 host-addressable data buffer 的 pointer 格式。
RAE: Retain Asynchronous Event，Get Log Page 是否保留相關 asynchronous event 的 selector。

來源：Base 2.4 §4.1.1, 5.2.13

來源：NVME-BASE-2.4, Rev. 2.4, §4.1.1, 5.2.13, 文件頁 140-142, 212-215, PDF 頁 166-168, 238-241

LID 03h 的目前與待啟用版本
版本或 slot 欄位	描述哪個時點	如何與其他欄位對照
CAFS	目前執行中的 slot	它不是 next-reset intent
NAFS	下一個 reset 後預定 active slot	0 表示未排定
FRSx	slot x 的 8-byte revision	全 0h 不是 ASCII 字串
Identify.FR	目前 active revision 的獨立觀察	與 CAFS 對應 FRSx 交叉確認

接著打開 Spec 看什麼

05.01.以下按概念列出閱讀位置。報告時先用上面的流程說明問題，再打開對應章節看欄位與完整條件。中文教學 HTML 另有本篇全部圖表的逐圖重點、案例與細節。

要說明的觀念	Spec 閱讀位置
更新前的能力與限制	Base 2.4 §5.2.14.1
Download 的長度、偏移與分段	Base 2.4 §5.2.10 · Base 2.4 §4.1.1, 5.2.10
Commit 的儲存與啟用選擇	Base 2.4 §5.2.9
LID 03h 的目前與待啟用版本	Base 2.4 §4.1.1, 5.2.13 · Base 2.4 §5.2.13 · Base 2.4 §5.2.13.1.4 · Base 2.4 §5.2.14.1

開啟完整中文教學與逐圖解釋 →

學完後想一想

1. Firmware Image Download 完成後，controller 是否已執行新韌體？

06.01.Download 是傳送 image；Commit 才依 action 決定保存或啟用，且啟用可能需要指定 reset。要結合 Commit 結果與 slot 資訊確認目前執行版本。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, 文件頁 205-206, PDF 頁 231-232

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 202-203, PDF 頁 228-229

2. NUMD=255 與 OFST=256 分別描述什麼？

06.02.NUMD 是 zero-based dword 長度，表示這次傳送 256 dwords，也就是 1024 bytes；OFST 是從 image 起點算的 dword offset，表示起點在 1024 bytes。相同數量附近的值，編碼用途不同。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §4.1.1, 5.2.10, 文件頁 140-142, 205-206, PDF 頁 166-168, 231-232

3. 某 slot 的 FRS 顯示新版本，能否單憑這一點宣告它正在執行？

06.03.FRS 描述 slot 中的 revision；還需看 active slot 與 next-active slot 資訊。已儲存、目前執行和下次啟用可以指向不同狀態。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, 文件頁 226, PDF 頁 252

4. 為何不能總把 firmware update 視為單一 controller 的私有變更？

06.04.Firmware 的作用範圍可能涉及共用的 domain 或 NVM subsystem 資源。先建立 controller 與更新範圍的關係，才能理解其他 controllers 受到的影響。

來源

來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 202, PDF 頁 228

Jia-Chang

Human

Comments

Write a comment ...