Hikvision DS-2CD2132F-IS bricked, in search of help
- Thread starter Billkater
- Start date
whoslooking
IPCT Contributor
You have nothing to lose, if you brick it you can ftp in
Just follow my guide on how to unbrick.
Just follow my guide on how to unbrick.
Last edited by a moderator:
Tried to instal 5.3.0. Still no joy. In a boot loop. Here is the log from it
View attachment 5.3.0 log.txt
View attachment 5.3.0 log.txt
alastairstevenson
Staff member
Yes, exactly the same problem - the Linux kernel does not like the contents of the block of firmware that holds the initial ramdisk - looking for the structures associated with an initramfs, not finding it, and not trying for the alternate initrd format as it normally would.
*edit*
This is the same section from my 2014 manufactured 2132 with firmware 5.2.3 installed.
The cause and solution has got us all stumped.
*edit*
This is the same section from my 2014 manufactured 2132 with firmware 5.2.3 installed.
Just came back in to do a little work. Found that SADP has seen the camera as DS-2cd-Min..... I pulled a log from it as I could use PuTTy and hook right to it without any problems. I rebooted the camera and SADP saw it aftre about 10 minutes. The log still shows
This just has me stumped. I am going to plug it into my lan and see if I can access it though a 192.168.x.x address. Any clue which one it will be?
I used the 5.3.0 firmware from http://overseas.hikvision.com/en/download_89.html#prettyPhoto. It was the Baseline Firmware_IPC_En_V5.3.0 150327 (2XX0)(New) version.
This just has me stumped. I am going to plug it into my lan and see if I can access it though a 192.168.x.x address. Any clue which one it will be?
Attachments
Sticker shows 01/2015 v5.2.8 141231
This is the same stage i am at - it lets me set an ip address and tftp also works but that's about it.. not tried connecting through the serial connector as I am unsure what could be achieved if anything
alastairstevenson
Staff member
This is @iTuneDVR view of what may be the problem - could be correct
It's possible it gets loaded into memory and corrupted.
On the other hand - the bootstrap works OK, the kernel loads, firmware update works, so no evidence of memory problems there.
as the primary flash area for the initrd has been re-written and the problem persists.
It's possible it gets loaded into memory and corrupted.
On the other hand - the bootstrap works OK, the kernel loads, firmware update works, so no evidence of memory problems there.
Last edited by a moderator:
alastairstevenson!
TFTP 5.2.5 must reflash mtd10 and mtd11 correctly!
Yes bootstap is ok, but use different part of memory.
I saw it many times in other hikvision IPC model, older and more newer.
In one case i rebuild firmware (do smaller) and TFTP work correctly, but with the original firmware TFTP does't work.
Here is other situation, but the ploblem the same. I think so!
TFTP 5.2.5 must reflash mtd10 and mtd11 correctly!
Yes bootstap is ok, but use different part of memory.
I saw it many times in other hikvision IPC model, older and more newer.
In one case i rebuild firmware (do smaller) and TFTP work correctly, but with the original firmware TFTP does't work.
Here is other situation, but the ploblem the same. I think so!
So, are you suggesting a hardware problem. Namely a memory problem?
Yes.
If you did everything right and nothing else from you does not depend on, it means that a problem with the hardware.
Thanks Itune
I guess this is viable - we usually expect around a 5% failure on flash memory sold in our shop + even PC's suffer from similar problems, often a faulty memory stick will only cause problems on installation of the O/S which is a tricky one to explain to the customer..
One last thing to try is a stable power supply - I tested a couple of supplies of which I found can be quite a bit off the 12v they are rated at.. I have read posts where people have found this to be an issue when flashing the F/W.
It didn't help me but it's worth checking
As i said If you did everything right and nothing else from you does not depend on......
If you look closely you will see that mtdblock10,11,12 -is in usual format, but 13-16 is in ubifs.
Of course, the possible failure flash memory, but your IPC has worked in the beginning!
But i think it's RAM problem.
In any case, do not come back and spend your time on it!
Q™
IPCT Contributor
Better to send it to alastairstevenson so that he might experiment for the betterment of ipcomeradom.
alastairstevenson
Staff member
I'd thought about that too - in the interests of academic research.
Would have been an interesting idea - but we're in different countries quite some miles apart.
Would have been an interesting idea - but we're in different countries quite some miles apart.
Interesting word - I'll need to look it up lol.
alastairstevenson
Staff member
@Billkater - This may be a dead topic for you now - or maybe not if your junk pile is bugging you. But may be of interest to others.
With the many problems being seen by people updating the new-manufacture 2-series Hikvision cameras I felt a bit helpless not having one to play with and try things out for myself. So I bought another 2CD3332N-I from CSST, arrived in 9 days.
Label 5.2.8 03/2015, apparent actual 5.2.5, so in the ball park for problems if updated. The camera works fine, connects to both 7816N-E2 NVRs, language=1 in prtHardInfo, 0x02 in mtdblock5&6, CCCH in the serial number. So Chinese under the covers.
So the first thing I did (after step 0 which was to make a copy of all the flash mtdblock segments ...) was to change the language byte from 0x02 to 0x01 in all the hardware descriptor blocks of mtdblock5 & 6 with a compensating change in the bytes that set the MAC address.
All was good after the reboot - no obvious changes. But it was still running the hacked firmware that masquerades the language to English.
The next thing I did was a planned empirical (suck it and see) exploration of which parts of the hardware descriptor block are covered by the checksum.
As expected, on the first single byte change, the camera bricked and bootlooped.
To get it back, I used TFTP with a 5.2.5 English digicap.dav (@whoslooking published) and left TFTP running after the file download and 'upgrade success' message, at which point telnet to 192.0.0.64 is available.
And here is the point of posting this here, as there may be some commonality with your problem:
Inspecting the kernel log (cat /proc/kmsg) showed the reason bootup was incomplete - no ramdisk. This is the symptom your camera has.
I put the previous (language-changed) copy of mtdblock6 back, and the camera booted up OK, though back to default settings, and with the 5.2.5 firmware installed.
So I'm wondering if the entry in the kernel log "Initramfs unpacking failed: junk in compressed archive" may be a deliberate red herring to cover what in reality is a checksum integrity failure.
I'll know more as I continue the journey of discovery.
With the many problems being seen by people updating the new-manufacture 2-series Hikvision cameras I felt a bit helpless not having one to play with and try things out for myself. So I bought another 2CD3332N-I from CSST, arrived in 9 days.
Label 5.2.8 03/2015, apparent actual 5.2.5, so in the ball park for problems if updated. The camera works fine, connects to both 7816N-E2 NVRs, language=1 in prtHardInfo, 0x02 in mtdblock5&6, CCCH in the serial number. So Chinese under the covers.
So the first thing I did (after step 0 which was to make a copy of all the flash mtdblock segments ...) was to change the language byte from 0x02 to 0x01 in all the hardware descriptor blocks of mtdblock5 & 6 with a compensating change in the bytes that set the MAC address.
All was good after the reboot - no obvious changes. But it was still running the hacked firmware that masquerades the language to English.
The next thing I did was a planned empirical (suck it and see) exploration of which parts of the hardware descriptor block are covered by the checksum.
As expected, on the first single byte change, the camera bricked and bootlooped.
To get it back, I used TFTP with a 5.2.5 English digicap.dav (@whoslooking published) and left TFTP running after the file download and 'upgrade success' message, at which point telnet to 192.0.0.64 is available.
And here is the point of posting this here, as there may be some commonality with your problem:
Inspecting the kernel log (cat /proc/kmsg) showed the reason bootup was incomplete - no ramdisk. This is the symptom your camera has.
I grabbed a copy of mtdblock11, which holds initrd, the ramdisk, to check out later. But all I'd changed was one byte in mtdblock6 to cause the camera to brick, so unlikely mtdblock11 was bad.
I put the previous (language-changed) copy of mtdblock6 back, and the camera booted up OK, though back to default settings, and with the 5.2.5 firmware installed.
So I'm wondering if the entry in the kernel log "Initramfs unpacking failed: junk in compressed archive" may be a deliberate red herring to cover what in reality is a checksum integrity failure.
I'll know more as I continue the journey of discovery.