*SOLVED* Swann NVR softbricked after firmware update - Currently on uBoot console

0x_0

0x_0

n3wb
Apr 4, 2020
9
3
United Kingdom
Good day all,

Last week I went ahead and tried to perform a firmware update on my Swann NVR (SWNVR-87285H). The firmware failed to update and the system hung. After an hour, it rebooted and halts on the loading page. Oh dear.

I've contacted support a number of times, and they've been no help. Thus, I grabbed my old USB->UART header dongle, found the UART headers on the NVR board and plugged in. Sure enough, a console getting stuck on "Starting Kernel ...". I rebooted the system and held down the enter key, this stopped the autoboot. (First thing I did from here was to set the env-var to wait 5 seconds before booting).

I'm wondering if anyone can help me get any further in re-flashing the device. I'm guessing this was just a bad flash. All commands on uboot working, so seems uboot isn't broken.

I've attached a copy of the output.

Could anyone help?
 

Attachments

  • Like
Reactions: mat200
I see a TFTP option (tftp - tftp - download or upload image via network using TFTP protocol)
I understand some of the Swann hardware was OEM'd from Hikvision. can't say about your model.
if so, might try setting up the TFTP server like for Hik cams, at 192.168.0.128 as described here on IPcamtalk and also:
How to reflash the firmware on Hikvision cameras (Hikvision TFTP procedure) | SecurityCamCenter.com (just googled that - no affiliation)

you'll need to make sure you have a version of the firmware that is compatible with your unit (digicap.dav file). If what you tried flashing in the first place was from Swann and supposed to run on your hardware, it may well do. Also, hope Swann didn't alter any of the parameters required for this to work like the Hik's do, which they may have, just to be pricks...

good luck! Paul.
 
  • Like
Reactions: fenderman and mat200
0x_0 said:
I've attached a copy of the output.
Click to expand...
With the sf and tftp commands available in the bootloader you should be able to selectively re-flash the needed partitions, provided the firmware is organised in a way to be able to do that and the partition layout is known.
It looks like you could get a firmware update from here : (didn't try it though as it needs registration) :
www.swann.com

NVR8-7285 8 Channel 1080p Network Video Recorder

Shop for NVR8-7285 8 Channel 1080p Network Video Recorder at the best prices from Swann Security today!
www.swann.com www.swann.com

What would be interesting would be seeing more of the serial console output, the attempted boot which should give a clue to the problem, and the printenv values.
For ease of reading you can paste the text into the code tags here - check the dropdown to the right of the emoticon icon in the menu bar.
The console log will likely provide info on the partition layout as well as other useful info.

Where did you get the firmware, and did you know for sure it was valid for your model?
You could attach it here and we can take a look inside.

A year or so back I bought a 'spares and repairs' Swann NVR off ebay for almost nothing, fixed it up (shorted transient suppressor on the 48v power line), messed with it a bit and hastily re-sold it when seeing how proprietary it was.
But I grabbed some firmware that was around at the time, and one looks like it is for the 4-channel version of your model.
With Hikvision, 4, 8, 16, 32 channels it's usually the same firmware, maybe not the case with Swann though.
See the attached file.
 

Attachments

  • Like
Reactions: 0x_0 and mat200
alastairstevenson said:
With the sf and tftp commands available in the bootloader you should be able to selectively re-flash the needed partitions, provided the firmware is organised in a way to be able to do that and the partition layout is known.
It looks like you could get a firmware update from here : (didn't try it though as it needs registration) :
www.swann.com

NVR8-7285 8 Channel 1080p Network Video Recorder

Shop for NVR8-7285 8 Channel 1080p Network Video Recorder at the best prices from Swann Security today!
www.swann.com www.swann.com

What would be interesting would be seeing more of the serial console output, the attempted boot which should give a clue to the problem, and the printenv values.
For ease of reading you can paste the text into the code tags here - check the dropdown to the right of the emoticon icon in the menu bar.
The console log will likely provide info on the partition layout as well as other useful info.

Where did you get the firmware, and did you know for sure it was valid for your model?
You could attach it here and we can take a look inside.

A year or so back I bought a 'spares and repairs' Swann NVR off ebay for almost nothing, fixed it up (shorted transient suppressor on the 48v power line), messed with it a bit and hastily re-sold it when seeing how proprietary it was.
But I grabbed some firmware that was around at the time, and one looks like it is for the 4-channel version of your model.
With Hikvision, 4, 8, 16, 32 channels it's usually the same firmware, maybe not the case with Swann though.
See the attached file.
Click to expand...

Hi there, Thanks for the quick reply :)

This is the printenv values. All are as standard except the bootdelay which I changed temporarily to 5 seconds. Just makes life easier when power-cycling manually
Code: 
hisilicon # printenv
bootargs=mem=104M console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:16M@0(wholeflash),512K@0(boot),2M(kernel),3072K(rootfs),9216K(app),1M(param),256K(logo),256K(uid)
bootcmd=sf probe 0;sf read 0x82000000 0xf80000 0x40000;setvobg  0 0;decjpg;startvo 0 36  14;startgx  0 0x86a9c000 1 1 1 1 1;sf read 0x82000000 0x80000 0x380000;bootm 0x82000000
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"
jpeg_addr=0x82000000
jpeg_size=0x40000
vobuf=0x86a9c000
bootdelay=5
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jul 29 2014 - 18:10:11)

