R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

Is there a similar English firmware for that model?
It depends on whether this is a G0 or G1 series camera, for example from here : DOWNLOAD PORTAL
What's the full model number? It seems to me that there are multiple, different, variants of '2335'.
But is this a Chinese camera with Chinese menus? If so, the EN/ML firmware will be rejected.
 
Hi, I tried to upgrade my DS-2CD2132F-IS camera (CN).
I followed the instructions and after uploading brickfixV2en.dav on it (tftp transfer and update works successfuly) my camera doesn't work anymore.

When connecting with RS232, I get this :

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
eth_fbi:st=0x0380a102
|NUL eth|
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 0x402d6000
loading ./orccode.bin...addr = 0x402d6000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x404d6000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x40576000, 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


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
After "begin to enter mini system" camera doesn't respond to ctrl+u command.

Hitting ctrl+U at start allows me to use console commands, but I can't manage to update to another firmware. Command Tftpboot just download "digicap" file from server but doesn't update camera.

Any help ? :embarrassed:
 
It depends on whether this is a G0 or G1 series camera, for example from here : DOWNLOAD PORTAL
What's the full model number? It seems to me that there are multiple, different, variants of '2335'.
But is this a Chinese camera with Chinese menus? If so, the EN/ML firmware will be rejected.
Serial number is "DS-2CD2335-I20150928AACH544009497", not sure if there is a better model number I can find somewhere? As far as I know it is a Chinese camera with Chinese menus.
If there is no way to get an English firmware on it, I am fine just updating it to the latest Chinese version to patch security issues.
 
When connecting with RS232, I get this :
That looks like a normal serial console transcript for the second or subsequent startups after the brickfixV2 tool has been installed.

On the first startup when power-cycled after installation, the brickfixv2 tool drops the payload, initialises the stage reference file for the /dav/fixup.sh script, deactivates itself, and reboots into min-system mode so that the /dav/fixup.sh script can be run via a telnet session.

On subsequent startups it simply reboots straight into min-system mode, as your transcript shows.

At this point you should be able to telnet to the 192.0.0.64 address from the PC at 192.0.0.128 to a root shell and run /dav/fixup.sh
Alternatively, as you have the serial console available, you should be able to see the '#' prompt if you press Return a couple of times, and run the /dav/fixup.sh script from there.
In either case - the Hikvision tftp updater should be closed, and the normal tftp server such as tftpd32.exe should be running, with the PC IP address set to 192.0.0.128
 
Serial number is "DS-2CD2335-I20150928AACH544009497"
OK, so that looks like a China region G0 DS-2CD2335-I camera.
As that model has the 'hardware signature block' saved in a separate security chip, not in a flash partition that can be edited, it would need 'hacked to English' firmware to convert to EN/ML menus.
I have done this to a DS-2CD3335D-I camera, but using access to the serial console so that the original hacked firmware was wiped as it was blocking any update attempts.

It sounds like your camera may be a China region camera running the stock CN firmware - a version of which might be available here : 海康威视是以视频为核心的物联网解决方案提供商
 
OK, so that looks like a China region G0 DS-2CD2335-I camera.
As that model has the 'hardware signature block' saved in a separate security chip, not in a flash partition that can be edited, it would need 'hacked to English' firmware to convert to EN/ML menus.
I have done this to a DS-2CD3335D-I camera, but using access to the serial console so that the original hacked firmware was wiped as it was blocking any update attempts.

It sounds like your camera may be a China region camera running the stock CN firmware - a version of which might be available here : 海康威视是以视频为核心的物联网解决方案提供商
Ok, glad it sounds possible, just more complicated.
I did buy a USB to serial adapter and have used it for some projects before including un-bricking a 2432 I really screwed up before.
 
This is my thread about that DS-2CD3335D G0 camera : Long-shot help request - Hikvision DS-2CD3335D - G0 series IPC.

