能力與更新單位
01-01確認可用 slots、寫入限制及下載片段的粒度。
NVMe · 規格與原理
NVMe Base 2.4：Firmware Update 與 LID 03h 驗證
00.01.韌體更新包含傳送映像、保存至 slot 與切換執行版本。這篇說明 Firmware Image Download、Firmware Commit 和 Firmware Slot Information 如何一起完成這件事，並分清楚每一步改變了什麼狀態。
這篇的主軸
下載與啟用
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.韌體更新前，主機需要知道裝置提供幾個 slot、哪些 slot 可以寫入，以及新映像可以如何啟用。Slot 是保存映像的位置，active slot 才是目前執行的版本。即使裝置提供多個位置，也不能直接假設 slot 1 可覆寫或任何映像都可以立即啟用。
01.02.傳輸安排還要考慮粒度與時間限制。FWUG 約束映像片段的大小和對齊，啟用時間欄位則描述不同階段允許的時間。若多個控制器共用同一個 firmware domain，更新計畫也要以共享範圍理解，不能把每個 PCIe Function 都當成互不相關的韌體副本。
- FWUG
- Firmware Update Granularity，download portion 的 granularity／alignment 能力欄位。
- PCIe
- PCI Express，NVMe memory-based controller 使用的 transport 與裝置互連。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 354, PDF 頁 380
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 359, PDF 頁 385
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 357, PDF 頁 383
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 364, PDF 頁 390
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 346, 364, PDF 頁 372, 390
把流程對回規格條件
01.03.FRMW 的 SMUD、FAWR、NOFS 與 FFSRO 分別表示重疊 update 偵測、免 reset activation、domain 支援的 slot 數（1 到 7）以及 slot 1 是否 read-only。
- FRMW
- Firmware Updates，Identify Controller 中回報 slot 數、slot 1 read-only 與 activation 能力的欄位。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 354, PDF 頁 380
01.04.FWUG 以 4 KiB 為單位限制 NUMD 與 OFST 的 granularity／alignment：1h=4 KiB、2h=8 KiB、0h=未提供資訊、FFh=可用任何 dword granularity 與 alignment。違反時 controller 可（may）回 Invalid Field in Command。
- controller
- controller，實作 NVMe 介面、取走 command 並回報 completion 的控制實體。
- Dword
- Dword（Double word）；32 bits，也就是 4 bytes。對比 word=16 bits；例如 zero-based dword count=3 代表 4 個 Dwords，也就是 16 bytes。
- NUMD
- Number of Dwords，0's-based transfer dword count；實際 bytes = (NUMD + 1) × 4。
- OFST
- Offset，Firmware Image Download 中以 dword 為單位的 image-relative offset。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 359, PDF 頁 385
01.05.MTFA 以 100 ms 為單位，表示 activation 時 controller 暫停處理 commands 的最長時間；支援免 reset activation 時此欄位必須（shall）有效，0h 表示最大時間未定義。
- MTFA
- Maximum Time for Firmware Activation，activation 可能暫停 command processing 的最長時間。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 357, PDF 頁 383
01.06.MPTFAWR 以 100 ms 為單位，估算 CA=011b 的 Firmware Commit 從處理到完成所需最大時間，且包含把 image commit 到 slot 的時間；不支援免 reset activation 時必須（shall）為 0h。
- MPTFAWR
- Maximum Processing Time for Firmware Activation Without Reset，立即 activation 不需要 reset 時的最大處理時間。
- CA
- Commit Action，Firmware Commit 中選擇 replace、activate 與 reset policy 的欄位。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 364, PDF 頁 390
01.07.CTRATT.MDS 判斷 LID 03h 回傳 domain scope 還是整個 NVM subsystem scope；CTRATT.ULIST 判斷 controller 是否支援 UUID List reporting。MDS=1 時 DID 必須（shall）非零；single-domain subsystem 的 DID 必須（shall）為 0h。
- NVM subsystem
- NVM subsystem，包含 controller、port、namespace 與非揮發性儲存資源的 NVMe 系統邊界。
- ULIST
- UUID List，指出 controller 是否支援 UUID List data structure 的能力 bit。
- UUID
- Universally Unique Identifier，128-bit identifier；其實際關聯範圍仍由使用它的資料結構決定。
- DID
- Domain Identifier，辨識 NVM subsystem 內 domain 的 identifier。
- MDS
- Multiple Domain Subsystem，指出 NVM subsystem 是否包含多個 domains 的能力 bit。
- NVM
- Non-Volatile Memory，斷電後仍能保存資料的記憶體。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 346, 364, PDF 頁 372, 390
| 更新能力 | 決定哪項選擇 | 何時使用這項資訊 |
|---|---|---|
| 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 所送的一段連續資料。
- FS
- Firmware Slot，Firmware Commit 中選擇目標 slot 的欄位。
02 Download 的長度、偏移與分段
完整映像與每次傳輸使用不同座標
先排好映像中的區段
02.01.以 16 KiB 映像、每次 4 KiB 傳輸為例，需要 4 次 Download。每次 DPTR 指向這次可讀的主機 buffer；OFST 則始終相對完整映像的起點。
- DPTR
- Data Pointer，SQE 中指出 command data buffer 的欄位。
分開換算位置與數量
02.02.每段長度 4096 bytes 等於 1024 Dwords，因此 NUMD=1023；四段 OFST 依序是 0、1024、2048、3072。OFST 沒有減 1，不能照 NUMD 的數量編碼方式計算。
把粒度及命令大小限制套回計畫
02.03.實際分段還要符合 FWUG、最大傳輸量與來源規定的順序及不重疊條件。分段成功只證明這些資料已傳入，下一步仍需 Commit 決定保存及啟用。
來源：Base 2.4 §5.2.10 · Base 2.4 §4.1.1, 5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, 文件頁 205-206, PDF 頁 231-232
來源：NVME-BASE-2.4, Rev. 2.4, §4.1.1, 5.2.10, 文件頁 140-142, 205-206, PDF 頁 166-168, 231-232
把流程對回規格條件
02.05.Firmware Image Download 可分成多個 portions，firmware image portions 可不依序送達；host 宜（should）避免 ranges 重疊並符合 FWUG。Boot Partition portions 則必須（shall）依序提交。
- Host
- 主機；執行作業系統並送出 NVMe 命令的一端。
來源：Base 2.4 §5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, 文件頁 205-206, PDF 頁 231-232
02.06.NVMe over PCIe 的 Admin command 不得使用 SGL，因此 DPTR 以 PRP 指向本次來源 buffer；NUMD 是 0's-based dword count，所以 bytes=(NUMD+1)×4；OFST 是距 image 起點的 dword offset，所以 byte offset=OFST×4。包含 image 起點的 portion 必須（shall）令 OFST=0h。
- 0's-based
- 0's-based encoding，以 0 表示實際數量 1；依欄位換算公式通常是欄位值加 1。
- offset
- offset；從指定起點算出的位移。它回答「離起點多遠」，不等於 index。
- Admin
- Administrative，建立、設定、查詢或管理 controller 與 queue 的控制路徑。
- NVMe
- Non-Volatile Memory Express，主機與非揮發性記憶體子系統之間的介面規範家族。
- PRP
- Physical Region Page，以 memory page 為單位描述 host-addressable data buffer 的 pointer 格式。
- SGL
- Scatter Gather List，以 descriptor 與 segment 描述一段或多段 data buffer 的格式。
來源：Base 2.4 §4.1.1, 5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §4.1.1, 5.2.10, 文件頁 140-142, 205-206, PDF 頁 166-168, 231-232
| 傳輸欄位 | 描述哪段位置或長度 | 從 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 分開檢查 |
03 Commit 的儲存與啟用選擇
03.01.映像下載完成後，Commit 才決定如何保存和啟用。CA 指定動作，FS 指定 slot；不同動作可能只保存、安排後續啟用，或依能力執行不需重設的啟用。因此 Download 的完成資訊，無法取代 Commit 的結果。
03.02.某些完成狀態是在告訴主機還需要哪一種重設才能啟用映像，不能一概解讀成映像內容無效。反過來，slot 已經保存新版本，也不表示目前正在執行它。應把傳輸完成、slot 內容和 active 版本放在時間線上分別確認。
來源：Base 2.4 §5.2.9
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 202-203, PDF 頁 228-229
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 203, PDF 頁 229
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 204, PDF 頁 230
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 204-205, PDF 頁 230-231
- Firmware Image Download：傳送映像的各個片段。
- Firmware Commit：依 CA 選擇保存至 slot 與啟用方式。
- 需要 reset 的啟用：在指定 reset 發生後切換執行版本。
- Firmware Slot Information：分開查看目前執行 slot 與下次預定 slot。
把流程對回規格條件
03.03.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
03.04.CDW10[5:3] 是 CA，CDW10[2:0] 是 FS。CA 000b 只放置；001b 放置並排定下次 CLR activation；010b 排定既有 slot；011b 立即 activation。FS=0h 時 controller 必須（shall）在 slot 1 到 7 中選一個。
- CDW
- CDW（Command Dword）；命令中的 32-bit 欄位單位，例如 CDW10 的 10 是欄位 index，不是 byte offset。
來源：Base 2.4 §5.2.9
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 203, PDF 頁 229
03.05.Firmware Commit CQE.DW0[1:0] 的 MUD 分別回報 Management Endpoint 與 Admin Submission Queue 偵測到的 overlap。若 FRMW.SMUD=0，MUD 必須（shall）為 00b；MUD 在 command 成功或 aborted 時都有效。
- CQE
- Completion Queue Entry，CQ 中的一筆完成結果資料結構。
- MUD
- Multiple Update Detected，completion 中指出 controller 偵測到 overlapping firmware update sequence 的 bit。
來源：Base 2.4 §5.2.9
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 204, PDF 頁 230
03.06.Firmware Commit 的 command-specific status 區分 invalid slot／image、需要 Conventional／NVM Subsystem／Controller Level Reset、MTFA violation、activation prohibited、overlapping range、Boot Partition write prohibited 與 personality incompatibility。
來源：Base 2.4 §5.2.9
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 204-205, PDF 頁 230-231
| Commit 欄位或結果 | 選擇或確認的動作 | 如何判斷啟用階段 |
|---|---|---|
| CA | replace 與 activation 行為 | 不可只記十進位值 |
| FS | 目標 firmware slot | 0 可能代表 controller 選 slot，依定義判讀 |
| SCT／SC | 成功、reset scope 或失敗原因 | 0Bh、10h、11h 的 reset scope 不同 |
| MUD | 重疊 update sequence 證據 | 即使 abort 也可能有效 |
- SCT
- Status Code Type；指定完成狀態碼所屬類別，需與 SC 一起解讀。
- SC
- Status Code；指定所選 SCT 類別中的完成結果。
04 LID 03h 的目前與待啟用版本
用兩次觀察辨認「已保存」與「正在執行」
先保留目前版本所在的 slot
04.01.更新前讀 AFI 與各 FRS，記下目前 active slot。不要只保存某個非空版本字串，因為非 active slot 也可能早已放著另一個映像。
- AFI
- Active Firmware Info，LID 03h 中同時包含目前 active slot 與下一次 reset 後預定 active slot 的 byte。
- FRS
- Firmware Revision for Slot，LID 03h 中每個 slot 的八-byte revision 字串欄位。
Commit 後依回覆辨認啟用時機
04.02.若所選動作需要 reset，這時新映像已保存也可能仍執行原版本。回覆指出的 reset 類型決定切換事件，不能把任何 reset 都當成等價。
切換後再核對 active 與版本
04.03.重新查詢 AFI，找到真正 active slot，再讀該 slot 的 FRS。這種對照才能回答新版本是否已在執行，而不只是映像是否已存在。
來源：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
來源：NVME-BASE-2.4, Rev. 2.4, §4.1.1, 5.2.13, 文件頁 140-142, 212-215, PDF 頁 166-168, 238-241
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, 文件頁 213-215, PDF 頁 239-241
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, 文件頁 215-216, PDF 頁 241-242
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, 文件頁 226, PDF 頁 252
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 340, PDF 頁 366
把流程對回規格條件
04.05.讀 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。
- 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。
- 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
04.06.NUMDL 與 NUMDU 合成 0's-based dword count。LID 03h 固定 512 bytes=128 dwords，因此 NUMD=127=0000007Fh，NUMDL=007Fh、NUMDU=0000h；在 LSP=0、RAE=0 下，CDW10=007F0003h。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, 文件頁 213-215, PDF 頁 239-241
04.07.Figure 209 的 LID 03h row 指定 CSI=N、scope=Domain／NVM subsystem、reference=§5.2.13.1.4。MDS=1 時回傳處理 command 之 controller 所屬 domain；否則回傳整個 NVM subsystem 的資訊。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, 文件頁 215-216, PDF 頁 241-242
04.08.byte 0 的 AFI 中，NAFS=bits 6:4、CAFS=bits 2:0；bits 7 與 3 reserved。NAFS 非零表示將於下一次能觸發 activation 的 CLR 啟用該 slot，NAFS=0 表示 controller 未指出 next slot；CAFS 是目前執行 image 的來源 slot。
- CAFS
- Current Active Firmware Slot，AFI 低三 bits，指出目前正在執行的 firmware slot。
- NAFS
- Next Active Firmware Slot，AFI bits 6:4，指出下一次 reset 後預定啟用的 slot；0 表示未排定。
來源：Base 2.4 §5.2.13.1.4
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, 文件頁 226, PDF 頁 252
04.09.FRS1 到 FRS7 位於 bytes 8-63，每格 8 bytes；slot 沒有有效 revision 或不支援時，該 FRS 必須（shall）清為 0h。bytes 1-7 與 64-511 reserved。
來源：Base 2.4 §5.2.13.1.4
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, 文件頁 226, PDF 頁 252
04.10.Identify Controller 的 FR 是目前 active firmware revision 的 8-byte ASCII string，scope 是 controller 所屬 domain；它與 LID 03h 回報的目前 revision 資訊相同。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, 文件頁 340, PDF 頁 366
| 版本或 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 交叉確認 |
05 讀懂本篇的規格圖表
05.01.以下依概念整理規格中的圖表。每組先說明讀取順序與要判斷的問題，接著列出各圖的欄位或行為說明。可以由正文的連結跳到對應組別，也可以用這一節檢查自己能否把欄位連回完整操作。
圖表組 01 · 更新前的能力與限制 · 2 張圖表
05.02.從 Identify 的 FRMW 選可用 slot 與啟用方式，再讀 FWUG 和相應時間欄位。Domain 關係圖回答哪些控制器共享 slots；它不能由單一 PCIe Function 編號推得。
回到本節的解釋與範例辨認識別碼的格式、有效範圍與用途
05.03.識別碼、文字欄位與清單索引需要不同解讀方式。先讀來源定義的長度與編碼，再決定要比較整個值、拆出廠商部分，或沿清單尋找指定物件。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| VID／SSVID／SN／MN | 前兩者識別廠商與子系統廠商，後兩者是序號與型號文字；不能套用相同的數值或字串規則。 | 文字欄位的 padding 與編碼要按定義處理，不將固定長度緩衝區一概當成以零結尾的字串。 |
| OUI／EUI64／NGUID／UUID | 有各自的長度與組成規則；識別物件時保留完整值。 | 僅有相同 OUI 只能說明共同的組成部分，不代表兩個 namespace 相同。 |
| NUMCIDS／Controller List／Namespace List | 數量欄位或清單終止規則決定有效項目；識別碼的合法性另行判斷。 | NUMCIDS=2 表示讀取兩個有效控制器項目，並非最高控制器識別碼是 2。 |
| UIDX／UUID List Entry／IDASSOC | UIDX 選清單項目，項目的識別關聯再決定 UUID 如何使用。 | UIDX=2 是選位置，不是把值 2 當成 128-bit UUID。 |
- NUMCIDS
- Number of Controller Identifiers；Controller List 中有效 controller IDs 的數量。
- EUI64
- 64-bit Extended Unique Identifier，使用 IEEE 配置空間建立的 64-bit identifier。
- NGUID
- Namespace Globally Unique Identifier，namespace 的 128-bit 全域識別值。
- SSVID
- Subsystem Vendor ID，辨識 subsystem vendor 的 PCI identifier。
- OUI
- Organizationally Unique Identifier，由 IEEE 配置給組織的 identifier 前綴。
- VID
- Vendor ID，由 PCI-SIG 配置、辨識 vendor 的 identifier。
- MN
- Model Number，辨識產品型號的字串。
- SN
- Serial Number，辨識一個產品實例的序號字串。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, Figure 337, 文件頁 340, PDF 頁 366
Base Figure 337 · Command Set Identifiers
一句話重點
Base337-1CSI 指定 namespace 使用哪一套 I/O Command Set。
- I/O
- Input/Output，對 namespace 執行資料輸入與輸出的操作類別。
來源：Base 2.4 §5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, Figure 337, 文件頁 340, PDF 頁 366
用例子讀懂
Base337-2CSI＝00h 對應 NVM Command Set；這個數值不是 NSID，也不是某個 Read 操作碼。
把更新策略連到裝置實際提供的能力
05.04.規劃更新時要一起查可用 slot、更新粒度與啟用方式。版本字串只描述目前回報的版本，不能代替能力檢查。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| FR／FRMW.NOFS／FFSRO／FAWR | FR 是版本資訊；NOFS 是 slot 數，FFSRO 說明第一個 slot 的唯讀性，FAWR 描述不需 reset 的啟用能力。 | 有多個 slot 不表示第一個一定可覆寫，也不保證任意映像都能立即啟用。 |
| FWUG／MDTS／MTFA | 更新粒度、最大傳輸量與最大啟用時間涉及不同階段。 | 分段大小先受傳輸與粒度限制；不能把啟用時間 MTFA 拿來算 Download 每段 bytes。 |
| MDS／DID／SMUD／MPTFAWR | 多 domain 的識別、同步更新支援及多次更新後啟用的相關能力，決定是否需要協調多個控制器。 | 存在多個 domain 時，不能只由其中一個 controller 的版本回報推論整個 subsystem 已同步完成更新。 |
來源：Base 2.4 §5.2.14.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 340-364, PDF 頁 366-390
Base Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
一句話重點
Base338-1Identify Controller 先告知能力與限制，主機再決定可使用的操作。
來源：Base 2.4 §5.2.14.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.1, Figure 338, 文件頁 340-364, PDF 頁 366-390
用例子讀懂
Base338-2規格列出某選用命令時，先查相應支援欄位再發出要求；「命令有定義」與「這台控制器支援」是不同證據。
圖表組 02 · Download 的長度、偏移與分段 · 5 張圖表
05.05.把映像畫成連續區間，逐段列出起點 bytes、長度 bytes、OFST 與 NUMD。各段邊界再核對 FWUG；主機 buffer 的 DPTR 不參與映像 offset 的累加。
回到本節的解釋與範例位移、傳輸長度、儲存位置與啟用時機
05.06.Download 把映像分段交給控制器；Commit 再決定保存或啟用。OFST 是映像中的位置，DPTR 是主機資料的位置，FS／BPID 是目標選擇，四者不可互換。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| DPTR／NUMD／OFST／FWUG | DPTR 指資料，NUMD 是 Dword 數量減 1，OFST 是 Dword 位移，FWUG 描述更新粒度。 | 4096 bytes 的一段使用 NUMD=1023；接續下一段的 OFST=1024，再檢查粒度及完整範圍。 |
| CA／FS／BPID | CA 選動作；一般韌體 slot 與 Boot Partition 有不同目標選擇。 | 保存映像成功不代表已切換執行版本；Boot 的寫入與選擇 active partition 也分開。 |
| MUD／MEFWO／ASQFWO；完成狀態 | 結果依支援能力及本次更新操作解讀，reset-required 狀態還指出啟用所需事件。 | 收到要求 reset 的結果後，先辨認所需 reset 類型，再追蹤真正啟用。 |
| AFI.CAFS／NAFS → FRS1–FRS7 | 先找目前 active slot 與下次 active slot，再讀相應版本字串。 | FRS2 有新版本而 CAFS 仍是 1，表示新映像可能已存在，但尚不能說它正在執行。 |
來源：Base 2.4 §5.2.9 · Base 2.4 §5.2.9.1 · Base 2.4 §5.2.10 · Base 2.4 §5.2.13.1.4
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, Figure 187, 文件頁 203, PDF 頁 229
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9.1, Figure 188, 文件頁 204, PDF 頁 230
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9.1, Figure 189, 文件頁 204-205, PDF 頁 230-231
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 190, 文件頁 205, PDF 頁 231
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 191, 文件頁 205, PDF 頁 231
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 192, 文件頁 206, PDF 頁 232
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 193, 文件頁 206, PDF 頁 232
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, Figure 215, 文件頁 226, PDF 頁 252
Base Figure 190 · Firmware Image Download – Data Pointer
一句話重點
Base190-1Firmware Image Download 的 DPTR 指向此次傳入的映像區段。
來源：Base 2.4 §5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 190, 文件頁 205, PDF 頁 231
用例子讀懂
Base190-2分兩次傳映像時，第二次 DPTR 可以指另一段主機 buffer；映像內的目的偏移另由 OFST 指定。
Base Figure 191 · Firmware Image Download – Command Dword 10
一句話重點
Base191-1Firmware Download 的 NUMD 以 Dwords 且從零起算表示長度。
來源：Base 2.4 §5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 191, 文件頁 205, PDF 頁 231
用例子讀懂
Base191-2傳入 4096 bytes 時共有 1024 Dwords，NUMD＝1023；若直接填 4096，單位及編碼都會錯。
Base Figure 192 · Firmware Image Download – Command Dword 11
一句話重點
Base192-1Firmware Download 的 OFST 指定映像中的 Dword 偏移。
來源：Base 2.4 §5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 192, 文件頁 206, PDF 頁 232
用例子讀懂
Base192-2接續前面 4096 bytes 的區段，OFST＝1024；它不是主機記憶體位址，也不是接續區段的 byte 長度。
Base Figure 193 · Firmware Image Download – Command Specific Status Values
一句話重點
Base193-1Overlapping Range 狀態指出傳入的映像區段發生不允許的重疊。
來源：Base 2.4 §5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.10, Figure 193, 文件頁 206, PDF 頁 232
用例子讀懂
Base193-2第一段覆蓋前 4096 bytes，第二段卻又從 byte 2048 開始時，需要按下載規則檢查重疊，不能只核對兩個 buffer 各自長度。
同一筆命令的身分、對象與資料方向
05.07.CDW0 先選操作與資料指標格式；NSID 選操作對象；DPTR／MPTR 再指向資料。命令專屬 Dwords 的含義由 OPC 與命令集決定。
- MPTR
- Metadata Pointer，SQE 中指出獨立 metadata buffer 的欄位。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| OPC／FUSE／CID | OPC 選操作，FUSE 說明融合操作角色，CID 讓完成項目找回原命令。 | 相同的 CDW10 數值放在 Read 與 Set Features 中，可能完全不是同一種意思。 |
| PSDT → DPTR／MPTR | PSDT 決定指標依 PRP 或 SGL 等格式解讀；指標內的數值不可在未選格式時直接當成長度。 | 主機先選指標格式，再按該格式準備 buffer 描述，最後由命令語意判斷資料方向。 |
| NSID／CDW2–CDW15 | NSID 與命令專屬欄位共同決定對象、範圍及選項。 | Create 的 DPTR 指向建立參數；它不是新 namespace 的實體儲存位址。 |
| NDT／NDM／MDPTR | 廠商命令使用共同格式時，資料與 metadata 長度各有自己的欄位及指標。 | 先看廠商命令格式支援宣告，再依長度定義換算，不能把欄位上限直接加 1 後存回同寬整數。 |
- metadata
- 隨 logical block 儲存的附加資料，可包含資料保護資訊，也可有其他用途。
- PSDT
- PRP or SGL for Data Transfer，CDW0 中決定 DPTR 應按 PRP 或 SGL 解讀的欄位。
- CID
- Command Identifier，與 SQ identifier 合用以辨識 outstanding command。
- NDM
- Number of Dwords in Metadata Transfer，standard vendor-specific format 中的實際 metadata dword 數。
- NDT
- Number of Dwords in Data Transfer，standard vendor-specific format 中的實際 data dword 數。
來源：Base 2.4 §4.1.1
來源：NVME-BASE-2.4, Rev. 2.4, §4.1.1, Figure 93, 文件頁 140-142, PDF 頁 166-168
Base Figure 93 · Common Command Format
一句話重點
Base93-1共通 SQE 固定各命令共用欄位的位置。
- SQE
- Submission Queue Entry，SQ 中的一筆命令資料結構。
來源：Base 2.4 §4.1.1
來源：NVME-BASE-2.4, Rev. 2.4, §4.1.1, Figure 93, 文件頁 140-142, PDF 頁 166-168
用例子讀懂
Base93-2同樣在 CDW10，Read 與管理命令可以有完全不同含義；先依 OPC 選命令，再查專屬欄位表。
圖表組 03 · Commit 的儲存與啟用選擇 · 3 張圖表
05.08.CA 表先看動作，再與 FS 和控制器能力配對。完成狀態表把映像拒絕、所需重設和一般完成分開；MUD 則另外描述重疊更新資訊，不用它代替啟用結果。
回到本節的解釋與範例Base Figure 187 · Firmware Commit – Command Dword 10
一句話重點
Base187-1Firmware Commit 的 CA 選動作，FS 或 BPID 指相關目標。
來源：Base 2.4 §5.2.9
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, Figure 187, 文件頁 203, PDF 頁 229
用例子讀懂
Base187-2更新 Boot Partition 時先按 CA 選替換或啟用相關動作，再看 BPID；不要把一般 firmware slot 的 FS 當成 boot partition 編號。
Base Figure 188 · Firmware Commit – Completion Queue Entry Dword 0
一句話重點
Base188-1Firmware Commit 回覆中的旗標描述特定更新偵測結果。
來源：Base 2.4 §5.2.9.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9.1, Figure 188, 文件頁 204, PDF 頁 230
用例子讀懂
Base188-2命令完成後，仍應逐個解讀 MUD 等回覆位元；不能用一個非零 DW0 直接推論「韌體版本已切換」。
Base Figure 189 · Firmware Commit – Command Specific Status Values
一句話重點
Base189-1Firmware Commit 狀態區分映像、slot 與需要重設等條件。
來源：Base 2.4 §5.2.9.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9.1, Figure 189, 文件頁 204-205, PDF 頁 230-231
用例子讀懂
Base189-2回覆需要 reset 的啟用條件，與 Invalid Firmware Image 是不同結果；前者需要安排流程，後者先檢查映像。
圖表組 04 · LID 03h 的目前與待啟用版本 · 12 張圖表
05.09.先拆開 AFI 中的 CAFS 與 NAFS，再以 slot 編號找到 FRSx，最後與 Identify.FR 對照。UUID 選擇及通知欄位只用於本次 LID 03h 的存取與事件關係，不改變版本欄位的意義。
回到本節的解釋與範例同一筆 Get Log Page 的目標、範圍與資料位置
05.10.讀 log 先選 LID 與命令集，再解讀該 log 的 LSP／LSI；NUMD 決定本次量，LPO 決定本次起點，DPTR 決定主機接收位置。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| LID／CSI／LSP／LSI | LID 與 CSI 選紀錄種類，LSP、LSI 的含義由所選 log 定義。 | LSP 在 Boot 中可含 BPID，在 Telemetry 中有建立 capture 的控制位元，不能跨 log 照搬。 |
| NUMDU／NUMDL | 先合成 NUMD=(NUMDU<<16)|NUMDL，再計算 (NUMD+1)×4 bytes。 | 512 bytes 對應 NUMD=127；高低部分不能各自加 1。 |
| LPOU／LPOL／OT | 高低欄位組成 64-bit offset；OT 決定按 byte 位移或項目索引解讀。 | byte-offset 模式下，從 512-byte 表頭後開始讀資料要保留起點差異；index 模式不能直接使用同一個 byte 數。 |
| DPTR／RAE | DPTR 給接收記憶體，RAE 控制相關事件的保留行為。 | 分段讀取先準備每段 buffer，再在恰當時機確認事件，避免中途改變可取得的紀錄。 |
| LSUPP／LID Specific Parameter | Supported Log Pages 回報實際支援及 log 專屬能力。 | 規格列有某個 LID，不代表此裝置一定實作；先查支援再使用進階選項。 |
- index
- index；用來選取清單中的項目或格式。它回答「選哪一項」，不是「離起點多遠」。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 203, 文件頁 213, PDF 頁 239
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 204, 文件頁 213, PDF 頁 239
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 205, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 206, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 207, 文件頁 214, PDF 頁 240
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 208, 文件頁 214-215, PDF 頁 240-241
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 209, 文件頁 215-216, PDF 頁 241-242
Base Figure 203 · Get Log Page – Data Pointer
一句話重點
Base203-1Get Log Page 的 DPTR 指向主機接收 log 資料的空間。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 203, 文件頁 213, PDF 頁 239
用例子讀懂
Base203-2同樣是 512-byte buffer，LID 不同會得到不同結構；DPTR 只提供位置，不會決定 log 類型。
Base Figure 204 · Get Log Page – Command Dword 10
一句話重點
Base204-1Get Log Page 的 CDW10 選擇 log、低位長度及相關控制參數。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 204, 文件頁 213, PDF 頁 239
用例子讀懂
Base204-2讀取 512 bytes 共 128 Dwords，長度原始值為 127；同時填正確 LID，才能知道回來的是哪一份紀錄。
Base Figure 205 · Get Log Page – Command Dword 11
一句話重點
Base205-1CDW11 提供長度高位與 log 特定識別資訊。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 205, 文件頁 214, PDF 頁 240
用例子讀懂
Base205-2NUMDU 非零時總長度需與 NUMDL 合併後再加 1；不能把兩個長度欄位各加 1 再相加。
Base Figure 206 · Get Log Page – Command Dword 12
一句話重點
Base206-1LPOL 是 log offset 的低 32 bits，單位還要看 offset 模式。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 206, 文件頁 214, PDF 頁 240
用例子讀懂
Base206-2byte-offset 模式下讀下一段 512 bytes，LPOL 設 512；index-offset 模式則以項目索引解釋，數字 512 不再表示相同位置。
- index-offset
- index-offset 對比；index 選取項目，offset 計算位置。例如從 0 起算的 Format Index=2 選第 3 個格式，而 OFST=256 表示從 image 起點位移 256 個 Dwords。
Base Figure 207 · Get Log Page – Command Dword 13
一句話重點
Base207-1LPOU 補齊較大 log offset 的高 32 bits。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 207, 文件頁 214, PDF 頁 240
用例子讀懂
Base207-2完整 offset＝00000001_00000000h 時，LPOU＝1、LPOL＝0；只讀 LPOL 會誤以為從開頭開始。
Base Figure 208 · Get Log Page – Command Dword 14
一句話重點
Base208-1CDW14 的 CSI、OT、UIDX 決定命令集、offset 模式與相關選擇。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 208, 文件頁 214-215, PDF 頁 240-241
用例子讀懂
Base208-2相同 LPOL＝4，在 byte-offset 與 index-offset 下表示不同事物；先看 OT 才能正確解讀位置。
Base Figure 209 · Get Log Page – Log Page Identifiers
一句話重點
Base209-1LID 清單把紀錄編號與其命令集、範圍連在一起。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, Figure 209, 文件頁 215-216, PDF 頁 241-242
用例子讀懂
Base209-2先依本篇所需的紀錄選取清單中的對應列，再看 CSI 與作用範圍；編號只選紀錄種類，完整欄位排列仍到該 log 的結構表閱讀。
Base Figure 215 · Firmware Slot Information Log Page
一句話重點
Base215-1Firmware Slot log 以啟用資訊連到各 slot 的韌體版本。
來源：Base 2.4 §5.2.13.1.4
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, Figure 215, 文件頁 226, PDF 頁 252
用例子讀懂
Base215-2先讀 AFI 所指 slot，再讀對應 FRS；其他 slot 存有映像，不代表它目前已在執行。
啟用通知提醒主機觀察版本切換
05.11.FID 0Bh 的 Firmware Activation Notices 控制對應通知，事件代表韌體啟用正在開始；目前 active slot 與版本仍需由 LID 03h 重新確認。
- FID
- Feature Identifier；指定要讀取或設定哪一項 Feature 的編號。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| FAN bit 9／Firmware Activation Starting | 啟用相應通知後，適用事件告知主機啟用活動開始。 | 收到事件並不代表新的 firmware 已完成所有必要的 reset 或切換，仍需沿啟用流程查看。 |
來源：Base 2.4 §5.2.2.1 · Base 2.4 §5.2.30.1.6
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 155, 文件頁 186, PDF 頁 212
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.6, Figure 474, 文件頁 466-468, PDF 頁 492-494
Base Figure 155 · Asynchronous Event Information – Notice
一句話重點
Base155-1Notice 類事件告知主機有狀態或配置變更。
來源：Base 2.4 §5.2.2.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2.1, Figure 155, 文件頁 186, PDF 頁 212
用例子讀懂
Base155-2收到 Firmware Activation Starting 通知，表示切換流程開始；要確認目前韌體仍須讀對應狀態及 log，而非把通知當完成證明。
查詢 log 時，UUID 的清單位置與值分開
05.12.需要 UUID 選擇的命令，以 UIDX 選 Identify 回傳的清單項目；UUID List 與其中的 Entry 結構共同定義這個對應。
| 一起判讀的欄位或標示 | 如何共同決定操作或結果 | 帶入情境後怎麼讀 |
|---|---|---|
| UIDX／UUID List Entry／IDASSOC／UUID | 索引選項目，識別關聯指出項目的用途，128-bit UUID 是項目所保存的識別值。 | UIDX=2 不等於 UUID=2；應找到該項目的完整 UUID 與關聯，再決定是否適用本次查詢。 |
來源：Base 2.4 §5.2.14.2.14
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.14, Figure 347, 文件頁 396, PDF 頁 422
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.14, Figure 348, 文件頁 396, PDF 頁 422
Base Figure 347 · UUID List
一句話重點
Base347-1UUID List 用索引連到完整 UUID。
來源：Base 2.4 §5.2.14.2.14
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.14, Figure 347, 文件頁 396, PDF 頁 422
用例子讀懂
Base347-2命令 UIDX＝2 時，先查第 2 個有效項目；數字 2 不是 UUID 本身，也不是 namespace 編號。
Base Figure 348 · UUID List Entry
一句話重點
Base348-1UUID List Entry 包含 UUID 與其關聯資訊。
來源：Base 2.4 §5.2.14.2.14
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.14.2.14, Figure 348, 文件頁 396, PDF 頁 422
用例子讀懂
Base348-2兩個項目即使位元長度相同，仍要讀 IDASSOC 才知道與誰關聯，不直接以出現順序猜用途。
Base Figure 474 · Asynchronous Event Configuration – Command Dword 11
一句話重點
Base474-1Asynchronous Event Configuration 各 bit 選擇對應的通知類別。
來源：Base 2.4 §5.2.30.1.6
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.30.1.6, Figure 474, 文件頁 466-468, PDF 頁 492-494
用例子讀懂
Base474-2主機啟用本篇需要的通知時，只設定對應的事件 bit；一種通知已啟用，不會自動啟用其他通知。
05.13.同一 domain 內的 controllers 共用 firmware slots，且相同 firmware image 會套用到該 domain 的所有 controllers；若不支援 multiple domains，範圍就是整個 NVM subsystem。
來源：Base 2.4 §5.2.9
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 202, PDF 頁 228
05.14.需要 reset 的標準流程是：一筆以上 Firmware Image Download、Firmware Commit 驗證並放入 slot、執行能觸發該 activation 的 Controller Level Reset，然後重新初始化 controller 與 I/O queues。
來源：Base 2.4 §3.11
來源：NVME-BASE-2.4, Rev. 2.4, §3.11, 文件頁 135-136, PDF 頁 161-162
05.15.CA=011b 要求立即 activation。Firmware Commit 不是 background operation，會保持進行中直到 activation 成功或失敗；若 Firmware Activation notice 已啟用，受影響 controller 可（may）送出 Firmware Activation Starting event。
來源：Base 2.4 §3.11
來源：NVME-BASE-2.4, Rev. 2.4, §3.11, 文件頁 136, PDF 頁 162
05.16.若新 image 無法成功載入，controller 必須（shall）回復到最近 activation 的 slot image；若該 image 也無法載入，則載入可用的 baseline read-only image，並產生 Firmware Image Load Error event。
來源：Base 2.4 §3.11
來源：NVME-BASE-2.4, Rev. 2.4, §3.11, 文件頁 136-137, PDF 頁 162-163
05.17.host 不宜（should not）讓 firmware／Boot Partition update sequences 重疊，且同一 sequence 宜（should）只使用一個 controller 或 Management Endpoint。
來源：Base 2.4 §3.11
來源：NVME-BASE-2.4, Rev. 2.4, §3.11, 文件頁 137, PDF 頁 163
05.18.Firmware Commit 完成後的第一筆新 Firmware Image Download，以及 download 後、Firmware Commit 完成前發生的 Controller Level Reset，都必須（shall）使 controller 丟棄尚存的已下載 portions。
來源：Base 2.4 §3.11, 5.2.10
來源：NVME-BASE-2.4, Rev. 2.4, §3.11, 5.2.10, 文件頁 137, 205-206, PDF 頁 163, 231-232
05.19.firmware revisions 間的 UUID List 宜（should）保持 entry 位置穩定：新增 UUID 宜接在尾端；移除時宜原位改成 NVMe Invalid UUID；不宜重用 invalid entry，也不宜縮短或移除清單。
來源：Base 2.4 §3.11.1
來源：NVME-BASE-2.4, Rev. 2.4, §3.11.1, 文件頁 137-138, PDF 頁 163-164
05.20.若 downloaded image 在既有 entry 中，以有效 UUID 取代 NVMe Invalid UUID 或另一個有效 UUID，controller 必須（shall）要求 reset；所有受這個 UUID List 變更影響的 controllers 都必須（shall）reset。
來源：Base 2.4 §3.11.1
來源：NVME-BASE-2.4, Rev. 2.4, §3.11.1, 文件頁 138, PDF 頁 164
05.21.BPID 與 CA=110b／111b 屬於 Boot Partition：110b 取代指定 partition，111b 將它標成 active；Boot Partition Write Prohibited 是 Firmware Commit 的 command-specific status 之一。
來源：Base 2.4 §5.2.9
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 文件頁 203-205, PDF 頁 229-231
05.22.RAE=0 會在 command 成功時清除對應 asynchronous event，RAE=1 則保留；若 command 未成功，controller 必須（shall）保留 event。Firmware Activation Starting event 要以 RAE=0 讀取 LID 03h 才會清除。
來源：Base 2.4 §5.2.2, 5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.2, 5.2.13, 文件頁 186, 213, PDF 頁 212, 239
05.23.本報告以完整 512-byte LID 03h、LPOL=LPOU=0、OT=0 為基準。一般 byte offset 必須 dword aligned；超過 log page 大小的 offset 必須（shall）回 Invalid Field in Command。LID 03h 不需要 index-offset 分支。
來源：Base 2.4 §5.2.13
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13, 文件頁 214-215, PDF 頁 240-241
05.24.Firmware Slot Information log page 固定 512 bytes，說明每個支援 slot 內的 firmware revision，並指出 current active slot 與（若 controller 有回報）next active slot。revision 以 ASCII string 表示。
來源：Base 2.4 §5.2.13.1.4
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, 文件頁 225-226, PDF 頁 251-252
05.25.NVMe over PCIe Transport 將 Conventional Reset 與 Function Level Reset 分別列為額外的 transport-specific Controller Level Reset 方法；除 Controller Reset 外，Controller Level Reset 會依 PCI Express Base Specification 重設 PCI register space。
來源：PCIe Transport 1.4 §3.3
來源：NVME-PCIE-TRANSPORT-1.4, Rev. 1.4, §3.3, 文件頁 11, PDF 頁 11
05.26.來源 §5.2.9 將 Firmware Revision 欄位指向 Figure 337；但 Figure 337 是 Command Set Identifiers，FR 實際列在 Figure 338。未取得另行核准的 errata，因此保留並揭露這個來源內部交叉引用差異，不靜默改寫。
來源：Base 2.4 §5.2.9, 5.2.14.1
來源：NVME-BASE-2.4, Rev. 2.4, §5.2.9, 5.2.14.1, 文件頁 202, 340, PDF 頁 228, 366
學完後想一想
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
來源：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