Environment size: 657/262140 bytes
hisilicon #

I can confirm that tftp is working, as I set my computer to 192.168.1.2, hosted a tftp server and uploaded some random data to confirm the connection.

If I don't cancel the autoboot, then the following is output to console
Code: 
U-Boot 2010.06 (Jul 29 2014 - 18:10:11)

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
Hit any key to stop autoboot:  0
16384 KiB hi_sfc at 0:0 is now current devicea

dev 0 set background color!
jpeg decoding ...
<<addr=0x82000000, size=0x40000, vobuf=0x86a9c000>>
mmu_enable
<<imgwidth=684, imgheight=456, linebytes=1376>>
decode success!!!!
decode jpeg!
dev 0 opened!
graphic layer 0 opened!

## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-3.0.8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2060232 Bytes = 2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Loading Kernel Image ... OK
OK

Starting kernel ...

It freezes endlessly on the "starting kernel ..." line. The only way to move from this is a manual power cycle.

alastairstevenson said:
This page appears to have current firmware for your NVR :

edit
Actually - this looks like a better match :
Click to expand...

This is where I got the original firmware for the update. I've attached a zipped copy of the firmware .pak file that's supplied by Swann for this unit.
 

Attachments

OK, no great clue then about why it's not fully booting, and also making the assumption that serial console output is not discontinued on kernel startup as is done by Dahua and others.
Is it just me, or do the bootcmd parameters look anomalous?
The kernel is 2MB, but the size read from the flash is 0x380000 which is 3584k
That doesn't even encompass the rootfs which is an additional 3072k
I'm guessing it's a typo as the size read should be 0x200000
I don't think reading too much is a problem though.

It's good practice to try to provide a fall-back position when experimenting with changes, so can I suggest initially grabbing the flash contents as the first activity?
You already have the environment to do so.
These should be the commands at the bootloader prompt.
Paste them in one line at a time.
Code: 
sf probe 0

sf read 0x82000000 0x00000 0x80000
tftp 0x82000000 boot 0x80000

sf read 0x82000000 0x80000 0x200000
tftp 0x82000000 kernel 0x200000

sf read 0x82000000 0x280000 0x300000
tftp 0x82000000 rootfs 0x300000

sf read 0x82000000 0x580000 0x900000
tftp 0x82000000 app 0x900000

sf read 0x82000000 0x0 0x1000000
tftp 0x82000000 flash_all 0x1000000

What might be interesting then would be to do a file compare of the extracted kernel with the kernel that's in the firmware file, attached.
There will be big differences past the 2MB point
If you haven't already got it, HxD is a useful hex editor that can also do file compares.
This may indicate whether the kernel from the firmware you used was correctly flashed.
If not - a possible next step could be to flash just the kernel partition with the kernel extracted from the firmware file.
 

Attachments

  • Like
