# Checklist: SMI firmware mitigation hardware qualification

Status: controller-test contract template; srv-rpi00.local execution not ready
Type: checklist
Updated: 2026-08-02
Next Action: none in this firmware workspace; the srv-rpi00.local qualification app creates an immutable exact-bundle campaign instance and coordinates the approved Controller B cases only after its readiness and exact-case gates pass
Campaign Reason: Historical record from campaign 010-qualify-firmware-negative-and-recovery-behavior; retained independently after campaign closure and requires no separate owner-queue execution.
Campaign: standalone
Parent: work/wp/active/wp-mitigate-smi-firmware-code-review-findings.md

## Execution Owner and Import Boundary

This checklist is the firmware-owned acceptance contract. Controller execution
belongs to `jong@srv-rpi00.local:~/dev/sd_qualification`. The coordinator binds
the exact SMI bundle, controller/J-Link identity, authorization, safety state,
stop/recovery route, and evidence directory before issuing any controller
command. It records every command/result and returns a reviewed immutable
manifest to this workspace.

This repository may prepare firmware, diagnostics, fixtures, and expected
outcomes, but it does not coordinate programming, reset, fault injection,
calibration-preservation, update interruption, or recovery on Controllers A/B.
Historical checked items remain evidence; unchecked items become copied
campaign criteria only after the remote readiness gate passes.

## Goal

Demonstrate on representative SMI hardware that the reviewed mitigations fail
safely and do not regress startup, control, UI, logging, export, USB update, debug,
or recovery. Record objective evidence for every result; a build-only result is
not an on-target pass.

## Test Record

| Field | Value |
| --- | --- |
| Date / time | |
| Tester | |
| Pi coordinator campaign ID / revision | |
| Imported SMI bundle manifest / SHA-256 | |
| Target serial number | |
| PCB assembly / revision | |
| Display revision | |
| Machine model configured | |
| Firmware artifact | `7520553_SMI_FW_00_05_00.elf` / `7520553_SMI_FW_00_05_00.srec` |
| Git branch / commit or dirty-tree ID | `codex/firmware-00-05-00-hpt-filesystem` / implementation `391c7b4d`, artifact freeze `c0901312` |
| Programmer and probe serial | Controller A J-Link `69664082`; Controller B J-Link `69660123` |
| USB media make / capacity / filesystem | |
| SD media make / capacity / filesystem | |
| Bench supply voltage / current limit | |
| Ambient conditions | |
| Evidence folder | `work/evidence/post-freeze-integrated-qualification-20260725.md` |
| Returned immutable result manifest | |

Result notation: `PASS`, `FAIL`, `BLOCKED`, or `N/A` with an explanation.

## 2026-07-25 autonomous electronic disposition

- [x] Final Debug S-record SHA-256
  `D386F03460E225B683D5146FFC7AD949CCFEF71A3EC8169C944EFA82B5992F9F`
  was programmed/verified/reset on Controllers A and B.
- [x] Both controller/card pairs passed same-run protocol, CID-valid, and
  representative-sector-read baselines with their complete raw CIDs recorded.
- [x] Both cards completed all `15,523,840` sectors of the bounded read-only
  scrub with zero failures, retry recoveries, identity mismatches, or HPT
  errors.
- [x] Both controllers passed the integrated HPT open, representative read,
  `720/720` chart rebuild, and logging gate with zero system errors.
- [x] Three predecessor cold-start/reopen/CID cycles passed on each controller.
  The final delta changes only bounded scrub scheduling, so these are accepted
  as delta-scoped evidence; Controller B cycle 3 must not be repeated.
- [x] Owner reported PASS on both controllers for visual wording/placement/
  legibility, touchscreen navigation, and alarm audio on 2026-07-25.

Evidence:
`work/evidence/post-freeze-integrated-qualification-20260725.md`.

Unchecked malformed-update, injected-failure, physical interruption,
degraded-media, endurance, multi-sample, and rollout items below remain
separately scoped. This disposition does not claim them complete.

## 2026-07-27 Controller B recovery-baseline disposition

- [x] Bound Controller B `1751219`, hardware variant `1`, J-Link `69660123`,
  source commit `2f4d8724...`, S-record `30C98F00...ADF649`, and CID
  `035344535330384780976F0085018507`.
- [x] Captured hashed pre-change RAM configuration, redundant VEEPROM
  configuration/calibration, and option memory.
- [x] Verified the known-good S-record against a fresh four-MiB internal-flash
  readback; both reconstruct to
  `6C0DBDB31E30AAD13993CA3D49BA0141BEDCC8FF2E4C38BC33743D9FA7389D4B`.
