tangent
IPCT Contributor
- May 12, 2016
- 4,619
- 3,973
I'd guess that's a buad rate or text encoding issue. A bad ground connection could also cause things like this.
The bootloader may require you to send a character like a space continuously at first as part of an automatic baud rate detection. After it's booted up this wouldn't be necessary.
Before you try two many things, verify your serial adapter is working by connecting tx and rx on the adapter and typing something to verify that you receive it.
The bootloader may require you to send a character like a space continuously at first as part of an automatic baud rate detection. After it's booted up this wouldn't be necessary.
Before you try two many things, verify your serial adapter is working by connecting tx and rx on the adapter and typing something to verify that you receive it.
Last edited:
tangent
IPCT Contributor
- May 12, 2016
- 4,619
- 3,973
Before you try resoldering anything, try some simple resistance checks or connecting the ground to the case of the nvr.
Are you trying to interact with the bootloader or serial once the device is running? If it's the bootloader, I think you'll need to hold down the space bar when you connect power for automaitc baud rate detection to work.
Have you tried other baud rates? Other text encoding options?
Any idea why ctr U is not working? I have Ds-7216 huhi k2 OEM . I am connected, via putty after boot up I can get help, try to use some commands, but I cant stop boot via CTR U... It is brand new oem - was with some old firmware, I put 4.2, was ok, but user said, that he wants old menu... SO I downgrade to latest old menu firmware, was ok. After month, client said, that wants to new menu
After upgrade there is onlu some user 5 to choose, but there is no admin, and pass is not good... Last time I succesfull upgrad with this cable with similary problem 7208 huhi k2, now I cant stop boot...
After upgrade there is onlu some user 5 to choose, but there is no admin, and pass is not good... Last time I succesfull upgrad with this cable with similary problem 7208 huhi k2, now I cant stop boot...
alastairstevenson
Staff member
OK, so you fixed up the problem that caused abnormal characters.
**edit** Sorry - mixed you up with the other post above.
And this confirms that TX is getting to the RX on the DVR.
You need to be really quick with the Control-U
The best way is to keep the keys pressed so auto-repeat kicks in, then power on the DVR.
Last edited:
Done... thx for answers. Once - too slow CTR+U, second - some jobs should be done not at midnight...
Last edited:
alastairstevenson
Staff member
There is a little trick to get round the barrier that Hikvision have placed at that bootloader prompt where normal commands are ignored ...
You need to prefix each command with setenv and enclose each command within single quotes and prefix with a semicolon.
This is an example of how to issue the commands - I'm not suggesting the contents are relevant to what you want to do, they are just for illustration.
I used this a couple of months back when fixing up a DS-7316HQHI-K4 that had an unknown admin password.
Code:
HKVS $ setenv ';printenv'
bootcmd=tftp 0x42000000 $(bootfile);bootm 0x42000000;
default=cramfsload 0x42000000 uImage;
sec=tftp 0x42000000 Ky2017-1-uImage_sec;bootm 0x42000000;
bootdelay=1
baudrate=115200
ipaddr=192.0.0.64
serverip=192.0.0.128
gatewayip=192.0.0.1
netmask=255.255.255.0
bootfile=uImage
passwd=Ff7mqPaKbKihTW5nC3vk5IoiCntz1B0tcwzUMtMOJFI=
phyaddr0=7
mdio_intf=rgmii
ethaddr=64:db:8b:8b:3e:01
stdin=serial
stdout=serial
stderr=serial
verify=n
bootargs=mem=296M console=ttyS0,115200n8 ;printenv
Environment size: 481/4092 bytes
HKVS $ setenv ';help'
? - alias for 'help'
bootm - boot application image from memory
brush - brush a flash image to the Flash, Be Carefully.
bubt - Burn an boot image on the Boot Flash.
cpld - write cpld info to encrypt media
cramfsload- cramfsload - load binary file from a filesystem image
cramfsls- cramfsls - list files in a directory (default /)
ddr - ddr training function
erase_env- erase envirement info on flash
getinfo - print hardware information
help - print command description/usage
loadb - load binary file over serial line (kermit mode)
loady - load binary file over serial line (ymodem mode)
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mw - memory write (fill)
pflash - print the compatibility list of flash.
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
tftp - tftp - download or upload image via network using TFTP protocol
update - Update the digicap of the device.
version - print monitor version
HKVS $
HKVS $
HKVS $ setenv ';setenv bootargs mem=296M console=ttyS0,115200n8'
HKVS $ setenv ';saveenv'
Saving Environment to SPI Flash...
Erasing SPI flash, offset 0x00060000 size 4K ...done
Writing to SPI flash, offset 0x00060000 size 4K ...done
HKVS $
HKVS $
HKVS $ setenv ';setenv bootargs mem=296M console=ttyS0,115200n8 single'
HKVS $ setenv ';saveenv'
Saving Environment to SPI Flash...
Erasing SPI flash, offset 0x00060000 size 4K ...done
Writing to SPI flash, offset 0x00060000 size 4K ...done
HKVS $
HKVS $ setenv ';reset'
resetting ...
Found the problem.
my TTL adaprot was not working.
just buy another, and work fine.
- Connected using putty
- control-u
- tft ready on pc
- setenv bootcmd ';update'
after update and reboot all was goog
many tnx to all
alastairstevenson
Staff member
I need help! I had 5 2-line hikvision cameras. I upgraded firmware to 4 of them using alastairstevenson directions about 1-1/2 years ago. I cannot thank you enough. However, one of them didn’t go right and seemed to be bricked. I finally bought a 2303 USB to serial cable. Actually bought 3 times from aliexpress and after a 6 month timeframe, finally received one!!! See picture.
Pulled my bricked camera from junk bin and as regrettably, pulling my hair out again...
Here is summary:
1) computer 192.0.0.128
2) Scan network with Advanced IP Scanner finds camera at 192.0.0.64
3) SADP cannot find it
4) I connected to camera via TTL. See picture
5) I use Putty64 using serial enter 115200, N, 8, Flow to None
6) I use Tftpd32 by PH. Jounin. Settings > Global DHCP off, Tftp security NONE, close and rerun program
7) Computer and camera is plugged into a common 24 port switch. Camera is injected with POE power. Both ports blinking randomly
8) All other IP cameras removed from switch
This is where I need help?
9) I unplug and plug in the ethernet cable to camera. Putty starts scrolling info.
10) I do it again by unplugging and plugging back in and immediate press CTRL -U and I get a prompt. As I do not know if anything is really working, I do know if I enter Tftpboot, the Tftp32 server program displays 192.0.0.64:1064 for about 5 seconds
11) If I now enter the command 'update'. It just does nothing. This is where I am stumped.
12) Observations: If I power on camera and let it finish its boot, DOS prompt cannot ping 192.0.0.64 (not reachable), but if I Ctrl U and get the prompt, I CAN ping 192.0.0.64
Any suggestions!?!
Pulled my bricked camera from junk bin and as regrettably, pulling my hair out again...
Here is summary:
1) computer 192.0.0.128
2) Scan network with Advanced IP Scanner finds camera at 192.0.0.64
3) SADP cannot find it
4) I connected to camera via TTL. See picture
5) I use Putty64 using serial enter 115200, N, 8, Flow to None
6) I use Tftpd32 by PH. Jounin. Settings > Global DHCP off, Tftp security NONE, close and rerun program
7) Computer and camera is plugged into a common 24 port switch. Camera is injected with POE power. Both ports blinking randomly
8) All other IP cameras removed from switch
This is where I need help?
9) I unplug and plug in the ethernet cable to camera. Putty starts scrolling info.
Code:
U-Boot 1.3.4-71557 (Apr 3 2014 - 13:08:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
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 191 LEBs (24643584 bytes, 23.5 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.
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 0x4020b000
loading ./orccode.bin...addr = 0x4020b000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x4040b000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x404ab000, 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-71557 (Apr 3 2014 - 13:08:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
begin to enter mini system10) I do it again by unplugging and plugging back in and immediate press CTRL -U and I get a prompt. As I do not know if anything is really working, I do know if I enter Tftpboot, the Tftp32 server program displays 192.0.0.64:1064 for about 5 seconds
11) If I now enter the command 'update'. It just does nothing. This is where I am stumped.
12) Observations: If I power on camera and let it finish its boot, DOS prompt cannot ping 192.0.0.64 (not reachable), but if I Ctrl U and get the prompt, I CAN ping 192.0.0.64
Any suggestions!?!
Attachments
Last edited:
alastairstevenson
Staff member
Your PuTTY log shows that the system attempts to reboot into the 'min-system' recovery mode, but it does not initiallise.
The 'update' command at the bootloader also uses the 'min-system' recovery mode to to the update - but it does not start.
It's a bit of a Catch-22 situation as an update is needed to install new firmware, but the update facility that the 'min-system' recovery provides is broken.
There will be ways to fix this up, assuming that it's not a hardware problem such as a flash failure that's causing it, but it would involve some low-level work.
The easiest way would be using flash write facilities in the bootloader - but it's likely Hikvision have removed these, depending on the date of manufacture.
To check if there is availability, interrupt the bootloader and list the commands with 'help'.
Another approach is to use a modified boot to get to a root shell.
This can be using the kernel / root file system that still exists in flash, or via a tftp boot if that facility remains in the bootloader.
Then by mounting an external file system, files can be transferred in and out.
Do you have a NAS available on your network?
To try booting to a root shell:
Interrupt the bootloader, and list existing environment variables using 'printenv'.
Save the PuTTY rollback to a text file with Notepad or similar, to ensure a record of the initial values.
The idea is to append init=/bin/sh to the bootargs value.
That should inhibit most of the normal startup and give a root shell.
It's handy to have these command in a text file, so they can simply be copied / pasted into PuTTY to save typing and avoid errors.
The original may be something like this:
setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
This can be modded like this:
setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0 init=/bin/sh
Then use 'saveenv' to write the changes to flash, and use 'reset' to boot the device.
Even after the root shell appears - there are some further commands needed to complete the environment and make it usable.
But let's see how you get on first.
Yikes. This look complicated. But I'll give it a shot. I hope the "easier" method applies to me
Model is DS-2CD2532F-IWS Mfg. Date 05/2014 and original firmware 5.1.6
Here is what I have with the HELP command:
Do you have a NAS available on your network?
I have a dedicated PC using Windows 10, with enough hard drives in the system to serve my home entertainment and Blue Iris needs, but I do NOT have a NAS dedicated device.
I think I got to the root shell by entering your commands: I'm now full of anticipation....
Model is DS-2CD2532F-IWS Mfg. Date 05/2014 and original firmware 5.1.6
Here is what I have with the HELP command:
Code:
U-Boot 1.3.4-71557 (Apr 3 2014 - 13:08:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 2
HKVS # help
The following commands are supported:
boot help bios diag
mtest dump erase go
exec ping r8 r16
r32 reset saveenv printenv
setenv show usbdl w8
w16 w32 tftpboot bootm
readoob killb crc nandread
nandwrite ups upm format
update upf upa upr
upk updateb ubi bapi
Use 'help' to get help on a specific command
HKVS #
hDo you have a NAS available on your network?
I have a dedicated PC using Windows 10, with enough hard drives in the system to serve my home entertainment and Blue Iris needs, but I do NOT have a NAS dedicated device.
I think I got to the root shell by entering your commands: I'm now full of anticipation....
Code:
Use 'help' to get help on a specific command
HKVS # printenv
Unknown command:printenv
HKVS # printenv
ipaddr=192.0.0.64
serverip=192.0.0.128
gatewayip=0.0.0.0
netmask=255.255.255.0
ethaddr=44:19:b6:30:02:23
loadaddr=0xc2000000
bootfile=digicap.dav
bootcmd=null
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
bootdelay=2
HKVS #
Unknown command:
HKVS # setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0 init=/bin/sh
Unknown command:setenv
HKVS # setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0 init=/bin/sh
HKVS # saveenv
Writing env to Nand... done
▒KVS # reset
U-Boot 1.3.4-71557 (Apr 3 2014 - 13:08:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
BusyBox v1.19.3 (2016-05-23 16:23:55 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
#alastairstevenson
Staff member
That's good, you have an older bootloader with some useful commands, some of which Hikvision stripped out in later versions.
There is tftpboot and nandwrite which together can be used to write to the flash memory.
You also have a Linux kernel that still responds to the 'init' bootargs parameter. Again, something stripped out in later versions.
Normally, using that would be the easiest and safest method to read and write to flash memory, but in the absence of a NAS/NFS share on the network we'd have to use Windows shares which is a bit more complicated.
The nandwrite should work OK, but it's a powerful command that will need to be exactly correct.
To give a level of confidence that will be better than guesswork so as not to break something, I'll need to find a camera with that command in the bootloader, and do a bit of testing.
Hopefully I'll have one - please bear with me while I check.
alastairstevenson
Staff member
OK - it turns out I had a DS-2CD3332-I camera that still had the same bootloader as your camera.
I've tested out the bootloader nandwrite command to re-write the flash partition that holds the 'rcvy' 'min-system recovery' system and extracted it again from the fully booted camera - and confirmed that the process worked OK.
Below is a transcript for you to follow.
You will need a standard tftp server running on the PC.
One that works quite well is the Jouinin one, from here : TFTP server
Drop the attached mtd8_new and mtd8_old files into the same folder as the tftp server.
For convenience, you can set the camera and tftp server IP addresses to suit your network using these commands :
setenv ipaddr 192.168.1.222
setenv serverip 192.168.1.99
You can write these to flash using 'saveenv' as you will presumably be using the 'update' command to apply new firmware.
It might be as well to put the bootargs value back the way it was at this point also, as you probably don't need to use the root shell.
I'd strongly recommend that you copy / paste the critical commands shown in the transcript below as opposed to typing them, to ensure accuracy, maybe from a text file in a text editor such as Notepad.
After you have done this - hopefully the 'update' command will now work.
mtd8_old is the original rcvy that does not prohibit rollback, mtd8_new is the newer version that has an anti-rollback feature.
I've tested out the bootloader nandwrite command to re-write the flash partition that holds the 'rcvy' 'min-system recovery' system and extracted it again from the fully booted camera - and confirmed that the process worked OK.
Below is a transcript for you to follow.
You will need a standard tftp server running on the PC.
One that works quite well is the Jouinin one, from here : TFTP server
Drop the attached mtd8_new and mtd8_old files into the same folder as the tftp server.
For convenience, you can set the camera and tftp server IP addresses to suit your network using these commands :
setenv ipaddr 192.168.1.222
setenv serverip 192.168.1.99
You can write these to flash using 'saveenv' as you will presumably be using the 'update' command to apply new firmware.
It might be as well to put the bootargs value back the way it was at this point also, as you probably don't need to use the root shell.
I'd strongly recommend that you copy / paste the critical commands shown in the transcript below as opposed to typing them, to ensure accuracy, maybe from a text file in a text editor such as Notepad.
After you have done this - hopefully the 'update' command will now work.
mtd8_old is the original rcvy that does not prohibit rollback, mtd8_new is the newer version that has an anti-rollback feature.
Code:
HKVS #
HKVS #
HKVS # printenv
ipaddr=192.168.1.222
serverip=192.168.1.99
gatewayip=0.0.0.0
netmask=255.255.255.0
ethaddr=c4:2f:90:02:d9:70
loadaddr=0xc2000000
bootfile=digicap.dav
bootcmd=null
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
bootdelay=2
HKVS #
HKVS # help
The following commands are supported:
boot help bios diag
mtest dump erase go
exec ping r8 r16
r32 reset saveenv printenv
setenv show usbdl w8
w16 w32 tftpboot bootm
readoob killb crc nandread
nandwrite ups upm format
update upf upa upr
upk updateb ubi bapi
Use 'help' to get help on a specific command
HKVS # help nandwrite
Help for 'nandwrite':
Usage: nand_write [ddr_addr] [block] [size]
Write data from ddr to nand flash
need ddr address, start block in nand, data size
HKVS #
HKVS # tftpboot 0xc2000000 mtd8_old
[ INFO][BLD]TFTP: MAC: c4:2f:90:02:d9:70
[ INFO][BLD]TFTP: TFTP from server 192.168.1.99; our IP address is 192.168.1.222
[ INFO][BLD]TFTP: Filename: 'mtd8_old'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: #####################################################################
[ INFO][BLD]TFTP: File size is 10485760 bytes (10240 KB)
HKVS #
HKVS #
HKVS # nandwrite 0xc2000000 49 0xa00000
start to program blocks
progress: 100%
done!
HKVS #I’ll give this a shot tonight when I get some quiet time. Family time is calling. Appreciate your efforts in helping.
See below. Hit a snag. I get an erase failed after executing the command:
nandwrite 0xc2000000 49 0xa00000
nandwrite 0xc2000000 49 0xa00000
Code:
HKVS # setenv ipaddr 192.168.1.222
Unknown command:setenv
HKVS # setenv ipaddr 192.168.1.222
HKVS # setenv serverip 192.168.1.99
HKVS # saveenv
Writing env to Nand... done
HKVS # printenv
ipaddr=192.168.1.222
serverip=192.168.1.99
gatewayip=0.0.0.0
netmask=255.255.255.0
ethaddr=44:19:b6:30:02:23
loadaddr=0xc2000000
bootfile=digicap.dav
bootcmd=null
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
bootdelay=2
HKVS #
HKVS # tftpboot 0xc2000000 mtd8_old
[ INFO][BLD]TFTP: MAC: 44:19:b6:30:02:23
[ INFO][BLD]TFTP: TFTP from server 192.168.1.99; our IP address is 192.168.1.222
[ INFO][BLD]TFTP: Filename: 'mtd8_old'
[ INFO][BLD]TFTP: ################################################################################
[ INFO][BLD]TFTP: #####################################################################
[ INFO][BLD]TFTP: File size is 10485760 bytes (10240 KB)
HKVS #
HKVS # nandwrite 0xc2000000 49 0xa00000
start to program blocks
erase failed. <block 69>
Try next block...
failed!s: 98%
HKVS #
HKVS #I also did try the update command and got false hope. It always just froze and never executed. Regrettably the update failed as the nandwrite never completed...
Code:
HKVS # update
[ INFO][MIN]TFTP: TFTP from server 192.168.1.99
[ INFO][MIN]TFTP: Filename: 'digicap.dav'
[ INFO][MIN]TFTP:
[ INFO][MIN]TFTP: Download File [OK]
[ INFO][MIN]BURN: File size is 0 bytes (0 KB)
[ INFO][MIN]BURN: Writing Flash
[ INFO][MIN]BURN: [ERROR][MIN]BURN: upgrade_from_digicap:file_nums=-1095252914
[ERROR][MIN]BURN: upgrade_from_digicap failed
[ INFO][MIN]BURN: Write Flash [FAIL] error: write flash.
!!!!! UPDATE FAIL !!!!!alastairstevenson
Staff member
Well, that's an interesting result.
It confirms there is a problem with the flash memory of the camera.
But block 69 is into the unused space after the working part of the min-system recovery partition, so that specific failure isn't fatal in this case.
And it has brought the update facility back to life - it's working normally.
However - when the downloaded firmware is being written to the flash memory, there is another write flash failure.
This is in a different location from that used by the min-system recovery area.
So - what to do now, apart from trash the camera?
It depends on whether you want to spend any more time on exploration.
A simple and quick thing to try, though, would be to see what the bootup looks like now.
There is some resilience built in to the partitions needed for normal operation.
The kernel, root file system, application and configuration partitions are all duplicated with a primary and secondary area.
There are basic checks on bootup that switch between primary and secondary.
Try booting normally and see how it looks.