прошивка DAHUA 5116HS-X

Осталась одна мелочь, не могу восстановить родной мак адрес. Прерываю загрузчик "*" ввожу мак с помощью "setenv ethaddr" и "saveenv", но после перезагрузки он прежний. Подскажите пожалуйста, как быть? И нужно ли восстанавливать серийник с помощью "setenv serialno", его и посмотреть потом негде?
 
Все, преписал и MAC адрес и сеийник. Там походу всегда загружается два загрузчика: первый - урезанный (svn3134), он нифига не меняет, а вот во втором (svn4554) и нужно тормозить и вводить "setenv ethaddr" и "setenv ID" и "saveenv".
System startup

U-Boot 2010.06-svn3134 (Apr 14 2018 - 03:06:43)

Check Flash Memory Controller v100 ... Found
SPI Nand(cs 0) ID: 0xef 0xaa 0x21 Name:"W25N01GV"
Block:128KB Page:2KB Chip:128MB*1 OOB:64B ECC:4bit/512
SPI Nand total size: 128MB
*** Warning - bad CRC or NAND, using default environment

NAND read: device 0 offset 0x100000, size 0x100000
1048576 bytes read: OK

NAND read: device 0 offset 0x200000, size 0x100000
1048576 bytes read: OK

NAND read: device 0 offset 0x200000, size 0x100000
1048576 bytes read: OK
Header CRC Checking ... OK
Data CRC Checking ... OK
## Starting application at 0x41000080 ...

System startup

U-Boot 2010.06-svn4554 (May 13 2024 - 21:26:04)

Check Flash Memory Controller v100 ... Found
SPI Nand total size: 128MB
===============================================
DPLL:466Mhz DDR:1864Mhz
APLL:1400Mhz VPLL0:297Mhz
===============================================
BDB: partid = 9; addr = 0x48c0000
BDB: partid = 9; addr = 0x4940000
BDB: partid = 9; addr = 0x4a00000
BDB: partid = b; addr = 0x48c0000
BDB: partid = b; addr = 0x4940000
BDB: partid = b; addr = 0x4a00000
Dectected gmac0 phyaddr set to 0, is it right?
nice find PHY TRL8211 on higmac
ETH0: PHY(phyaddr=0, rgmii) link UP: DUPLEX=FULL : SPEED=100M
mcu i2c fail
mem= 482
Config/hwidconfig not found!
Hit any key to stop autoboot: 0
hisilicon
hisilicon # reset
resetting ...

System startup
 

Техпідтримка VidiMost.com

Спеціаліст
Команда форуму
BDB: partid = 9; addr = 0x48c0000
BDB: partid = 9; addr = 0x4940000
BDB: partid = 9; addr = 0x4a00000
BDB: partid = b; addr = 0x48c0000
BDB: partid = b; addr = 0x4940000
BDB: partid = b; addr = 0x4a00000
Але у вас судячи з логу залишились бедблоки на флешці і тому невідомо скільки у вас пропрацює пристрій, тому ми міняємо флешку і записуємо чистий дамп новий.
 
Але у вас судячи з логу залишились бедблоки на флешці і тому невідомо скільки у вас пропрацює пристрій, тому ми міняємо флешку і записуємо чистий дамп новий.
Дякую за пораду, згоден, що заміна флешкі - надійніше. Я не дуже розбираюсь в операційній системі Dahua, але chatGPT трактує ці строки по іншому:
BDB — это внутренние отладочные сообщения, появляющиеся на стадии инициализации флеш-памяти и разделов NAND в прошивке Dahua.
BDB — модуль, читающий Board Data Block или Boot Debug Block.
partid = 9 и partid = b — идентификаторы NAND-разделов, представленные в шестнадцатеричном виде:
9 = 9
b = 11 (в десятичной системе)
addr = 0x48c0000 и т.п. — это адреса блоков памяти NAND, откуда читается информация.

В прошивках Dahua, особенно на HiSilicon SoC (как у тебя Hi3531D), такие обращения к BDB происходят:
Для чтения данных о конфигурации, MAC-адресе, серийном номере и пр.
Для поиска резервных копий данных (чаще всего читаются сразу несколько адресов подряд).
Разделы с partid = 9 и b (11) могут быть, например, config, custom, env, или user_data — нужно смотреть в mtd таблицу или в firmware.img.
Эти строки означают, что загрузчик/ядро ищет конфигурационные или пользовательские данные в NAND-разделах с ID 9 и 11.
Он проверяет несколько возможных местоположений (возможно, с резервированием), чтобы загрузить нужную информацию (например, настройки системы или сетевые параметры).
 

Максим Шелест

спеціаліст компанії "UARTservice"
Мій ШІ показує як 4 варіанти: Boot data block; Bad data block; Board data block; Backup data block
Судячи з досвіду, з 100% випадків, коли XVRxxxx-X має проблему з прошивкою і симптоми як у Вас, флешка пошкоджена у 60% випадків. Так, можна повторно накатати дамп на биту флешку і може навіть попрацює якийсь час.
 