I also used the same method to update a DS-2335-I that had the 'dieter and fiona' hacked firmware.
It turned out that my modded firmware was a tight squeeze though, as I thought I'd be clever and extracted all the language files from the original hacked firmware and the resultant size was just a bit too large.
Dieter & Fiona
If you ever get round to exploring this yourself, PM me for copies of the tweaked files.
 
That looks like a normal serial console transcript for the second or subsequent startups after the brickfixV2 tool has been installed.

On the first startup when power-cycled after installation, the brickfixv2 tool drops the payload, initialises the stage reference file for the /dav/fixup.sh script, deactivates itself, and reboots into min-system mode so that the /dav/fixup.sh script can be run via a telnet session.

On subsequent startups it simply reboots straight into min-system mode, as your transcript shows.

At this point you should be able to telnet to the 192.0.0.64 address from the PC at 192.0.0.128 to a root shell and run /dav/fixup.sh
Alternatively, as you have the serial console available, you should be able to see the '#' prompt if you press Return a couple of times, and run the /dav/fixup.sh script from there.
In either case - the Hikvision tftp updater should be closed, and the normal tftp server such as tftpd32.exe should be running, with the PC IP address set to 192.0.0.128
Hello Alastair,

When I press ctrl + U I get this command prompt :

Code:
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot


U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 2
HKVS # eth_fbi:st=0x0380a102

HKVS #

Is that what you called # ?
How can I run /dav/fixup.sh ? If I do HKVS # /dav/fixup.sh, I get "unkown command"

My computer get a successfull ping when pinging 192.0.0.64 but telnet is not working...
 
When I press ctrl + U I get this command prompt :
That's the bootloader you have interrupted.
It's used to load up the next level of the bootup, the Linux kernel, in either the normal full system or the 'min-system' recovery mode..
But just out of curiosity, see what values the 'printenv' command comes up with.

The 'min-system' recovery mode is a stripped down version of the normal running environment, booted from a different flash partition than the normal full system.
If you use the 'reset' command, it should boot into the needed 'min-system' mode, after passing through the de-activated brickfixv2 system.
When it says 'begin to enter mini system' give it maybe 10 seconds and you should get the min-system '#' prompt.
And telnet should work - though you don't really need it when you have console access.
 
printenv return this

Code:
HKVS # printenv
ipaddr=192.0.0.64
serverip=192.0.0.128
gatewayip=0.0.0.0
netmask=255.255.255.0
ethaddr=....
loadaddr=0xc2000000
bootfile=digicap.dav
bootcmd=null
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
bootdelay=2