- [x] Verified the serial-bound J-Link program/recovery route, normal reset,
  run, and post-reset reacquisition.
- [x] Intentionally disabled main-temperature control through the normal
  persisted configuration path. After reset, configuration generation `174`
  remained committed and operational with zero findings; both heater demands,
  high-heat state, and heater output bit remained zero.
- [x] After capturing that bounded recovery snapshot, restored normal
  main-temperature control and verified it across reset at committed generation
  `175`. Setpoint and calibration are unchanged; active heater demand and
  normal physical output-bit toggling were observed.
- [x] Captured the complete CID identity before and after reset. Identity is
  byte-identical; protocol state, CID validity, and representative-sector read
  pass.
- [x] No SD format, initialization, removal, insertion, or replacement
  occurred.

Evidence:
`work/evidence/controller-b-recovery-baseline-20260727.md`.

This closes the recovery-baseline prerequisite only. The non-heating snapshot
is recovery evidence, not the endurance configuration. Normal controller
functions remain enabled during general and endurance qualification.

## Safety and Stop Conditions

- [x] Testing is on an approved bench target, not equipment serving a process.
- [x] Heater/output loads are disconnected or safely simulated unless a test
  explicitly requires them and an operator is monitoring the equipment.
- [x] Independent over-temperature protection and an accessible power disconnect
  are present for energized control tests.
- [x] A known-good ELF/SREC, J-Flash project, probe, and recovery procedure are available.
- [x] Current configuration/calibration VEEPROM and option memory are backed up
  and hash-matched after the replacement load; SD media was not mutated.
- [ ] Tester will stop immediately for uncontrolled heating, repeated reset,
  unexpected output activation, corrupt calibration, smoke, excessive current,
  or inability to recover debug/programming access.
- [x] G-PWR-A has passed the Controller A permanently connected topology
  witness matrix.
- [x] G-PWR-B passed three current-firmware reset witnesses with exact-target
  recovery and matching baseline/post-reboot CID identity.

## 1. Image and Bench Baseline

- [ ] Confirm the headless Debug build/package log reports success and artifact
  version `00.05.00`. Evidence: ____________________ Result: ______
- [x] Record SHA-256 hashes of the exact ELF, SREC, and any update image used.
  Evidence: ____________________ Result: ______
- [x] Program with the serial-bound checked-in bench script and perform verify.
  Project/probe: `script/program-bench.ps1`, J-Link `69664082` Result: `PASS`
- [ ] Cold-start the target three times. Each reaches the normal home screen
  without a boot loop, assertion, or unexpected error. Result: ______
- [ ] Attach e² Studio, halt once, confirm symbols/source resolve, resume, then
  detach without changing runtime behavior. Result: ______
- [ ] Record startup time, idle current, free-running duration, and any diagnostic
  counters before fault testing. Evidence: ____________________ Result: ______

## 2. Normal Functional Smoke Test

- [ ] Touchscreen navigation, keyboard entry, back/cancel, and screen refresh work.
- [ ] Door input changes state correctly and produces the expected event/alarm behavior.
- [ ] Temperature input, setpoint display, and simulated control response are correct.
- [ ] No unexpected heater/output activation occurs during boot or UI navigation.
- [ ] Time/date survives the expected reset/power cycle.
- [ ] SD logging creates records; reboot and reload preserve readable history.
- [ ] USB insertion/removal is detected and normal file browsing works.
- [ ] Export a small known date range and verify CSV filename, record count,
  timestamps, temperatures, and events. Evidence: ____________________
- [ ] Run for at least 30 minutes while monitoring reset cause, error counters,
  stack/heap indicators if available, control state, and UI responsiveness.
  Duration: ______ Result: ______

## 3. CR-08/09 — Filename and Keyboard Boundaries

- [ ] Enter an empty export filename; confirm the UI handles it without corruption.
- [ ] Enter a one-character filename and export successfully.
- [ ] Enter the maximum UI-accepted filename. Confirm the resulting name is
  terminated, has the expected extension, and opens on a PC.
- [ ] Attempt one character beyond the accepted maximum. Confirm input is rejected
  or bounded and adjacent UI/global state is unchanged.
- [ ] Exercise general keyboard entry at zero, one, maximum, and attempted
  over-maximum lengths; navigate away and back after each case.
- [ ] Repeat maximum-length entry/export ten times while SD logging continues.
- [ ] Inspect exported directory entries on a PC for malformed names or filesystem errors.
  Evidence: ____________________ Result: ______

