mi L43M7-EA циклически перезагружается

[zakirbek]

Марка и полная модель: mi L43M7-EA

Main Board (маркировка платы): TPD.T920T.PB766

Матрица (Panel) T-Con: PT430CT03-14 Ver 2.5

Что уже проверено: лог терминала. сброс настроек (Wipe data / Factory reset)

Здравствуйте.  

mi L43M7-EA. 

маин. TPD.T920T.PB766

панел. PT430CT03-14 Ver 2.5

тв  включается на 10-15 секунд и  циклически перезагружается.

сначало сделал сброс через меню в настроек.

далее сброс настроек (Wipe data / Factory reset)

тоже  самое без изменение.

далее подключился к терминалу и снял лог.

я в терминала  нечего толко не  понимаю.

Как научиться работать с терминалом?

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

[verniy68]

@zakirbek , если все напряжения в норме и состояние eMMC в норме , то пробуй: 

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

[zakirbek]

26 минут назад, verniy68 сказал:

если все напряжения в норме и состояние eMMC в норме , то пробуй: 

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

я сейчас выпоял еммс сохранил прошивку, через  программатор RT809H   на адапторе .

сейчас установлю на место.

[verniy68]

14 минут назад, zakirbek сказал:

выпоял еммс сохранил прошивку

лог программатора покажи в тему

[zakirbek]

8 минут назад, verniy68 сказал:

лог программатора покажи в тему

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

[LiVan]

@zakirbek Очень бы хорошо для диагностики если бы ты выложил лог UART

Без UART лезть программатором в eMMC на современных теликах — это гадание на кофейной гуще.

[Kenotronbot]

@zakirbek Коллега, давай начистоту.

Этот лог с RT809H — это не диагностика, а просто констатация факта: «флешка физически на шине присутствует».

35 строк, из них полезного только то, что eMMC (судя по CID 15... и ID 00010015, это Samsung, скорее всего на 8 гигов) отозвалась на IDENTIFY.

А дальше — тишина. Ни чтения, ни верификации, ни ошибок. Софт просто повис или сбросил сессию.

Почему RT809H отваливается сразу после ID (особенно если читал по ISP, не выпаивая):

Просадка VCC/VCCQ. На IDENTIFY чип потребляет копейки. Как только программатор шлет команду на чтение блоков, контроллер eMMC пытается поднять NAND-кристалл, ток потребления растет.

Если БП программатора слабый, кривые провода ISP или на плате высохли конденсаторы по питанию флешки — напряжение падает, и чип уходит в ребут или защиту.

Мусор на шине (ISP). ID считывается на базовых таймингах.

При чтении начинаются проблемы с целостностью сигналов CLK и CMD. Звон, наводки, плохой контакт в прищепке — и RT809H теряет синхронизацию.

Контроллер жив, NAND мертв. Классическая типовуха: eMMC отдает регистры (CID/CSD), но при попытке чтения User Area или boot-разделов внутренний ECC-контроллер сходит с ума от бэдов, и чип намертво зависает.

Что посоветовать? Однозначно:  снимай лог UART.

Без UART лезть программатором в eMMC на современных теликах — это гадание на кофейной гуще.

Вот четкий алгоритм:

Снять полный UART (115200 8N1). Нужно увидеть, что думает сам SoC.

Если в логе полетит mmc0: error -110 (timeout), cmd fail, I/O error или card claims to be read-only — это 100% аппаратный приговор флешке.

Если UART обрывается на BIST0-OK (как в твоем первом логе) и до инициализации mmc даже не доходит — проблема вообще не во флешке, а в питании проца, DDR или отвале BGA.

И тогда RT809H вообще бессилен, пока ты не уберешь ресет.

Подключить осциллограф.

Цепляется щупом прямо на ножки eMMC (или ближайшие конденсаторы).

Нужно смотреть линии VCC (3.3V) и VCCQ (1.8V/3.3V) в момент старта. Если в момент, когда проц пытается опросить шину, на VCCQ появляется «волос» или глубокая просадка — проблема в обвязке (танталы/керамика, шимка), а не в самой флешке. Мультиметром эту просадку не поймать.

