Благое дело мыслят умные люди и как тут не помочь такому, могу предоставить рабочие прошивки практически новых тв 15-17 год выпуска для экспериментов скачанные лично мной, с миру по нитке смотри и сварганится рабочий софт для не совсем легкой роботы над телевизорами, сделаем некую интеллектуальную складчину не для широких масс
Группа: Пользователи
Сообщений: 8
Статус: Offline
onkyo, а вот возвращаясь к Вашему методу получения идеальной прошивки не могли бы Вы подсказать такой момент..
По факту, мы же получаем не дамп NAND, а образ самой системы, который потом нужно будет разложить по страницам или я ошибаюсь?
И второй момент — купил пару новых NAND, прошил, но аппарат так и весит в постоянном перезагрузе.
Очень смутила эта эта тема и подпаялся к CN801_dbug.
А в ответ кроме «Hello UART» ничего больше не прилетает (причем может высыпать и «Helvo UARj»).
Скажите, этот порт обязательно нужно переключать в режим DBUG через сервис?
32M9000 NAND firmware problem
Это я к чему.
По идее, даже при условии что аппарат перезагружается, информацию о NAND и начальную загрузочную инфу в порт должно вываливать, а этого не происходит.
Отсюда 2 вопроса:
1. Можно ли изменить параметры порта с UART на DBUG с применением программатора?
2. Или все же склонить голову над мертвым процессором?
Цитата talkos ( )
Благое дело мыслят умные люди и как тут не помочь такому, могу предоставить рабочие прошивки практически новых тв 15-17 год выпуска для экспериментов скачанные лично мной, с миру по нитке смотри и сварганится рабочий софт для не совсем легкой роботы над телевизорами, сделаем некую интеллектуальную складчину не для широких масс
Меня уже трясти начинает от этой NAND))
Я уже готов хоть все с 0 сделать программатор и софт написать, главное чтобы работало все без танцев с бубнами и не было возвратов.
Сейчас в ярой погоне за информацией по данной тематике.
Вообще, было бы отлично написать софт, который будет иметь обширную базу прошивок если не ко всем, то к большей части аппаратов.
Воткнул NAND в программатор, выбрал аппарат и пошел чай пить — вот к чему стремиться нужно.
Группа: Пользователи
Сообщений: 84
Статус: Offline
вот то что есть пока в наличии но пополнение почти каждый день один два тв вычитывается.
ктото говорил просто открываеш прошивку в рар архиваторе и там наблюдаеш теже вышеописаные папки с файлами и даже без проблем можно вытащить любую папку и также вставить обратно . много инфи есть на скрытом форуме монитора и некаждому дано почитать ети талмуты уже пройденого етапа с нашей проблемой — приходилось както глазком взглянуть туда и чесно говоря можно день ети прелести читать прям розжевали на малекулы но такое количество инфи нужно немало времени и желания переварить и понять что написано. одно помню точно ребята знают точно где вылетает тот самый злощастный бит или два правят и никто непарится бед блоками .
Источник: www.willem-ua.com
Телевизор LG 32LB650650V висит на заставке. Шьём eMMC
Как прошить нанд флеш в телевизоре без программатора
Есть майн TP.MS608.P83 у которого слетел Андроид. Есть такой же майн рабочий. Есть прогеры RT809F и Easy-NAND Tiny Tools. В рабочем майне стоит нанда THGBM5G5A1JB, в нерабочем — SDIN7DP2-4G. Обе в копусах на шарах. Прогер RT809F через VGA подключается к процессору и определяет его как MSD6A608, видит флеху 25Q16 и читает ее.
Можно ли с таким набором перелить прошивку нанды с одного майна на другой?
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Статус: отсутствует
Участники
Для просмотра сообщения Вы должны быть Участником форума. Для этого Вам необходимо Зарегистрироваться и пройти Тест.
Источник: remont-aud.net
NANDкромантия: трансплантация флэш-памяти наживую
Нередко при анализе встроенной системы происходят преднамеренные, а иногда и нет, изменения, которые приводят к тому, что целевая система выходит из строя и впадает в так называемое состояние «кирпича». В некоторых случаях для ее реанимации достаточно выполнить сброс к заводским настройкам, в иных же приходится прошивать систему при помощи интерфейса отладки (JTAG/SWD/*) или вручную через внешнее устройство памяти (SPI/NOR/Nand/eMMC). В данной статье мы рассмотрим весьма креативный метод «раскирпичивания» системы после подобного сбоя.
Как-то в свободное время я возился с памятью маршрутизатора, где в качестве загрузчика использовалась прошивка CFE (Common Software Environment). В ходе моего взаимодействия с CFE в попытке определить аргументы, передаваемые при загрузке в ОС устройства, конфигурация системы была случайно повреждена:
CFE> b Press: to use current value ‘-‘ to go previous parameter ‘.’ to clear the current value ‘x’ to exit this command 94908AC5300R —— 03 94906REF —— 07 GT-AC2900 —— 08 Board Id : 8 X
В тот момент я понял, что для сохранения этих случайных изменений осталось выполнить заключительную операцию сохранения/записи, поэтому решил просто физически перезапустить устройство, чтобы избежать внесения изменений. После перезапуска возникла ошибка:
Shmoo WR DM WR DM 0000000000111111111122222222223333333333444444444455555555556666666666 0123456789012345678901234567890123456789012345678901234567890123456789 00 ——++++++++++++++++++++++++++X+++++++++++++++++++++++++++———- 01 —+++++++++++++++++++++++++X++++++++++++++++++++++++++—————- 02 X——————————————————————— 03 X——————————————————————— MEMSYS init failed, return code 00000001 MEMC error: 0x00000000 PHY error: 0x00000000 SHMOO error: 0x10c00000 0x00000082 0x00000000
Когда маршрутизатор снова заработал, то тут же выдал вышеприведенную ошибку и в CFE не вошел.
Без возможности обратиться к загрузчику конфигурацию изменить было нельзя, а процесс его восстановления тоже не представлялся возможным. Онлайн-поиск решения по этой ошибке ничем не помог и привел в тупик. Единственным выводом было, что при повреждении CFE подобным образом устройство впадает в состояние «кирпича». Тогда я переключился на работу с резервным девайсом, чтобы получить ответ на изначальный вопрос по интересовавшим меня аргументам. К слову говоря, установка kernp mfg_nvram_mode=1 mfg_nvram_url=BADURL была особенно интересна.
Позже я вернулся к своему «кирпичу», чтобы найти способ его восстановления. В нем используется Broadcom SoC, и, как выяснилось, доступ к JTAG обеспечивается через нераспаянные контакты на плате:
После перебора контактов JTAG с помощью JTagulator мне удалось подключиться, используя OpenOCD.
$ openocd -f ../interface/jlink.cfg -f bcm49.cfg Open On-Chip Debugger 0.11.0-rc2+dev-gba0f382-dirty (2021-02-26-14:07) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html DEPRECATED! use ‘adapter speed’ not ‘adapter_khz’ Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : J-Link V10 compiled Dec 11 2020 15:39:30 Info : Hardware version: 10.10 Info : VTarget = 3.323 V Info : clock speed 1000 kHz Info : JTAG tap: bcm490x.tap tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x5) Info : JTAG tap: auto0.tap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4) Info : JTAG tap: auto1.tap tap/device found: 0x0490617f (mfg: 0x0bf (Broadcom), part: 0x4906, ver: 0x0) Info : JTAG tap: auto2.tap tap/device found: 0x0490617f (mfg: 0x0bf (Broadcom), part: 0x4906, ver: 0x0) Info : bcm490x.a53.0: hardware has 6 breakpoints, 4 watchpoints
Другой способ восстановления системы реализуется через флеш-память, а именно микросхему Macronix NAND:
И здесь я задумался. У меня ведь есть рабочее устройство, на котором я вполне могу запустить загрузчик. А что, если при этом попробовать заменить его рабочий чип NAND на поврежденный, чтобы перепрошить?
Прежде, чем что-либо пробовать, я спросил коллегу, что он думает по поводу столь дурацкой идеи. Оптимистичных прогнозов он не дал, да и я, честно говоря, на них не особо рассчитывал. В итоге мы заключили небольшое пари по результату моего эксперимента, и я вернулся к работе.
Первым делом предстояло выяснить, переживет ли система удаление NAND в работающем состоянии? Я понимал, что для ответа на этот вопрос мне потребуется более методический подход, нежели просто «обдать работающее устройство горячим воздухом и извлечь микросхему». Для начала нужно было выяснить, как NAND запитана. Судя по схеме, Vcc подключены к микросхеме в следующих местах:
Определив дорожки подключения Vcc, проще всего ответить на основной вопрос можно было отключив их от NAND при работающей системе. Чтобы это сделать, изначально я попробовал отсечь эти дорожки и добавить проводные перемычки (рекомендую 36 AWG Magnet Wire), которые можно будет разъединить после запуска загрузчика:
С правой стороны я отсек трассу питания подальше, решив, что это место будет более удачным, поскольку от него запитывается несколько контактов NAND. При установке первой перемычки трассу я отсек небольшим ножом и зачистил покрытие абразивным карандашом:
Получилось так себе, потому что карандаш оказался великоват, и в итоге я оголил чересчур большой участок. Лучше использовать остроконечный нож, чтобы не натворить бардак и получить что-то подобное:
Припаяв и соединив провода, я запустил маршрутизатор и, дождавшись старта загрузчика (CFE), с помощью команды dn (dump nand) убедился в доступности NAND, затем обесточил микросхему, разъединив провода.
CFE> dn —————— block: 0, page: 0 —————— 00000000: 00000000 00000000 00000000 00000000 . 00000010: 00000000 00000000 00000000 00000000 . 00000020: 00000000 00000000 00000000 00000000 . ———— spare area for block 0, page 0 ———— 00000800: ff851903 20000008 00fff645 c2b9bf55 . . E. U 00000810: ffffffff ffffffff ffee9423 4ba37819 . #K.x. 00000820: ffffffff ffffffff ffee9423 4ba37819 . #K.x. 00000830: ffffffff ffffffff ffee9423 4ba37819 . #K.x. *** command status = 1 CFE> web info: Waiting for connection on socket 1.␛[J CFE> web info: Waiting for connection on socket 0.␛[J CFE> ␀—-
После отключения питания (отмечено как Vcc removed ), устройство перезагрузилось и не смогло запустить загрузчик, так как NAND была недоступна. Проблема оказалась в том, что точка отсечения питания справа отключала его подачу не только на NAND, но и на SoC. Чтобы не усложнять, я просто восстановил этот отрезок и проделал всю ту же процедуру с установкой перемычки в точке ближе к NAND:
Вернув систему в строй и повторив предыдущий тест, я получил ответ на изначальный вопрос: когда питание отключается разъединением проводов перемычки, система продолжает работать, что подтверждается командой dn :
dn —————— block: 0, page: 2 —————— Status wait timeout: nandsts=0x30000000 mask=0x80000000, count=2000000 Error reading block 0 00001000: 00000000 00000000 00000000 00000000 . Status wait timeout: nandsts=0x30000000 mask=0x80000000, count=2000000 ———— spare area for block 0, page 2 ———— 00000800: 00000000 00000000 00000000 00000000 . 00000810: 00000000 00000000 00000000 00000000 . 00000820: 00000000 00000000 00000000 00000000 . 00000830: 00000000 00000000 00000000 00000000 . Error reading block 0 *** command status = -1 CFE> CFE> CFE> dn —————— block: 0, page: 3 —————— 00001800: 00000000 00000000 00000000 00000000 . 00001810: 00000000 00000000 00000000 00000000 . ———— spare area for block 0, page 3 ———— 00000800: ffffffff ffffffff ffee9423 4ba37819 . #K.x. 00000810: ffffffff ffffffff ffee9423 4ba37819 . #K.x. 00000820: ffffffff ffffffff ffee9423 4ba37819 . #K.x. 00000830: ffffffff ffffffff ffee9423 4ba37819 . #K.x. *** command status = 1
После того, как я убедился в возможности отключения NAND на работающей системе без влияния на загрузчик, очередным шагом было попробовать физически извлечь отключенную NAND из платы.
Прогрев микросхему горячим воздухом, я поочередно приподнял пинцетом сначала правую, а затем левую стороны:
В результате этого процесса система перезапустилась и провалила попытку войти в загрузчик:
Так как стороны микросхемы при ее отсоединении я поднимал поочередно, посматривая при этом в консоль, то стало очевидно, что перезагрузка произошла при подъеме именно левой стороны:
Наиболее вероятной причиной было изменение состояния контактов Read Enable (RE#) или Ready/Busy (R/B#). Чтобы это проверить, я добавил к обоим перемычки:
Тут NAND пришлось установить на место, чтобы вернуть систему в загрузчик. Затем я в очередной раз отключил ее питание, разъединив ведущие на Vcc провода, а дорожкиRE# и R/B# привязал к земле:
Затем я снова поочередно извлек правую-левую стороны микросхемы, поглядывая в консоль загрузчика:
На этот раз он остался активен, и система в перезагрузку не ушла. Закончив очередной этап головоломки, я перешел к следующему – установке поврежденной NAND в работающее устройство.
Для припаивания NAND снова использовался горячий воздух. Первая попытка оказалась безуспешной, так как некоторые контакты замкнуло при моей попытке выровнять чип по обеим сторонам. На этом этапе ввиду сбоя в очередной раз пришлось ставить обратно рабочую NAND.
Во второй попытке я уже использовал небольшой листок бумаги для изолирования одной стороны NAND на время выравнивания и закрепления другой:
После установки первой стороны бумажку я убрал и припаял вторую. Загрузчик остался активен. Следующим шагом нужно было восстановить контакты RE#, RB# удалением заземляющей перемычки, а также вновь соединить перемычку Vcc. После окончательного восстановления подключения я выполнил dn , чтобы убедиться в доступности NAND:
CFE> dn —————— block: 0, page: 0 —————— 00000000: 00000000 00000000 00000000 00000000 . 00000010: 00000000 00000000 00000000 00000000 . 00000020: 00000000 00000000 00000000 00000000 . ———— spare area for block 0, page 0 ———— 00000800: ff851903 20080000 00c2b822 c978ff97 . . «.x.. 00000810: ffffffff ffffffff ffee9423 4ba37819 . #K.x. 00000820: ffffffff ffffffff ffee9423 4ba37819 . #K.x. 00000830: ffffffff ffffffff ffee9423 4ba37819 . #K.x. *** command status = 1
Тест чтения завершился успешно, и через веб-интерфейс загрузчика я прошил микросхему заводским образом:
Как видно из вывода, прошивка прошла успешно, и система загрузила ОС устройства.
Уверен, некоторые читатели спросят: «Почему просто не использовать для перепрошивки NAND специализированный программатор?» Это абсолютно уместный вопрос, и, быть может, так даже правильнее, чем заниматься всей этой чепухой.
И все же считаю, что здесь будет уместна цитата персонажа из к/ф «Парк Юрского периода», которого играл Джефф Голдблюм:
Ваши ученые настолько озабочены вопросом о том, могут ли они что-то сделать, что забывают приостановиться и подумать, а надо ли вообще это делать.
- ruvds_перевод
- flash-память
- nand
- восстановление данных
Источник: habr.com