Yet another bricked camera... This one gets "writing /dav_sec failed"

[Viking83]

Hi there,

I tried to upgrade my DS-2CD2032-I from 5.3.4 (might have been 5.3.5, not sure) to the latest 5.4.5.

As stated on the "Important-read before upgrade.txt" file, you need a 2 step upgrade:
1) update to V5.4.41 build 170310 FIRST, reboot
2) update to v5.4.5 Build 170123, reboot

After the 5.4.41 attempt, the camera bricked. It's on an endless davinci error loop.

I had no idea my camera was lang 2, so I used the 5.4.41 firmware from the US site that is packaged with 5.4.5. Thinking that could be the issue, I tried to inspect that file so I could change the lang, but I get "Invalid magic".

Then I tried a language modified version of 5.4.0 and 5.4.5 and I get this:

HKVS # update
[ INFO][MIN]TFTP: TFTP from server 192.0.0.128
[ INFO][MIN]TFTP: Filename: 'digicap.dav'
[ INFO][MIN]TFTP: ####################################################################
[ INFO][MIN]TFTP: Download File [OK]
[ INFO][MIN]BURN: File size is 22219640 bytes (21698 KB)
[UPG][DEBUG_NOTICE][ext/sys_firm_version.c][firm_version_check][435]:i=15,szFileName=_cfgUpgClass,iFirmOffset=0x48857a
[UPG][DEBUG_NOTICE][ext/sys_firm_version.c][firm_version_check][479]:####### iFirmVers=0x5040000, sys firm version check ok #######
[UPG][DEBUG_NOTICE][ext/sys_firm_version.c][firm_version_upgrade][626]:####### iFirmVers=0x5040000,iDevsVers=0x5030000,iBase=0x0,iMask=0xffff0000 #######
[ INFO][MIN]BURN: Writing Flash
[ INFO][MIN]BURN: [ERROR][MIN]BURN: update_flash:writing /dav_sec failed
[ERROR][MIN]BURN: update_flash:writing /dav failed
[ERROR][MIN]BURN: upgrade_from_digicap failed

[ INFO][MIN]BURN: Write Flash [FAIL] error: write flash.
!!!!! UPDATE FAIL !!!!!

If I try the 5.4.41 again, I get language mismatch. And since it shows Invalid Magic, I cannot edit the file. I also tried to find a Chinese version of it with no luck.

Any ideas?

Thanks in advance!

 

[Viking83]

I just tried 5.3.0 and the error is very similar. Only the order of the /dav_sec and /dav are not the same:

[ INFO][MIN]BURN: Writing Flash
[ INFO][MIN]BURN: [ERROR][MIN]BURN: update_flash:writing /dav failed
[ERROR][MIN]BURN: update_flash:writing /dav_sec failed
[ERROR][MIN]BURN: upgrade_from_digicap failed

BTW, I'm using hikpack version 2.5 by @montecrypto. Many thanks to him for developing it!

 

[alastairstevenson]

That sounds more like a flash problem than a firmware problem - it's complaining about writing - but sometimes the debug messages are not easily interpreted.
Suggestion:
If you allow the Hikvision tftp updater to do the firmware update, as opposed to the 'update' command, it will erase the app flash areas before attempting to write it.
That might make a difference, though if the flash was full I'd expect a better diagnostic.
For convenience, you can set the tftp server and the device IP addresses to convenient values (setenv / saveenv) to save messing with the PC IP address.

After the 5.4.41 attempt, the camera bricked. It's on an endless davinci error loop.

What is the specific error that's triggering the reboot?

It might be an idea to get back to basics with a downgrade to 5.2.5 and work up again to see how it goes.
Let me know if you want to try this : Hik brick-fix and downgrader tool - R0 / DS-2CD2x32 IP cameras.

I had no idea my camera was lang 2

*Warning* If you are considering doing the 'mtd hack' to lang=1, do not do it above firmware 5.2.5 unless you want to spring a particularly nasty Hikvision trap.

 

[Viking83]

Thanks for you reply.

The camera is making no attempt to TFTP on its own, so I've been using the update command. Is there a way to force it?

The line that forces the reboot is:
[06-17 19:05:34][pid:852][SYSINIT][ERROR]hwif_dsp_init error force sys reboot,ret=-12!!!!

There are many other errors during the load, but I cannot tell which ones are real errors, or just expected errors that happen on every boot.

I will definitely try the downgrader tomorrow and let you know the results. At this point I don't think I've got much to lose...

