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