Y2 SD SDR104 stability — research and diagnostic candidate 3

Source and software record, 2026-10-02. Candidate 2 negotiated SDR104 on a real Y2 and fell back to DDR50 under sustained reads. This page records why the old tuning could not have found a stable operating point, what the MT6582 controller actually implements, and what diagnostic candidate 3 adds. Candidate 3 was flashed on 2026-10-02 and characterized over SSH; the measurements are in "Physical characterization of candidate 3". Candidate 4 follows from them and has not been flashed.

Evidence from the installed candidate 2

The interface works at 200 MHz, but not for a sustained load. It is not proof that SDR104 is impossible. A clean 128 MiB read is not a qualification.

What the old SD tuning really did

Decoding tune_pad with the MT6582 MSDC_PAD_TUNE layout (below):

Two defects explain these numbers.

1. A 64-step sweep on a 32-tap delay line. Mainline mtk-sd.c chooses

   tuning_step from MMC_CAP2_NO_MMC: 64 for a host that cannot do MMC. The Y2 SD host declares no-mmc, so it swept 64 steps. MT6582 delay fields are 5 bits wide. Steps 32 to 63 re-tested tap 31, and the "second half" registers mainline writes at PAD_TUNE + 4 are MSDC_DAT_RDDLY0 on this controller (offset 0xf0), not a second tuning register.

2. No failing tap. get_best_delay() returns len / 3 for a window that

   starts at tap 0. For an all-pass 64-step map that is 64 / 3 = 21, which is exactly what both command and data picked, in two independent tunings. Neither sweep saw a failing tap, so "21" was arbitrary and said nothing about the timing eye.

The CMDRRDLY / CLKTXDLY values come from the same bug. sdr_set_field() does not mask its value, so the internal-delay sweep at step 38 wrote 38 << 22: the low five bits landed in CMDRRDLY (6) and bit 5 set bit 27, CLKTXDLY (1). The retune picked 42 and produced 10 and 1. The card clock output delay was therefore shifted by one tap as a side effect.

This is a hypothesis about timing margin, not a measured eye. The decoded registers and the arithmetic fit it. The pass maps added by candidate 3 settle it.

MT6582 MSDC register facts

Sources: the MediaTek MT6582 BSP mt6582/sd.c (register dump and the msdc_tune_* functions), and the stock Y2 kernel functions msdc_set_sr, msdc_set_smt, msdc_set_rdtdsel, msdc_set_driving, msdc_pin_pud, disassembled from the retained stock kernel.

The stock autok code (msdc_autok_*) is the SDIO 3.0 calibration of the WiFi host (it scans over core voltage). It is not a model for the SD slot.

What candidate 3 changes

No electrical setting changes: voltage, pad drive and the clock source are exactly candidate 2's.

Windows are linear: Y2_TUNE_CIRCULAR is 0 because tap 31 is not adjacent to tap 0 on this delay line. The helper supports a circular line and is tested for it.

Diagnostics reference

Both attributes live under /sys/bus/platform/devices/11240000.mmc/ (SD) and 11230000.mmc (eMMC, y2_storage_diag only). Every line is key=value or key: field=value ....

y2_storage_diag:

y2_tune_diag: for the first and the latest tuning, the registers at the end of the sweep, then per phase (cmd, cmd_int, data) the pick (edge, delay, window, eye width, margins, open, clipping, window counts, what the old get_best_delay would have chosen) and, per scanned edge, the all map (every try passed), the any map (at least one try passed) and the passing windows. Bit n of a map is tap n.

Only the first failure of a boot is logged (Y2 storage first fault:). Later failures are counted without logging.

Characterization interface (y2_lab)

Root-only (0600) on the SD host. Unmount the card first: a marginal operating point can fail reads.

Physical characterization of candidate 3

Flashed 2026-10-02 (6.18.0-y2linux-sd-sdr104-diag-03), SD128 119 GiB UHS-I card, SDR104 at 199 999 771 Hz, 1.8 V (vqmmc_mv=1800, vmmc_mv=3300). Read-only raw reads of /dev/mmcblk1, iflag=direct.

What the new diagnostics showed

What does not fix SDR104. Each point renegotiates SDR104 through y2_lab (level SDR104), applies the setting, then reads raw 16 MiB chunks and stops at the first CRC:

So the failure is a 200 MHz signal-margin problem that no sampling-phase setting recovers: all four data lanes fail, on both edges, at any delay. SDR50 (100 MHz) and SDR104 timing capped at 100 MHz are clean and run at about 42 MB/s, the same as DDR50. The clock tree offers nothing between 100 and 200 MHz (the shared MSDCPLL is the only source).

Candidate 4

Two untested dimensions remain, both backed by evidence rather than guesses:

1. Host input pads. The stock msdc_set_smt / msdc_set_rdtdsel (bic-only,

   so they write zero) leave MSDC1 with Schmitt inputs on CLK/CMD/DAT and RDSEL = TDSEL = 0 at both voltages. Linux leaves LK's `SMT=0, RDSEL=12, TDSEL=5`. Candidate 4 programs the stock values for the SD host together with the drive, at the same two places (probe and the 1.8 V switch). The eMMC pads are unchanged.

2. Card output driver type. The host had no select_drive_strength hook, so

   the core always used type B. Candidate 4 adds the hook and advertises types A, C and D for the SD host. The default is still B; y2_lab can request A, C or D for the next negotiation (set drvtype=1|2|3, then level SDR104).

y2_lab also gains smt_clk|cmd|dat, pull_clk|cmd|dat, rdsel and tdsel, so the LK values can be restored for an A/B comparison on the same boot.

Characterization plan

1. For each setting, level SDR104, set the field, read raw chunks to the first

   CRC (the harness above), and record the registers before reading.

2. If a setting reaches multi-GiB with zero faults, repeat on other offsets and

   for much longer, with hashes, then run the full qualification list: repeated multi-GiB reads, runtime suspend and resume, idle and wake, repeated mode setup and reboot negotiation, zero CRC, timeouts, resets and unexpected fallbacks.

3. If nothing reaches 200 MHz, the production ceiling is the 100 MHz modes

   (SDR50, or SDR104 timing capped at 100 MHz), with DDR50 behind them.

Candidate 4 receipt

Not flashed, not pushed, no physical result.

Tests

tests/test_sd_tuning.py (23 tests): window detection, wrap-around on a circular line only, midpoint and margins, the open eye, multiple windows, narrow-eye rejection, edge selection, command and data CRC classification, fault log first/last and lane histogram, pad cell decoding, pad readback and set through the real pinctrl.c code, RXDLYSEL, a simulated controller that runs the real tuning code (separate command and data picks, flaky taps, failure with register restore, open eye), the diagnostic output and its one-page budget, and fallback cause. tests/test_storage_ceiling.py keeps its contracts. Both run in tools/production/tests.sh.

Candidate receipt

Not flashed, not pushed, no physical result. Owner action: flash this package's BOOTIMG and Y2ROOT with the preserve-data scatter.