NVMe Base 2.4: Firmware Update and LID 03h Verification
00.01.Firmware updates involve transferring an image, storing it in a slot, and changing the running version. This note explains how Firmware Image Download, Firmware Commit, and Firmware Slot Information cooperate, distinguishing the state changed by each step.
The main ideas
Capabilities and update units
01-01Establish available slots, write restrictions, and download granularity.
Download and activation
02-01Understand image ranges, Commit Action, and reset requirements.
Running version
03-01Use current and next active slots to distinguish stored and running images.
00.02.A firmware slot stores an image; a revision string alone does not establish that the image is running. Controller capabilities, command completion, and slot information provide distinct information.
Connecting the main ideas
00.03.Firmware update connects capability reporting, image transfer, storage and activation, and result verification. These stages link Identify capabilities, Download lengths and offsets, Commit choices, and the current/pending slots in LID 03h.
- LID 03h
- Identifier 03h for the Firmware Slot Information log page.
- LID
- Log Page Identifier: selects the type of log page to read.
00.04.The report uses Firmware Slot Information to interpret the update result without expanding into all log pages. The aim is to explain why a successful download does not establish that new firmware is running and to follow an example using actual portions and slot states.
01 Capabilities and limits before an update
01.01.Firmware update is not a fixed command recipe. FRMW controls slots and activation capability, FWUG controls download granularity and alignment, MTFA and MPTFAWR bound waiting time, and MDS/DID define which controllers share the result.
- MPTFAWR
- Maximum Processing Time for Firmware Activation Without Reset, the maximum processing time for immediate activation without a reset.
- FRMW
- Firmware Updates, the Identify Controller field reporting slot count, slot-1 read-only state, and activation capabilities.
- FWUG
- Firmware Update Granularity, the capability field governing download-portion granularity and alignment.
- MTFA
- Maximum Time for Firmware Activation, the maximum time activation may pause command processing.
- DID
- Domain Identifier, the identifier of a domain within an NVM subsystem.
- MDS
- Multiple Domain Subsystem, the capability bit indicating whether an NVM subsystem contains multiple domains.
01.02.FRMW.SMUD, FAWR, NOFS, and FFSRO describe overlapping-update detection, activation without reset, the domain's supported slot count (1 through 7), and whether slot 1 is read-only.
Sources: Base 2.4 §5.2.14.1
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.14.1, printed pages 354, PDF pages 380
| Update capability | Choice it constrains | When it is used |
|---|---|---|
| FRMW | Available slots, slot-1 read-only state, activation capability | Read before selecting FS and CA |
| FWUG | Download-portion granularity and alignment | Convert to bytes before splitting the image |
| MTFA / MPTFAWR | Timing bounds for activation interruption | Do not hard-code timeout |
| MDS / DID | Domain that shares firmware slots | A PCI Function is not the complete scope |
- portion
- A contiguous portion sent in one firmware-download transfer.
- CA
- Commit Action, the Firmware Commit field selecting replacement, activation, and reset policy.
- FS
- Firmware Slot, the Firmware Commit field selecting the target slot.
02 Download lengths, offsets, and portions
02.01.Firmware Download uses NUMD as a zero-based length and OFST as a dword offset from the image start. Use the index-offset contrast: an index selects an item, while an offset measures distance from the start; neither value can be converted without its field definition.
- index-offset
- index-offset contrast: an index selects an item, while an offset measures a position. Zero-based Format Index=2 selects the third format; OFST=256 is a 256-Dword displacement from the image start.
- zero-based
- zero-based: numbering starts at zero, so raw=3 can mean the fourth item or four units; the field definition still decides which.
- offset
- offset: a displacement measured from a stated start. It answers “how far from the start,” unlike an index.
- Dword
- Dword (double word): 32 bits, or 4 bytes. A word is 16 bits; for example, a zero-based dword count of 3 represents 4 Dwords, or 16 bytes.
- index
- index: selects an item or format in a list. It answers “which one,” not “how far from the start.”
- NUMD
- Number of Dwords, a zero-based transfer-dword count; actual bytes = (NUMD + 1) × 4.
- OFST
- Offset, the dword-based image-relative offset in Firmware Image Download.
02.02.Firmware Image Download may split an image into portions, and firmware-image portions may arrive out of order. The host should avoid overlapping ranges and comply with FWUG. Boot Partition portions shall be submitted in order.
- Host
- The system running the operating system and issuing NVMe commands.
Sources: Base 2.4 §5.2.10
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.10, printed pages 205-206, PDF pages 231-232
| Transfer field | Position or length described | Conversion from bytes |
|---|---|---|
| DPTR | Host buffer for this transfer | A valid address does not prove a valid length |
| NUMD | Zero-based dword count for this transfer | 4096 bytes → 1024 dwords → 03FFh |
| OFST | Dword offset from the image start | The second 4 KiB portion starts at 1024 dwords |
| FWUG | Alignment and granularity requirements for each portion | Validate the image and each portion separately |
- DPTR
- Data Pointer, the SQE field identifying a command data buffer.
03 Commit storage and activation choices
03.01.Commit Action (CA) is not a success flag; it selects replacement, activation, and reset boundary. Firmware Slot (FS) selects the target slot, while CQE status determines whether software verifies, performs a specific reset, waits, or stops.
- CQE
- Completion Queue Entry, one completion-result structure in a CQ.
- Firmware Image Download transfers portions of the image.
- Firmware Commit uses CA to choose slot replacement and activation behavior.
- Activation requiring reset changes the running image after the specified reset.
- Firmware Slot Information distinguishes the current active slot from the next active slot.
03.02.Firmware Commit validates the last downloaded image, places it in a firmware slot, and uses Commit Action to choose placement only, activation at a later Controller Level Reset, or immediate activation. Successful commit does not by itself mean the image is currently active.
Sources: Base 2.4 §5.2.9
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.9, printed pages 202-203, PDF pages 228-229
| Commit field or result | Selected or established action | Determining the activation stage |
|---|---|---|
| CA | Replacement and activation behavior | Do not log only a decimal value |
| FS | Target firmware slot | Zero may let the controller choose; follow the definition |
| SCT / SC | Success, reset scope, or failure cause | 0Bh, 10h, and 11h imply different reset scopes |
| MUD | Evidence of overlapping update sequences | It may be meaningful even when the command aborts |
- controller
- Controller, the entity that implements the NVMe interface, fetches commands, and reports completions.
- MUD
- Multiple Update Detected, the completion bit indicating detection of overlapping firmware-update sequences.
- SCT
- Status Code Type: selects the completion-status category and is interpreted with SC.
- SC
- Status Code: identifies the completion result within the selected SCT category.
04 Current and pending versions in LID 03h
04.01.Get Log Page first builds a 512-byte transfer from common command fields and selects Firmware Slot Information with LID=03h. AFI separates CAFS from NAFS, FRS1-FRS7 report slot revisions, and Identify.FR plus domain scope provide the final cross-check.
- CAFS
- Current Active Firmware Slot, the low three AFI bits identifying the currently executing firmware slot.
- NAFS
- Next Active Firmware Slot, AFI bits 6:4 identifying the slot scheduled for the next reset; zero means none is scheduled.
- AFI
- Active Firmware Info, the LID 03h byte containing the current active slot and the slot scheduled for the next reset.
04.02.When reading LID 03h, no namespace is used, so NSID shall be 0h, and DPTR uses PRPs to identify the 512-byte destination buffer. The required CDW10-CDW14 slice is LID=03h, LSP=0, RAE=0, NUMDL/NUMDU for 512 bytes, LSI=0, LPOL/LPOU=0, OT=0, and UIDX=0. LID 03h does not use CSI, which the controller ignores under Figure 208's rule.
- namespace
- Namespace, a formatted quantity of non-volatile memory accessed by a host through a controller.
- NUMDL
- Number of Dwords Lower, the low 16 bits of Get Log Page NUMD.
- NUMDU
- Number of Dwords Upper, the high 16 bits of Get Log Page NUMD.
- LPOL
- Log Page Offset Lower, the low 32 bits of the Get Log Page byte offset.
- LPOU
- Log Page Offset Upper, the high 32 bits of the Get Log Page byte offset.
- NSID
- Namespace Identifier, a controller-visible numeric handle for a namespace; the identifier is not the namespace object itself.
- UIDX
- UUID Index, an index into the UUID List; zero indicates that no UUID is specified.
- CDW
- CDW (Command Dword): a 32-bit command field. In CDW10, 10 is the field index, not a byte offset.
- CSI
- I/O Command Set Identifier: selects an I/O command set; NVM uses 00h.
- LSI
- Log Specific Identifier, an identifier whose meaning is defined by the selected log page.
- LSP
- Log Specific Field, a command selector whose meaning is defined by the selected log page.
- RAE
- Retain Asynchronous Event, the Get Log Page selector controlling retention of a related asynchronous event.
Sources: Base 2.4 §4.1.1, 5.2.13
Source: NVME-BASE-2.4, Rev. 2.4, §4.1.1, 5.2.13, printed pages 140-142, 212-215, PDF pages 166-168, 238-241
| Revision or slot field | Time/state described | Cross-check with other fields |
|---|---|---|
| CAFS | Currently executing slot | It is not next-reset intent |
| NAFS | Slot scheduled after the next reset | Zero means none scheduled |
| FRSx | Eight-byte revision for slot x | All-zero bytes are not an ASCII string |
| Identify.FR | Independent observation of current revision | Cross-check against the FRSx selected by CAFS |
Where to continue in the specification
05.01.Use the flow above to frame the problem, then open the corresponding sections for fields and full conditions. The Chinese tutorial also explains every in-scope figure with its takeaway, example, and details.
| Concept to explain | Specification sections |
|---|---|
| Capabilities and limits before an update | Base 2.4 §5.2.14.1 |
| Download lengths, offsets, and portions | Base 2.4 §5.2.10 · Base 2.4 §4.1.1, 5.2.10 |
| Commit storage and activation choices | Base 2.4 §5.2.9 |
| Current and pending versions in 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 |
Check your understanding
1. Is new firmware executing as soon as Firmware Image Download completes?
06.01.Download transfers the image. Commit selects storage or activation behavior, and activation may require a specified reset. Commit results and slot information establish the currently running version.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.10, printed pages 205-206, PDF pages 231-232
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.9, printed pages 202-203, PDF pages 228-229
2. What do NUMD=255 and OFST=256 describe?
06.02.NUMD is a zero-based dword length: 256 dwords, or 1024 bytes, are transferred. OFST is a dword offset from the image start, so the transfer begins at byte 1024. Their encoding roles differ.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §4.1.1, 5.2.10, printed pages 140-142, 205-206, PDF pages 166-168, 231-232
3. Does a new version in a slot’s FRS prove that it is running?
06.03.FRS describes the revision stored in a slot. Active-slot and next-active-slot information are also needed. Stored, currently running, and pending activation are distinct states.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, printed pages 226, PDF pages 252
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.13.1.4, printed pages 226, PDF pages 252
4. Why is a firmware update not always a private change to one controller?
06.04.Firmware scope may involve shared domain or NVM subsystem resources. Establish the relationship between the controller and update scope to understand effects on other controllers.
Sources
Source: NVME-BASE-2.4, Rev. 2.4, §5.2.9, printed pages 202, PDF pages 228


Comments