Восстановление прошивки и сброс пароля XM с помощью USB UART

[Sonya]

Он же из загрузчика выполняется, соответственно действуют те же ограничения.

[bulka58807]

update.img для 140 тоже не помог?

Он может быть и помог бы, но рег наотрез не хотел даже начинать считывать образ с USB флешки.
Я тут же взял другой файл update.img для рега 107, загрузил на эту же флешку, вставил в рег 107-ой - перезагрузил и при запуске появился экран с загрузкой, побежали проценты и всё нормально обновилось.

А эта модель 140 не делает! Я и разные USB порты пробовал.

[Sonya]

А эта модель 140 не делает! Я и разные USB порты пробовал.

Значит попался кривой загрузчик, который не понимает даже USB. Я тоже намучился с этими моделями: то нет лога в UART (отключен в загрузчике), то он не может ничего перезаписать (хотя стирает). В общем, без пайки не обошлось.

[AlienP666]

Значит попался кривой загрузчик

Интересно как это выявить? Ведь будь он не кривым возможно и лок снимался бы целиком.

[Sonya]

Интересно как это выявить? Ведь будь он не кривым возможно и лок снимался бы целиком.

В логе пишется дата и версия загрузчика.

U-Boot 2010.06 (Mar 31 2015 - 14:11:0 - - в этом загрузчике заблокирован вывод в консоль
U-Boot 2010.06 (Jan 14 2017 - 11:22:32) - загрузчик не имеет sf lock 0, запись на флеху не производит
U-Boot 2010.06 (Apr 14 2018 - 13:56:29) - в загрузчике есть sf lock 0
U-Boot 2010.06-svn270 (Nov 14 2015 - 10:16:16) - sf lock там нету , но проблем с локами у меня на нем не было

[AlienP666]

Эта инфа есть по версиям сборки, но больше всего интересно именно опознавание кривого бута. U-Boot 2010.06-svn1125 (Jul 02 2018 - 10:37:03) вот такой не реагирует на Ctrl-C с программатора CH340G, из-за него пришлось восстанавливать старый дешевый программатор на PL2303. Кривость бута, его особенность или кривость программатора?

[Sonya]

не реагирует на Ctrl-C с программатора CH340G, из-за него пришлось восстанавливать старый дешевый программатор на PL2303. Кривость бута, его особенность или кривость программатора?

Скорее всего, дело в самом устройстве. Очень часто на UART не запаивают резисторы, защитные и "подтягивающие", из-за чего и возникают проблемы. Один преобразователь работает с этой платой, а другой - уже нет.

[AlienP666]

не реагирует на Ctrl-C с программатора CH340G, из-за него пришлось восстанавливать старый дешевый программатор на PL2303. Кривость бута, его особенность или кривость программатора?

Скорее всего, дело в самом устройстве. Очень часто на UART не запаивают резисторы, защитные и "подтягивающие", из-за чего и возникают проблемы. Один преобразователь работает с этой платой, а другой - уже нет.

Да возможно, тем более что у меня одних УАРТ только разных 6 штук. Работают с этим бутом из них только 2 на PL2303 (разной компоновки) и то один работает криво .

[PorterSV]

Здравствуйте. Купил на Али камеры (2 штуки) IPG-84HE20PY-S (Hi3516Ev100+IMX307). Пришли с одним МАС адресом. Дамп слил через UART.

Код: Выделить всё

https://yadi.sk/d/PXjoyJV7XXphFw

нужна помощь по смене МАКа на любой другой.

Код: Выделить всё

xmtech # printenv
bootargs=init=linuxrc mem=${osmem} console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=squashfs mtdparts=hi_sfc:0x30000(boot),0x2E0000(romfs),0x300000(user),0x160000(web),0x40000(custom),0x50000(mtd)
bootcmd=setenv setargs setenv bootargs ${bootargs};run setargs;sf probe 0;sf read 83000000 30000 2E0000;squashfsload;bootm 0x82000000
bootdelay=1
baudrate=115200
bootfile="uImage"
da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
dl=mw.b 0x82000000 ff 1000000;tftp 0x82000000 logo-x.cramfs.img;sf probe 0;flwrite
dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
ua=mw.b 0x82000000 ff 1000000;tftp 0x82000000 upall_verify.img;sf probe 0;flwrite
tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 uImage;setenv setargs setenv bootargs ${bootargs};run setargs;bootm 0x82000000
dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
de=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.env.img;sf probe 0;flwrite
NID=0x0001
muxctl0=0x12040064
muxval0=0x0
gpio0=0x77
gpioval0=0x00
muxctl1=0x12040104
muxval1=0x00
gpio1=0x82
gpioval1=0x04
osmem=39M
appCloudExAbility=CWp2yRh961M=
appSystemLanguage=SimpChinese
appVideoStandard=PAL
appNetIP=0x0B01A8C00x00FFFFFF0x0101A8C0
netmask=255.255.255.0
ipaddr=192.168.1.10
serverip=192.168.1.107
ethaddr=00:12:17:e0:09:4c
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06-svn1125 (Jul 02 2018 - 10:37:03)

Environment size: 1772/65532 bytes

может кто разбирался, как это сделать.

[dede]

Вы уверены, что маки одинаковые? Не с бута ж проверяли? Лучше написать продавцу, если действительно одинаковые, менять на любой при использовании облака нельзя, могут быть коллизии

[PorterSV]

МАКи одинаковы, все локально, без облака. Продавцу писал, тишина.

[AlienP666]

Недавно попался рег XM NVR с запоротым фастбутом, на реге был установлен не всем привычный SPI, а NAND. Я немного удивился, проверил несколько раз, что плата от XM и потом уже принялся за восстановление. Первое, что выяснилось, этот NAND на XM не залочен вообще никак и планируется это сделать только в ближайшем будущем. Соответственно такого плана реги оставлять без паролей совсем нельзя.

При подключении UART по логам было сразу понятно, что проблема с фастбутом. Рег тут же при загрузке начал нервно искать USB и файл fastboot.bin на нем, пришлось обрезать uboot.img из прошивки рега и скормить его через USB на рег. Регистратор после таких действий загрузился в "фантомном режиме", часть команд была урезана, но для возможности слить с него dump необходимые команды присутствовали. Дамп был снят одним целым разом и ничего делить, а потом клеить не пришлось. Что делать с fastboot? Мысль сразу мелькнула в голове про Hitool, благо со времен китайского мининвр такие вещи у меня остались в разных исполнениях и под разные процы. Проц я знал и так и вычислять его не пришлось - Hi3798M. Открыл Hitool, залил через него, ранее обрезанный, fastboot и рег стал загружаться до радуги. Тут же обрадованный взял USB закинул на него update.img и стал смотреть за процессом восстановления, но после восстановления рег по прежнему висел на радуге. После этого пришлось немного попотеть т.к. команды run du, run dw, run dr, run dc рег принимал спокойно и записывал все необходимые данные, но загружаться рег отказывался наотрез, возможно я что-то упустил, но область предварительно зачищалась и после заливались необходимые модули. В итоге решил опять вернуться к update.img, но загрузить уже его через команду run up и вот оно, после того же процесса (как с USB) это чудо ожило.

P.S. Надеюсь описанные действия помогут в дальнейшем тем - кто с этим столкнется.