## 4. CR-10 — Persisted Model Validation

Use an approved debugger/service method to corrupt only the persisted model index;
do not overwrite calibration or unrelated NVRAM fields.

- [ ] Establish a valid nonzero model, reboot, and record the displayed model/configuration.
- [ ] Inject model index `17` (first invalid value), cold-start, and confirm a
  configuration finding is reported, effective heat is inhibited, and every
  model-name/filename consumer uses a bounded safe fallback.
- [ ] Reboot again without reinjection and confirm the invalid requested value
  remains available for diagnosis and was not silently rewritten or persisted
  as model `0`.
- [ ] Inject `0xFF` or the field's maximum representable invalid value and repeat.
- [ ] Confirm no out-of-range text, corrupted screen, exception, or reset occurred.
- [ ] Use the approved explicit recovery action to restore the target's intended
  model, verify the finding clears, and verify it survives reboot.
  Injection method/evidence: ____________________ Result: ______

## 4A. Bounded Main-Temperature Calibration

Capture offset, raw temperature, adjusted temperature, sensor source, alarm
state, configuration hashes, and CID-linked controller/card identity before the
first mutation. Use the same frozen image for all cases.

Qualification scope on 2026-07-24: RTD is the only in-scope
main-temperature sensor. Execute RTD-applicable cases. LM73 hardware testing is
excluded by owner decision and must be recorded `N/A — LM73 outside approved
product/release qualification scope`, not deferred or passed.

- [ ] Customer reference-device calibration clamps the total offset at exactly
  `-10.0 C` and `+10.0 C`; an additional outward step cannot create an
  out-of-range configuration mutation.
- [ ] Service 514 always displays the fixed `[-10.0,+10.0] C` interval, reaches
  both inclusive endpoints, and cannot inherit setpoint-specific endpoint
  behavior; repeated saves at either boundary cannot walk the range.
- [ ] Cancel, malformed entry, and timeout leave the offset and persistence
  request unchanged.
- [ ] Inject a fingerprinted out-of-range offset and confirm it remains
  diagnostic, produces the expected finding, inhibits effective heat, and
  service 514 starts replacement entry at zero without an implicit save.
- [ ] Save an explicit valid replacement and confirm exact preservation through
  reboot and compatible firmware update.
- [ ] Repeat the applicable raw/adjusted/control/display/alarm/log checks with
  the RTD selection.
- [x] LM73 hardware qualification: `N/A — LM73 outside approved
  product/release qualification scope`; no LM73 release claim is permitted.
- [ ] Restore and record the intended final offset, sensor source, alarms, and
  configuration hashes on both controllers.
  Evidence: ____________________ Result: ______

## 5. CR-04 — NVRAM Completion Timeout and Recovery

This test requires a controlled way to suppress the NVRAM completion callback,
such as a test build, debugger breakpoint, or approved bus/test-jig fault.

- [ ] Record the fault-injection build/patch or physical method exactly.
- [ ] Suppress completion for the first startup NVRAM transfer.
- [ ] Confirm System Monitor does not remain blocked indefinitely; the bounded
  wait expires (configured as 100 ThreadX ticks).
- [ ] Confirm alarm monitoring and UI remain responsive after the timeout.
- [ ] Remove the fault and demonstrate a successful transfer or controlled recovery.
- [ ] Repeat for the second startup NVRAM transfer.
- [ ] Repeat fault/recovery for three cold starts; confirm no semaphore accumulation,
  deadlock, stack corruption, or watchdog loop.
  Timing/log evidence: ____________________ Result: ______

## 6. CR-03 — Internal Flash Entry Timeout

Do not run internal-flash fault injection without a verified probe recovery path.
Use an instrumented test build that forces the FENTRYR-ready condition to remain
false; do not physically damage or over-voltage the flash interface.

- [ ] Archive the exact instrumented source diff and resulting ELF.
- [ ] Invoke the flash-write path with forced FENTRYR timeout.
- [ ] Confirm `HptCodeFlashWriteOneBlock()` returns `SSP_ERR_PE_FAILURE` and does
  not spin indefinitely or underflow its timeout counter.
- [ ] Confirm no unintended internal-flash block changed (programmer compare/hash).
- [ ] Power-cycle and confirm the original application still boots.
- [ ] Restore the production image and perform programmer verify.
  Timing/programmer evidence: ____________________ Result: ______

## 7. CR-06 — SDRAM Layout and Runtime Exercise

Build evidence currently places display SDRAM through `0x90232800`, export data
through `0x90FF2580`, and chart data through `0x91A2A048`.

