Driver–firmware integration boundary

Firmware implementation is owned by the firmware team and is outside this Wiki’s repository scope. The driver still owns the host side of the integration contract and cannot be documented as though firmware were absent.

Scope model

flowchart LR
  subgraph Driver_Project[Driver project scope]
    IOCTL[WBF IOCTL / service request]
    Device[CBiometricDevice update and command orchestration]
    VFM[VFM device-update process]
    SSI[niseCore sensorUpdate and command processor]
    ABI[biometrics-include packed command ABI]
    PAL[PAL USB / SPI transport]
    IOCTL --> Device --> VFM --> SSI --> ABI --> PAL
  end
  subgraph Firmware_Team[External firmware-team scope]
    Handler[Firmware command handlers]
    State[Sensor state machine and algorithms]
    Boot[Bootloader / MFW / configuration storage]
    Handler --> State
    Handler --> Boot
  end
  PAL -->|command ID + packed request| Handler
  Handler -->|status + packed reply / event| PAL

Ownership contract

Concern	Driver-project responsibility	Firmware-team responsibility	Joint evidence
Command ABI	Select command IDs, serialize packed requests, parse replies, map status/error codes and preserve ABI headers.	Implement command semantics and firmware-side validation/state transitions.	Shared command/version specification plus host and firmware tests.
Transport and timing	USB/SPI I/O, request lifetime, timeout/retry/reset behavior, power-state coordination.	Endpoint behavior, response timing, sleep/interrupt behavior.	Trace from host request through firmware reply under normal and fault conditions.
Firmware/configuration update	Authorize request path, validate input context, compare product/version, verify signed patch where enabled, drive multi-step update, persist restart context and count failures.	Produce compatible signed MFW/configuration payloads, bootloader/update implementation and recovery behavior.	Update matrix by product/version, success/failure/recovery tests and version read-back.
IOTA	Select customer IOTA/configuration, validate project rules, submit/read configuration and report errors.	Interpret and persist supported IOTA types and values.	IOTA schema/rule compatibility and device read-back.
Runtime behavior	Map firmware replies/events to WBF/VFM behavior and Windows-visible errors.	Capture, finger-detect, match/security and device-state behavior behind commands.	End-to-end scenario tests; host-only mocks are insufficient.
Firmware source	Out of scope; do not infer internal algorithms.	Owned, reviewed and released by firmware team.	Reference released firmware version/artifact, not private implementation source.

Driver-side update sequence

sequenceDiagram
  participant U as Windows/service IOCTL
  participant D as CBiometricDevice
  participant V as VFM
  participant S as niseCore sensor module
  participant F as Firmware/bootloader
  U->>D: firmware or IOTA payload
  D->>D: validate and copy input, select external update type
  loop until complete or error
    D->>V: vfmDeviceUpdateProcess(action/context)
    V->>S: sensorUpdate
    S->>S: validate product/version/payload/signature policy
    S->>F: bootloader patch/configuration commands
    F-->>S: status/reply/reset requirement
    S-->>V: action ID + output context
    V-->>D: action/result
    opt reset/restart required
      D->>D: persist update context and operation flag
    end
  end
  D-->>U: completion HRESULT

Observed source behavior includes product compatibility checks, version/build comparison, optional patch verification, bootloader patch download, IOTA update handling, restart-context persistence, and bounded consecutive-failure counting. This documents host behavior only; it does not certify the firmware implementation.

Primary driver-side anchors

• WBF: CBiometricDevice::DoDeviceUpdate, OnUpdateFirmware, OnUpdateIOTA, SendCommand.
• niseCore API: SSI_IOCTL_CODE_CMD_SEND and sensorUpdate.
• Tudor update: product/version/signature checks and MFW/IOTA update state.
• Tudor command processor: command allocation, transport, reply status mapping and concrete v4 commands.
• Shared ABI: vcsfw_v4.h and extension headers.

Jira movement at this boundary

The one-month summary-only classification found 16 firmware/IOTA/UEFI/EFI/command-related issues, five currently unresolved. Representative active work is IOTA rule coverage (HDRFP-12216, HDRFP-12258), EFI timeout behavior (HDRFP-12046, HDRFP-12047) and UEFI ForceClear hang (HDRFP-12200). These issues may be driver-owned, firmware-owned or joint; assignment requires inspecting the failing side and command trace, not merely the word “firmware.”

Required compatibility evidence

• Exact driver refs/SHAs, hardware product ID, firmware/MFW/config version and update payload identity.
• Command/request/reply or event trace with secrets/biometric data removed.
• Expected versus actual status mapping and timeout/reset behavior.
• Host-side focused tests plus device/firmware integration result.
• For an update: pre-version, update decision, signature/product check, reset/recovery path and post-version read-back.