Shame I bought this camera in the US through Amazon and I had no idea Hikvision would hurt it's customers in the process of eradicating unwanted cross country sales.

 

[alastairstevenson]

The line that forces the reboot is:
[06-17 19:05:34][pid:852][SYSINIT][ERROR]hwif_dsp_init error force sys reboot,ret=-12!!!!

Prior to that there will be a reference to the detail that triggers that action.
Look for any references to vitype (sensor type) and device_type (model).

The camera is making no attempt to TFTP on its own, so I've been using the update command. Is there a way to force it?

When you have the Hikvision-specific tftp updater running? That's unusual.
It might be worth checking the values held for it in the bootloader environment variables to see if they are not at the original defaults.
Use printenv to inspect the values, setenv / saveenv to change and save.
For convenience you can change the tftp-related values away from the defaults to save changing the PC IP address each time for the tftp updater tool.
Maybe also worth knowing if you haven't seen this -
If you use 'update' when no tftp server is listening, the bootloader will load up the min-system kernel, run the update script, complain about an update failure - and leave you with a shell prompt.
This will either be 'psh' for the newer min-system / upgrade versions, or an actually usable shell for the older version.

 

[Viking83]

When you say Hikvision-specific-tftp, do you mean some special version of TFTP? I'm just using what I already have on my Linux system. But I don't see the TFTP request coming out of the camera on my Wireshark trace.

Is this what you looking for?
dsp_init: Unsupported viType=0

It might be easier if you can see the whole thing, so here is the full capture:

Anyway, this morning I set out to try and downgrade to 5.2.5 and never got a chance. At some point yesterday, I made it worse... The camera now stops with a dirty partition error:

Hit Ctrl+u to stop autoboot: 0
|BIND err|
Unknown command:null
pri and sec part data dirty, enter minisystem
BusyBox v1.2.1 Protect Shell (psh)
Enter 'help' for a list of davinci system commands.
#

Printenv shows this:

HKVS # printenv
ipaddr=192.168.1.24
serverip=192.168.1.35
gatewayip=0.0.0.0
netmask=255.255.255.0
ethaddr=c4:2f:90:32:3f:d4
loadaddr=0xc2000000
bootfile=digicap.dav
bootcmd=null
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
bootdelay=2

 

[Viking83]

Ok, so I didn't have the proper filter on wireshark. I was looking at TFTP requests, and the camera sends out some special UPD package. The camera is indeed trying to get something out of the TFTP server during the boot. I did some research and actually found a post from you explaining how the Hikvision TFTP is special. I'll download it, but it seems to be a Windows only software, so now I need to dig out a Windows PC to try it out...

 

[alastairstevenson]

but it seems to be a Windows only software, so now I need to dig out a Windows PC to try it out...

Yes, unfortunate, but true.
And doesn't play well on a VM either.
*edit* But a member made a Python version, on Github somewhere if I recall.
Here is a link to a copy of the Hikvision-specfic 'tftp updater' tool, in the link in the first post : Custom Firmware Downgrader 5.3.0 Chinese to 5.2.5 English
When the camera or NVR powers up, it emits from source port 9979 a UDP broadcast to destination port 9978 with the common Hikvision Magic number SWKH in the payload. The tftp updater specifically recognises this and responds.
This handshake then triggers the update process, where digicap.dav is transferred via tftp, verified, and written to flash.
Updating this way, the app areas of the flash will be erased, so the 'dirty' status will be cleared.
But the downgrade to older firmware will be blocked, and the newer firmware won't run on a CN camera, so a Catch-22 status.

Is this what you looking for?
dsp_init: Unsupported viType=0

And yes, this is the root cause.
The updated firmware is deliberately objecting to the camera-specific hardware definitions in mtdblock6
Interesting that you had a 5.3.4 firmware with a lang=2 value. That's quite a new 'hacked to English' firmware version.
The camera will revert to it's original CN language when attempting any updates.
As seen by the 'psh' appearance in your transcript, you have the newer version of the 'upgrade' program that the 'update' command invokes.
I expect this to block any downgrade attempt.
It's to get round this that I created the brick-fix downgrader tool which I think you will need.
Hik brick-fix and downgrader tool - R0 / DS-2CD2x32 IP cameras.
But lets see how you get on with getting the camera to a clean starting state.

 

[Viking83]

Thanks for that Python tip! I found it and it works just fine.
GitHub - scottlamb/hikvision-tftpd: Unbrick a Hikvision device (NVR or camera) via TFTP

