Sensor map
Measure what can explain action.
Rails, VRMs, retimers, inlet/outlet, accelerator module, coolant/airflow assumptions, board zones, and service-relevant FRUs.
Case 03 - BMC / Validation
BMC Bring-up and Validation Matrix
A hardware-facing platform management plan: power-on sequencing, sensor map, event log schema, fault injection, factory hooks, and service evidence for AI server platform bring-up.
Public-reference note
This page does not claim production AI-server BMC ownership. Its method is grounded in verified power sequencing, SmartVID/PMBus, board bring-up, platform validation, NPI, RCA, and checklist experience.
Bring-up State Machine
The BMC should make hardware state explicit.
A platform does not become easier to debug merely because it has sensors. The state machine must explain which dependencies are checked, which events are latched, which retries are allowed, and when hardware evidence is preserved for failure analysis.
1
Standby alive
BMC boots, inventory loads, board ID and FRU data are readable, standby rails are in range.
2
Pre-power checks
Thermal sensors present, fan/pump or airflow assumptions valid, critical PMBus devices respond.
3
Rail sequencing
Input, intermediate, accelerator, retimer, memory, and housekeeping rails ramp with expected dependencies.
4
Reset release
Clock stable and rail-good conditions are confirmed before host and fabric resets are released.
5
Host/fabric observation
Enumeration, link speed/width, AER counters, and retimer status are logged against the BMC timeline.
6
Stress and service mode
Workload, thermal, and fault-injection events preserve enough evidence for validation and field triage.
Log schema
Preserve causality.
Timestamp, source, state transition, rail ID, sensor ID, correlation ID, fault latch, retry counter, service action.
Ownership
Hardware owns the meaning.
Firmware may implement the log, but hardware/system integration must define thresholds, dependencies, and diagnostic value.
Validation Matrix
Validation should produce evidence a factory or field team can reuse.
| Test | Purpose | Pass signal | Escalation signal |
|---|---|---|---|
| Sensor presence | Detect missing or swapped devices before power-on. | All expected devices respond with stable IDs and sane readings. | Missing sensor, duplicate address, out-of-range default, inconsistent FRU data. |
| Sequence margin | Confirm rail and reset ordering under delay and tolerance variation. | Power-good dependencies hold across cold/warm cycle and brownout assumption. | Reset releases before dependent rail, rail-good chatter, retry loop, hidden latch. |
| Fault injection | Verify the platform reports actionable faults rather than generic failure. | Correct fault code, preserved evidence, expected service action, no collateral damage. | Ambiguous event, lost log, incorrect severity, unsafe auto-retry, no FA breadcrumb. |
| Thermal policy | Validate derating and protection behavior with platform workload. | Throttle reason, sensor map, power reduction, workload context, recovery criteria. | Unexpected throttle, sensor mismatch, hotspot not observed, policy oscillation. |
| Factory hook | Make production screening cheaper than field rediscovery. | FCT script captures rail, sensor, inventory, and fabric smoke-test bundle. | Manual-only inspection, missing serial traceability, no golden-log comparison. |