Reactions: 0x_0 and fenderman
alastairstevenson said:
OK, no great clue then about why it's not fully booting, and also making the assumption that serial console output is not discontinued on kernel startup as is done by Dahua and others.
Is it just me, or do the bootcmd parameters look anomalous?
The kernel is 2MB, but the size read from the flash is 0x380000 which is 3584k
That doesn't even encompass the rootfs which is an additional 3072k
I'm guessing it's a typo as the size read should be 0x200000
I don't think reading too much is a problem though.

It's good practice to try to provide a fall-back position when experimenting with changes, so can I suggest initially grabbing the flash contents as the first activity?
You already have the environment to do so.
These should be the commands at the bootloader prompt.
Paste them in one line at a time.
Code: 
sf probe 0

sf read 0x82000000 0x00000 0x80000
tftp 0x82000000 boot 0x80000

sf read 0x82000000 0x80000 0x200000
tftp 0x82000000 kernel 0x200000

sf read 0x82000000 0x280000 0x300000
tftp 0x82000000 rootfs 0x300000

sf read 0x82000000 0x580000 0x900000
tftp 0x82000000 app 0x900000

sf read 0x82000000 0x0 0x1000000
tftp 0x82000000 flash_all 0x1000000

What might be interesting then would be to do a file compare of the extracted kernel with the kernel that's in the firmware file, attached.
There will be big differences past the 2MB point
If you haven't already got it, HxD is a useful hex editor that can also do file compares.
This may indicate whether the kernel from the firmware you used was correctly flashed.
If not - a possible next step could be to flash just the kernel partition with the kernel extracted from the firmware file.
Click to expand...

Again, thank-you for your prompt reply. Really appreciate the help!

I've created the backups of the flash contents. Good shout, and thanks for the commands.

Comparing the kernel file you've linked with the kernel extracted from the flash, it would appear the failed flash appeared during the kernel write.

There are no changes between the original kernel and the kernel you attached until 000303F0 offset 0C. From here through to 000BFFF0 offset 0F, all values are FF. The rest of the kernel beyond the blank data is all there, but it doesn't match the firmware file you've attached. Thus I'm assuming this is the un-erased / original firmware left from before as it failed to complete the flash?

There is a size difference between the kernel that you've attached (2,013k), and the one taken from the system (2048k). The difference appears to just be padding at the end of the file its all FF values.

I think you may be right in a kernel reflash being required, as it certainly appears something isn't right. I've attached the kernel I've extracted from the device. (The zipped size shows the clear blank space issue)
 

Attachments

0x_0 said:
I think you may be right in a kernel reflash being required, as it certainly appears something isn't right. I've attached the kernel I've extracted from the device. (The zipped size shows the clear blank space issue)
Click to expand...
The extracted file has big chunks that have not been written.
I wonder if that will also be the case in the other partitions.
It might be a misbehaving flash chip, in which case it would be messy to fix, would need a physical replacement.

If you are up for it - and in truth there isn't much to lose - you could try flashing the kernel that I extracted from the firmware file.
Rename the kernel file I'd attached above as kernel_from_fw in the tftp server folder.
The re-written file can be read out again to do a comparison.
It's easy enough to do, the commands should be as follows at the bootloader prompt, one line at a time :
Code: 
sf probe 0

tftp 0x82000000 kernel_from_fw

sf erase 0x80000 0x200000

sf write 0x82000000 0x80000 0x200000

sf read 0x82000000 0x80000 0x200000

tftp 0x82000000 kernel_reread 0x200000

reset

And just for interest, here is how I split the firmware :
Code: 
#!/bin/sh
# This is a simple 'split out some of the components' script based on a manual inspection
# of the original NVR8-7285_0113_3438_1103.pak firmware.
# It looks like the firmware is organised as a simple manifest front section, giving name,
# location and size for each component.
#
dd if=orig_fw.pak of=uboot1 bs=1 skip=$((0x04f8)) count=$((0x03770c))
dd if=orig_fw.pak of=bootargs bs=1 skip=$((0x037c04)) count=$((0x0200))
dd if=orig_fw.pak of=kernel bs=1 skip=$((0x057c04)) count=$((0x1f7008))
dd if=orig_fw.pak of=fs bs=1 skip=$((0x24ec0c)) count=$((0x2d4000))
# This is the fs SQUASHFS partition which we can directly unpack.
sudo unsquashfs -d fs_squashfs fs
dd if=orig_fw.pak of=app bs=1 skip=$((0x522c0c)) count=$((0x74e000))
# This is the app SQUASHFS partition which we can directly unpack.
sudo unsquashfs -d app_squashfs app
dd if=orig_fw.pak of=logo bs=1 skip=$((0xc70c0c)) count=$((0xf1fd))

