NVMe Self-Study Bank: Firmware update and boot partitions
read more
NVMe Self-Study Bank: Firmware update and boot partitions
NVMe · Q1–328
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
Q136–Q148
Firmware update and boot partitions
Separate download, commit and activation, then compare boot-image access and selection.
Each question is followed by its explanation. Start with the volume overview, then follow the field interpretations, comparisons or processes. Essential conditions and the normal path are visible from the start. All numerical examples are hypothetical. Status is written SCT/SC; h indicates hexadecimal.
- SCT
- Status Code Type
From image bytes to activation
Slot contents, pending activation and running revision describe different stages.
| Stage | Evidence | Conclusion |
|---|---|---|
| Download | Offset, length, coverage | Transferred, not activated |
| Commit | Slot, action, status | Stored or activation scheduled |
| Activation | Required reset, revision, active slot | Establish running version |
| Boot partition | Active partition, read state, protection | Interpret boot access/protection |
Worked interpretation: Pending slot activation need not change FR early; boot CA7 selects a partition and is not ordinary firmware activation.
Sources: 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
Review the terminology when needed
- Controller / namespace
- A controller receives commands and manages access. A namespace is a logical storage space that commands can address. An NVM subsystem contains controllers and nonvolatile storage resources.
- SQ / CQ / SQE / CQE
- Submission and Completion Queues carry command entries (SQEs) and completion entries (CQEs). QID identifies a queue, CID distinguishes outstanding commands in one SQ, and NSID identifies a namespace.
- Register / Identify / Feature / Log
- A register exposes control or state. Identify queries capabilities and attributes; features query or configure operation; log pages report specific state or records. FID, LID, CNS and CSI select features, logs, Identify structures and command sets.
- index / offset / zero-based
- An index selects an entry, usually starting at 0; an offset measures distance from an origin in specified units. A zero-based count encodes count−1, but not every zero-valued field is a count. A Dword is 4 bytes; a byte is 8 bits.
- Scope / reset / retention
- Scope names the affected objects; retention means preserving state. Controller Reset (clearing CC.EN) is one form of Controller Level Reset, or CLR. Different CLR triggers can retain different registers.
Questions in this volume
- Q136 · Where are firmware slot count, protection and usage reported?
- Q137 · How do OFST and NUMD describe firmware download pieces?
- Q138 · How are overlap, gaps, order and invalid images handled?
- Q139 · How are Firmware Commit slot and action selected?
- Q140 · How do immediate and reset-triggered activation differ?
- Q141 · When is Firmware Activation Starting reported?
- Q142 · How are firmware-update interruptions recovered?
- Q143 · How does firmware-load failure recovery work?
- Q144 · How is completed activation verified?
- Q145 · What should persist or be rediscovered after activation?
- Q146 · How are boot partition support, state and active ID discovered?
- Q147 · How are boot images downloaded, committed and selected?
- Q148 · How do boot and controller-firmware updates differ?
Q136 Where are firmware slot count, protection and usage reported?
Follow the explanation
Read both Identify and the Firmware Slot Information Log: Identify.FRMW supplies the slot count and slot 1 read-only capability; the log supplies slot contents and activation state.
1. Select the target and information
Firmware slots are shared within a domain; identify the update domain first.
OACS advertises firmware commands; FRMW reports slot count, slot 1 protection and reset-free activation capability.
LID 03h CAFS is current slot, NAFS the pending next-reset slot and FRS1–7 the slot revisions.
- LID
- Log Page Identifier
2. Query sequence and interpretation
Read FRMW then LID 03h and choose a writable slot; do not probe protection by attempting overwrite.
- LID
- Log Page Identifier
Establish count, populated slots, running slot and pending activation separately.
3. Handle missing or inconsistent evidence
All-zero revision can mean empty or unsupported and cannot establish count; invalid/read-only slots use Invalid Firmware Slot.
Identify.FR reports the running firmware revision. NAFS identifies the slot selected for the next activation; check its relation to the running image after activation completes.
First read FRMW before interpreting an empty slot as nonexistent.
Sources: 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)
Source locations for this question
Sources: 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 How do OFST and NUMD describe firmware download pieces?
Follow the explanation
Segmentation avoids transferring an entire image at once but requires correct positions and lengths.
1. Establish the source and scope
OFST is relative to the whole image, not the host buffer for the current piece.
Check FWUG alignment/granularity and applicable transfer limits such as MDTS, honoring FWUG special values.
2. Fields, units and worked interpretation
OFST counts Dwords and NUMD is zero-based Dword length: byte start=OFST×4 and length=(NUMD+1)×4.
For 4096-byte pieces use OFST0/NUMD1023 then OFST1024/NUMD1023 with each pointer addressing that piece.
Download success completes the piece, not Commit or activation.
3. Conditions that change the interpretation
FWUG violations may return Invalid Field and overlaps Overlapping Range; unit mistakes create misplaced data and gaps.
Verify complete coverage from each range and compare with the source image.
Sources: 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)
Source locations for this question
Sources: 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 How are overlap, gaps, order and invalid images handled?
Follow the explanation
Separate segment-transfer errors from whole-image validation; successful pieces can still form an invalid incomplete image.
1. Distinguish the failure conditions
Keep one image per update sequence and use the same controller; avoid interleaving firmware/boot updates.
Firmware pieces may arrive out of order; boot pieces must be ordered from the start. Range overlap and MUD sequence-overlap reporting are distinct.
Overlap may use 1/14h and invalid Commit image 1/07h. Overlapping update sequences can have undefined results, not a universal recovery status.
2. Establish the cause from evidence
Check FWUG, image requirements and supported multiple-update detection.
Track ranges and successful transfers, verify no gaps/overlap, Commit, then begin the next image.
3. Outcome and follow-up checks
A valid complete image proceeds through Commit; individual pieces need not validate the complete image.
Preserve ranges and Commit results to separate transfer completion, completeness and activation validity.
First check whether firmware and boot ordering rules were interchanged.
Sources: 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)
Source locations for this question
Sources: 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 How are Firmware Commit slot and action selected?
Follow the explanation
Commit can store, schedule or activate immediately, depending on the update plan and capability.
1. Prepare the operation
FS selects firmware slots while BPID selects boot partitions.
Read FRMW, active/pending slots and MTFA before choosing reset-free activation.
CA0 stores only,1 stores/schedules CLR activation,2 schedules an existing slot and 3 activates immediately. FS0 lets the controller select a slot 1–7.
2. Sequence and completion conditions
Download when needed, then Commit; activating an existing stored image need not redownload it.
CA0 leaves the running version unchanged, CA1/2 await reset and CA3 remains outstanding until activation succeeds or fails.
3. Handle unmet conditions
Invalid/read-only slots and images have distinct errors; required-reset statuses can indicate successful storage with activation still pending.
Derive FR/CAFS/NAFS expectations from CA rather than demanding immediate FR change for every action.
Sources: 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)
Source locations for this question
Sources: 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 How do immediate and reset-triggered activation differ?
Follow the explanation
Immediate activation can preserve the operating environment, but image changes may require reset; honor the reported reset type.
1. What differs
Activation covers the domain, while the chosen reset can have broader scope.
Required resets use 1/0Bh,1/10h and 1/11h;1/12h means activation exceeds MTFA, leaving the image committed but inactive.
2. How to choose and verify
Check reset-free capability, MTFA and Commit status; capability does not guarantee every image qualifies.
After CA3 success check the new revision; otherwise perform the required reset and reinitialize. A narrower reset does not satisfy a stronger requirement.
CA1/2 success allows activation by applicable CLR methods; explicit Conventional/Subsystem requirements narrow the trigger.
3. Conditions that shape the comparison
If Conventional Reset was required, clearing CC.EN alone leaves the old image running and unchanged FR is expected.
Correlate CA, status, actual reset source and recovered FR.
Sources: 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)
Source locations for this question
Sources: 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 When is Firmware Activation Starting reported?
Follow the explanation
The event announces reset-free activation and possible processing pause, not successful completion.
1. When the event exists and who observes it
Affected controllers report according to their notification settings, not solely the Commit recipient.
Check enabled activation notices, posted AERs and activation capabilities/timing.
The Notice event points to LID 03h; CSTS.PP reports processing pause.
2. Notification, reading and acknowledgment
Handle the event at activation start, observe processing recovery, then check Commit and FR.
Success requires the relevant completion and running revision; Starting establishes initiation only.
3. Evaluate missing notifications or records
Disabled notices or unavailable AERs alter notification observation; load failure has its own error event.
Correlate event timing, PP and completion to distinguish activation stalls from unhandled notifications.
First check the activation-notice configuration, not merely whether an AER was submitted.
4. Asynchronous Event notification conditions
Starting reset-free activation triggers Firmware Activation Starting on affected controllers when notices are enabled. Read the complete conditions in this volume
Sources: 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)
Source locations for this question
Sources: 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 How are firmware-update interruptions recovered?
Follow the explanation
Staging, committing and activation have different persistence; identify the interruption stage first.
1. Identify the trigger and affected objects
Storage and activation are domain-wide and interruption can affect its shared controllers.
Preserve last completed transfers/Commit, CA/FS and revision/slot snapshots, then reread after recovery.
2. State changes and recovery
CLR between download and completed Commit discards staging; D3cold during activation Commit may resume with old or new firmware.
Recover, inspect running/stored revisions and redownload uncommitted staging rather than assuming resumable offsets.
Decide completion/retry/recommit only after identifying running revision, pending state and capabilities.
3. Checks across reset or power loss
| Trigger | Effect on this operation or state |
|---|---|
| What survives or continues after Controller Reset? | A CLR between download and completed Commit discards staged portions. Committed slots/pending activation follow CA and required reset type; not every reset activates the image. |
| What survives or continues after NVM Subsystem Reset? | Subsystem reset affects its covered controllers and satisfies a required subsystem-reset activation. Recheck revision, slots and capabilities; uncommitted staging cannot be reused. |
| What survives or continues after a power cycle? | Entering D3cold during activation Commit can resume with the old or newly activated image; verify it. Uncommitted downloaded portions are not a persistent slot. |
4. Verify retention and recovery
Do not invent status for a lost CQE; retaining old firmware can be a valid interrupted-activation outcome.
- CQE
- Completion Queue Entry
Use Commit/Reset PEL history but compare requested NFR with actual FR.
First identify the last completed Commit rather than the last downloaded piece.
Sources: 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)
Source locations for this question
Sources: 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 How does firmware-load failure recovery work?
Follow the explanation
Recovery depends on available previously activated or baseline images when a new image cannot load.
1. Preserve the evidence first
Recovery affects controllers using the image; one slot alone does not describe full history.
Check FR, active/pending slots, revisions, load-error events and PEL.
On load failure, revert to the most recently activated slot image or available read-only baseline and report Firmware Image Load Error.
2. Work through the possible causes
First check whether the active slot was overwritten.
Read recovered FR and failure evidence before attempting the same image again.
3. Connect observations to specification conditions
Running old firmware can demonstrate recovery while the attempted update remains failed.
Overwriting the active slot may remove the prior image; no guarantee exists of returning to any chosen historical revision.
Compare actual slot/baseline availability rather than demanding rollback to unavailable content.
Sources: 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)
Source locations for this question
Sources: 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 How is completed activation verified?
Follow the explanation
Activation can change capabilities/effects; refresh caches rather than relying solely on revision text.
1. Prepare the operation
Compare the same affected controller/domain and namespace identities before and after.
Read FR/FRMW/CAP, slot information and relevant-CSI Commands Supported and Effects.
CAFS identifies current slot, NAFS pending activation and FR running revision; Effects reports support and possible capability/inventory changes.
2. Sequence and completion conditions
Establish activation completion, refresh capability and validate required commands/formats.
Running revision, active slot and activation outcome should agree; pending activation does not require early FR changes.
3. Handle unmet conditions
Diagnose readiness/media restrictions and new capability before declaring image corruption.
Compare applicable fields and CSI rather than reserved or unrelated structures.
- CSI
- Command Set Identifier
Sources: 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)
Source locations for this question
Sources: 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 What should persist or be rediscovered after activation?
Follow the explanation
Do not require every byte to remain unchanged: capability can evolve while data/configuration obey their persistence rules.
1. Identify the trigger and affected objects
Separate reset-free activation from actual reset, which independently changes queues, features and registers.
Compare feature saved/current/persistence, namespace identity/attachment, capabilities and UUID list.
2. State changes and recovery
FR identifies the image, not feature restoration. Incompatible UUID-slot changes can require reset to avoid reinterpreting old indices.
Snapshot before update, record activation/reset path, compare each function’s persistence and restore required host state.
Validate the actual activation/reset path, distinguishing permitted capability changes from improper data/configuration loss.
3. Verify retention and recovery
Firmware change does not justify arbitrary loss, nor does updating preserve queues across a real reset.
Map differences to requirements: changed capability, retained values and rebuilt state.
First establish whether CLR occurred before setting persistence expectations.
Sources: 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)
Source locations for this question
Sources: 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 How are boot partition support, state and active ID discovered?
Follow the explanation
Boot partitions provide pre-queue/pre-enable image access through a simplified interface, not ordinary namespace LBAs.
1. Select the target and information
Supported controllers expose two equal partitions, IDs 0/1, potentially shared across controllers.
Read CAP.BPS and BPINFO.ABPID/BPSZ/BRS, Identify.BPC for protection and supported LID 15h for log access.
BPMBL supplies buffer address, BPRSEL selects partition/range and BRS reports transfer state.
2. Query sequence and interpretation
Allocate contiguous memory, ensure no read is active, configure address/selection and wait for BRS; do not reset/shutdown/change transport properties during the read.
BRS10b indicates transferred data and 11b transfer error; the register-based flow has no NVMe CQE.
- CQE
- Completion Queue Entry
3. Checks across reset or power loss
| Trigger | Effect on this operation or state |
|---|---|
| What survives or continues after Controller Reset? | Boot contents are not cleared like queue state, but the host must not reset during an active register read. Recheck properties/state afterward. |
4. Handle missing or inconsistent evidence
Do not invent Invalid Field CQEs for BPRSEL writes; the log path separately follows Get Log completion rules.
Verify capability, selected active ID, size, status and content; ABPID alone does not validate the image.
First distinguish register and log interfaces before applying offset/completion semantics.
5. Reporting and shared objects
The register path has no DNR/More; LID 15h uses its Get Log Page CQE.
- DNR
- Do Not Retry, a completion retry indication
Register reads report through BRS, without updating firmware-slot history; the log path returns selected boot data and uses its own CQE/error rules.
Controllers may share partitions, but one controller’s completed transfer does not complete another’s buffer.
Sources: 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)
Source locations for this question
Sources: 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 How are boot images downloaded, committed and selected?
Follow the explanation
Two partitions allow updating and verifying the inactive image before selection, reducing interrupted-update risk.
1. Prepare the operation
BPID selects the written/activated partition, with protection enforced by all sharing controllers.
Check BPS/BPC, ABPID and the active protection mechanism; FID 85h and RPMB do not simultaneously control protection.
- FID
- Feature Identifier
Download in order; CommitCA6 replaces the selected partition and CA7 selects it active.
2. Sequence and completion conditions
Download, unlock target, commitCA6, verify, selectCA7 and restore protection.
CA6 success writes the partition without necessarily changing ABPID; verify ABPID after CA7.
3. Handle unmet conditions
Locked writes use Boot Partition Write Prohibited; reset/power interruption can leave mixed contents requiring verification before activation.
Compare downloaded/readback content and ABPID separately.
4. Reporting and shared objects
Verify commit, ABPID, boot-data readback and protection; firmware-slot information is not a boot-image inventory.
Shared boot partitions require coordinated update/protection across all sharing controllers.
Sources: 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)
Source locations for this question
Sources: 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 How do boot and controller-firmware updates differ?
Follow the explanation
Boot images are for host booting; controller firmware runs the SSD. Shared download commands do not imply shared semantics.
1. What differs
Boot uses IDs 0/1; firmware uses slots 1–7 within a domain.
Firmware download may be out of order withCA0–3; boot download is ordered withCA6/7.
2. How to choose and verify
Boot discovery uses BPS/BPC/BPINFO; firmware uses OACS/FRMW/MTFA and LID 03h.
Identify the target before selecting capabilities, order, action and verification; do not interleave update sequences.
Verify firmware via running revision/slot and boot via content/ABPID; boot update does not require FR to change.
3. Checks across reset or power loss
| Trigger | Effect on this operation or state |
|---|---|
| What survives or continues after Controller Reset? | CLR discards uncommitted staging; committed firmware follows activation rules, while interrupted boot writes can leave mixed contents. |
| What survives or continues after a power cycle? | After power loss verify actual firmware/fallback or potentially mixed boot contents; power restoration alone proves neither update successful. |
4. Conditions that shape the comparison
Interrupted boot commits can mix contents; firmware load failure has image fallback rules. Do not transfer guarantees between them.
Record target-specific state/persistence rather than conflating boot Active selection with firmware CAFS.
5. Reporting and shared objects
Reset-free controller-firmware activation follows the enabled Starting notice; Boot CA6/CA7 do not require that notice.
Firmware uses slot information and running revision; boot uses ABPID, content and protection. Preserve target-specific commit/error evidence.
Coordinate the firmware domain or all controllers sharing a boot partition, not only the submitting path.
Sources: 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)
Source locations for this question
Sources: 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)
Shared rules linked from the answers
Each shared mechanism is explained in full once in this volume. Use browser Back to return to the question; explicit command or feature exceptions take precedence.
Shared conditions for this topic · Is an asynchronous event generated?
Starting reset-free activation triggers Firmware Activation Starting on affected controllers when notices are enabled. Load failure has a separate error event; each successful download segment does not trigger activation.
Source locations and existing figure guides
Base printed page = PDF page−26; the other two use identical numbers. Locations follow the supplied PDF body and retain figure numbers. Shared pages contribute only the relevant definitions, excluding Fabrics and PCIe link/packet content.
- Base 2.4 · §3.1.4 (CC, CSTS, NSSR)
Printed pages 60–66 · PDF 86–92 · Figure 41–43 - Base 2.4 · §3.1.4 (BPINFO, BPRSEL, BPMBL)
Printed pages 69–70 · PDF 95–96 · Figure 49–51 - Base 2.4 · §3.7.1–3.7.4
Printed pages 120–124 · PDF 146–150 - Base 2.4 · §3.11–3.11.1, 5.2.9–5.2.10
Printed pages 135–138, 202–206 · PDF 161–164, 228–232 · Figure 187–193 - Base 2.4 · §4.2.3
Printed pages 145–155 · PDF 171–181 · Figure 101–105 - Base 2.4 · §4.4
Printed pages 166–169 · PDF 192–195 · Figure 126–127 - Base 2.4 · §5.2.2
Printed pages 183–190 · PDF 209–216 · Figure 150–156 - Base 2.4 · §5.2.2 (PCIe-applicable events)
Printed pages 183–191 · PDF 209–217 · Figure 150–160 - Base 2.4 · §5.2.13.1.2
Printed pages 218–220 · PDF 244–246 · Figure 212 - Base 2.4 · §5.2.13.1.4
Printed pages 225–226 · PDF 251–252 · Figure 215 - Base 2.4 · §5.2.13.1.6
Printed pages 226–229 · PDF 252–255 · Figure 216–217 - Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Printed pages 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
Printed pages 252–255 · PDF 278–281 · Figure 238, 240–241 - Base 2.4 · §5.2.13.1.21
Printed pages 283–284 · PDF 309–310 · Figure 279–280 - Base 2.4 · §5.2.14.2.1
Printed pages 340–387 · PDF 366–413 · Figure 338–341 - Base 2.4 · §5.2.30.1.6
Printed pages 466–468 · PDF 492–494 · Figure 474 - Base 2.4 · §5.2.30.1.39
Printed pages 512–514 · PDF 538–540 · Figure 542 - Base 2.4 · §8.1.3–8.1.3.3.3
Printed pages 586–592 · PDF 612–618 · Figure 679–683 - Base 2.4 · §8.1.31.1–8.1.31.2
Printed pages 737–738 · PDF 763–764 · Figure 782 - NVM Command Set 1.3 · §4.1.5.1–4.1.5.4
Printed pages 84–107 · PDF 84–107 · Figure 123–130
When you need a field guide
Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.
- 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
Original documents used
- 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