Bricked DS-7604NXI-K1/4P, am I out of options?

Virgilvdw

n3wb
May 6, 2023
8
3
Netherlands
Hi,

Recently I've bought a DS-7604NXI-K1/4P NVR from a authorized Hikvision reseller in the Netherlands. After setting up the smart events I've noticed some inconsistencies when events we're triggered. After trying to finetune some settings in the configuration I was still unhappy about the lack of consistent alarms being triggered. So reason for me to try a firmware update.

So I've downloaden the latest version available from Hikvision Europe, read the release notes to confirm my model is supported. After trying to upgrade de firmware it failed at around 75%. Every retry it failed again, untill it wouldn't start up at all.

Now I'm with a device that is stuck in a bootloop. I've tried numerous options available on this forum. Setting up TFTP is not working, the NVR is not requesting the firmware. I've bought a USB to TTL serial adapter and hooked it up to the 4-pin JST ZH connector on the PCB. I've started up PuTTY and turned on the device. I'm able to interrupt the autoboot but that is as far as I can get. The CLI is not responding to any commands, not even with the 'trick' provided on this forum on models with the "HKVS $" prompt.



U-Boot 2019.04 (May 10 2022 - 21:16:34 +0800), Build: jenkins-Backend-BSP-CCI-6361

Read power trim = 0x00000000
remap_data 8
pwm_id:0 pinmux = 0x1
pwm_id(0) pwm_pinmux(0x1)
pclk_freq(30000000) div(3)
NVT_MMC1: 1
OK
switch to partitions #0, OK
mmc1(part 0) is current device
nvt_emmc_set_bootbus: Set EMMC boot bus to 8-bit mode
misc_init_r: boot time: 2118452(us)
misc_init_r: boot time: 2192520(us)
[na51090_mmcboot_partition][2040]find emmc part cpld info.
[na51090_mmcboot_partition][2040]find emmc part bootparam info.
[na51090_mmcboot_partition][2040]find emmc part ubootenv info.
Set CPU clk 1200MHz

Warning: eth0 MAC addresses don't match:
Address in SROM is e0:ba:ad:c5:2c:7f
Address in environment is 00:00:23:34:45:66
[na51090_mmcboot_partition][2040]find emmc part ubootenv info.
Hit ctrl+u to stop autoboot: 0
HKVS $ setenv ';help'
HKVS $ setenv bootcmd ';update'
HKVS $ setenv ';update'
HKVS $


Has anyone here experienced the same problems with these newer model NVRs? And is it even fixable at this point
 
