Bricked SV3C IP 1080P Firmware help

RubberDinero · Aug 13, 2018

alastairstevenson said:
This was going to be the second attempt:
In the bootloader, there is a NAND subsystem.
With some care not to execute any commands to erase or format the flash, can you see what subcommands it supports?

Code:

nand
nand - NAND sub-system

Usage:
nand info - show available NAND devices
nand device [dev] - show or set current device
nand read - addr off|partition size
nand write - addr off|partition size
    read/write 'size' bytes starting at offset 'off'
    to/from memory address 'addr', skipping bad blocks.
nand erase[.spread] [clean] off size - erase 'size' bytes from offset 'off'
    With '.spread', erase enough for given file size, otherwise,
    'size' includes skipped bad blocks.
nand erase.part [clean] partition - erase entire mtd partition'
nand erase.chip [clean] - erase entire chip'
nand bad - show bad blocks
nand dump[.oob] off - dump page
nand scrub off size | scrub.part partition | scrub.chip
    really clean NAND erasing bad blocks (UNSAFE)
nand markbad off [...] - mark bad block(s) at offset (UNSAFE)
nand biterr off - make a bit error at offset (UNSAFE)

alastairstevenson · Aug 13, 2018

Well that's promising - and a bit risky ...
But the flash may be NOR flash if it's SPI connected.
The bootloader also has an SPI subsystem - can you check that out?

Although not listed, does the bootloader have a tftp option?
There would be a need to load a file into memory to write to flash.
And I'm guessing there isn't an SD card available in the camera?

RubberDinero · Aug 13, 2018

alastairstevenson said:
Well that's promising - and a bit risky ...
But the flash may be NOR flash if it's SPI connected.
The bootloader also has an SPI subsystem - can you check that out?

Code:

spi
spi - spi - Serial Flash sub-system

Usage:
spi spi erase offset len       - erase 'len' bytes from 'offset'
spi read  addr offset len  - read  'len' bytes starting at 'offset' to memory at 'addr'
spi write addr offset len  - write 'len' bytes from memory at 'addr' to flash at 'offset'

alastairstevenson said:
Although not listed, does the bootloader have a tftp option?
There would be a need to load a file into memory to write to flash.
And I'm guessing there isn't an SD card available in the camera?

It does have tftpboot that can be used to upload uImage, but i don't have that image.

RubberDinero · Aug 13, 2018

alastairstevenson said:
Although not listed, does the bootloader have a tftp option?
There would be a need to load a file into memory to write to flash.
And I'm guessing there isn't an SD card available in the camera?

No SD or USB of any kind

RubberDinero · Aug 13, 2018

i inserted the "init" code on the good camera and i get this

can I extract "uImage" from this device and tftp it to the bricked one?

alastairstevenson · Aug 14, 2018

That's the intended result for the bad camera. I wonder why it doesn't work on that.
The system needs more commands to fully initialise before the flash partitions can be extracted. Usually /etc/rcS would be enough.
**edit** Oops .. should be /etc/init.d/rcS

But no point until a similar state can be achieved on the bad camera.

alastairstevenson · Aug 14, 2018

Ok, so it does have tftp facilities.
Do you have a link to valid firmware?
I should be able to extract uImage from it.

alastairstevenson · Aug 14, 2018

I'm quite hesitant to suggest this, as it may go badly wrong if it impacted the bootloader, and it would need the correct firmware.
The risk depends on how well the update program in the bootloader validates the offered data source.

I had a look at the firmware download from here : POE-1080P（Lseries）
The .ov file appears to be a packaged version of a flash image file, as opposed to a set of files in a wrapper.
It holds the bootloader, environment variables, uImage, rootfs etc
I'm wondering if that is the data format that the bootloader command 'update' is built to handle.

If you felt you wanted to try this, you'd need a tftp server active on the IP address shown by the variable serverip, which you could use as-is by changing the PC IP address, or you could change the value for serverip with setenv.
A simple and effective tftp server can be downloaded here : TFTPD32 : an opensource IPv6 ready TFTP server/service for windows : TFTP server

RubberDinero · Aug 14, 2018

alastairstevenson said:
Ok, so it does have tftp facilities.
Do you have a link to valid firmware?
I should be able to extract uImage from it.

Sorry for the late reply. sv3c.com/firmware.html has the firmware, but when i change the extension to that of a compress file, i can see the file inside, but it says it's corrupted. I tried changing the header with a hex editor, repairing the file as zip, but nothing get's me a successful unzip.
if you'd like to try, it's the "L-series" from that site

