# Isolated 32 KiB USB recovery controller deployment

Status: complete
Type: evidence
Updated: 2026-08-01
Next Action: none; the USB09 regression and final broad-baseline sequence are complete

Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md
Workpackage: work/wp/completed/wp-restore-broad-usb-compatibility-baseline.md
Checklist: work/checklists/checklist-stage-1b-four-drive-usb-compatibility-baseline.md

## Authorized candidate

- Existing owner authorization covered serial-bound controller programming.
- Source commit: `8fa1479b6b942f72f18ff4ed2cb1a5c73ddc2501`.
- Frozen-candidate manifest commit: `d7cb1eaa`.
- Release S-record SHA-256:
  `82A277EEBBED0CC4FBDDCC848ACEFD43E706849803673C4920E7851FC2ACABB5`.
- Release ELF SHA-256:
  `6A2D8F79D72387311C83599663B192FCF764F53AB3E0926E3B917F3746B426CA`.
- Expanded 4 MiB candidate internal-flash SHA-256:
  `B0E8A7B41F10FCB073823DBBBCB975A563F8190D9B0D1636C2FFEE571AA67BB0`.
- The exact ignored generated candidate artifacts were used directly. The
  older tracked Release outputs were not substituted.

## Rollback capture

Before programming, both controllers were captured independently across the
complete 4 MiB internal-flash range. Each capture matched the previously
deployed session-recovery candidate.

| Controller | Assembly | J-Link | Bytes | Captured SHA-256 | Prior candidate match |
| --- | --- | --- | ---: | --- | --- |
| B | `1751219` | `69660123` | 4,194,304 | `429D5B2FFE72148288FAD79D8E7DDE160F74A5C0F6325439E44B1EDE42152C1A` | PASS |
| A | `1751136` | `69664082` | 4,194,304 | `429D5B2FFE72148288FAD79D8E7DDE160F74A5C0F6325439E44B1EDE42152C1A` | PASS |

The prior Release S-record SHA-256 was
`0FE12FCE02C411378D1AF45EB11C1AC27694A5D69613830FD970865518C72B3F`.
Controller A's pre-deploy USB application error count of 2 was the preserved
USB09 failure state; it reset to zero after programming and reboot.

## Serial-bound deployment and readback

Controller B was programmed and verified first. Only one 32 KiB flash range
changed, consistent with the isolated source delta. B passed full readback and
post-reboot health before the identical candidate was programmed to A. A then
showed the same single-range change and passed the same gates.

| Controller | Hardware variant | Program and verify | Full readback | Candidate match |
| --- | ---: | --- | --- | --- |
| B | 1 | PASS | `B0E8A7B4...67BB0` | PASS |
| A | 0 | PASS | `B0E8A7B4...67BB0` | PASS |

## Post-reboot controller and SD identity

| Gate | Controller A | Controller B |
| --- | --- | --- |
| Complete raw CID | `035344535330384780976F0084018559` | `035344535330384780976F0085018507` |
| CID available / driver status | `1 / 0` | `1 / 0` |
| MID / OEM / product | `03 / SD / SS08G` | `03 / SD / SS08G` |
| Revision / serial | `8.0 / 2540634244` | `8.0 / 2540634245` |
| Manufacturing date | `2024-05`, valid | `2024-05`, valid |
| SD state / identity / sector read | `5 / 1 / 1` | `5 / 1 / 1` |
| HPT state / status / SSP status | `5 / 0 / 0` | `5 / 0 / 0` |
| HPT mismatch / lost / replace-media | `0 / 0 / 0` | `0 / 0 / 0` |
| System errors / USB application errors | `0 / 0` | `0 / 0` |
| USB mounted / attached | `0 / 0` | `0 / 0` |
| Pending storage / FileX media pointer | `0 / 0` | `0 / 0` |

No SD card was removed or inserted. Programming reset each controller, so the
post-reboot CID and representative-sector evidence is a fresh identity gate.

## Evidence locations

Raw captures remain in ignored controller-specific directories:

- `work/evidence/hpt-log-store-circular-mirror/controller-a/usb-32k-recovery-deployment-20260731/pre-deploy/`
- `work/evidence/hpt-log-store-circular-mirror/controller-a/usb-32k-recovery-deployment-20260731/post-deploy/`
- `work/evidence/hpt-log-store-circular-mirror/controller-b/usb-32k-recovery-deployment-20260731/pre-deploy/`
- `work/evidence/hpt-log-store-circular-mirror/controller-b/usb-32k-recovery-deployment-20260731/post-deploy/`

## Disposition

The exact isolated 32 KiB candidate is deployed identically and passes the
controller, full-flash, and SD baseline gates on both hardware variants. This
clears USB09 and broad-matrix testing. It does not qualify USB compatibility
or authorize erasing USB09's preserved failed filesystem. That media action
requires explicit owner approval; the failure content is already hash-backed
and summarized in tracked evidence.

The owner subsequently authorized and completed a full Windows FAT32 format.
USB09 then passed exact identity, equal-FAT, filesystem, full-device direct
read, capacity, content, unmounted-state, and kernel-error gates on the Pi.
See `work/evidence/usb09-post-windows-format-pi-health-20260731.md`.
