uzbek-plus/r2/T3B-LK-EMMC-AUDIT.md
q 8d7721c775 B7: add network time bootstrap and persistent B7C cache
B7A: QMI DMS time vs VNIIFTRI NTP (DMS = UTC - 0.28 s, sigma 1 ms; NITZ = DMS
truncated to 1 s). B7B: a 1970 -> 2026 date -s step is harmless for the modem
stack. B7C: aurora-modem probes DMS/NITZ along the start flow and steps
CLOCK_REALTIME once at the first valid sample (REG registered/attached), never
RTC; background SNTP check (query only) after START OK. 3/3 class-A cold boots
PASS (residual +0.04/+0.36/+0.84 s), cache 14fe453a written (B7C_WRITE_VERIFIED)
and verified by a normal power-on (V1, +0.26 s).

Also publishes the prerequisite R2 (boot-hang / lk eMMC investigation, T4
telnet baseline that B7C builds on) and R3 (autonomous cold boot, NCM loss)
material, and extends tools/publish-sanitize.py to r2/, r3/, b7/.
Binary images, initramfs, busybox and raw logs stay out (see b7/*/SHA256SUMS).
2026-10-02 20:18:25 +03:00

8 KiB
Raw Blame History

R2/T3B: разбор инициализации eMMC в lk1st (lk2nd 23.1 e9c8b217), только чтение исходников

Исходник: lk2nd-build/src (clean tree, e9c8b21735c1). Бинарники не менялись и не собирались.

1. Путь до ошибки

app/aboot → platform_init() → target_init() (target/msm8916/init.c:204) → target_sdc_init() (init.c:102):

  • set_sdc_power_ctrl(1) — TLMM: drive strength и pull-up для линий SDC1 (init.c:325);
  • mmc_init(slot1, 8-bit, 177 MHz, hs400=0) (platform/msm_shared/mmc_sdhci.c:1761):
    • mmc_host_init() (:1094) → clock_init_mmc(1) + clock_config_mmc(1, 177M) + clock_config_cdc(1) → sdhci_msm_init() → sdhci_init() → sdhci_clk_supply(400 kHz);
    • mmc_card_init() (:1515) → mmc_reset_card_and_send_op() (:1207) → CMD0 (без ответа) → CMD1 (цикл) → mmc_identify_card() (:1162) → CMD2 → CMD3 → CMD9 → CMD7 → EXT_CSD, ширина шины, HS200…
  • если slot1 не отвечает, пробуется slot2 (SD-слот, карты нет, его ошибки штатные) → dprintf("mmc init failed!") → ASSERT(0) (init.c:129–130) → _panic() (lib/debug/debug.c:72).

2. Точка отказа

CMD2 ALL_SEND_CID (mmc_all_send_cid, mmc_sdhci.c:438). В sdhci_cmd_err_status (sdhci.c:378) выставлен бит SDHCI_CMD_TIMEOUT → печать «Error: Command timeout error», затем «Failure getting card's CID number!».

  • CMD0 не требует ответа и считается успешным всегда.
  • CMD1 прошёл: иначе была бы строка «Failure getting OCR response», а её на slot1 нет. Значит, карта ответила R3 с установленным битом готовности (OCR busy=1).
  • Отказ случается через ~10 мс после target_init() ([10] → [20]).

3. Таймауты и повторы

  • CMD1: до MMC_MAX_COMMAND_RETRY попыток с mdelay(1).
  • CMD2: без повтора. Одна ошибка — и весь slot1 объявлен сбойным.
  • mmc_init для slot1 вызывается один раз, повторной инициализации slot1 нет; при неудаче сразу ASSERT.
  • Ожидание CMD complete: SDHCI_MAX_TRANS_RETRY циклов опроса. Аппаратный таймаут ответа — 64 такта CLK (160 мкс на 400 кГц).

4. Какие сбросы делает lk

  • Контроллер: sdhci_reset(SDHCI_SOFT_RESET) (сброс всего SDHCI), очистка pwrctl IRQ, BUS_POWER_ON с рукопожатием через pwrctl IRQ (sdhci_msm.c:144–224, sdhci.c:248).
  • Карта: только программный CMD0 (GO_IDLE_STATE).
  • Нет: аппаратного сброса карты через RST_n, переключения питания VCC/VCCQ (L8/L5 — lk их не трогает), задержки после CMD0, проверки состояния карты (CMD13) перед CMD0.
  • После успешной инициализации lk включает RST_n_FUNCTION в EXT_CSD, если он выключен (mmc_sdhci.c, после bus width). Это одноразовое (OTP) поле eMMC. Скорее всего, оно уже выставлено на первом PASS-старте lk1st; проверить можно чтением EXT_CSD[162].

5. Что lk получает в наследство от SBL1 (не переинициализирует)

  • Питание eMMC: L8 (VCC ~2.9 В) и L5 (VCCQ 1.8 В) — включены SBL1/RPM, режим (LPM/NPM) и напряжение lk не меняет.
  • Состояние карты: SBL1 только что читал с неё TZ/HYP/aboot и оставил её в Transfer state, в своём режиме шины (ширина и частота по выбору SBL1).
  • Вендорные регистры SDCC (HC_MODE, VENDOR_SPECIFIC_FUNC, DLL/CDC). Soft reset SDHCI их не сбрасывает, lk часть перезаписывает (0xA1C → VENDOR_SPECIFIC_FUNC, HC_MODE_EN, FF_CLK_SW_RST_DIS).
  • GCC-клоки SDCC1 (lk перенастраивает через clock framework) и TLMM (lk перезаписывает hdrive/pull).

6. Сравнение со stock LK Aurora

  • Stock aboot собран из того же CAF platform/msm_shared/{sdhci,sdhci_msm,mmc_sdhci}.c: в бинарнике те же строки «Failure getting card's CID number!», «mmc init failed!», HS200/HS400.
  • Stock — release-сборка, MMC-сообщения не печатаются. target_init у stock другой (вендорский): «Panel power on done» на [210] мс, «Config SPI PANEL». Порядок инициализации SDC и панели по UART не установить.
  • Stock-цепочка (stock TZ.BF.2.2 + stock HYP) ни разу не показала этот panic в ~35 загрузках, включая 5 стартов класса A. Но для lk на stock-цепочке это не доказательство: stock-сборка могла зависнуть молча.

7. Сравнение с JZ02

  • JZ02: lk1st 23.1-next-8b46487c (8b46487, 2026-09-20) + DB410c TZ + qhypstub — та же схема.
  • git diff e9c8b217..8b46487 по platform/msm_shared, target/msm8916, platform/msm8916: изменён только mmc.c (коммит 3b7896f, таймаут записи MCLK в старом драйвере, msm8916 им не пользуется) и qpic_nand.c. Код eMMC у Aurora и JZ02 идентичен.
  • На JZ02 старты с полным сбросом PMIC (класс A) не проверялись.

8. Upstream

  • Upstream HEAD на 2026-10-01 = 8b46487 (клон с GitHub). После 23.1 в mmc_sdhci.c / sdhci.c / sdhci_msm.c / msm8916 нет коммитов про cold boot / CID / повторы.

9. Что происходит после panic

  • lk1st: PANIC_REBOOT_MODE ?= EMERGENCY_DLOAD (lk2nd/project/lk1st.mk:5). Штатно _panic → дамп → platform_halt() → печать «HALT: reboot into EMERGENCY_DLOAD» → reboot_device(EMERGENCY_DLOAD) → warm reset в режим EDL.
  • На деле (D2) вывод обрывается после строки irq r13 в dump_fault_frame(): нет строк svc/und/sys, panic (caller …), ASSERT FAILED, HALT…. Плата не ушла в EDL, а через 14.8 с сбросилась через PS_HOLD (0x80A=02) и нормально загрузилась.
  • В lk1st для msm8916 watchdog не взводится (WDOG_SUPPORT не задан; msm_wdog_init только под #if). APSS WDT в Linux: EN=0. Что роняет PS_HOLD через ~15 с, не установлено (кандидаты: watchdog TZ/RPM, взведённый на время загрузки).
  • Если бы lk дошёл до reboot_device(EMERGENCY_DLOAD), плата, вероятно, ушла бы в EDL 9008 и не загрузилась бы сама. Зависание дампа сейчас «спасает» автономность.

10. PASS против FAIL (класс A)

Вывод lk совпадает до [10] target_init(). Первая расходящаяся строка:

  • PASS (D1, B5, D3b): MMC card: H4G2a (0.2, 05 2002) … → «SDHC Running in …» → штатный отказ SD-слота → загрузка;
  • FAIL (D2): [20] Error: Command timeout error → [30] Failure getting card's CID number!.

Те же «зависания lk после target_init()» с самосбросом через ~15 с были после warm reboot -f (14:27:22, 02:49:13; UART тогда обрезался). Судя по всему, это тот же panic, и он не привязан только к классу A.