# End

Good luck!
 
alastairstevenson said:
The extracted file has big chunks that have not been written.
I wonder if that will also be the case in the other partitions.
It might be a misbehaving flash chip, in which case it would be messy to fix, would need a physical replacement.

If you are up for it - and in truth there isn't much to lose - you could try flashing the kernel that I extracted from the firmware file.
Rename the kernel file I'd attached above as kernel_from_fw in the tftp server folder.
The re-written file can be read out again to do a comparison.
It's easy enough to do, the commands should be as follows at the bootloader prompt, one line at a time :
Code: 
sf probe 0

tftp 0x82000000 kernel_from_fw

sf erase 0x80000 0x200000

sf write 0x82000000 0x80000 0x200000

sf read 0x82000000 0x80000 0x200000

tftp 0x82000000 kernel_reread 0x200000

reset

And just for interest, here is how I split the firmware :
Code: 
#!/bin/sh
# This is a simple 'split out some of the components' script based on a manual inspection
# of the original NVR8-7285_0113_3438_1103.pak firmware.
# It looks like the firmware is organised as a simple manifest front section, giving name,
# location and size for each component.
#
dd if=orig_fw.pak of=uboot1 bs=1 skip=$((0x04f8)) count=$((0x03770c))
dd if=orig_fw.pak of=bootargs bs=1 skip=$((0x037c04)) count=$((0x0200))
dd if=orig_fw.pak of=kernel bs=1 skip=$((0x057c04)) count=$((0x1f7008))
dd if=orig_fw.pak of=fs bs=1 skip=$((0x24ec0c)) count=$((0x2d4000))
# This is the fs SQUASHFS partition which we can directly unpack.
sudo unsquashfs -d fs_squashfs fs
dd if=orig_fw.pak of=app bs=1 skip=$((0x522c0c)) count=$((0x74e000))
# This is the app SQUASHFS partition which we can directly unpack.
sudo unsquashfs -d app_squashfs app
dd if=orig_fw.pak of=logo bs=1 skip=$((0xc70c0c)) count=$((0xf1fd))

# End

Good luck!
Click to expand...

We have good news, and bad news.

The good news is, kernel re-flash went well. The read back in HxD gives a comparisons info stating that the files are exactly the same except the padding on the end of the reread. This is good!

After a reset, it now moves on from its original issue.

Bad news, it seems other partitions such as the fs are corrupt too. Booting uncompresses Linux, but enters a kernel panic when trying to mount the rootfs, I'm going to guess that all partitions beyond the kernel are corrupt: so probably rootfs, app, param, logo and uid? I'm going to inspect all of these in HxD and see if any others have blinding big areas missing / corrupt.

Here is the new output from console;
Code: 
U-Boot 2010.06 (Jul 29 2014 - 18:10:11)

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
Hit any key to stop autoboot:  0
16384 KiB hi_sfc at 0:0 is now current device

dev 0 set background color!
jpeg decoding ...
<<addr=0x82000000, size=0x40000, vobuf=0x86a9c000>>
mmu_enable
<<imgwidth=684, imgheight=456, linebytes=1376>>
decode success!!!!
decode jpeg!
dev 0 opened!
graphic layer 0 opened!

## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-3.0.8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2060232 Bytes = 2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 3.0.8 (mdq@baichuan) (gcc version 4.4.1 (Hisilicon_v100(gcc4.4-290+uclibc_0.9.32.1+eabi+linuxpthread)) ) #4 Thu Apr 30 10:32:09 CST 2015
CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: hi3520d
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 26416
Kernel command line: mem=104M console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:16M@0(wholeflash),512K@0(boot),2M(kernel),3072K(rootfs),9216K(app),1M(param),256K(logo),256K(uid)
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 104MB = 104MB total
Memory: 100048k/100048k available, 6448k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc7000000 - 0xfe000000   ( 880 MB)
    lowmem  : 0xc0000000 - 0xc6800000   ( 104 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc002a000   ( 136 kB)
      .text : 0xc002a000 - 0xc04df000   (4820 kB)
      .data : 0xc04e0000 - 0xc04fee40   ( 124 kB)
       .bss : 0xc04fee64 - 0xc05578d8   ( 355 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:128 nr_irqs:128 128
sched_clock: 32 bits at 82MHz, resolution 12ns, wraps every 52060ms
Calibrating delay loop... 1318.91 BogoMIPS (lpj=6594560)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
Serial: AMBA PL011 UART driver
uart:0: ttyAMA0 at MMIO 0x20080000 (irq = 40) is a PL011 rev2
console [ttyAMA0] enabled
uart:1: ttyAMA1 at MMIO 0x20090000 (irq = 41) is a PL011 rev2
uart:2: ttyAMA2 at MMIO 0x200a0000 (irq = 42) is a PL011 rev2
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switching to clocksource timer1
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
L2cache cache controller enabled
squashfs: version 4.0 (2009/01/31) Phillip Lougher
NTFS driver 2.1.30 [Flags: R/W].
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
fuse init (API version 7.16)
msgmni has been set to 195
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
brd: module loaded
loop: module loaded
ahci: SSS flag set, parallel bus scan disabled
ahci ahci.0: AHCI 0001.0200 32 slots 2 ports 3 Gbps 0x3 impl platform mode
ahci ahci.0: flags: ncq sntf stag pm led clo only pmp pio slum part ccc sxs boh
scsi0 : ahci_platform
scsi1 : ahci_platform
ata1: SATA max UDMA/133 mmio [mem 0x10080000-0x1008ffff] port 0x100 irq 52
ata2: SATA max UDMA/133 mmio [mem 0x10080000-0x1008ffff] port 0x180 irq 52
Spi id table Version 1.22
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
SPI FLASH start_up_mode is 3 Bytes
Spi(cs1):
Block:64KB
Chip:16MB
Name:"MX25L128XX"
spi size: 0x16777216
chip num: 1
8 cmdlinepart partitions found on MTD device hi_sfc
Creating 8 MTD partitions on "hi_sfc":
0x000000000000-0x000001000000 : "wholeflash"
0x000000000000-0x000000080000 : "boot"
0x000000080000-0x000000280000 : "kernel"
0x000000280000-0x000000580000 : "rootfs"
0x000000580000-0x000000e80000 : "app"
0x000000e80000-0x000000f80000 : "param"
0x000000f80000-0x000000fc0000 : "logo"
0x000000fc0000-0x000001000000 : "uid"
Fixed MDIO Bus: probed
ata1: SATA link down (SStatus 0 SControl 300)
himii: probed
ata2: SATA link down (SStatus 0 SControl 300)
Invalid HW-MAC Address: 00:00:00:00:00:00
Set Random MAC address: 82:CD:91:67:77:5B
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
NET: Registered protocol family 24
usbmon: debugfs is not available
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
hiusb-ehci hiusb-ehci.0: HIUSB EHCI
hiusb-ehci hiusb-ehci.0: new USB bus registered, assigned bus number 1
hiusb-ehci hiusb-ehci.0: irq 53, io mem 0x100b0000
hiusb-ehci hiusb-ehci.0: USB 0.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
hiusb-ohci hiusb-ohci.0: HIUSB OHCI
hiusb-ohci hiusb-ohci.0: new USB bus registered, assigned bus number 2
hiusb-ohci hiusb-ohci.0: irq 54, io mem 0x100a0000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usbcore: registered new interface driver cdc_acm
cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
usbcore: registered new interface driver cdc_wdm
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver ums-alauda
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-isd200
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver mdc800
mdc800: v0.7.5 (30/10/2000):USB Driver for Mustek MDC800 Digital Camera
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
mousedev: PS/2 mouse device common for all mice
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Registering the dns_resolver key type
registered taskstats version 1
List of all partitions:
1f00           16384 mtdblock0  (driver?)
1f01             512 mtdblock1  (driver?)
1f02            2048 mtdblock2  (driver?)
1f03            3072 mtdblock3  (driver?)
1f04            9216 mtdblock4  (driver?)
1f05            1024 mtdblock5  (driver?)
1f06             256 mtdblock6  (driver?)
1f07             256 mtdblock7  (driver?)
f000           16384 romblock0  (driver?)
f001             512 romblock1  (driver?)
f002            2048 romblock2  (driver?)
f003            3072 romblock3  (driver?)
f004            9216 romblock4  (driver?)
f005            1024 romblock5  (driver?)
f006             256 romblock6  (driver?)
f007             256 romblock7  (driver?)
No filesystem could mount root, tried:  squashfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
Backtrace:
[<c002e734>] (dump_backtrace+0x0/0x110) from [<c03ed764>] (dump_stack+0x18/0x1c)
 r6:c6025f58 r5:c04ff1f0 r4:c04ff1f0 r3:60000013
[<c03ed74c>] (dump_stack+0x0/0x1c) from [<c03ed7dc>] (panic+0x74/0x188)
[<c03ed768>] (panic+0x0/0x188) from [<c0008fa4>] (mount_block_root+0x220/0x23c)
 r3:c6025f2c r2:00000020 r1:c6025f58 r0:c047cc60
 r7:00000009
[<c0008d84>] (mount_block_root+0x0/0x23c) from [<c0009090>] (mount_root+0xd0/0xd8)
[<c0008fc0>] (mount_root+0x0/0xd8) from [<c0009238>] (prepare_namespace+0x1a0/0x1dc)
 r5:c0024ba1 r4:c04feee0
[<c0009098>] (prepare_namespace+0x0/0x1dc) from [<c0008488>] (kernel_init+0x118/0x124)
 r5:c0024170 r4:c0024170
[<c0008370>] (kernel_init+0x0/0x124) from [<c003e9e4>] (do_exit+0x0/0x6d4)
 r5:c0008370 r4:00000000

Thank-you for your help so far. I'm learning a huge amount from this.

Maybe a reflash of the other partitions might resolve this?
 
0x_0 said:
We have good news, and bad news.
Click to expand...
No, not bad news, very good news and as expected news.
The other partitions are also corrupted - but we can fix them up.
Let me work up the commands.
The serial console log you've posted will save me some arithmetic.
Though when I look at it, it matches my scribbles.
Code: 
0x000000000000-0x000001000000 : "wholeflash"
0x000000000000-0x000000080000 : "boot"
0x000000080000-0x000000280000 : "kernel"
0x000000280000-0x000000580000 : "rootfs"
0x000000580000-0x000000e80000 : "app"
0x000000e80000-0x000000f80000 : "param"
0x000000f80000-0x000000fc0000 : "logo"
0x000000fc0000-0x000001000000 : "uid"

In the meantime, here are the other partitions, attached.
 

Attachments

  • Like
Reactions: 0x_0
alastairstevenson said:
Sorry about the delay - I've been watching the Netflix series Travelers - finding it quite absorbing in this lockdown.
Click to expand...
Hey, absolutely no worries! I'm more than happy that you've helped me at all. It's your free time. I can't thank you enough for this. Take your time. Travelers you say... Looks interesting. That can be next on my list :)
 
OK, here are the commands.
Rename the incoming files as shown, as we did for the kernel.
Hopefully my arithmetic is correct.
Don't re-type - copy/paste one line at a time.
Code: 
sf probe 0

tftp 0x82000000 rootfs_from_fw

sf erase 0x280000 0x300000

sf write 0x82000000 0x280000 0x300000

sf read 0x82000000 0x280000 0x300000

tftp 0x82000000 rootfs_reread 0x300000

tftp 0x82000000 app_from_fw

sf erase 0x580000 0x900000

sf write 0x82000000 0x580000 0x900000

sf read 0x82000000 0x580000 0x900000

tftp 0x82000000 app_reread 0x900000

reset
 
  • Love
Reactions: 0x_0
alastairstevenson said:
OK, here are the commands.
Rename the incoming files as shown, as we did for the kernel.
Hopefully my arithmetic is correct.
Don't re-type - copy/paste one line at a time.
Code: 
sf probe 0

tftp 0x82000000 rootfs_from_fw

sf erase 0x280000 0x300000

sf write 0x82000000 0x280000 0x300000

sf read 0x82000000 0x280000 0x300000

tftp 0x82000000 rootfs_reread 0x300000

tftp 0x82000000 app_from_fw

sf erase 0x580000 0x900000

sf write 0x82000000 0x580000 0x900000

sf read 0x82000000 0x580000 0x900000

tftp 0x82000000 app_reread 0x900000

reset
Click to expand...

Its done! Its completed successfully! I've checked both the files to make sure they've flashed correctly prior to the reset, and returned same files with padding at end. Perfect!

Ran the reset, and its booted through. Went through the quick setup with default values to make sure cameras show up, and its golden.

Thank-you so much! I've learnt a huge amount about the system. I'm going to take a flash dump now its working, in-case I break it again , I can just flash back. :banghead:

I've actually really enjoyed working on the hardware like this. I've tried stuff like this before with old routers, but didn't get stuck in enough to understand anything. I think this has been my eye opening to the world of ... Hardware 'hacking'? I'm certainly gonna stick around for a while. :):lol:
 
  • Wow
