is there a "generic" firmware available for Hi3535 based NVR? (owsoo branded)

and bootscreen ncom:

U-Boot 2010.06 (Oct 16 2015 - 04:33:14)

Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128XX"
In: serial
Out: serial
Err: serial
(Re)start USB search...
USB: scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... usb_stor_get_info->1422,blksz:512
1 Storage Device(s) found
Press Ctrl+C to stop autoboot
saveaddr: 82000000
do_netupdate
Hisilicon ETH net controler
MAC: 00-00-23-34-45-66
UP_PORT : phy status change : LINK=UP : DUPLEX=FULL : SPEED=100M
JVUpd Start
OurPort: 3037
starting...
packet not correct: des: 7437, our: 3037

time out resend: 0
after resend data

JVUpdTimeout When CMD_TRY
sf probe 0;sf read 0x86000000 0x60000 0x20000
16384 KiB hi_sfc at 0:0 is now current device

vo 0,picwh:800 0, addr=0, xywh:0 300 800 0
vo 2,picwh:800 0, addr=a0, xywh:0 288 720 0
setenv jpeg_addr 0x86000004
setenv jpeg_size 0x2999bdd8
setenv vobuf 0x0
jpeg decoding ...
Invalid VOU buffer address 0x00000000
load jpeg err.
dev 0 opened!
16384 KiB hi_sfc at 0:0 is now current device


Wrong Image Format for bootm command
ERROR: can't get kernel image!
 
If you have tftpserver set up then use JUpdate, i think it may work like this:

usage:JUpdate (filesize) (temp ram addr)


Put firmware via TFTP to temp ram addr at 0x81000000:
tftpboot 0x81000000 firmware.bin

Filesize is 16777216 so it can be either
16777216 if it is supposed to be in decimal
or (i would guess) in hexadecimal:
0x1000000

So it would be either (if in hex)
JUpdate 0x1000000 0x81000000

or

unlikely in dec
JUpdate 16777216 0x81000000
 
I can't dowload the file with JUpdate.

on screen:
hisilicon # JUpdate 0x1000000 0x81000000
JUpdate Ver2.0 for JVS-D8008...

JUpdate 16777216 0x81000000
With this line it's the same.

After this nothing goes on.
My tftp server is running, when i make tftp upload it is running but at adress 0x80008000.

Which name must have the .bin file?
 
Last edited:
I think the filename is irrelevant, therefore you give the address where it is stored.

Did you try:
tftpboot 0x80008000 firmware.bin
JUpdate 0x1000000 0x80008000

?

Do you have the correct firmware file with 16777216 bytes?
 
tftp is correct, you are right.

If it is stored in 0x80008000

Did you try:
tftp 0x80008000 firmware.bin
JUpdate 0x1000000 0x80008000
?
 
No, what must i do when the download is finnished?

I tried
JUpdate 0x1000000 0x81000000
and
Jupdate 1000000 0x81000000
and
JUpdate 16777216 0x8100000

without booting screen.
 
Last edited:
The tftp download seems to be ok, after that JUpdate did't load....

JUpdate 0x1000000 0x80008000
I try it too, same screen.
 

Attachments

  • tftp.jpg
    tftp.jpg
    743.6 KB · Views: 30
(Intended to be) helpful suggestion, for both you and us:
PuTTY has the very useful 'copy scrollback to clipboard' facility that allows the terminal output to be pasted as text into your favourite text editor.
And the forum has the 'easy on the eye for lengthy samples' of the 'code' tags via the '+' of the edit menu.
 
I don't know which file or even if you can just write one these files to SPI Flash storage.
Since one of these files has exact size of 16777216 and that is exactly 16MB like the SPI Flash storage, it could be the file to flash.

Following the tutorial from here Booting Linux kernel using U-Boot - Texas Instruments Wiki
under SPI Flash section, it should go like this for you:

sf probe 0
tftp 0x81000000 firmware.bin
sf erase 0x0 0x1000000
sf write 0x81000000 0x0 0x1000000

! However this would overwrite uboot (!) and if it is wrong, you really would have a brick or you will need a SPI Flash Programmer and knownledge.

What could be worth a try is, to extract the firmware in Linux. Like shown here: Reverse Engineering DVR firmware
I have extracted another firmware before for other reasons, but i have never flashed it.
But maybe you could then skip the uboot partition and flash manually to each partition, with uboot being untouched.

This is how the partition table of my NVR looks like:
0x000000000000-0x000000100000 : "boot"
0x000000100000-0x000000480000 : "kernel"
0x000000480000-0x000000700000 : "rootfs"
0x000000700000-0x000000e00000 : "APP"
0x000000e00000-0x000001000000 : "config"
 
I tried

sf probe 0
tftp 0x81000000 firmware.bin
sf erase 0x0 0x1000000
sf write 0x81000000 0x0 0x1000000

without success, now the systen does't boot anymore.
I think I will get a new board.
 
Sorry to hear, but don't blame me man :D. I told you to extract firmware first and leave the uboot untouched.
 
No, no problem, I wanted it that way, you made a lot of effort.
Thank you for the help and know.
I think I learned a lot about tftp and other.
 
Karsten said:
I think I will get a new board.
Click to expand...
With apologies for the intrusion ...
Looking at the firmware you used that was linked to earlier in the thread, the jdvr-recover-sw-nd6004-h1-2.0-128M.bin seems to be a simple XOR-encoded monolithic flash dump of a 16MB flash chip. Presumably you decoded it before you used it? I don't think I saw that mentioned.

If the flash chip on the board is a 24 / 25 series SOP8 DIP8 device - I've found that it's possible and quite easy to do an in-situ full flash re-program at very low cost with a CH341A programmer and an SOP8 DIP8 test clip.

It might be worth a look at the board to try to identify the flash chip - you might be lucky!
 
Let's try it....

I have seen these devices in many onlineshops.
First i post a photo from the nvr board.
 

Attachments

  • 4ch owsoo nvr.JPG
    4ch owsoo nvr.JPG
    616.9 KB · Views: 44
The numbers are verry smal, what i can see, on the
chip bottom right:

25L12......
M2I-1...
80286...
L16......

chip top right

....09
402...

3 chips on the left with the same numbers
FR9886
G1608
L849D
 
Last edited:
You must log in or register to reply here.
Top Bottom