Longse LS-N3525D Bricked

B

bheremans

Young grasshopper
Nov 11, 2015
38
5
I have a nvr , I think it is the longse LS-N3525D (no type nr on device itself)
http://www.longse.com/Info/View_pro.asp?id=918

When it did work, i saw it has the hreospeed software (http://www.herospeed.net/herospeed/)

After a wrong firmware update it doens't boot anymore, it hangs on the boot image with says nvr initializing.
It has the HI3535 chipset

IMG_20160201_221837.jpgIMG_20160201_221824.jpg

Anybody has experience with this type of devices ?
I already tried putting the firmware that i downloaded from herospeed on a usb device with name Hi3535_AutoUpdate.bin, that was a name I found when opening the firmware with text editor. The device begins beeping when I boot ... but nothing happens.
http://herospeed.net/herospeed/index.php?m=content&c=index&a=show&catid=10&id=8

Best Regards

Bart
 
I have their 5Mp ip cameras. none of their nvr. so I don't know. and now is Chinese new year. so everyone went back home. you have to wait until feb. 17 for them to come back to work. maybe sooner.
 
Still trying to get the thing running again.
I made some better pictures.
trying to find how to get serial access ... (no serial port on back side)

20160220_115041.jpg20160220_115049.jpg20160220_115353.jpg

If anybody has an idea how I can connect serial port, any help is welcome :-)

Thx
 
That J4 you have connected to does look like a candidate.
I suppose you've tried quite a few combinations of connections with no success?
Suggestion to try:
Assuming the NVR case is connected to ground - connect the GND or 0V of the serial convertor to the NVR case.
With the serial convertor using PuTTY set to 115,200baud / 8 bits no parity, connect the RX wire to each of J4 pins in turn and power-cycle the NVR.
In case of uncertainty as to which of the serial convertor wires is 'receive data' also connect TX to each of the J4 pins in turn and power-cycle the NVR.
Do you see any characters on the PuTTY screen when you do this?
 
I measured the pins with a multi meter. Left one should be GND.
Tried connecting with a USB to TTL adapter (PL2303), bit I think I blew it up because I connected another pin with GND on the adapter before.
After that I remembered I still had an old USB to serial adapter, googled the pins (5 = GND, 3 = TX, 2 = RX) connected GND correctly and played with the older pins. But I only get garbage on the putty terminal.
2016-02-20 14_40_27-Start.png
 
It does look like that is going to be a serial console.
A couple of possibilities to give the effect you have shown in your screenshot:

Your alternate adapter is USB to RS232 serial - in other words the signal levels are not compatible with 'TTL serial'. Classsic RS232 uses bipolar signal levels, +-3v to +-15v. TTL serial is typically 0 - 3v though there is a 5v variant.
You may be able to confirm this from the model number and specs.

A less likely alternative is that the baud rate is wrong. A bit tedious to experiment with all the options - but if pressing the Enter key generates a response you could save the NVR the stress of being switched on and off to create traffic.

Are you convinced your TTL serial to USB adapter is dead? The connections are reasonably robust. Though I suppose it depends on what you did with it. Have you tried swapping the Tx and Rx?
 
hmm pevious post not posted :-(

Old usb to rs232 adapter is a belkin f5u103v, I used to connect point of sales stuff, so certainly not TTL.
In the mean time I connected my cheap TTL adapter where i connected a 3.3 v line to GND before, to a working PI (http://elinux.org/RPi_Serial_Connection) and it shows nothing ..
So I'm still waiting for a new usb to ttl adapter that I ordered more than a week ago on ebay :-)

regards
 
FInally new usb to ttl arrived.. connected and got this


NAND: Check nand flash controller v504. found
Special NAND id table Version 1.36
Nand ID: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
No NAND device found!!!
0 MiB
Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x19 0xC2 0x20 0x19
Spi(cs1): Block:64KB Chip:32MB Name:"MX25L25635E/735E/635F"
In: serial
Out: serial
Err: serial
32768 KiB hi_sfc at 0:0 is now current device


jpeg decoding ...
<<addr=0x82000000, size=0xc0000, vobuf=0xc7160000>>
mmu_enable
<<imgwidth=1280, imgheight=720, linebytes=2560>>
decode success!!!!
decode jpeg!
dev 1 opened!
graphic layer 1 opened!
USB: scanning bus for devices... USB: Starting the controller
scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot: 0
32768 KiB hi_sfc at 0:0 is now current device




Wrong Image Format for bootm command
ERROR: can't get kernel image!
hisilicon #


Help shows some available commands
Now trying to boot with usb stick and image file and trying to find out how I can flash image
 
Well, at least there is some life in the bootloader, if not any system in the flash.
You might be lucky and get a fairly normal set of u-boot commands if you interrupt it, good luck.
Should be an interesting journey.

Do you know which of the firmware version linked in your first post is the one for your NVR?
 
I had a quick look at the Hi3535 firmware - it looks like regular eLinux stuff, cramfs with lots of files.
You may have to extract the uImage to give to the u-boot bootloader, it looks like the firmware is packed for a web GUI update method.
 
Unless maybe the bootloader is expecting the manufacturer-specific header after all, and can decode the raw format.
Are there some obvious update-related commands in the bootloader?
The linked file looks like a slightly older version of that on the herospeed site.
 
alastairstevenson said:
Unless maybe the bootloader is expecting the manufacturer-specific header after all, and can decode the raw format.
Are there some obvious update-related commands in the bootloader?
The linked file looks like a slightly older version of that on the herospeed site.
Click to expand...

This are the command available

Code: 
Wrong Image Format for bootm command
ERROR: can't get kernel image!
hisilicon # ?
?       - 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
ddr     - ddr training function
decjpg  - jpgd   - decode jpeg picture.


ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
getinfo - print hardware information
go      - start application at address 'addr'
help    - print command description/usage
loadb   - load binary file over serial line (kermit mode)
loady   - load binary file over serial line (ymodem mode)
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)
nand    - NAND sub-system
nboot   - boot from NAND device
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
setvobg - setvobg   - set vo backgroud color.
        - setvobg [dev color]
sf      - SPI flash sub-system
startgx - startgx   - open graphics layer.
        - startgx [layer addr stride x y w h]


startvo - startvo   - open interface of vo device.
        - startvo [dev type sync]
stopgx  - stopgx   - close graphics layer.
        - stopgx [layer]
stopvo  - stopvo   - close interface of vo device.
        - stopvo [dev]
tftp    - tftp  - download or upload image via network using TFTP protocol
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor version

Still have to find out how everything works :-)