RubberDinero · Aug 14, 2018

alastairstevenson said:
I'm quite hesitant to suggest this, as it may go badly wrong if it impacted the bootloader, and it would need the correct firmware.
The risk depends on how well the update program in the bootloader validates the offered data source.

I had a look at the firmware download from here : POE-1080P（Lseries）
The .ov file appears to be a packaged version of a flash image file, as opposed to a set of files in a wrapper.
It holds the bootloader, environment variables, uImage, rootfs etc
I'm wondering if that is the data format that the bootloader command 'update' is built to handle.

If you felt you wanted to try this, you'd need a tftp server active on the IP address shown by the variable serverip, which you could use as-is by changing the PC IP address, or you could change the value for serverip with setenv.
A simple and effective tftp server can be downloaded here : TFTPD32 : an opensource IPv6 ready TFTP server/service for windows : TFTP server

I'm pretty confident in using tftp, but i hadn't found the "uImage" to upload, because that's the file it looks for, and also, i wasn't sure what memory address to overwrite after. But I'm good at following directions and I'll give anything a try.

I would need to know how to use the update command and it's variables because i've ran it and it's like a foreign language what inputs it's asking me.

alastairstevenson · Aug 14, 2018

RubberDinero said:
when i change the extension to that of a compress file, i can see the file inside, but it says it's corrupted.

The firmware file is not a zip file - it's a set of flash image files concatenated together.

RubberDinero said:
i hadn't found the "uImage" to upload, because that's the file it looks for

That's just the default filename if no other arguments are used.
uImage is the kernel.
From what I can see, that's OK, it boots up normally, until it finds that the specified rootfs is invalid and it aborts, that's a fatal condition for a kernel.

RubberDinero said:
I would need to know how to use the update command and it's variables because i've ran it and it's like a foreign language what inputs it's asking me.

It would be good to see what the prompts are.
I wondered if it would be a 'monolithic' 'write the whole flash' approach, or if it would allow partitions to be written selectively.
It's the rootfs that's not correct.
And I wondered if it's built to process the distributed firmware file, or maybe a special 'factory' version.

RubberDinero · Aug 14, 2018

I'll get you the prompts as soon as I have access to my computer. but it may be a few hours.

alastairstevenson · Aug 14, 2018

RubberDinero said:
I'll get you the prompts as soon as I have access to my computer. but it may be a few hours.

No worries.
And I'll hopefully be asleep ...
Till the next time.

RubberDinero · Aug 15, 2018

alastairstevenson said:
No worries.
And I'll hopefully be asleep ...
Till the next time.

Code:

update - update image, u-env, factory, u-logo, user, kernel, rootfs-r, rootfs-rw, firmware/firmware_f

Usage:
update type address size verify - start update image application at address 'addr'

ERROR: update cmd parameter num err

RubberDinero · Aug 15, 2018

alastairstevenson said:
No worries.
And I'll hopefully be asleep ...
Till the next time.

also, i never fully gave you the boot sequence after i inserted the code, just a screen shot, so maybe you can extract more from the full text

Code:

## Booting kernel from Legacy Image at 00008000 ...
   Image Name:   Linux-2.6.35.12
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1294032 Bytes = 1.2 MiB
   Load Address: 00008000
   Entry Point:  00008040
   Verifying Checksum ... OK
   XIP Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.35.12 (cwz@vvvsvr) (gcc version 4.5.2 (SONiX GCC-4.5.2 Release 2011-12-06) ) #16 Fri Jul 1 20:27:18 CST 2016
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00057177
CPU: VIVT data cache, VIVT instruction cache
Machine: SONiX SN98600 Development Platform
Memory policy: ECC disabled, Data cache writeback
CPU: found ITCM 16k @ ffff4000, enabled
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock2 rootfstype=squashfs init=/bin/sh mem=64M isp=11M vc=11M vo=0M mtdparts=snx-spi:320k(uboot),1408k(kernel),6016k(rootfs),64k(key),384k(etc)
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 38816k/38816k available, 26720k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffa00000 - 0xffe00000   (   4 MB)
    vmalloc : 0xc4800000 - 0xe0000000   ( 440 MB)
    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc001d000   (  84 kB)
      .text : 0xc001d000 - 0xc0330000   (3148 kB)
      .data : 0xc0344000 - 0xc035cae0   (  99 kB)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
        RCU-based detection of stalled CPUs is disabled.
        Verbose stalled-CPUs detection is disabled.