Ah...another "hey let me see if a firmware I pull off the internet update fixes this" even though the release notes are silent on whether update would fix it (hint it usually doesn't)...

We have seen many people brick their camera or NVR with this mindset.

You should always get firmware updates from the seller.

@alastairstevenson is our Hikvision expert - if anyone can figure it out, it will be him.
 
Last edited:
HKVS $ setenv ';help'
HKVS $ setenv bootcmd ';update'
HKVS $ setenv ';update'
HKVS $
These commands have generated the desired results on recent I-series and K-series bootloaders.
It's an obfuscation attempt by Hikvision to inhibit the ability of technical users to 'do stuff'.
But it got out into public view - so I'd speculate that as a consequence Hikvision have now blocked that method of interacting with the bootloader.
If so - I've not seen (yet) how we get round that.
 
Now I'm with a device that is stuck in a bootloop.
If it's a fairly lengthy bootloop, there might just be a chance to get more detail from the serial console than it's usual very quiet behaviour, to see what it's complaining about that triggers the reboot.

If it's behaving like current I-series firmware, there may be a command
ttyAuth
which prompts for a username / password to enable the usual detail.
If available - it's can just be tried a few times during the boot process.
username=admin with the configured password should work if the command is available.
Then check the tail end of the serial console output.
 
  • Like
Reactions: JDreaming
Is there a reason you do not go back to your authorized Hikvision reseller in the Netherlands? They should be able to help you since you bought it from them.
 
Is there a reason you do not go back to your authorized Hikvision reseller in the Netherlands? They should be able to help you since you bought it from them.

I have contacted them and they offered me to send it to them to have an attempt at fixing it for an acceptable fee however they couldn't garantee to get it working again. Ofcourse messing with the software isn't covered by the waranty so I wouldn't expect them to send me a new one either.

As I'm this far with troubleshooting on this myself I'd thought to try this forum first to see if the experts here have a solution for this. If not then I doubt the reseller would get it fixed themselves. It would save me the hassle to pack the NVR and send it to them.
 
If it's a fairly lengthy bootloop, there might just be a chance to get more detail from the serial console than it's usual very quiet behaviour, to see what it's complaining about that triggers the reboot.

If it's behaving like current I-series firmware, there may be a command
ttyAuth
which prompts for a username / password to enable the usual detail.
If available - it's can just be tried a few times during the boot process.
username=admin with the configured password should work if the command is available.
Then check the tail end of the serial console output.

At what stage would I be able to enter the "ttyAuth" command? If I let the boot process run the last lines in the console output would be this:

[DVR_MAIN_PROCESS][26][dvr_startup_mega_baseline_init] start!!,time[1683405627]!!
<MEGA_DSP>Def Value:
<MEGA_DSP>Main mux type [0x10][0x2].
<MEGA_DSP>Sub mux type [0x10][0x2].
<MEGA_DSP>audio enc type[0x1011][0x1].
<MEGA_DSP>voicetalk type[0x1011][0x1].
<MEGA_DSP>Need PS SysHdr[0].
iVideoEncType : 2
iAudioEncType : 4113
iVTType : 4113
iMainMuxType : 16
iSubMuxType : 16
iMainPackLen : 1376
iSubPackLen : 1376
bNeedPSSysHdr : FALSE
bNeedSubQVGARes : FALSE
bMegaPlatEnable : FALSE

[DVR_MAIN_PROCESS][26][dvr_startup_mega_ba


After this it cycles back to the bootloader.
 
Ah...another "hey let me see if a firmware I pull off the internet update fixes this" even though the release notes are silent on whether update would fix it (hint it usually doesn't)...

We have seen many people brick their camera or NVR with this mindset.

You should always get firmware updates from the seller.

@alastairstevenson is our Hikvision expert - if anyone can figure it out, it will be him.

Thanks for the passive-aggressive statement. In my defense the release notes of the firmware version I was trying to load state the following:

Reason of Upgrade: Fix known defects and optimize product performance.

It didn't go further into details.

Also as I'm a IT Infrastructure specialist it is very common in my line of work to apply firmware updates on a regular basis on e.g. firewalls to mitigate bugs and close security vulnerabillities.

As this is my first time touching Hikvision software, and as it (at first) seemed to be an A-brand product, I wasn't expecting such bad implementation of software. I mean who the hell is still using webcomponents that require the use of a deprecated browser like IE to run the Live Views? Which I also need to configure the smart features like line crossing detection or intrusion detection.. Also no firmware validation before installation? Would be preventing a lot of bricked devices..

I have the NVR mounted in my server rack and I'm only using the Hik-connect app, thats why I chose the NVR over a DVR.
 
At what stage would I be able to enter the "ttyAuth" command?
In the I-series firmware, the command isn't accepted until maybe half way through the boot process, but no harm just keeping on typing it in multiple times during the process.
If the system becomes ready to process this command, it issues an authentication prompt.

I see nothing in your bootlog transcript to indicate why it's rebooting.
 
In the I-series firmware, the command isn't accepted until maybe half way through the boot process, but no harm just keeping on typing it in multiple times during the process.
If the system becomes ready to process this command, it issues an authentication prompt.

I see nothing in your bootlog transcript to indicate why it's rebooting.

I've tried the command multiple times but it stated an error. I've attached the output transcript of a 1,5 bootcycle.
 

Attachments

I get it, it sucks to have bricked your unit. Many of us have been there. Unfortunately for educational purposes for future users a post may come across as passive aggressive to the OP.

My comment is more of a cautionary tale for people that come here and do a search before applying an update to see what issues people are experiencing. If you did that you would have found this is a likely outcome.

Something you will find is most of us don't update firmware on these devices - too many issues.

Being an IT specialist, wouldn't you want to search first for issues before blindly applying firmware you found on the internet?

Keep in mind we are not the intended market of Hikvision, so yeah they use old browsers and their market is professional installers who never update their install equipment. Further most installers don't have maintenance contracts with their users, so most stuff is never updated.

So we either deal with outdated browsers but better cameras or go with crap consumer grade cameras that use fancy apps and modern browsers but horrible images.

In most instances, updates are simply security vulnerability patches (usually years after the breach was found), but since we do not give our units internet access, the update is useless to us.

Unless the release notes specifically mention it fixing a problem you are experiencing, more than likely it won't fix an issue and may make the device worse by removing functionality. We have seen that with many devices. Looks like we are adding this NVR to the list.

Another thing to consider is that the same model could have different firmware for different chipsets used during the life of that model. So you run the risk of bricking if you do not know what chipset you have.

Further, it is best to obtain any firmware updates from the vendor you purchased it from so that you do not run into issues. Any firmware you find here or elsewhere is obviously proceed at your own risk. We have many threads here where someone tried an update with a firmware they found on the internet and bricked their unit, even firmware from the manufacturer website.

How long ago did you buy it? If with return period simply return it.
 
  • Like
Reactions: JDreaming
I get it, it sucks to have bricked your unit. Many of us have been there. Unfortunately for educational purposes for future users a post may come across as passive aggressive to the OP.

My comment is more of a cautionary tale for people that come here and do a search before applying an update to see what issues people are experiencing. If you did that you would have found this is a likely outcome.

Something you will find is most of us don't update firmware on these devices - too many issues.

Being an IT specialist, wouldn't you want to search first for issues before blindly applying firmware you found on the internet?

Keep in mind we are not the intended market of Hikvision, so yeah they use old browsers and their market is professional installers who never update their install equipment. Further most installers don't have maintenance contracts with their users, so most stuff is never updated.

So we either deal with outdated browsers but better cameras or go with crap consumer grade cameras that use fancy apps and modern browsers but horrible images.

In most instances, updates are simply security vulnerability patches (usually years after the breach was found), but since we do not give our units internet access, the update is useless to us.

Unless the release notes specifically mention it fixing a problem you are experiencing, more than likely it won't fix an issue and may make the device worse by removing functionality. We have seen that with many devices. Looks like we are adding this NVR to the list.

Another thing to consider is that the same model could have different firmware for different chipsets used during the life of that model. So you run the risk of bricking if you do not know what chipset you have.

Further, it is best to obtain any firmware updates from the vendor you purchased it from so that you do not run into issues. Any firmware you find here or elsewhere is obviously proceed at your own risk. We have many threads here where someone tried an update with a firmware they found on the internet and bricked their unit, even firmware from the manufacturer website.

How long ago did you buy it? If with return period simply return it.

I've bought it a week ago, but in this state it is not within the return policy. As for firmware updates within my line of work we usually defer a 'x' amount of time from latest releases. And always receive them from official resources. Maybe I'm spoiled with good working software..
 
Wow a week and you cannot return? That is harsh.

If you decide to dabble in these type of systems, you will find you have been spoiled with good working software lol.

It is an unfortunate nuisance we have to deal with old browsers and wonky firmware and bricking units when updating. So we learn to not update and deal with older browsers as the sacrifice to get good quality video.

Many/Most here will say that the consumer grade cameras software/app experience of say a Reolink or Ring is better than a Dahua or Hikvision, but their video quality, especially at night is useless.

I would go back to the seller and tell them you have a defective unit. Buying from an authorized reseller should give you more protection on a firmware update than a 3rd part reseller from Amazon or Aliexpress.
 
  • Like
Reactions: JDreaming
I've bought it a week ago, but in this state it is not within the return policy. As for firmware updates within my line of work we usually defer a 'x' amount of time from latest releases. And always receive them from official resources. Maybe I'm spoiled with good working software..

What is good working software ?

OS X ? Many bugs that will never get fixed , not even in yearly "brand new better than before version"

Windows ? :rofl:

Android ? :rofl:

SAP ? Oracle ? :rofl:


What is your state ?
European Union has 14 days by law.

This is clearly a DOA device.
Send it back or claim warranty via hikvision support.
 
  • Like
Reactions: Chango
IP Cameras don't behave like network appliances where you have a robust recovery subsystem and the ability to boot from any OS on your flash card.
IP Cameras behave more like phones that have a locked bootloader. You can only upgrade forward and if it breaks, you buy a new phone.
 
I mean who the hell is still using webcomponents that require the use of a deprecated browser like IE to run the Live Views?
You are preaching to the choir. That is a common complaint here. While I do not use Hik components, they are one of the 'A' brands.

As @wittaj stated "their market is professional installers who never update their install equipment. Further most installers don't have maintenance contracts with their users, so most stuff is never updated."

Most commercial settings, which is what these cam companies are selling to, don't upgrade or update firmware. In a few years, they just replace everything.
 
  • Like
Reactions: Flintstone61
I've tried the command multiple times but it stated an error.
Yes, ttyAuth isn't a feature on that firmware.
But it's not needed, as the serial console is it's usual chatty self, unlike the current K51 I-series firmware where it's almost silent.

Despite the good detail in your transcript, it's still not clear to me what's causing the reboot, when the NVR has pretty well completed the bootup process.

I'm curious what this little comment means though :
UNZOK!PCK[120]

edit It seems this is just a startup comment from the bootloader.
 
Last edited: