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

61 lines
8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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.