- [ ] Confirm the tested map contains those linker symbols and all three SDRAM
  assertions evaluate true.
- [ ] Populate enough SD history to exercise chart loading across its available range.
- [ ] Open, pan, and redraw charts repeatedly at oldest/newest boundaries.
- [ ] Export a large date range that materially fills the export SDRAM buffer.
- [ ] While exporting, exercise screen changes and chart redraws; confirm no
  framebuffer corruption, graphical artifacts, reset, or data corruption.
- [ ] Compare a sample of first/middle/last exported records with source logs.
- [ ] Repeat large chart load/export three times with a reboot between runs.
  Record counts/duration/evidence: ____________________ Result: ______

## 8. CR-02/07 — Malformed Update Rejection

Use copies of the normal update file. Preserve one untouched control image. Each
negative case must be rejected before QSPI erase/program activity. Capture the UI
result and, where possible, QSPI sentinel/hash evidence.

- [ ] Untouched valid image is recognized and reaches the expected confirmation flow.
- [ ] Header shorter than 256 bytes is rejected.
- [ ] Header CRC corruption is rejected.
- [ ] Update format version other than `1` is rejected.
- [ ] Wrong SMI machine-mask image is rejected.
- [ ] Main length `0` is rejected.
- [ ] Main length greater than `0x00400000` is rejected.
- [ ] Main length not divisible by 1024 is rejected.
- [ ] Nonzero I/O payload length is rejected for SMI.
- [ ] Audio length greater than `0x00480000` is rejected.
- [ ] Audio length not divisible by 1024 is rejected.
- [ ] File truncated in the main payload is rejected.
- [ ] File truncated in the audio payload is rejected.
- [ ] File with trailing bytes beyond declared payload lengths is rejected.
- [ ] Payload bit flip with unchanged CRC is rejected by the payload CRC check.
- [ ] Remove USB media during a read; confirm bounded failure and responsive UI.
- [ ] After every negative case, cold-start and verify application, SD logging,
  configuration, and a QSPI sentinel/hash remain unchanged.
  Corpus path and evidence: ____________________ Result: ______

## 9. Valid Update and Power-Interruption Recovery

Run the valid-update portion only after Sections 1–8 pass. Run physical
power-interruption cases only after G-PWR passes its witness gate.

- [ ] Install a valid compatible CRC-based update and confirm reported success.
- [ ] Cold-start three times; confirm expected version, settings, logging, UI,
  controls, and debugger/programmer connectivity.
- [ ] With a recoverable bench target, interrupt power once during each approved
  update phase: file read, QSPI erase, QSPI program, QSPI CRC verification, and
  internal-flash replacement.
- [ ] For each interruption, record whether the unit boots, rejects the partial
  image, retries, or requires probe recovery.
- [ ] Recover using the documented J-Flash procedure and verify the known-good image.
- [ ] Record any phase that can leave the target unrecoverable without a probe as
  a release risk; do not mark the workpackage complete without disposition.
  Evidence/recovery times: ____________________ Result: ______

## 10. Regression and Closeout

- [ ] Repeat the complete normal smoke test from Section 2 after all faults.
- [ ] Run continuously for the agreed soak interval: ______ hours.
- [ ] During soak, exercise door changes, temperature simulation, UI navigation,
  SD logging, chart viewing, USB insertion/removal, and at least one export.
- [ ] No unexpected reset, watchdog event, memory/display corruption, stuck
  progress screen, lost configuration, or control anomaly occurred.
- [ ] Collect final firmware version, reset cause, diagnostics, error counters,
  SD/USB artifacts, photos/video, debugger logs, and programmer verification.
- [ ] Restore intended production configuration/model/calibration.
- [ ] Remove all instrumented fault-injection firmware and verify the production image.
- [ ] Log every failure as a separate ticket linked to the parent workpackage.
- [ ] Reviewer confirms evidence is sufficient for each checked item.

## Final Sign-Off

| Role | Name | Result | Date | Signature / reference |
| --- | --- | --- | --- | --- |
| Tester | | | | |
| Firmware reviewer | | | | |
| Hardware reviewer | | | | |
| Product/release owner | | | | |

Overall result: `PASS / FAIL / BLOCKED`

Open failures, deviations, or accepted risks:

1. ___________________________________________________________________________
2. ___________________________________________________________________________
3. ___________________________________________________________________________

## Completion Rule

This checklist is complete only when all applicable items have evidence, all
instrumented builds are removed, production firmware is restored and verified,
failures have disposition, and the four sign-off rows are complete. Link the
finished evidence from the parent workpackage before closing it.
