Bricked SV3C IP 1080P Firmware help

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?
Click to expand...

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)
 
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?
 
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?
Click to expand...
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?
Click to expand...
It does have tftpboot that can be used to upload uImage, but i don't have that image.
 
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.
 
Last edited:
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
 
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.
Click to expand...

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
 
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
Click to expand...

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.
 
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.
Click to expand...
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
Click to expand...
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.
Click to expand...
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.
 
alastairstevenson said:
No worries.
And I'll hopefully be asleep ...
Till the next time.
Click to expand...
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)
 
RubberDinero said:
Usage: update type address size verify - start update image application at address 'addr'
Click to expand...
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 ...
 

Attachments

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 ...
Click to expand...
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
 
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 ...
Click to expand...
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'
 
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
 
alastairstevenson said:
So maybe try
tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0x5C0000 1
Click to expand...
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
 
You must log in or register to reply here.
Top Bottom