DS-2CD4112FWD-IZ Fails to boot: Uncompressing Linux... unexpected EOF -- System halted

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
Hello! I'm attempting to bring a Hikvision DS-2CD4112FWD-IZ back from the dead and I could sure use some help.

I received the camera in a state where it would not boot up. I don't know how it got into this state.

I've flashed several different versions of firmware to the camera (from both the USA and Europe Hikvision sites). I'm using the Hikvision TFTP tool, and the firmwares always seem to upload without issue, but the camera will not boot.

I cobbled together a USB TTL-Serial connection so I could get some more details using a serial connection with Putty. After updating the firmware, the camera attempts to boot and I see the following information in the putty terminal:

Starting kernel ...
Uncompressing Linux...
unexpected EOF
-- System halted
Any suggestions on what where to go from here??? I'm not sure what the next steps to troubleshoot this would be... THANKS!

Full putty session below (several lines of hash marks removed for brevity):

Code:
U-Boot 2010.06-113941 (Feb 03 2015 - 11:17:39)

ARM clk: 1000MHz
DDR clk: 533MHz
L3  clk: 240MHz
IVA clk: 410MHz (HDVICP)
ISS clk: 480MHz
DSS clk: 240MHz
DSP Default OFF

I2C:   ready
DRAM:  512 MiB
Hit Ctrl+u to stop autoboot:  0
link up on port 0, speed 100, full duplex
found tftpserver
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Filename 'digicap.dav'.
Load address: 0x81000000
Loading: #################################################################
         (38 lines of hash marks....)
         ##################################################
done
Bytes transferred = 13563100 (cef4dc hex)
Found 1 packets.
Skip file _cfgUpgSecPls
Skip file _cfgUpgClass
write uImage len: 3006692 ok
write app.img len: 10555392 ok
Upgrade success!
load kernel to 0x80007fc0 ... Done!
## Booting kernel from Legacy Image at 80007fc0 ...
   Image Name:   Linux-2.6.37_DM385_IPNC_3.00.00
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3006628 Bytes = 2.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK
OK
Starting kernel ...
Uncompressing Linux...
unexpected EOF
-- System halted
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I've flashed several different versions of firmware to the camera (from both the USA and Europe Hikvision sites)
This might be the key to the problem if the firmware you've tried isn't the correct one for the model.
Which series firmware did you use?

This looks like the one that matches the model number : DOWNLOAD EU PORTAL
But it's probably the one you use as the kernel version matches your bootlog transcript above : Linux-2.6.37_DM385_IPNC_3.00.00

It looks like the data from flash is being truncated - perhaps there is a flash hardware fault.
If the bootloader still has that functionality (Hikvision keep stripping out 'useful' capability, though that is an older model camera) maybe try tftp booting the attached kernel over the network to see if it starts up.
 

Attachments

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
Thanks @alastairstevenson !

Yes, I've tried the firmwares found at that link (except for V5.4.5_Build170216 since it said it was '(Only for Dual-lens ATM)'). The firmware I was loading in the example shared was the one from the USA Hikvision site:
https://us.hikvision.com/sites/default/files/firmware/ds-4x124x24f4x32_ip_camera_firmware_v5.3.4_150812.zip

However, I get the same result regardless of the firmware I attempt.

I'll try the kernel you shared first thing in the morning and report back. I'm going to have to refresh my knowledge on how to boot that image via tftp. If there are some instructions/forum post on how that's done please direct me to it.

Thanks again for the assistance!
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I think there are several potential approaches to exploring this, which will depend on what command set is available in the bootloader.
As a starting point, suggest :
printenv
To see the environment variables.
help
To see the commands available.

Assuming some address variables are set suitably, here is something I've used previously when a tftp server is running with the uImage in the same folder :
Adjust addresses to suit.

setenv ipaddr 192.168.1.64
setenv serverip 192.168.1.99
tftpboot uImage;bootm
 

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
Thanks again. I encountered the same 'unexpected EOF' error when using the uImage you provided. Here is the output from the commands you suggested:

Code:
HKVS # printenv
bootargs=console=ttyS0,115200n8 mem=128M
bootcmd=loadk;bootm 0x80007fc0
bootdelay=2
baudrate=115200
netmask=255.255.255.0
bootfile="uImage"
bldfile="u-boot_385.bin"
trspt=0
ethact=cpsw
ipaddr=192.0.0.64
serverip=192.0.0.128
stdin=serial
stdout=serial
stderr=serial
ethaddr=28:57:be:47:8a:de
ver=U-Boot 2010.06-113941 (Feb 03 2015 - 11:17:39)