NR_IRQS:96
Console: colour dummy device 80x30
console [ttyS0] enabled
Calibrating delay loop... 200.29 BogoMIPS (lpj=1001472)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
0x00b00000 bytes system memory reserved for isp device at 0x003fd000
0x00b00000 bytes system memory reserved for vc device at 0x00efd000
bio: create slab <bio-0> at 0
Linux media interface: v0.10
Linux video capture interface: v2.00
Advanced Linux Sound Architecture Driver Version 1.0.23.
Switching to clocksource ft_clocksource
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
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
squashfs: version 4.0 (2009/01/31) Phillip Lougher
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
fuse init (API version 7.14)
msgmni has been set to 75
async_tx: api initialized (async)
io scheduler noop registered (default)
SONIX UART driver, (c) 2013 Sonix
snx_uart.0: ttyS0 at MMIO 0x98a00000 (irq = 8) is a SONiX
snx_uart.1: ttyS1 at MMIO 0x98b00000 (irq = 10) is a SONiX
loop: module loaded
5 cmdlinepart partitions found on MTD device snx-spi
Creating 5 MTD partitions on "snx-spi":
0x000000000000-0x000000050000 : "uboot"
0x000000050000-0x0000001b0000 : "kernel"
0x0000001b0000-0x000000790000 : "rootfs"
0x000000790000-0x0000007a0000 : "key"
0x0000007a0000-0x000000800000 : "etc"
snx_spi_init register
SONiX Ethernet driver, (c) 2013 Sonix
eth0: Dropping NETIF_F_SG since no checksum feature.
snx_mac: SNX Ethernet MAC controller at 0x90500000 (irq = 17) 00:b0:27:08:90:14.
snx_mac: IP101G Ethernet PHY 100 Mbps FullDuplex (Auto Negotiation)
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
SONIX SNX I2C adapter driver, (c) 2012 Sonix
snx_i2c.0: SNX I2C0 controller at 0x98300000 (irq = 1)
I2C GPIO driver INIT
snx_i2c.1: SNX I2C1 controller at 0x98400000 (irq = 2)
snx_hdma snx_hdma: SNX AHB DMA Controller (memcpy memset), 4 channels
SNX AHB DMA driver register
ALSA device list:
  No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
lib80211: common routines for IEEE802.11 drivers
SQUASHFS error: squashfs_read_data failed to read block 0x5a95ce
SQUASHFS error: Unable to read metadata cache entry [5a95ce]
SQUASHFS error: Unable to read inode 0x1185169f
VFS: Cannot open root device "mtdblock2" or unknown-block(31,2)
Please append a correct "root=" boot option; here are the available partitions:
1f00             320 mtdblock0 (driver?)
1f01            1408 mtdblock1 (driver?)
1f02            6016 mtdblock2 (driver?)
1f03              64 mtdblock3 (driver?)
1f04             384 mtdblock4 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,2)
[<c0023510>] (unwind_backtrace+0x0/0xf4) from [<c021ca20>] (panic+0x58/0xd4)
[<c021ca20>] (panic+0x58/0xd4) from [<c0008d00>] (mount_block_root+0x1d8/0x29c)
[<c0008d00>] (mount_block_root+0x1d8/0x29c) from [<c0008f48>] (prepare_namespace+0x120/0x178)
[<c0008f48>] (prepare_namespace+0x120/0x178) from [<c00089e4>] (kernel_init+0x110/0x150)
[<c00089e4>] (kernel_init+0x110/0x150) from [<c001f0d0>] (kernel_thread_exit+0x0/0x8)

alastairstevenson · Aug 15, 2018

RubberDinero said:
Usage: update type address size verify - start update image application at address 'addr'

If you're up for it - this might be worth checking out.
There are various unknowns ... and risks.
Does 'update' implicitly run tftp to download the image file, which if so could be a pre-defined name?
Does the 'address' command-line parameter refer to a memory address that a prior tftp download has loaded with the image file? Or is it the offset address in flash where the file is to be written? And is it in hex or decimal format?
Does the 'update' command know the offset address in flash to write to as a consequence of specifyng the 'type' in the command line?

Attached is the squashfs segment extracted from the firmware that holds the rootfs.
Squashfs is a read-only file system, so I'm thinking that would be the 'rootfs-r' referred to in the update command line.
With a tftp server running at the 'serverip' address (remember you can change serverip and ipaddrs definitions to suit your network, to save messing with the PC address).

