Serial M-PHY storage
Power rails, reset, reference clock, M-PHY differential lanes, device descriptor, LUNs, RPMB and health attributes.
ANDROID DIAGNOSTICS / UFS • eMMC • ISP • HEALTH
Storage faults.
Storage faults.
Follow the evidence.
Separate power, reset, clock, bus/link, controller, health, boot-partition and firmware-evidence failures without jumping directly to reballing or donor replacement.
STORAGE INITIALIZATION HIGHWAY
POWERVCC / VCCQ
RESETRST_N
CLOCKREF_CLK / CLK
LINKM-PHY / CMD
IDDescriptor / CID
BOOTLUN / BOOT1
Voltage alone cannot prove storage health. Power, protocol activity, identity and media-state evidence must be combined.
01 — STORAGE PROTOCOL DOMAINS
UFS and eMMC fail differently
The uploaded source separates UFS M-PHY/link behavior from eMMC parallel command/data-bus behavior. AIFlasher keeps them as different diagnostic systems.
Parallel command/data storage
VCC/VCCQ, CLK, CMD, DAT0–DAT7, DS, CID/CSD/EXT_CSD, BOOT1/BOOT2, RPMB and User Area.
Direct storage evidence
Use programmer detection, identity, health and read/write behavior as evidence. ISP wiring quality can itself create false failures.
02 — STORAGE BOOT SEQUENCE INTELLIGENCE
Find the first stage that never completes
These are technician-level startup sequences derived from the uploaded source. Exact controller timing, PHY training and SoC-specific boot policy remain platform-specific.
SELECTED SEQUENCE
| Order | Stage | Voltage / State | Source | Signal / Protocol | If Abnormal | Confirmation |
|---|
LIVE STARTUP CHECK
Mark each stage from the bench
Mark observed stages as present, missing, unstable or unknown.
03 — STORAGE FAILURE PROFILER
Symptom → stage → proof → repair path
The uploaded source includes strong example cases. V1 keeps their measurements and workflows but avoids turning one current pattern or one GR reading into a guaranteed IC diagnosis.
SELECTED STORAGE CASE
Source evidence
Bench measurements
Interpretation
04 — MASTER STORAGE VOLTAGE / GR DATABASE
Power, clocks, buses and link lines
Values below are retained as uploaded-source reference values. They should be replaced by exact model/board known-good data whenever available.
| Protocol | Rail / Signal | Operating Voltage | GR / Diode | Resistance | Signal / Scope | Evidence Use |
|---|
Compare one storage test point
Enter at least one measurement.
Compare paired lines instead of one reading
Use paired measurements as supporting evidence, not automatic proof of a cracked BGA ball.
05 — HEALTH / IDENTITY / PARTITIONS
Storage can be electrically alive but logically unhealthy
Direct programmer or software readout should separate identity, health, boot partitions, LUN configuration and write behavior.
Descriptor / manufacturer / model / capacity
Confirm that the device enumerates and reports consistent identity before blaming partitions or firmware.
Life Time A / B + Pre-EOL
Use reported health fields to support wear analysis. A health value alone does not explain every boot failure.
LUN0–LUN7 / Boot LUN / RPMB
Check expected logical units, boot source and read/write behavior where the tool supports it.
CID / CSD / EXT_CSD
Verify manufacturer, capacity, bus capabilities, boot configuration and extended device state.
Life Time Estimation + Pre-EOL
The uploaded source uses EXT_CSD life-time fields as wear evidence. Preserve raw values and tool/version context.
BOOT1 / BOOT2 / RPMB / User Area
Separate boot-partition corruption from media wear and from power/bus failure.
HEALTH INTERPRETER
Record raw health values
06 — STORAGE COMPATIBILITY EVIDENCE MODEL
Do not confuse host capability with donor support
Firmware evidence is divided into three separate axes so compatibility conclusions do not overreach.
Requirement Evidence
Provisioning/rawprogram metadata, partition requirements, expected storage layout and capacity constraints.
Answers:What does this firmware build expect?Host-Ceiling Evidence
SoC/PHY limits from XBL_CONFIG, DTS, storage drivers, gears, lanes, rate and reference clock configuration.
Answers:What can the host interface support?Device-Keyed Support
Tables that explicitly key behavior to storage-device identity. MediaTek preloader EMI tables are the important device-keyed example.
Answers:Is this specific device explicitly supported?
Compatibility rule:
Qualcomm XBL/Firehose strings and generic host parameters must not be treated as a storage donor whitelist. Host capability evidence and device-keyed support are different things.
07 — ISP / SOCKET FORENSICS
Direct access is a test instrument, not a verdict
The uploaded source contains practical ISP guidance. V1 keeps the useful workflow but avoids universal cable-length or reball conclusions as absolute rules.
Power first
Confirm correct VCC/VCCQ levels and common ground before interpreting CMD/M-PHY failures.
Short signal path
Keep high-speed ISP wiring physically short and clean. Exact acceptable length depends on adapter, frequency, impedance and topology.
Lower bus speed
For unstable eMMC ISP, reduce clock and use 1-bit mode where supported before calling the storage dead.
Identity before write
Read CID/CSD/EXT_CSD or UFS descriptors and health before flashing or changing configuration.
Backup first
Dump critical boot, modem/calibration and user-related partitions before destructive repair when the device is readable.
RPMB caution
Preserve raw RPMB state/tool evidence. Do not assume every used donor can be made bootable by “cleaning” RPMB; implementation and keying are platform-specific.