It formated the flash:

Unfortunately, the "data dirty" remains...

I guess I'll have to try your method after all.

 

[Viking83]

Here is the latest development... I tried the 'EN downngrade_digicap.dav' from the Custom downgrader dropbox and it booted. But any attempt to upgrade to 5.3.0 or 5.4.0 sets me back to the data dirty condition.

At this point, I'm inclined to just leave it alone, unless you tell me there is hope on bringing the camera to a newer version without too much risk. I really only need it to record to my NAS on motion events. Unfortunately the Save button on the Motion Detection page is not showing for some reason (I tried using Firefox, Chrome and IE and that whole tab is kind of weird, things appear and disappear on refresh), so I might have to leave it on continuous recording mode (still need to figure that out). But it's way better than having a brick

 

[alastairstevenson]

I guess I'll have to try your method after all.

I was going to send you the instructions - but it won't do any good because it's function is to remove the 'anti-rollback' downgrade block which occurs after loading 5.4.0 or higher.
That's not a problem your camera has - it's unable to write all the flash successfully, but you can load the '5.3.0 to 5.2.5 downgrader' successfully.

I don't know if it's worth trying any of the ubi tools in /usr/sbin to see if any useful info can be found about the flash status.
That version of firmware gives little useful info on startup about the ubifs initiallisation, even with dbg=9 on the end of bootargs.
But you may see something useful with 'dmesg'.

 

[Viking83]

Well... The one thing I didn't mentioned is that I have another bricked camera (continuous boot) I haven't got to yet, mainly because it's up on my 2nd story roof. As you may guess, I upgraded both at the same time...

I'll probably work on it on the next couple of days. I need to get a tall ladder first...

On the Basic Event page problem, I can see the Save button on a Win7 PC with IE 11. Kind of annoying since the IE I had tested with was the same version but on Win8 PC with a smaller resolution, so either the size or the OS made the difference.
** EDIT ** The problem had nothing to do with browser or OS. It was caused by not having Webcomponents installed.

Again, I cannot thank you enough for sticking with me through this ordeal!

 

[Viking83]

Just for curiosity sake, here is the dmesg:

Nothing pops out to me. But I don't have dbg=9 set... At this point I think I'm going to focus on the next camera and leave this one alone.

 

[alastairstevenson]

Nothing pops out to me. But I don't have dbg=9 set...

Agreed, nothing abnormal showing.
I'd wondered if there might have been some UBIFS errors showing that might help determine the problem, but there isn't commentary on them all.

[ INFO][MIN]BURN: [ERROR][MIN]BURN: update_flash:writing /dav_sec failed

I believe /dav_sec gets mounted to more than one mtdblock during updating - but it's likely to be mtdblock14 (app_sec)

 

[Viking83]

Ok, so I got the other camera. Same original problem, i.e. same davinci reboot error. I then tried to load 5.3.0 and got the "writing to /dav_sec" error. And then the "pri and sec part data dirty" was back.

I guess some flag gets set the moment you try to update with the modified language dav file and it prevents any further attempts to upgrade to any release 5.3.0 or higher.

Using the 5.2.5 dav file got me back in business like before.

 

[alastairstevenson]

Any chance you could share a copy of the mtdblock6 so I could try it on a test camera and see if the upgrade block is linked to specific contents?
If so - zip it and file attach in Conversations would be good.

mtdblock1 is used to hold upgrade-related items such as last firmware version loaded, and upgrade success / fail counts and is queried by new firmware on bootup to determine how to behave.

 

[Purduephotog]

How did this turn out @alastairstevenson ?

"do not do it above firmware 5.2.5 unless you want to spring a particularly nasty Hikvision trap." - and ... what's this trap you were talking about Alastair?

Ya know, as I browse these forums more I'm simply amazed at the breadth of your knowledge and how freely you give it.

So- Thank You.

~J

 

[alastairstevenson]

what's this trap you were talking about Alastair?

A new Hikvision tripwire.

How did this turn out @alastairstevenson ?

This turned out OK in the end.
To help avoid some of the rather techy steps of the 'enhanced MTD hack' that converts the CN R0 series cameras to EN/upgradable I created the brickfixV2 fixup method. It's been used by lots of people.
This hides away using a script quite a lot of the techy stuff than can trip up many people - automates the read/re-write of mtdblock6 from a kernel that doesn't mess nastily with it, and also automatically writes a valid template in to mtdblock1 to cover those early-manufactured cameras that had one that bricked when later firmware was applied.