More info :
Link to the content of an image file i could mount in linux by cutting of first part of the binary file :
https://www.dropbox.com/sh/rtoui3iwpnk1hu5/AAC_J0TTFi0cck6lTkg2iwVYa?dl=0
 
Last edited by a moderator:
These look like the fairly normal, if a limited set, of u-boot commands.
No obvious extras associated with updating firmware.
In can flash i file by renaming it to hi3535_AutoUpdate.bin but after reboot still error it cannt find kernel.
Click to expand...
Did you try this with the whole file, nothing stripped off?
And, maybe a long shot, but you never know, contact Longse tech support about how to recover this?
It should certainly be possible, with the right process.

With apologies if you've already tried this, just a suggestion based on what I might try in the same situation just to see what would happen.
The (older version) bootloader in Hikvision NVRs opens up the cramfs.img that's been written as-is to mtdblock2, finds uImage, loads it into RAM and boots it as a kernel.
It uncompresses and boots into a self-contained system that then expands up to the running environment from the rest of the cramfs contents in mtdblock2.
Your NVR doesn't appear to have anything in the flash to boot from.
But you could probably boot up the uImage and see if there are any scripts or commands that would update the flash. Or it might just bomb when run stand-alone.
Easy enough to try, though.
Here is an extract of the firmware from the herospeed site. The extracts.img will be larger than they ideally should be as the trailing data has not been removed. Inside are the file systems contents and also the uImage.
The uImage has a small uncompressor followed by a compressed main body. It should boot - but whether it will run in isolation from the flash environment is unknown.
https://drive.google.com/open?id=0ByOOL4RskWFLRmx1SmFkMzREWTQ

For this you will need a tftp server and the uImage in the same folder location.
At the u-boot prompt, use 'printenv' to check the boot command.
I'd guess that it references uImage and bootm.
Use the tftp command to download uImage
If you are lucky, all you will need to specify will be the tftp server IP address, the remote filename (uImage) and the safe memory load address should already be configured.
If it loads OK and doesn't overwrite u-boot, try booting it with 'bootm'.
Again, the load address and start address hopefully will already be set.
After that - who knows?

Anyway - hopefully Longse will help by providing some useful info.
 
alastairstevenson said:
These look like the fairly normal, if a limited set, of u-boot commands.
No obvious extras associated with updating firmware.

Did you try this with the whole file, nothing stripped off?
And, maybe a long shot, but you never know, contact Longse tech support about how to recover this?
It should certainly be possible, with the right process.

With apologies if you've already tried this, just a suggestion based on what I might try in the same situation just to see what would happen.
The (older version) bootloader in Hikvision NVRs opens up the cramfs.img that's been written as-is to mtdblock2, finds uImage, loads it into RAM and boots it as a kernel.
It uncompresses and boots into a self-contained system that then expands up to the running environment from the rest of the cramfs contents in mtdblock2.
Your NVR doesn't appear to have anything in the flash to boot from.
But you could probably boot up the uImage and see if there are any scripts or commands that would update the flash. Or it might just bomb when run stand-alone.
Easy enough to try, though.
Here is an extract of the firmware from the herospeed site. The extracts.img will be larger than they ideally should be as the trailing data has not been removed. Inside are the file systems contents and also the uImage.
The uImage has a small uncompressor followed by a compressed main body. It should boot - but whether it will run in isolation from the flash environment is unknown.
https://drive.google.com/open?id=0ByOOL4RskWFLRmx1SmFkMzREWTQ