Andy

Well-known member
У всієї серії XVRxxxx-X проблема з мікросхемами nand-пам'яті, це їх дитяча хвороба, якщо так можно висловитися.
Тому найкращий вихід це заміна флешки, але потрібен дорогий програматор, на ch341 таку флешку не запрограмуєш.
Мені попався XVRxx32-X пару тижнів тому, там було в два рази більше помилок, ніж у вас, відновив прошивку через юсб-флешку, але на скільки цього вистачить - не маю уявлення🤷‍♂️
 
Судячи з досвіду, з 100% випадків, коли XVRxxxx-X має проблему з прошивкою і симптоми як у Вас, флешка пошкоджена у 60% випадків.
Зрозумів, будемо чекати коли він накриється :cautious:
У всієї серії XVRxxxx-X проблема з мікросхемами nand-пам'яті, це їх дитяча хвороба, якщо так можно висловитися.
Якщо ця болячка через партію неякісних мікросхем flash, то її заміна повністю вирішує проблему, а якщо винен кривий софт, який жере ресурс циклів запису flash, то це знову відновлення на певний час. Та і нові мікросхеми зараз доступні лише з аліекспрес, їх якість - лотерея.
 

Техпідтримка VidiMost.com

Спеціаліст
Команда форуму
Дякую за пораду, згоден, що заміна флешкі - надійніше. Я не дуже розбираюсь в операційній системі Dahua, але chatGPT трактує ці строки по іншому:
BDB — это внутренние отладочные сообщения, появляющиеся на стадии инициализации флеш-памяти и разделов NAND в прошивке Dahua.
BDB — модуль, читающий Board Data Block или Boot Debug Block.
partid = 9 и partid = b — идентификаторы NAND-разделов, представленные в шестнадцатеричном виде:
9 = 9
b = 11 (в десятичной системе)
addr = 0x48c0000 и т.п. — это адреса блоков памяти NAND, откуда читается информация.

В прошивках Dahua, особенно на HiSilicon SoC (как у тебя Hi3531D), такие обращения к BDB происходят:
Для чтения данных о конфигурации, MAC-адресе, серийном номере и пр.
Для поиска резервных копий данных (чаще всего читаются сразу несколько адресов подряд).
Разделы с partid = 9 и b (11) могут быть, например, config, custom, env, или user_data — нужно смотреть в mtd таблицу или в firmware.img.
Эти строки означают, что загрузчик/ядро ищет конфигурационные или пользовательские данные в NAND-разделах с ID 9 и 11.
Он проверяет несколько возможных местоположений (возможно, с резервированием), чтобы загрузить нужную информацию (например, настройки системы или сетевые параметры).
Не знаю як там чат GPT, але у здорового дампу цих звернень до блоків немає
 

Yukaran

Member
Привет всем! Восстановил таки рег. без перешивки флэш. Повторил путь товарища XGX в теме https://www.dahuacctv.com/threads/dh-xvr5116hs-x-черный-экран-сеть-молчит.229/ . Возился дня три, но учитывая, что я ничего не понимаю в LINUX получил кое какой опыт и моральное удовлетворение :).
Подключение к компу через китайский переходник USB-UART_TTL на 3,3В. В качестве терминала - PuTTy (настройки bits=8/1,Spped=115200, Parity=none, Flow cjntrol=none). Исходное состояние: черный экран, сеть молчит, напряжения на плате в норме (приложил фото), ток потребления около 0,4 А, в консоли доступен загрузчик. Исходный лог и printenv приложил.
System startup

U-Boot 2010.06-svn3134 (Apr 14 2018 - 03:06:43)

Check Flash Memory Controller v100 ... Found
SPI Nand(cs 0) ID: 0xef 0xaa 0x21 Name:"W25N01GV"
Block:128KB Page:2KB Chip:128MB*1 OOB:64B ECC:4bit/512
SPI Nand total size: 128MB
*** Warning - bad CRC or NAND, using default environment



NAND read: device 0 offset 0x100000, size 0x100000
1048576 bytes read: OK

NAND read: device 0 offset 0x200000, size 0x100000
1048576 bytes read: OK

NAND read: device 0 offset 0x200000, size 0x100000
1048576 bytes read: OK
Header CRC Checking ... OK
Data CRC Checking ... OK
## Starting application at 0x41000080 ...

System startup

U-Boot 2010.06-svn3134 (Mar 17 2018 - 16:16:27)