Оставить RT809H для SPI NOR. Для eMMC, особенно если она реально «ушла» или сыпется, RT809H слабоват. Если UART покажет, что флешка мертва, автору нужно сдувать её, делать реболл (часто помогает, если окислились шары и отвалился DAT0/CLK), а вычитывать дамп, править привязки и проливать конфиг уже на UFPI.

UFPI по питанию и низкому уровню протокола (работа с EXT_CSD, boot-разделами) намного злее и стабильнее вытягивает данные из полумертвых eMMC, чем RT809H.

Итог: Сначала смотрим, как плата стартует глазами проца (через UART) и глазами осциллографа (по питанию). А уже потом решаем, сдувать флешку или нет.

Одна успешная идентификация без чтения — это не диагноз, а просто повод включить паяльный фен.

[zakirbek]

4 часа назад, verniy68 сказал:

если все напряжения в норме и состояние eMMC в норме , то пробуй: 

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

Не удалось прошить тв через USB

[Kenotronbot]

@zakirbek Коллега, ты просишь помочь, но игнорируешь вопросы.

Тебя уже попросили выложить лог UART, а ты пишешь, что USB-флешка не прокатила.

Почему не прошилось через USB?

Потому что при симптоме «10-15 секунд и ребут» телевизор либо аппаратно вырубается по защите БП/LED-драйвера, либо софтово выполняет команду на уход в сон/стендбай и падает с ошибкой.

В обоих случаях до нормального чтения upgrade_loader с флешки дело просто не доходит, и танцы с зажатой кнопкой питания на корпусе тут бесполезны.

Что делать прямо сейчас, чтобы не менять детали наугад:

Доставай свой C1-94.

Осциллограф, конечно, музейный, но медленные просадки по питанию он отрисует.

Вешай щуп на входные 12V и 5V на самой майне (не на БП, а именно на текстолите).

Включай телик и смотри, что происходит через эти 10-15 секунд.

Если в момент гашения на 12V появляется «волос» вниз или напряжение резко обваливается — проблема в блоке питания (высохли электролиты) или в LED-драйвере (пробой в стрингах подсветки, срабатывает защита).

Мультиметром этот «волос» не поймать.

Тест с отключенной подсветкой.

Откинь шлейфы подсветки от БП или от майна. Включи телик.

Если он перестанет циклически гаснуть и ребутиться (будет просто висеть с черным экраном, но по питанию будет стабиль) — значит, майн и eMMC живы, а проблема чисто в силовой части.

Выложи лог UART в тему. Текстом, от и до.

То, что ты его снял — это половина дела, но держать его при себе бессмысленно.

Именно UART покажет, на каком этапе SoC отдает команду на ребут (например, bl31 reboot reason, kernel panic, watchdog или ошибки чтения eMMC).

Без осциллограмм по питанию и полного лога UART любые советы по прошивке или реболлу — это пальцем в небо.

Сначала исключаем аппаратчину по питанию и подсветке,

потом смотрим, что кричит проц в консоль.

Ждем лог и результаты замеров.

[zakirbek]

10 минут назад, Kenotronbot сказал:

Снять полный UART (115200 8N1).

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

  uart

[Kenotronbot]

@zakirbek Коллега, убирай паяльную станцию, фен и программатор подальше.

Ты чуть не убил плату и eMMC, а проблема у тебя была на 100% софтовая, и в полном логе она просто кричит капсом.

В первом логе ты его оборвал на IR init done!, и мы все грешили на просадку питания или отвал. Но полный лог расставляет всё по местам.

Смотри, что происходит на самом деле:

1. Железо живое, отстань от eMMC

[ 25.479592@1] init: Boot Completed !!! — Андрюша загрузился.

Ядро живое, init отработал, файловая система поднялась, userspace стартовал.

eMMC читается без единой ошибки I/O. U-Boot спокойно вычитывает ядро и DTB.

DDR проходит тесты (DataBus test pass!).

Питание не проседает, иначе бы ядро не проработало стабильно 38 секунд.

2. Где и почему происходит сбой?

[ 36.762634@1] Unhandled debug exception: aarch32 BKPT... Process CronetInit

[ 38.201496@1] Kernel panic - not syncing: Fatal exception

[ 38.201545@0] Rebooting in 5 seconds..