Reactions: alastairstevenson
Well, that's a good result.
I can sense that you are pleased ...
How was the logo?
That's also in the firmware, I did wonder if it (and actually the intervening configuration files) might also be corrupt.
But it seems not.
I suspect the configuration was treated as corrupt and reset to defaults. I'd have suggested you do that anyway if the reflash had worked.
It was fun, and it's great to get a good result.
 
  • Like
Reactions: 0x_0
alastairstevenson said:
Well, that's a good result.
I can sense that you are pleased ...
How was the logo?
That's also in the firmware, I did wonder if it (and actually the intervening configuration files) might also be corrupt.
But it seems not.
I suspect the configuration was treated as corrupt and reset to defaults. I'd have suggested you do that anyway if the reflash had worked.
It was fun, and it's great to get a good result.
Click to expand...

Very pleased. The logo seems to be fine. However I'm fairly unhappy with seeing their logo due to their responses to me as a customer in a time of need. :p Maybe that's something I can resolve in the future.

I'm assuming you're right, and the configuration file was reset as it's acting like a brand new system.
 
  • Like
Reactions: alastairstevenson
Good Morning,

reading your posts about your nvr, I found myself in the same boat with NVR4-7400

The GA3.1 firmware file you have attached is also the same firemware file for my nvr

i see that you were able to connect via uart were you able to reflash from there also?