Environment size: 342/8136 bytes


HKVS # help
?       - alias for 'help'
base    - print or set address offset
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
dcache  - enable or disable data cache
format  - format flash except bootloader area
go      - start application at address 'addr'
help    - print command description/usage
icache  - enable or disable instruction cache
loadk   - load kernel to DRAM
loop    - infinite loop on address range
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mtest   - simple RAM read/write test
mw      - memory write (fill)
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
tftpboot- boot image via network using TFTP protocol
upa     - update app image
update  - update digicap.dav
updateb - update bootloader
upf     - update firmware, format and update (factory use)
upk     - update uImage
version - print monitor version


HKVS # tftpboot uImage;bootm
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Filename 'uImage'.
Load address: 0x81000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###
done
Bytes transferred = 3006692 (2de0e4 hex)
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-2.6.37_DM385_IPNC_3.00.00
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3006628 Bytes = 2.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux...

unexpected EOF
 -- System halted
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
HKVS # tftpboot uImage;bootm
That worked well - loaded the kernel over the network and executed in RAM at the load address.
And it gave the same error.
I extracted the uImage from the firmware linked to in the earlier post.

So seems to eliminate the flash memory as the cause of a truncated file.

The question now is - what is truncating the data?
Whether it's loaded from flash into memory in the normal way, or loaded into memory using tftp, the same error occurs.
Memory is the common factor. Maybe there is a hardware fault in the RAM.
Let me see if I can work up some commands to test it, there are several methods that should work.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
OK - here is something simple to try.
Interrupt the bootloader.
Check out the command parameters of the memory fill command, mw, probably by just using mw by itself on the command line to get some help text.
We're looking for the order of where, what and how much, to fill memory with FF for 0x2e0000 bytes, so probably for example -
mw 0x81000000 0xff 0x2e0000

And then, assuming a large rollback buffer in PuTTY, or maybe easiest to do it in several chunks, read back the memory and see if it matches what was written.
md 0x81000000 0xb8000

If that shows as OK - repeat by writing 0x00 or 0xAA instead of 0xFF

Beyond that would be something like loading up the uImage into memory, and writing it back out again to do a comparison.
But that takes a few more steps.
 

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
Thanks I'll try out the mw command and see what I come up with...

FYI, here is the help output for mw:

HKVS # mw
mw - memory write (fill)

Usage:
mw [.b, .w, .l] address value [count]
..and the md command:
HKVS # help md
md - memory display