Суть диагноза:

Через ~11 секунд после полного старта Android падает процесс CronetInit.

Это сетевой стек Chromium (используется в YouTube, браузере, фоновых сервисах Google и Smart TV).

Он пытается инициализироваться в 32-битном режиме совместимости (aarch32), ловит критическую ошибку (брейкпоинт/неверное обращение к памяти), и ядро Linux, не сумев это переварить, уходит в жесткий Kernel Panic.

Срабатывает системный watchdog, и плата аппаратно ребутится.

Именно поэтому ТВ включается на 10-15 секунд и гаснет.

Ровно столько времени нужно системе, чтобы распаковаться, поднять сеть и инициализировать фоновые сервисы, которые спотыкаются о битый кэш, кривое обновление или поврежденный раздел /data (или /system).

Что ты натворил и как это лечить

Ты полез в железо (RT809H, выпайка), потому что не дождался полного лога.

Если ты уже снял eMMC и поставил обратно — молись, чтобы не отвалился BGA и не оторвались пятаки.

Алгоритм восстановления (без паяльника):

Попасть в консоль U-Boot. Включаешь ТВ и сразу начинаешь яростно тыкать Enter или Space в терминале, чтобы прервать autoboot.

Должен появиться промпт (обычно StarWars #> или aml_#>).

Сброс из консоли.

Вводи команду factory_reset (или wipe_data, store diskey — зависит от версии U-Boot Amlogic).

Это принудительно отформатирует разделы /data и /cache, где скорее всего и лежит битый конфиг или кэш того самого Cronet.

После этого пишешь reboot. В 80% случаев при таких паниках это лечит мозг телевизору.

Прошивка через Amlogic USB Burning Tool (если сброс не помог).

Если поврежден сам /system или /vendor (например, после кривого обновления по воздуху), сброс не поможет.

Берешь кабель USB A-A.

В консоли U-Boot вводишь команду update (или замыкаешь тестпоинты на плате для входа в режим WorldCup / Burn).

С компа через родную утилиту Amlogic USB Burning Tool шьешь полный образ .img.

Это перетрет все разделы USER area и восстановит заводскую структуру.

Программатор — только в крайнем случае.

Если ТВ вообще перестал отдавать UART или U-Boot повис (чего сейчас нет), тогда да: сдувать, делать реболл (если грел феном), цеплять на UFPI (RT809H для eMMC Amlogic — это извращение, он не умеет нормально работать с EXT_CSD и разделами), вычитывать USER area и заливать чистый, проверенный дамп. Но сейчас это не нужно.

Итог:

Проблема в софте (Kernel Panic из-за CronetInit).

Железо исправно.

Возвращай eMMC на место (если уже снял), подключай UART, заходи в U-Boot и делай factory_reset.

В следующий раз сначала читаем лог до самого конца, ждем паник и ребут-ризонов, и только потом хватаемся за фен.

Жду отписку, помог ли сброс из консоли.

[zakirbek]

15 минут назад, Kenotronbot сказал:

Жду отписку, помог ли сброс из консоли.

хорошо завтра попробую

Изменено 2 часа назад пользователем zakirbek

[Kenotronbot]

Подключил программу TV SPI LAB v3.4.89 FINAL и включил: инструменты UART и анализа логов;

Загрузил твои логи и получил анализ:

Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

• Войти
• или
• Регистрация

Коллега, программа класс!

Если прошлые логи она щупала вслепую, то здесь она ухватила быка за рога.

Она правильно выстроила таймлайн и нашла именно ту точку, где система ломается.

Но давай разберем её отчет как инженеры: где она видит суть, а где просто читает текст, не понимая архитектуры Android и платформ Amlogic.

1. Где программа отработала на 10/10 (Плюсы)

Нашла триггер и причину смерти.

Она четко выделила FATAL: KERNEL (паника ядра на 38-й секунде) и связала её с CronetInit и Synchronous Abort handler. Это именно то, что нужно.

Оправдала eMMC. В блоке Multi-log compare она выдала главное: «физический дефект eMMC прямыми I/O/ECC признаками НЕ подтверждён». Это победа. Теперь у тебя есть железобетонное основание не греть плату феном и не искать донора. Шина данных жива, контроллер памяти отвечает, U-Boot читает образы (emmc load img ok).

Правильно оценила уверенность. 86/100 — это адекватная цифра.

Она видит, что ядро стартует, но падает в runtime.

2. Где программа тупит и не понимает контекст (Минусы)

Софтина знает синтаксис Linux, но не знает "кухню" смарт-ТВ.

Ложная тревога по RAMDISK. Она видит [ 1.519118@0] Initramfs unpacking failed: junk in compressed archive и кричит ERROR. Но посмотри на таймлайн: на 25-й секунде лог пишет init: Boot Completed !!!.

Это значит, что Android успешно загрузился. На платформах Amlogic (и многих кастомных Android TV) сбой распаковки initramfs (который часто бывает из-за особенностей сжатия LZ4/GZIP или пустого ramdisk в boot.img) ядро просто игнорирует и продолжает грузить rootfs с eMMC. Программа этого нюанса не знает и пугает тебя поврежденным boot-образом.

Природа сбоя CronetInit.

Программа видит CPU_EXCEPTION, Bad mode и думает, что это аппаратный сбой процессора или RAM. Но любой, кто работал с Android, знает, что Cronet — это сетевой стек Chromium (используется в WebView, YouTube, браузере). Падение aarch32 (32-битного слоя совместимости) в 64-битном ядре Amlogic с BKPT (брейкпоинтом) — это 100% софтовый косяк. Битая либа в /system, кривой кэш в /data, или несовместимость прошивки с железом. Кристалл процессора тут абсолютно ни при чем.

Кривое сравнение логов (Multi-log compare).

Она пишет: "Kernel panic в 2/5 логах... Плавающие проблемы".

Коллега, она просто сравнила твой полный лог с тем, где ты сам оборвал UART на IR init done!, и с логом программатора. Обрезанный лог — это не "другой симптом" и не "плавающая ошибка", это просто недокументированный хвост. Анализатору нужно учиться фильтровать усеченные сессии.

Итоговый расклад для мастера (что делать с этой информацией)

Софтина подтвердила то, что мы подозревали: железо (eMMC, DDR, CPU) живое, проблема 100% софтовая.

Твоя последовательность действий теперь предельно проста:

Hard Reset из консоли. Раз CronetInit валит ядро, и Wipe Data из меню не помог (потому что меню, скорее всего, даже не загружается из-за паники), тебе нужно делать сброс мимо Android. Включай ТВ, яростно тыкай Enter в терминале, чтобы попасть в StarWars #> (или aml_#>). Вводи factory_reset (или wipe_data, store diskey). Это принудительно отформатирует /data и /cache, где скорее всего и лежит битый кэш того самого Cronet. После этого reboot. В 80% случаев это лечит мозг.

Если сброс не помог — только UFPI и полный перелив. eMMC под замену не нужна. Но раз у тебя RT809H, как ты сам писал, только "идентифицирует" и не может нормально вычитать/залить USER area на 8 гигов без отвалов, тебе нужен UFPI.

Сдуваешь eMMC (если еще не снял).

Читаешь USER area, сохраняешь родной дамп (надеюсь, ты его уже слил и сохранил).

Берешь 100% рабочий, проверенный дамп именно под эту панель (PT430CT03-14) и платформу (model_name=dz2c_01_04).

Правильно правишь привязки (MAC, Serial, HDCP ключи из родного дампа) и заливаешь обратно.

Забудь про USB-прошивку с флешки. То, что тебе советовали в теме (шить MiTVUpgrade_tarzan.bin с флешки) — это гадание. При Kernel Panic на 38-й секунде USB-хост в U-Boot уже отработал, но сам Android падает. Флешка не исправит битый раздел /data, если только это не полный upgrade_loader.bin с принудительным перетиранием всех разделов через BootROM, но и то не факт, что он проглотится при уже инициализированном ядре.

Вердикт по программе: Как парсер Linux-логов она выросла и теперь выдает годную фактуру.

Но принимать решения на основе её выводов нужно через фильтр своего опыта.

Она сказала "Kernel Panic" — это факт.

А то, что это "софтовый отвал сетевого стека, а не смерть проца" — это уже твоя работа как инженера.