For this you will need a tftp server and the uImage in the same folder location.
At the u-boot prompt, use 'printenv' to check the boot command.
I'd guess that it references uImage and bootm.
Use the tftp command to download uImage
If you are lucky, all you will need to specify will be the tftp server IP address, the remote filename (uImage) and the safe memory load address should already be configured.
If it loads OK and doesn't overwrite u-boot, try booting it with 'bootm'.
Again, the load address and start address hopefully will already be set.
After that - who knows?

Anyway - hopefully Longse will help by providing some useful info.
Click to expand...

Thanks I will try soem stuff tonight.

I tried contacting longse before about info how to flash it with usb.. they didn't reply.
Now I contacted the distributor for a fulle image file and info@longse.com.. I hope someone can provide the right autoupdate file after I found out that you actualy can flash from usb.

Not at home, but I'm sure that it can boot something over tftp, the commands are there and printenv shows the serverip I have to use

Code: 
hisilicon # printenv
bootdelay=1
baudrate=115200
ethaddr=00:00:23:34:45:66
ipaddr=192.168.1.10
serverip=192.168.1.2
netmask=255.255.254.0
bootfile="uImage"
filesize=46C08
bootargs=mem=500M console=ttyAMA0,115200 initrd=0x82400000,0xA00000 root=/dev/ram0 init=/linuxrc mtdparts=hi_sfc:1M(boot),4M(kernel),10M(rootfs),10M(app),4M(www),1M(data),1M(config),1M(logo)
bootcmd=sf probe 0;sf read 0x82000000 0x100000 0x400000;sf read 0x82400000 0x500000 0xA00000;bootm 0x82000000
bootlogo=sf probe 0;sf read 0x82000000 0x1F00000 0x100000;decjpg;startvo 1 36 6;startgx 1 0xC7160000 2560 0 0 1280 720
jpeg_addr=0x82000000
jpeg_size=0xC0000
vobuf=0xC7160000
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Mar 08 2015 - 05:37:46)
 
Finaly some time to test. tftp seems not to tkae an anrgment. but i was able to change netwirk settings with setenv and launch tftp. Wich downloaded the uImage but same error :

Code: 
TFTP from server 192.168.0.198; our IP address is 192.168.0.99
Download Filename 'uImage'.
Download to address: 0x192
Downloading: ## Warning: gatewayip needed but not set
## Warning: gatewayip needed but not set
#       [ Connected ]
data abort
pc : [<0000116c>]          lr : [<00000000>]
sp : 00000000  ip : 00000000     fp : 00000000
r10: 00000000  r9 : 00000000     r8 : 00000000
r7 : 00000000  r6 : 00000000     #5 : 00000000  r4 : 00000000
r3 : 2005011b  r2 : c0001fe0     r1 : 00000100  r0 : 00000000
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...


######resetting ...
###


U-Boot 2010.06 (Mar 08 2015 - 05:37:46)


NAND:  Check nand flash controller v504. found
Special NAND id table Version 1.36
Nand ID: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
No NAND device found!!!
0 MiB
Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x19 0xC2 0x20 0x19
Spi(cs1): Block:64KB Chip:32MB Name:"MX25L25635E/735E/635F"
In:    serial
Out:   serial
Err:   serial
32768 KiB hi_sfc at 0:0 is now current device


jpeg decoding ...
<<addr=0x82000000, size=0xc0000, vobuf=0xc7160000>>
mmu_enable
<<imgwidth=1280, imgheight=720, linebytes=2560>>
decode success!!!!
decode jpeg!
dev 1 opened!
graphic layer 1 opened!
USB:   scanning bus for devices... USB:   Starting the controller
scanning bus for devices... 1 USB Device(s) found
0 Storage Device(s) found
Hit any key to stop autoboot:  0
32768 KiB hi_sfc at 0:0 is now current device




Wrong Image Format for bootm command
ERROR: can't get kernel image!

I tried to flash the unmodfied bin file and the one where I cut the header.
I know the update script is executed when I boot with an usb drive and H_3535_AUtoUpdate.img file. becasue I see some parts of the script like :
Code: 
flash_eraseall

Now going to try some stuff with the files you provided.
 
Exact autoput when booting with a usb drive
Code: 
Partition 1: Filesystem: FAT32 "NO NAME    "
reading Hi3535_Uboot.bin
reading Hi3535_Kernel
reading Hi3535_Rootfs
reading Hi3535_App
reading Hi3535_Www
reading Hi3535_Data
reading Hi3535_Config
reading Hi3535_Logo
reading Hi3535_AutoUpdate.bin
reading Hi3535_AutoUpdate.bin
.............................................................................................................................................................................................................................
flash erase...
flash write...
hisfc350.c(444): write length is 0.
Hit any key to stop autoboot:  0
32768 KiB hi_sfc at 0:0 is now current device




Wrong Image Format for bootm command
ERROR: can't get kernel image!
hisilicon #
 
You must log in or register to reply here.
Top Bottom