Usage:
md [.b, .w, .l] address [# of objects]
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
Looks OK - try it out.
The idea is to write memory with a fixed value for about the same size as the kernel, then read it back to see if it is the same.
A bit crude - but I think we're looking for a gross problem here.
 

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
I ran the mw and md commands as specified. I enabled logging on putty in hopes of catching all of the output to the putty log.

The mw command executed in less than a second. It appears to have worked, as the md command floods the screen with the memory contents (000000ff). After about 10 seconds of this, my computer blue screens and reboots (Windows 10). It blue-screened with and without logging enabled.

I'm doing some research/experimenting with the md parameters now. What do you think would be a reasonably sized 'chunk' to give the md command?

HKVS # mw 0x81000000 0xff 0x2e0000
HKVS # md 0x81000000 0xb8000
81000000: 000000ff 000000ff 000000ff 000000ff ................
81000010: 000000ff 000000ff 000000ff 000000ff ................
81000020: 000000ff 000000ff 000000ff 000000ff ................
81000030: 000000ff 000000ff 000000ff 000000ff ................
81000040: 000000ff 000000ff 000000ff 000000ff ................
81000050: 000000ff 000000ff 000000ff 000000ff ................
81000060: 000000ff 000000ff 000000ff 000000ff ................
.
.
.
.
(Blue Screen)
 

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
Instead of using the 'md' command to display the contents of memory, I tried using the 'cmp' command to compare the first half of that memory block to the second half. Also, I read that the U-Boot memory commands accept modifiers to define the size of the memory object, so I executed all commands using 'bytes' (.b modifier) as the object size to keep it simple for my tiny 8-bit brain. (the default size is 32 bit or long words).

The cmp commands report that the first half and second half memory comparisons are the same, so it would appear the 'mw' command executed successfully and the memory was read successfully.

Please check my work and let me know if this is a valid test. It's entirely possible I'm completely misunderstanding how this environment works and how to use these tools.

Edit: (Corrected commands pasted into code section below)
Code:
HKVS #  mw.b 0x81000000 0xff 0x2e0000
HKVS # cmp.b 0x81000000 0x81170000 0x170000
Total of 1507328 bytes were the same
HKVS # mw.b 0x81000000 0x00 0x2e0000
HKVS # cmp.b 0x81000000 0x81170000 0x170000
Total of 1507328 bytes were the same
HKVS # mw.b 0x81000000 0xAA 0x2e0000
HKVS # cmp.b 0x81000000 0x81170000 0x170000
Total of 1507328 bytes were the same
 
Last edited:

rearanger

Getting the hang of it
Joined
Feb 10, 2016
Messages
224
Reaction score
96
Location
Scottish Borders
does the uImage not need loaded to 0x80007fc0 and called at 0x80008000?(according to printenv) NOT 0x81000000

Also has the printenv been altered?
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
Instead of using the 'md' command to display the contents of memory, I tried using the 'cmp' command to compare the first half of that memory block to the second half.
That method is so much better and more elegant than my crude suggestion - I'm embarrassed not to have thought of it.
If it's doing what it appears to be doing, it suggests that the memory where the uImage is loaded is working as it should.
Maybe as a confirmation, change one byte somewhere and confirm it gets noticed.

So where to go from here?

Although it seems very unlikely that there is a problem with the downloaded firmware, maybe worth trying the 'update' command on another of the versions from here : DOWNLOAD EU PORTAL

does the uImage not need loaded to 0x80007fc0 and called at 0x80008000?(according to printenv) NOT 0x81000000
You are quite right - that region of memory should be tested as well, as that's what the default boot from flash process uses.
Though both the normal boot, at 0x80008000 and the tftpboot over the network at 0x81000000 are giving the same error when uncompressing the kernel.
 

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
Thanks for your continued support @alastairstevenson and welcome to the party @rearanger !

Maybe as a confirmation, change one byte somewhere and confirm it gets noticed.
I ran a test by changing one byte and confirmed the cmp command detected the difference:

Step1: Set the memory to all 0xff values, and run the comparison:
Code:
HKVS # mw.b 0x81000000 0xff 0x2e0000
HKVS # cmp.b 0x81000000 0x81170000 0x170000
Total of 1507328 bytes were the same
Step2: Change one byte, and re-run the comparison:
Code:
HKVS # mw.b 0x81110000 0xbb
HKVS # cmp.b 0x81000000 0x81170000 0x170000
byte at 0x81110000 (0xbb) != byte at 0x81280000 (0xff)
Total of 1114112 bytes were the same

maybe worth trying the 'update' command on another of the versions from here : DOWNLOAD EU PORTA
I've tried 4 different firmwares using the 'update' command from within the U-Boot environment (two from EU portal and two from USA web site). All of them install successfully, but fail with the same "
Starting kernel ... Uncompressing Linux... unexpected EOF -- System halted" message.

You are quite right - that region of memory should be tested as well, as that's what the default boot from flash process uses.
I tested the 0x80008000 memory space using the same 'mw' and 'cmp' procedure as before and it tested ok. As an additional test, I loaded the firmware @alastairstevenson extracted the uImage file from ('IPC_R1_EN_STD_V5.4.5_Build170228.zip') using the 'update' command. Then I loaded the uImage as a normal boot would do (to 0x80007fc0), downloaded the uImage using tftp (to 0x81000000) and compared the two memory spaces. They were identical:

Code:
HKVS # loadk
load kernel to 0x80007fc0 ... Done!


HKVS # tftpboot uImage
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Filename 'uImage'.
Load address: 0x81000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###
done
Bytes transferred = 3006692 (2de0e4 hex)


HKVS # cmp.b 0x80007fc0 0x81000000 0x2DE0E4
Total of 3006692 bytes were the same
HKVS #


Maybe it is in the space where the compressed linux kernel is being extracted to (and the error message is a bit misleading). If you have any other suggestions on tests to perform I'm willing to give it a try. At this point it is more of a learning opportunity and challenge to see if the root cause can be discovered. I've already learned a lot through this process. Thanks!
 
Last edited:

rearanger

Getting the hang of it
Joined
Feb 10, 2016
Messages
224
Reaction score
96
Location
Scottish Borders
try this
tftp 0x80007fc0 uImage
go 0x80008000

If it does work change bootm to "bootm 0x80008000" or take bootm out (its not on my G0 cam)

On a G0 cam that loads the uImage into correct area. If you attempt to load into 0x81000000 the G0 camera attempts to uncompress but hangs.(I know its not a G0, but it has similarities). if you attempt to execute/go at 0x80007fc0 it also halts /freezes loading linux

Also when you upgraded did you go via a hub for ethernet? (as apposed to direct connection to PC.) Don't use direct connection go through a hub. the error correction/tftp transfer is iffy. It sometimes it says the transfers is fine and its not.

if none of that helps then I am unsure what else to try.
 

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
Thanks for the additional suggestions.

try this
tftp 0x80007fc0 uImage
go 0x80008000
I tried that and got the same result:
Code:
HKVS #  tftp 0x80007fc0 uImage
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Filename 'uImage'.
Load address: 0x80007fc0
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###
done
Bytes transferred = 3006692 (2de0e4 hex)
HKVS # go 0x80008000
## Starting application at 0x80008000 ...
Uncompressing Linux...

unexpected EOF
 -- System halted
Also when you upgraded did you go via a hub for ethernet?
I upgraded using a POE switch. Just my laptop and the camera attached to the switch.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I am unsure what else to try.
Me too - I'm at a loss as to what else to suggest to explore this problem.

So the uncompressor on the front of uImage starts OK but does not complete
On the face of it, the flash memory and RAM memory are able to hold the uImage data without errors.
Re-flashing the firmware does not fix it.
 

fritzycat1

n3wb
Joined
Jan 19, 2016
Messages
26
Reaction score
11
Location
Hollywood, CA
I'm all out of ideas too. I'll probably put this aside for a while unless some new ideas come up. Thanks again for all the help - it's been a good educational exercise for me.

I did have a question though - how did you extract the uImage file from the firmware file?
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
how did you extract the uImage file from the firmware file?
I used the @montecrypto very useful Hikvision firmware repacker tool, from here : [MCR] Hikvision packer/unpacker for 5.3.x and newer firmware

Like so -

Code:
alastair@PC-I5 ~/cctv/CameraFirmware/V5.4.5/IPC_R1_EN_STD_V5.4.5_Build170228 $ ll
total 26500
drwxrwxr-x  2 alastair alastair     4096 May 20 09:32 ./
drwxr-xr-x 11 alastair alastair     4096 May 18 10:38 ../
-rwxrwxr-x  1 alastair alastair 13563100 Feb 28  2017 digicap.dav*
-rw-rw-r--  1 alastair alastair 13559259 May 18 10:37 IPC_R1_EN_STD_V5.4.5_Build170228.zip
alastair@PC-I5 ~/cctv/CameraFirmware/V5.4.5/IPC_R1_EN_STD_V5.4.5_Build170228 $ hikpack_2.5 -t r1 -x digicap.dav -o contents
Magic   : 484b5753
hdr_crc : 0000277b (OK)
lang_id : 00000001
Date    : 170228
version : 05040005
frm_flg : 1160030041111110011
File: _cfgUpgSecPls, CRC OK
File: _cfgUpgClass, CRC OK
File: uImage, CRC OK
File: app.img, CRC OK
alastair@PC-I5 ~/cctv/CameraFirmware/V5.4.5/IPC_R1_EN_STD_V5.4.5_Build170228 $ ll contents
total 13268
drwxr-xr-x 2 alastair alastair     4096 May 20 09:32 ./
drwxrwxr-x 3 alastair alastair     4096 May 20 09:32 ../
-rw-r--r-- 1 alastair alastair 10555392 May 20 09:32 app.img
-rw-r--r-- 1 alastair alastair      276 May 20 09:32 _cfgUpgClass
-rw-r--r-- 1 alastair alastair      500 May 20 09:32 _cfgUpgSecPls
-rw-r--r-- 1 alastair alastair      240 May 20 09:32 dav_header
-rw-r--r-- 1 alastair alastair  3006692 May 20 09:32 uImage
alastair@PC-I5 ~/cctv/CameraFirmware/V5.4.5/IPC_R1_EN_STD_V5.4.5_Build170228 $
 
Top