R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.
- Thread starter alastairstevenson
- Start date
Help please!
It's at this point that I ran into problems. My anti-virus software decided to kill the tftp server process while it was transferring the mtd6ro_orig file. So the file never made it to my PC to edit. But the script set itself up for the next phase - but that next phase expects m5d6ro_mod to exist, and it doesn't.
I tried to get it to start over again at Stage 1 - by deleting the ..._stage2.txt file - but that didn't work.
Is there a way to get the min-system mode to go through the updater step again, where I'm running the Hikvision tftp updater process, and it's waiting for the "test tftpserver" message from the camera?
Here's my fixup_log.txt file:
-- cut here --
[Brick-fix tool] Initialising fixup_log.txt
Payload dropped, rollback re-enabled
Initialising fixup current status to stage1
[Brick-fix tool] Initiating reboot into min-system
Checking that tftp works OK ...
Extracting the original mtdblocks ...
Extracted the original mtdblock6 as mtd6ro_orig
Extracted the original mtdblock1 as mtd1ro_orig
Transferring out mtd6ro_orig via tftp ...
*** error transferring mtd6ro_orig via tftp to the PC. ****
End of script - ready for the next run.
.
Checking that tftp works OK ...
[stage start] fixup_log.txt successfully transferrred to the PC via tftp
*** error transferring mtd6ro_mod via tftp from the PC. ****
End of script - ready for the next run.
.
-- cut here --
Any ideas?
THANKS!
It's at this point that I ran into problems. My anti-virus software decided to kill the tftp server process while it was transferring the mtd6ro_orig file. So the file never made it to my PC to edit. But the script set itself up for the next phase - but that next phase expects m5d6ro_mod to exist, and it doesn't.
I tried to get it to start over again at Stage 1 - by deleting the ..._stage2.txt file - but that didn't work.
Is there a way to get the min-system mode to go through the updater step again, where I'm running the Hikvision tftp updater process, and it's waiting for the "test tftpserver" message from the camera?
Here's my fixup_log.txt file:
-- cut here --
[Brick-fix tool] Initialising fixup_log.txt
Payload dropped, rollback re-enabled
Initialising fixup current status to stage1
[Brick-fix tool] Initiating reboot into min-system
Checking that tftp works OK ...
Extracting the original mtdblocks ...
Extracted the original mtdblock6 as mtd6ro_orig
Extracted the original mtdblock1 as mtd1ro_orig
Transferring out mtd6ro_orig via tftp ...
*** error transferring mtd6ro_orig via tftp to the PC. ****
End of script - ready for the next run.
.
Checking that tftp works OK ...
[stage start] fixup_log.txt successfully transferrred to the PC via tftp
*** error transferring mtd6ro_mod via tftp from the PC. ****
End of script - ready for the next run.
.
-- cut here --
Any ideas?
THANKS!
militarymedic23
Young grasshopper
- Jan 13, 2017
- 47
- 1
What issues did you notice with 2019 R1 and HK cameras? I have 16 cameras running on two different R1 servers and haven't noticed anything odd.
I do have some chinese cameras that are back at 5.2 that I want to upgrade via this thread's instructions.
Thanks
To save re-installing the brickfixV2 firmware you can go back to Stage1 by re-creating the flag file at the shell prompt - the contents is not important :
Code:
echo "Fixup stage1 completed - rollback payload dropped" > /dav/fixup_stage1.txt
So the content of the file wasn't important, so I wrote "Alistair ROCKS!" to the file. And it worked! Well, it got me past that part. I followed the steps and installed one of the firmware versions linked in the instructions. Now, every time I boot the camera, it boots into Min System mode (when I telnet in using Putty and look, the /dav directory is empty). I tried to start over, but when I run the Hikvision tftp updater, the camera never sends out its test message to retrieve the brickfixv2 data...
Any ideas? Any way to - from the command line while telnet'd into the camera - kick off the process where it goes out and looks for the tftp server to download from?
THANKS for your help!
P.S. What part of Scotland do you live in? Spent a week in Scotland (Edinburgh, Stirling, Isle of Skye). Beautiful country you have there.
OK, as a candidate to update to in the Stage3?
Did you get 'Firmware update successful'?
Maybe pick an earlier version of the firmware than the 5.4.5 which generally works OK.
Drop the digicap.dav into the folder where tftpd32.exe is running and use
/bin/upgrade /digicap.dav
to start the update process.
I'm from Fife - in the East Central belt of Scotland.
So not far from Edinburgh, and not far from many other parts of this small but beautiful country.
A couple of days back I was over in the Isle of Bute, over on the West Coast.
Up North is a bit further though, I'll be there on holiday in July, walking in the Isles.
Just a thought - the reboot into the min-system mode might be due to an objection to the mtd6_mod contents.
How confident are you with the changes to that?
The very early versions of firmware are more tolerant of things like the checksum not being matched.
How confident are you with the changes to that?
The very early versions of firmware are more tolerant of things like the checksum not being matched.
Yessir, as the digicap.dav file, I used the 5.4.5 version. That's the version that the camera just boots into Min System mode, which I can telnet into, and the /dav directory is empty. So, I am trying to use the next lower version (5.4.41). I'll try the /bin/upgrade command next time I'm at the camera (probably Monday).
There's an article about how a particularly depressing article about climate change is supposedly driving people to relocate to the Scottish countryside (The Climate Change Paper So Depressing It's Sending People to Therapy). I thought, "yeah, Scotland is amazing - I guess that's what I'd do too!".
There's an article about how a particularly depressing article about climate change is supposedly driving people to relocate to the Scottish countryside (The Climate Change Paper So Depressing It's Sending People to Therapy). I thought, "yeah, Scotland is amazing - I guess that's what I'd do too!".
I followed everything step by step and carefully (I'm a software engineer, so I know that every bit is important!), so I am pretty confident that I calculated the Checksum-16 over the correct range, and entered it in "little endian", byte-swapped mode. But now that I know about the /bin/upgrade command, I can try it again from the start.
Oddly enough (and I was confused originally too) this is the newest version, the 5.4.5 is the older version.
And is less reliable to use as the upgrade target in Stage3 than the 5.4.5 version.
But the very early versions, such as the @whoslooking '5.3.0 to 5.2.5 downgrader' should provide a safety net as a start point.
Probably just because it's not mounted.
Hmm... I can't get /bin/upgrade to do anything. I have the Hikvision TFTP updater running. I open up a PuTTY session - and here's the transcript:
OK, try this at the telnet prompt :
Code:
tftp -g -r digicap.dav -b 1400 192.0.0.128
/bin/upgrade /digicap.davSUCCESS! I got it running with the 5.4.5 version. I may be brave and try to update to the 5.4.41... Thanks for your help.
Hello,
First Thank You for the great job Alastairs!
I've got 2 Hikvision DS-2CD2132F-IS bought on AliExpress few years ago.
They were both were previously in 5.2.5.
When I tried to upgrade the 1st one through the GUI it get bricked…
Thanks to your post I've been able to fix it!!! Thanks a lot!!
So I've decided to apply your fix to my second CAM (still in 5.2.5) without trying to upgrade it through the GUI before (it wasn't bricked when I tried to apply the fix….)
I've been able to get successfully through the 1st step (tftp through the Hikvision tool) but then I've never been able to login via telnet.
I can't ping 192.0.0.64. When spying the Ethernet with Wireshark, the Hikvision shows sometimes briefly on startup and then disappears. I don't see it neither to another ip address like 192.168.1.64 for example.
When it shows briefly at 192.0.0.64 I can see this log when I try using the Hikvision TFTP tool and Nothing else:
So I've setup a rs232 link to see if I could get more information:
When no Hikvision TFTP server is listening it boots whith errors then reboots to enter "mini system" and then freezes
When I've got a Hikivision TFTP server listening (also tried on Linux with the Python hack to ensure there were no issues with the antivirus or the firewall) I can see the UDP Magic packets with Wireshark but the cam console freezes :
[/CODE]U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
[/CODE]
If I stop U-boot and launch "update" or "update digicap.dav" it also freezes:
If I stop U-Boot and launch "tftpboot" the digicap.dav file is transfered and I still get a prompt but I don't know what to do with that...
Note : as You can see on the log I've modified the ipaddr and serverip to be usable on my LAN.
Any idea?
Thanks a lot for the help!
First Thank You for the great job Alastairs!
I've got 2 Hikvision DS-2CD2132F-IS bought on AliExpress few years ago.
They were both were previously in 5.2.5.
When I tried to upgrade the 1st one through the GUI it get bricked…
Thanks to your post I've been able to fix it!!! Thanks a lot!!
So I've decided to apply your fix to my second CAM (still in 5.2.5) without trying to upgrade it through the GUI before (it wasn't bricked when I tried to apply the fix….)
I've been able to get successfully through the 1st step (tftp through the Hikvision tool) but then I've never been able to login via telnet.
I can't ping 192.0.0.64. When spying the Ethernet with Wireshark, the Hikvision shows sometimes briefly on startup and then disappears. I don't see it neither to another ip address like 192.168.1.64 for example.
When it shows briefly at 192.0.0.64 I can see this log when I try using the Hikvision TFTP tool and Nothing else:
Code:
[2019-04-18 23:46:44] TFTP server[192.0.0.128] initialized
[2019-04-18 23:46:53] Device[192.0.0.64] test tftpserverWhen no Hikvision TFTP server is listening it boots whith errors then reboots to enter "mini system" and then freezes
Code:
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
[ 0.431047] [ kernel version: svn-174544 ]
init started: BusyBox v1.19.3 (2016-05-23 16:23:55 CST)
starting pid 378, tty '': '/etc/init.d/rcS'
Starting udev: [ OK ]
UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEB)
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:0x1, sec_iUpgSuccCnt:0x1
UBI device number 3, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs ()
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs ()
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
diagnose_way = 15, repair_way = 1, interval = 30
route: ioctl 0x890c failed: No such process
mount: mounting none on /proc/bus/usb failed: No such file or directory
/dav
map_size = 0x300000
nr_item = 3
addr_offset = 0x0 filename = orccode.bin
addr_offset = 0x200000 filename = orcme.bin
addr_offset = 0x2a0000 filename = default_binary.bin
mmap returns 0x4029d000
loading ./orccode.bin...addr = 0x4029d000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x4049d000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x4053d000, size = 0x40000
===============================
u_code version = 2016/4/6 3.0
===============================
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
[ 10.993883] Restarting system.
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
begin to enter mini system[/CODE]U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
[/CODE]
If I stop U-boot and launch "update" or "update digicap.dav" it also freezes:
Code:
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 3
HKVS # update
Code:
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 1
HKVS # update digicap.dav
Code:
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 1
HKVS # tftpboot
[ INFO][BLD]TFTP: MAC: c4:2f:90:03:e1:bc
[ INFO][BLD]TFTP: TFTP from server 192.168.0.13; our IP address is 192.168.0.20
[ INFO][BLD]TFTP: Filename: 'digicap.dav'
[ INFO][BLD]TFTP: ##############################################################
[ INFO][BLD]TFTP: ##############################################################
[ INFO][BLD]TFTP: ##############################################################
[ INFO][BLD]TFTP: #########################
[ INFO][BLD]TFTP: File size is 18558206 bytes (18123 KB)
HKVS #
HKVS #Any idea?
Thanks a lot for the help!
That's good.
And that's not so good.
The 'min-system recovery environment' (also known as mImage) is not working.
This is where the update code runs, including the code that is called when the tftp updater probe returns a successful handshake.
So with that not working, normal updates at bootloader level are not possible.
There are various ways this could be worked around, which might be a bit fiddly to do back and forth on the forum.
But let's try.
As a first somewhat long-shot simple attempt, put this text including the blank line after it into a text editor (eg Notepad), then copy it to the clipboard.
/usr/sbin/set_sysflag -m 0
Power up the camera with the serial console active using PuTTY and about when the UBI mounts are taking place, use Shift-Insert to paste the text in a few times.
There should be a small window of opportunity to turn off the reboot flag.
Hello Alastairs and Thank You for the reply!
After my previous post I've tried the followin bootargs configuration
It let me have a shell prompt but barely nothing functional. Then I've launched :
I've been able to configure the Ethernet and try to play with your scripts but "tftp" couldn't be found...
What is weird is that now I can start without the "init=/bin/sh" arg and get a prompt for a while before the reboot occurs.
I've tried to enter your command when the prompt is ready but it still reboots in min-system after a while (about 4-5 minutes).
Thank You for your help!
After my previous post I've tried the followin bootargs configuration
Code:
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0 init=/bin/sh
Code:
# /etc/init.d/rcSWhat is weird is that now I can start without the "init=/bin/sh" arg and get a prompt for a while before the reboot occurs.
Code:
U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2016-05-23 16:23:55 CST)
starting pid 378, tty '': '/etc/init.d/rcS'
Starting udev: [ OK ]
UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:0x1, sec_iUpgSuccCnt:0x1
UBI device number 3, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
diagnose_way = 15, repair_way = 1, interval = 30
route: ioctl 0x890c failed: No such process
mount: mounting none on /proc/bus/usb failed: No such file or directory
/dav
map_size = 0x300000
nr_item = 3
addr_offset = 0x0 filename = orccode.bin
addr_offset = 0x200000 filename = orcme.bin
addr_offset = 0x2a0000 filename = default_binary.bin
mmap returns 0x402eb000
loading ./orccode.bin...addr = 0x402eb000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x404eb000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x4058b000, size = 0x40000
===============================
u_code version = 2016/4/6 3.0
===============================
/home/initrun.sh: line 80: /dav/guard.sh: not found
ln: /dev/rtc: File exists
=====check_config start=====
===db file doesn't exist===
===db file doesn't exist===
==== both config files are broken====
pppoed==>pppoed ret -1.
netprocess version[getaddrinfo security]: 1.6.1 [14:12:02-Apr 5 2016].
[04-22 08:20:24][pid:836][STRM_ANLS][ERROR]connect call failed errno 2
[04-22 08:20:24][pid:836][STRM_ANLS][ERROR]list node num is [0], load_type is [10012].
No need to recover kernel pri partition.
No need to recover ramdisk pri partition.
IEfile uncompressed.
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- anywhere anywhere tcp dpt:ssh
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
flushed:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
starting pid 853, tty '': '-/bin/psh'
BusyBox v1.19.3 (2016-05-23 16:23:55 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# no rx packets
reset eth0.
no rx packets
reset eth0.
no tx packets
reset eth0.
/usr/sbin/set_sysflag -m 0
# no rx packets
reset eth0.
no tx packets
reset eth0.
no rx packets
reset eth0.
davinci not found and watchdog not initialized! auto reboot system!
begin to set enter minisys flag~~
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system rebootThank You for your help!
I think maybe I could use an SD card to exchange data with the CAM since I've got a shell now...
Yes, that's worth trying. I'm not sure what device will show under, try
ls -al /dev/mmc*
You will probably need to mount it, maybe something like
mount -t fat /dev/mmc1 /mnt/mmc01
or maybe just
mount /dev/mmc1 /mnt/mmc01
replacing mmc1 with whatever is found for the SD card device.
Attached are a couple of versions of mtdblock8 - the 'mImage recovery partition' - which should get it back to being able to run the min-system recovery environment, which would then allow normal updates to be done at the bootloader.
To apply use
cat /mnt/mmc01 > /dev/mtdblock8
Do you have a NAS? If so, an NFS share works well.
Good luck!
I think that's because the sys_flag to initiate the reboot into min-system mode resets itself.
And then when davinci is not running such that the watchdog timer does not get periodically reset, the watchdog triggers a reboot, usually 10 minutes.