Chineese NVR board (8025r-pl) no longer saves settings

runekyndal

n3wb
Joined
Dec 19, 2017
Messages
18
Reaction score
2
Hi guys.
new to the forum here.

i have a cheap chineese NVR board NBD8025r-pl
currently
V4.02.R11.C6380197.12201.140000.00000


and its been working okay. but its now stopped saving any changes.
be it ip address, camera setups etc. after reboot it just reverts
to the same state (not factory) it does have some of my configs
i just cant change anything anymore

i have tried firmware update which says "success" but the version
does not change

i have tried TFTP update via an update.img i found somewhere
(since almost bricked. i figured hey)
but even though it finishes successfully the version does not change
and still no joy on settings

i have tried doing the restore to defaults in the GUI no joy

any ideas out there on getting this board backt to factory and fixed ?

id love to get a proper update.img for this board
or help converting one of the few available "firmware-upgrade.bin" files?
firmwares appear to be for 00000197

Thanks
Rune Kyndal
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,963
Reaction score
6,794
Location
Scotland
Maybe something like logfiles has filled up to the point where there is no remaining space.
I've seen systems where logfiles share a flash partition with system files.

One way that would very likely tell you what's going wrong would be to find and connect to the 'serial console'.
This is the Linux and application running commentary of what's going on internally.

Suggestion:
Inspect the board to see if there are any obvious candidates for a serial connection - it will be either a 3 or 4 pin small connector, or 3 or 4 pads on the circuit board.
If you can do a decent, in-focus, hi-res picture we might be able to spot a candidate.
 

runekyndal

n3wb
Joined
Dec 19, 2017
Messages
18
Reaction score
2
i have cleared to factory default several times.
which removes any logs that might take up flash.

i do have the pinout of the 3.3v ttl serial, it runs 115200 on this board. and do get startup log messages.
but they seize to flow once the system goes online. just the initial boot up stuff.

i am able to enter uboot. and have flashed from TFTP

run da TFTP's u-boot.bin.img
run du TFTP'suser-x.cramfs.img
run dr TFTP's romfs-x.cramfs.img
run dw TFTP's web-x.cramfs.img
run dl TFTP's logo-x.cramfs.img
run dc TFTP's custom-x.cramfs.img
run up TFTP's update.img

i dont have the files to do
tk for zImage.img or
dd for mtd-x.jffs2.img

and while they appear to go 100% and successfully writing to flash. Nothing seem to actually happen.
and the same firmware and configuration is persistant..

can my flash chip have entered some sort of read only state ?


bit puzzling that it no longer wil commit changes to memory..

i have ordered up a Dahua NVR2108HS-S2 now should to the job.
with a bit less dodgy chineesium i hope
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,963
Reaction score
6,794
Location
Scotland
do get startup log messages.
but the seize when the system goes online. just the initial boot up stuff.
run da TFTP's u-boot.bin.img
run du TFTP'suser-x.cramfs.img
run dr TFTP's romfs-x.cramfs.img
run dw TFTP's web-x.cramfs.img
run dl TFTP's logo-x.cramfs.img
run dc TFTP's custom-x.cramfs.img
run up TFTP's update.img
That looks like a Dahua system.
To get the full serial console, use the following u-boot commands:

setenv dh_keyboard 0
saveenv

Then you should be able to observe potential causes when you attempt a configuration save at the web GUI

When you get to a Linux command prompt, use the
df -h
command to see the utilisation of the partitions in use.
You can inhibit the main app from running with the u-boot command
setenv appauto 0
saveenv

which removes any logs that might take up flash.
I would not guarantee that unless you have actually watched the files being removed.
The last 'spares and repairs' Dahua NVR and camera I bought both had loads of logs from when originally purchased, even after a 'reset to defaults'.
On the camera - it gave a lie to the seller claim 'new - not been used' lol!
 

runekyndal

n3wb
Joined
Dec 19, 2017
Messages
18
Reaction score
2
unfortunately its not a Dahua.. its a xiongmaitech product..
could be a clone ofcourse

uses the NETsurvailance web interface. not similar to my dahua cameras..

i will try those commands for sure.. .id love to get root access to this thing
serial,telnet,ssh but besides uboot. pretty locked in at the moment

Rune
 

runekyndal

n3wb
Joined
Dec 19, 2017
Messages
18
Reaction score
2
so.. i have tried changing some environmental stuff over Serial port / UBOOT

bootdelay 3
dh_keyboard 0
saved to flash


Code:
hisilicon # setenv dh_keyboard 0
hisilicon # setenv bootdelay 3
hisilicon # saveenv
Saving Environment to SPI Flash...
at sf_saveenv() start unlock spi flash.
unlock all block.
Erasing SPI flash, offset 0x00040000 size 64K ...done
Writing to SPI flash, offset 0x00040000 size 64K ...done
hisilicon #
looks successfull
and a printenv before reboot shows the enviroment

Code:
silent=0
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06-svn673 (Sep 04 2017 - 15:27:08)
dh_keyboard=0
bootdelay=3

immidiately after a reboot to uboot the printenv shows no change

Code:
hisilicon # printenv
bootcmd=sf probe 0;sf read 0x82000000 0xf60000 0x20000;logoload 0x82000000;decjpg;sf read 0x82000000 0x50000 0x500000;squashfsload 82000000;bootm 0x81000000
bootdelay=1
baudrate=115200
ethaddr=00:0b:3f:00:00:01
ipaddr=192.168.1.10
serverip=192.168.1.12
netmask=255.255.0.0
gatewayip=192.168.1.1
bootfile="uImage"
da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
dl=mw.b 0x82000000 ff 1000000;tftp 0x82000000 logo-x.cramfs.img;sf probe 0;flwrite
dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 zImage.img; bootm 0x42000000
dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
appVideoStandard=PAL
appSystemLanguage=English
bootargs=mem=200M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=squashfs mtdparts=hi_sfc:320K(boot),3968K(romfs),7104K(usr),1536K(web),2816K(custom),128K(logo),512K(mtd) coherent_pool=2M
silent=0
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06-svn673 (Sep 04 2017 - 15:27:08)
jpeg_addr=0x9f000000
jpeg_size=0xb85f9
vobuf=0x9f600000

Environment size: 1450/65532 bytes
hisilicon #

it does not look like i can commit anything to the SPI flash
pretty strange behaviour
 
Last edited:

runekyndal

n3wb
Joined
Dec 19, 2017
Messages
18
Reaction score
2
i have ordered a replacement flash chip. will see if that can fix the problem
 
Top