So, maybe, assuming it's hex number and not decimal :
update rootfs-r 0x1B0000 0x5E0000 1
and see what it complains about.

And possibly, with the unzipped rootfs.squashfs file in the folder the tftp server is running in, thinking it will download to a default address of 0x1000000 :
tftp rootfs.squashfs
or if it complains
tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0x5E0000 1

I'm guessing a bit here, as I'm sure you know ...

RubberDinero · Aug 15, 2018

alastairstevenson said:
So, maybe, assuming it's hex number and not decimal :
update rootfs-r 0x1B0000 0x5E0000 1
and see what it complains about.

And possibly, with the unzipped rootfs.squashfs file in the folder the tftp server is running in, thinking it will download to a default address of 0x1000000 :
tftp rootfs.squashfs
or if it complains
tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0x5E0000 1

I'm guessing a bit here, as I'm sure you know ...

Code:

sonix # update rootfs-r 0x1B0000 0X5E0000 1
update rootfs-r 0x1B0000 0X5E0000 1
## Update rootfs-r Starting  ...
serial flash erase offset = 0x350000 len = 0x0
Serial Flash Erase: done
serial flash erase offset = 0x1000 len = 0x1000
Serial Flash Erase: done
verify: err size
## Update rootfs-r End, rc = 0xFFFFFFFF
ERROR: update failed

Code:

tftp rootfs.squashfs
TFTP from server 192.168.0.120; our IP address is 192.168.0.124
Filename 'rootfs.squashfs'.
Load address: 0x1000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #####################
done
Bytes transferred = 6029312 (5c0000 hex)
TFTP is : Success
sonix # update rootfs-r 0x1000000 0x5E0000 1
update rootfs-r 0x1000000 0x5E0000 1
## Update rootfs-r Starting  ...
serial flash erase offset = 0x350000 len = 0x5e0000
serial flash MXIC&AMIC: end address out of chip size
## Update rootfs-r End, rc = 0xFFFFFFFF
ERROR: update failed

RubberDinero · Aug 15, 2018

alastairstevenson said:
And possibly, with the unzipped rootfs.squashfs file in the folder the tftp server is running in, thinking it will download to a default address of 0x1000000 :
tftp rootfs.squashfs
or if it complains
tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0x5E0000 1

I'm guessing a bit here, as I'm sure you know ...

What if were tftp the entire firmware and do the "update firmware", i would just need the correct address

Code:

update - update image, u-env, factory, u-logo, user, kernel, rootfs-r, rootfs-rw, firmware/firmware_f

Usage:
update type address size verify - start update image application at address 'addr'

alastairstevenson · Aug 15, 2018

Interesting - so the update rootfs-r implicitly knows the starting offset in the flash memory - "offset = 0x350000"
That's good.

And the tftp command works OK.
For the 'length' parameter I'd used what appears to be the rootfs partition size, 0x5E0000
But the actual size of the extracted rootfs.squashfs is 0x5C0000

So maybe try
tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0x5C0000 1

RubberDinero · Aug 15, 2018

alastairstevenson said:
So maybe try
tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0x5C0000 1

Code:

tftp rootfs.squashfs
TFTP from server 192.168.0.120; our IP address is 192.168.0.124
Filename 'rootfs.squashfs'.
Load address: 0x0
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #####################
done
Bytes transferred = 6029312 (5c0000 hex)
TFTP is : Success
sonix # update rootfs-r 0x1000000 0x5C0000 1
update rootfs-r 0x1000000 0x5C0000 1
## Update rootfs-r Starting  ...
serial flash erase offset = 0x350000 len = 0x5c0000
serial flash MXIC&AMIC: end address out of chip size
## Update rootfs-r End, rc = 0xFFFFFFFF
ERROR: update failed

Search

Bricked SV3C IP 1080P Firmware help

RubberDinero

Young grasshopper

alastairstevenson

RubberDinero

Young grasshopper

RubberDinero

Young grasshopper

RubberDinero

Young grasshopper

alastairstevenson

alastairstevenson

alastairstevenson

RubberDinero

Young grasshopper

RubberDinero

Young grasshopper

alastairstevenson

RubberDinero

Young grasshopper

alastairstevenson

RubberDinero

Young grasshopper

RubberDinero

Young grasshopper

alastairstevenson

Attachments

RubberDinero

Young grasshopper

RubberDinero

Young grasshopper

alastairstevenson

RubberDinero

Young grasshopper