NVMe Base 2.4: Firmware Update and LID 03h Verification

19 minute read

繁體中文

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

01

Capabilities and update units

01-01Establish available slots, write restrictions, and download granularity.

02

Download and activation

02-01Understand image ranges, Commit Action, and reset requirements.

03

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

Capabilities and limits before an update
Update capabilityChoice it constrainsWhen it is used
FRMWAvailable slots, slot-1 read-only state, activation capabilityRead before selecting FS and CA
FWUGDownload-portion granularity and alignmentConvert to bytes before splitting the image
MTFA / MPTFAWRTiming bounds for activation interruptionDo not hard-code timeout
MDS / DIDDomain that shares firmware slotsA 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

Download lengths, offsets, and portions
Transfer fieldPosition or length describedConversion from bytes
DPTRHost buffer for this transferA valid address does not prove a valid length
NUMDZero-based dword count for this transfer4096 bytes → 1024 dwords → 03FFh
OFSTDword offset from the image startThe second 4 KiB portion starts at 1024 dwords
FWUGAlignment and granularity requirements for each portionValidate 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.
Downloading, storing, and activating have different effects
  1. Firmware Image Download transfers portions of the image.
  2. Firmware Commit uses CA to choose slot replacement and activation behavior.
  3. Activation requiring reset changes the running image after the specified reset.
  4. Firmware Slot Information distinguishes the current active slot from the next active slot.
Transfer complete, image stored, and image running are different states.

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 storage and activation choices
Commit field or resultSelected or established actionDetermining the activation stage
CAReplacement and activation behaviorDo not log only a decimal value
FSTarget firmware slotZero may let the controller choose; follow the definition
SCT / SCSuccess, reset scope, or failure cause0Bh, 10h, and 11h imply different reset scopes
MUDEvidence of overlapping update sequencesIt 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

Current and pending versions in LID 03h
Revision or slot fieldTime/state describedCross-check with other fields
CAFSCurrently executing slotIt is not next-reset intent
NAFSSlot scheduled after the next resetZero means none scheduled
FRSxEight-byte revision for slot xAll-zero bytes are not an ASCII string
Identify.FRIndependent observation of current revisionCross-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 explainSpecification sections
Capabilities and limits before an updateBase 2.4 §5.2.14.1
Download lengths, offsets, and portionsBase 2.4 §5.2.10 · Base 2.4 §4.1.1, 5.2.10
Commit storage and activation choicesBase 2.4 §5.2.9
Current and pending versions in LID 03hBase 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
Open the complete Chinese tutorial and figure explanations →

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

Specification editions

NVM Express Base Specification, Revision 2.4

NVM Express NVMe over PCIe Transport Specification, Revision 1.4

Jia-Chang

Jia-Chang

Human

Comments

  Write a comment ...