If I wait about min-system, nothing happens, no prompt and telnet :(
Ping is successfull when I am in "boootloader" console.
When camera is loading and waiting to enter in min-system, I can't ping it...
 
printenv return this
That looks normal.
It sounds like you need to re-install the brickfixv2 tool.

Suggestion:
Ensure the EN or CN version of brickfixv2 is named digicap.dav and is in the same folder as tftpserve.exe
Start the Hikvision tftpserve.exe program when the PC IP address is 192.0.0.128
At the serial console connection, use the 'reset' command and watch for the 'update completed' message.
Power the camera off, power it back on again, and watch for the brickfixv2 messages.
Hopefully that will be OK and you can proceed with /dav/fixup.sh
 
That looks normal.
It sounds like you need to re-install the brickfixv2 tool.

Suggestion:
Ensure the EN or CN version of brickfixv2 is named digicap.dav and is in the same folder as tftpserve.exe
Start the Hikvision tftpserve.exe program when the PC IP address is 192.0.0.128
At the serial console connection, use the 'reset' command and watch for the 'update completed' message.
Power the camera off, power it back on again, and watch for the brickfixv2 messages.
Hopefully that will be OK and you can proceed with /dav/fixup.sh
My camera is not responding to ping after that :
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
tftpserver received a "test tftpserver" and nothing after that.

Same thing is happening after using reset command.

If I'm not stoping autoboot, I lose camera on network and it's blocked on "
begin to enter mini system"

If I try the update commande in ctrl+U console, I can't ping my camera and nothing is happening on it.
 
Tried to use this method to update my 2CD2232-i5 yesterday from 5.2.5 to 5.4.5. Everything went fine until camera got mtd hack and rebooted. It's now completely dead. Not booting up, no response to ping. Any ideas how to troubleshoot?
 
tftpserver received a "test tftpserver" and nothing after that.
After that successful handshake, the 'min-system recovery' system should start, but it clearly doesn't.
It's the same situation when doing the normal startup.
I think this will need some detailed hands-on to figure out the cause and fix it.

Where are you located?
 
It's now completely dead. Not booting up, no response to ping. Any ideas how to troubleshoot?
A first useful thing to try is to see what SADP shows, if anything.
After power-on, see if anything changes after about 10 minutes. There is a watchdog timer that kicks in after 10 mins when not being regularly reset.
 
A first useful thing to try is to see what SADP shows, if anything.
After power-on, see if anything changes after about 10 minutes. There is a watchdog timer that kicks in after 10 mins when not being regularly reset.

Unfortunately nothing in SADP, even after 10 minutes :( It seems network is not coming up - I removed camera from the wall and plugged power directly, then connected to the switch - no light on the switch for that port...

Will try to connect via serial and check if there is some live there. Looking for 4pin JST connector now.
 
Last edited:
After that successful handshake, the 'min-system recovery' system should start, but it clearly doesn't.
It's the same situation when doing the normal startup.
I think this will need some detailed hands-on to figure out the cause and fix it.

Where are you located?
I'm from France !
 
t seems network is not coming up - I removed camera from the wall and plugged power directly, then connected to the switch - no light on the switch for that port...
Well, that's very strange. I don't think I've come across an Ethernet interface problem after a firmware update.
It will be interesting to see what the serial console has to say.

Does the LAN link detect show at all straight after power-on? The bootloader won't have been changed by any firmware update.
 
If I'm not stoping autoboot, I lose camera on network and it's blocked on "
begin to enter mini system"
OK, so the 'min-system' recovery environment is not working.
It's been a while since I did this on an R0 camera, and I've loaned out all my Hikvision spare devices to a friend of a friend who is experiencing some issues so I can't test this out ...

As an experiment, depending on the version of bootloader this may not work, but easy enough to try :
Drop an unzipped copy of the attached hImage into the same folder as the Hikvision tftp updater.
With the PC IP address set to 192.0.0.128 at the serial console try :

tftp hImage
bootm

and see if that works.
The idea is to boot from an external image.
Then if that works - we can proceed from there.
But if not - if you feel able to send the camera to me, I could have a go at fixing it up for you.
 

Attachments

OK, so the 'min-system' recovery environment is not working.
It's been a while since I did this on an R0 camera, and I've loaned out all my Hikvision spare devices to a friend of a friend who is experiencing some issues so I can't test this out ...

As an experiment, depending on the version of bootloader this may not work, but easy enough to try :
Drop an unzipped copy of the attached hImage into the same folder as the Hikvision tftp updater.
With the PC IP address set to 192.0.0.128 at the serial console try :

tftp hImage
bootm

and see if that works.
The idea is to boot from an external image.
Then if that works - we can proceed from there.
But if not - if you feel able to send the camera to me, I could have a go at fixing it up for you.
I do this :

Code:
HKVS # upk
[ INFO][BLD]TFTP: MAC: 
[ INFO][BLD]TFTP: TFTP from server 192.0.0.128; our IP address is 192.0.0.64
[ INFO][BLD]TFTP: Filename: 'hImage'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: ###########################################################
[ INFO][BLD]TFTP: File size is 5617796 bytes (5486 KB)
no need to update partition [9]
no need to update partition [10]
HKVS # bootm
## Starting kernel at 0xc0208000 with ramdisk at 0x00000000, rmd_size: 0x00000000,
cmdline = 'console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0'
after bootm, nothing happens and I can't ping camera