As my nvr will not find a connection to being TFTP
no active on the ethernet port ?

Thank you in advance
 
ojassy said:
Good Morning,

reading your posts about your nvr, I found myself in the same boat with NVR4-7400

The GA3.1 firmware file you have attached is also the same firemware file for my nvr

i see that you were able to connect via uart were you able to reflash from there also?

As my nvr will not find a connection to being TFTP
no active on the ethernet port ?

Thank you in advance
Click to expand...

Hi ojassy,

First of, bare with me here as it's been a long while since I did this. I'm also not sure how much you've tried, or how experienced you are with these such things.

The reflashing was all done while in the uboot environment. I used the uart to execute the tftp commands to pull the firmware into the NVR's memory.

You should be able to make use of the main WAN/LAN ethernet port on the NVR.

I'd recommend to keep it as simple as possible by using a laptop/desktop, and plugging a ethernet cable direct between.

On your NVR, Execute the 'printenv' command, and look for the ipaddr, serverip and netmask. Set your desktop/laptops IP is set static to the serverip with the correct mask.

Check the connectivity by using the 'ping' command from the NVR to your desktop/laptop. You should see a successful round trip.

Once you've confirmed traffic is passing between the 2 devices, you should be able to spawn the TFTP server on your desktop/laptop. Make sure it's assigned to the correct network interface, and then you should be able to use the TFTP client on the NVR. I'd recommend you try grabbing an random text file or dumping some random part of memory as an initial test. If this works, then you're good to go :)
 
You must log in or register to reply here.
Top Bottom