Check Flash Memory Controller v100 ... Found
SPI Nand(cs 0) ID: 0xef 0xaa 0x21 Name:"W25N01GV"
Block:128KB Page:2KB Chip:128MB*1 OOB:64B ECC:4bit/512
SPI Nand total size: 128MB
===============================================
DPLL:466Mhz DDR:1864Mhz
APLL:1400Mhz VPLL0:297Mhz
===============================================
BDB: partid = 9; addr = 0x48c0000
BDB: partid = 9; addr = 0x4940000
BDB: partid = 9; addr = 0x4a00000
BDB: partid = b; addr = 0x48c0000
BDB: partid = b; addr = 0x4940000
BDB: partid = b; addr = 0x4a00000
ETH0: PHY(phyaddr=1, rgmii) not link!
higmac init fail!
nice find PHY TRL8211 on higmac
mem= 512
Creating 1 MTD partitions on "nand0":
0x000004700000-0x000005100000 : "mtd=0"

hisilicon # printenv
bootargs=mem=96M console=ttyAMA0,115200
bootcmd=bootm 0x41000000 0x42000000
bootdelay=1
baudrate=115200
ethaddr="00:00:23:34:45:66"
ipaddr="192.168.1.10"
serverip="192.168.1.2"
netmask="255.255.255.0"
bootfile="uImage"
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06-svn3134 (Apr 14 2018 - 03:06:43)

Environment size: 321/2097148 bytes
hisilicon #
Алгоритм следующий:
0 Тот загрузчик что работает очень «урезанный», с его помощью во флэш ничего не зашить, только в ОЗУ.
1 Через консоль по UART активировать загрузку данных в ОЗУ (командой loadb).
2 Через протокол kermit (программа kermit_95) по тому же UART залить в ОЗУ более «продвинутый» загрузчик (u-boot.bin.img).
3 Запустить этот загрузчик из ОЗУ и с его помощью прошить флеш либо через TFTP-сервер (командами run dr, da, du …) либо с USB-флэшки.



У меня прошивка с TFTP-сервера (программа tftpd64) не получилась, хоть другим компом я сэтого сервера файлы качал, получилось прошить только через USB-флэшку. Прошивал DH_XVR5x16-X_MultiLang_NP_V4.000.0000002.4.R.190402.bin , оттуда же взял и загрузчик (u-boot.bin.img), с другими прошивками почему то не шло. Потом прошился до актуальной версии.

Из особенностей:
1 «Урезанный» загрузчик перезагружает ситему каждые три минуты, поэтому делать нужно все быстро.
2 И программа PuTTy и программа kermit_95 должны работать через один COM порт, поэтому вместе их не запускать, только поочереди.
3 Файл «u-boot.bin.img» положить в папку программы kermit_95.

Операции пошагово:
  1. Установить USB-флешку с прошивкой в регистратор или подключить Ethernet кабель между компом и регистратором и запустить TFTP-сервер (в зависимости от того как будете прошивать).
  2. Запустить терминал PuTTy
  3. Включить питания рега, и постоянно нажимать клавишу "*" в окне PuTTy (Время 3 мин пошло).
  4. После появления «hisilicon #» Ввести в PuTTy (а лучше вставить
setenv dh_keyboard 0
setenv appauto 0
loadb

4. Закрыть PuTTy. Запустить kermit и ввести (а лучше вставить)
set line COM(номер порта)
set speed 115200
set carrier-watch off
set flow-control none
set prefixing all
set modem none
set file type bin
set file name lit
connect
send u-boot.bin.img

5. Пойдет прошивка. По окончании закрыть kermit. Запустить PuTTy и ввести
saveenv
go 0x410000c0
(все это нужно сделать за 3 мин)

6. Пойдет запуск нового загрузчика. Тут я снова постоянно жал "*" или другие кнопки, чтоб остановить загрузчик, он останавливается не всегда, но если и не остановится он все равно придет к «hisilicon #». Но, если ничего не нажимать, при установленной USB-флэш (с прошивкой) в гнездо рега у меня пошло обновление автоматически (это почему то произошло не с первого раза). Если же обновляться с TFTP, нужно ввести:
setenv dh_keyboard 0
setenv appauto 0
setenv ipaddr 192.168.1.10
setenv serverip 192.168.1.2 (IP сетевухи TFTP-сервера)
setenv ethaddr 88:88:88:88:88:88 (ввести ваш мак)
setenv netmask 255.255.255.0
saveenv

7. Далее, при условии рабочего TFTP-сервера, установленного IP на компе 192.168.1.2 и подключенного напрямую Ethernet кабеля ввести:
run dr
run da
run du
run dw
run dc
run dh
run dl
У меня вариант с TFTP не пошел.
Добрый день.
похожая ситуация, делаю как вы и описываете, пытаюсь шить через флешку, через сеть не получается.

после ввода команд
setenv dh_keyboard 0
setenv appauto 0
loadb
putty что то еще делает, долго ждал. Так должно быть ? Я закрыл проинудително.
и еше
после ввода команды
connect, открывается голубое окно, в которое ничего нельзя ввести
Как ввести send u-boot.bin.img ?
 
Останнє редагування:
Зверху