Bricked SV3C IP 1080P Firmware help

I pulled the devinfo, maybe it's usefull to you
Code: 
## Device Info Starting ...
Invalid rootfsr
Flash-Type=SPI

SPI : u-boot/factory/kernel/rootfs-r/rootfs-rw/user/u-logo
hw-setting=0x00000000,0x00000FFF
u-boot=0x00002000,0x0004DFFF
u-env=0x0004E000,0x0004EFFF
flash-layout=0x0004F000,0x0004FFFF
factory=0x0004FFFF,0x0004FFFF
kernel=0x00050000,0x0034FFFF
rootfs-r=0x00350000,0x00A4FFFF
rootfs-app=0x00A4FFFF,0x00A4FFFF
rootfs-rw =0x00A50000,0x00B4FFFF
user=0x00B4FFFF,0x00B4FFFF
u-logo=0x00B4FFFF,0x00B4FFFF
rescue=0x00A4FFFF,0x00A4FFFF
u-boot.ver=u-boot-2011-09
u-boot.tm=
factory.ver=▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
factory.tm=▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
kernel.ver=master_054a_20160511_1704
kernel.tm=2016-07-01 20:27
user.ver=▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
user.tm=▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
rootfs-r.ver=
rootfs-r.tm=
## Device Info End, rc = 0xFFFFFFFB
ERROR: devinfo read version time Failed
 
RubberDinero said:
I pulled the devinfo, maybe it's usefull to you
Click to expand...
That looks like it should be useful - but will need some interpretation.

RubberDinero said:
serial flash MXIC&AMIC: end address out of chip size
Click to expand...
There isn't a lot of dead space on the end of the file - so not much scope for empirically trying a smaller size.
But you never know.
Do you want to try some smaller size values to see where it stops complaining?

Plus, there is the assumption I've made that rootfs-r is the squashfs segment as opposed to the rootfs-rw.
The next section in the firmware is the 'key' at 65,536 and then 'etc' at 393,216 which I think may be the configuration.

RubberDinero said:
What if were tftp the entire firmware and do the "update firmware", i would just need the correct address
Click to expand...
The 'update' program seems equipped with flash address offsets.
I'm wondering though if this would need something other than the published firmware.
I don't know - more risky potentially impacting the bootloader and kernel.
 
alastairstevenson said:
Plus, there is the assumption I've made that rootfs-r is the squashfs segment as opposed to the rootfs-rw.
Click to expand...
For sure we have an invalid rootfsr problem, but it being squashfs or not is beyond my understanding. A question i have is that if "rootfs-r=0x00350000" shouldn't we be writing to
Code: 
update rootfs-r 0x1000000 0x0350000 1
I don't know much on this matter, and i'd probably brick it beyond repair. I'm just curious.
alastairstevenson said:
The 'update' program seems equipped with flash address offsets.
I'm wondering though if this would need something other than the published firmware.
I don't know - more risky potentially impacting the bootloader and kernel.
Click to expand...
I would like to try the entire firmware option, as long as the writing address is after the bootloader, it shouldn't affect it, right?
 
I found this at another website
Code: 
update rootfs tftp <rootfs-file>.ext4

would this work if we modified it to
Code: 
update rootfs tftp rootfs.squashfs
 
RubberDinero said:
would this work if we modified it to
Click to expand...
To be honest, I don't know if that would work.
It doesn't seem to match required syntax.
The file downloaded OK, and an attempt was made to use it, but it was rejected by the requested write size being too large.

I'm encouraged by the update rootfs-r command, it looks promising.
The only error so far is the size parameter.
I'm wondering if the size is measured in flash erase-blocks as opposed to bytes.
If so, that would account for the complaint about being too large.
If the erase-block size is 2048, the size would be 0xb80
If the erase-block size is 512, the size would be 0x2E00
You never know. But flash erase/write routines do generally operate in erase-block chunks, sometimes hidden away though.
 
alastairstevenson said:
To be honest, I don't know if that would work.
I'm encouraged by the update rootfs-r command, it looks promising.
The only error so far is the size parameter.
I'm wondering if the size is measured in flash erase-blocks as opposed to bytes.
If so, that would account for the complaint about being too large.
If the erase-block size is 2048, the size would be 0xb80
If the erase-block size is 512, the size would be 0x2E00
You never know. But flash erase/write routines do generally operate in erase-block chunks, sometimes hidden away though.
Click to expand...
I'll try anything, there is no way for me to unbrick it myself, so either way, it's dead-weight as is. Let me know what commands you'd like me to try and I'll give it a go.
 
I was thinking of :

tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0xb80 1

and also
tftp rootfs.squashfs 0x1000000
and then
update rootfs-r 0x1000000 0x2E00 1
 
alastairstevenson said:
Either, one assumes a 2048 byte block size, the other a 512 byte block size.
Click to expand...
Code: 
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 0xb80 1
update rootfs-r 0x1000000 0xb80 1
## Update rootfs-r Starting  ...
serial flash erase offset = 0x350000 len = 0x1000
Serial Flash Erase: done
serial flash erase offset = 0x1000 len = 0x1000
Serial Flash Erase: done
CRC16 Error, check = 0x00000000, crc = 0x0000DBE5
Verify: CRC16 ERROR
## Update rootfs-r End, rc = 0xFFFFFFFF
ERROR: update failed
sonix # update rootfs-r 0x1000000 0x2E00 1
update rootfs-r 0x1000000 0x2E00 1
## Update rootfs-r Starting  ...
serial flash erase offset = 0x350000 len = 0x3000
Serial Flash Erase: done
serial flash erase offset = 0x1000 len = 0x1000
Serial Flash Erase: done
CRC16 Error, check = 0x00006DB4, crc = 0x00005790
Verify: CRC16 ERROR
## Update rootfs-r End, rc = 0xFFFFFFFF
ERROR: update failed
 
alastairstevenson said:
Either, one assumes a 2048 byte block size, the other a 512 byte block size.
Click to expand...
so i went to On-line CRC calculation and free library and tried all the CRC-16 sizes for 5c0000, below are just a few, and i got success with 0x489e.
Code: 
sonix # update rootfs-r 0x1000000 0x4026 1
update rootfs-r 0x1000000 0x4026 1
## Update rootfs-r Starting  ...
serial flash erase offset = 0x350000 len = 0x5000
Serial Flash Erase: done
serial flash erase offset = 0x1000 len = 0x1000
Serial Flash Erase: done
SONIX HWCRC16: len must be 4 bytes aligned, len can't be zero len = 0x3fb6
CRC16 Error, check = 0x0000C8C1, crc = 0x00000000
Verify: CRC16 ERROR
## Update rootfs-r End, rc = 0xFFFFFFFF
ERROR: update failed
sonix # update rootfs-r 0x1000000 0x490E 1
update rootfs-r 0x1000000 0x490E 1
## Update rootfs-r Starting  ...
serial flash erase offset = 0x350000 len = 0x5000
Serial Flash Erase: done
serial flash erase offset = 0x1000 len = 0x1000
Serial Flash Erase: done
SONIX HWCRC16: len must be 4 bytes aligned, len can't be zero len = 0x489e
## Update rootfs-r End, rc = 0x0
This work is : Success
but after a reset and boot i still get the same boot sequence.
so even though it said success, i don't it actually worked.
 
RubberDinero said:
sonix # update rootfs-r 0x1000000 0x2E00 1 update rootfs-r 0x1000000 0x2E00 1 ## Update rootfs-r Starting ... serial flash erase offset = 0x350000 len = 0x3000
Click to expand...
This indicates to me that the 'length' parameter may be in bytes, as it seems to be rounding up from the one on the command line.
If it was erase-blocks, it would not round up in steps of 0x1000

RubberDinero said:
so i went to On-line CRC calculation and free library and tried all the CRC-16 sizes for 5c0000, below are just a few, and i got success with 0x489e.
Click to expand...
The CRC error is interesting, as it needs a value to compare against. And it needs to be calculated from the actual data.
Usually this would be held in a header or file descriptor, as it needs to be separate from the data it is linked to.
But in this case, I simply extracted the rootfs from the firmware, so there is no header or descriptor to reference that holds a CRC, if it's against the whole data.
It almost suggests there needs to be a 'packaged' version of the rootfs-r image for the update command to process, in which case the extract I did isn't useful.

I'm conscious of the fact that with all my guesswork suggestions, it's consuming a lot of your time, much more than the money the camera is worth.
But often we do these things just for the satisfaction of the problem solving as opposed to saving cash.
So I'm a bit hesitant to keep suggesting things to try.

The size complaint still puzzles me, as the length suggested is consistent with the info from the serial console.
On the CRC - maybe turning the verify off would hide that problem.
If you do want to explore a bit more, here are some suggestions:

Try to figure out the size boundary by trying the size parameter until it doesn't complain.
The tftp download to RAM would only need done once.
And maybe the verify=0 will ignore any CRC errors.
tftp rootfs.squashfs 0x1000000
update rootfs-r 0x1000000 0x5c0000 0

And then maybe the rootfs-r isn't the right choice - maybe see what happens with rootfs-rw

I wonder if SV3C tech support would be any help with a suitable firmware image for the update program, and some info on the command-line paramters.
 
alastairstevenson said:
I'm conscious of the fact that with all my guesswork suggestions, it's consuming a lot of your time, much more than the money the camera is worth.
But often we do these things just for the satisfaction of the problem solving as opposed to saving cash.
So I'm a bit hesitant to keep suggesting things to try.
Click to expand...
I'm definitely only doing this for the satisfaction and to gain knowledge on the process. Aspiring to learn programming someday and this is a fun project.
 
alastairstevenson said:
Try to figure out the size boundary by trying the size parameter until it doesn't complain.
The tftp download to RAM would only need done once.
And maybe the verify=0 will ignore any CRC errors.
tftp rootfs.squashfs 0x1000000
update rootfs-r 0x1000000 0x5c0000 0

And then maybe the rootfs-r isn't the right choice - maybe see what happens with rootfs-rw

I wonder if SV3C tech support would be any help with a suitable firmware image for the update program, and some info on the command-line paramters.
Click to expand...
None of these work, but i would like to try the erase command but i've tried erase 0x1b0000 5c0000
but most attempts are followed by "Error: end address (0x0078ffff) not in flash!"(0x0078ffff being different each time)
if successful, i would have followed it with a cp.b 0x1000000 0x1b0000 5c0000
but i don't think 1b0000 is the correct address
 
RubberDinero said:
but i don't think 1b0000 is the correct address
Click to expand...
This from the console log should be a valid list of how the flash is laid out :
Code: 
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
And 0x0000001b0000-0x000000790000 : "rootfs" gives a size of 0x5E0000 which fits well with the extracted squashfs file size of 0x5C0000
But then we have the devinfo showing
Code: 
rootfs-r=0x00350000,0x00A4FFFF
which equates to a larger size of 0x700000 and a different offset address from the console log, but does match what the 'update' command associates with rootfs-r

So I'm puzzled why the complaint about the end address being too large.
 
alastairstevenson said:
This from the console log should be a valid list of how the flash is laid out :
Click to expand...
maybe the 5c0000 needs to be in CRC16
some type of erase 0x1b0000 [CRC16 VALUE]

Earlier today, i received a message on this forum from someone that is going through the same issue. He said he is in contact with SV3C and they forwarded him an email that was supposed to have an img attachment, but file was not attached. He said that he has also requested tftp loading commands and expects a response soon.
I'll keep trying anything you'd like, or we can give it a break and wait for this person's response. Hopefully a proper flashing procedure is produced and I will share any success story. I also don't want to waste your time.
 
alastairstevenson said:
That's not a problem - I'm probably as curious about how to fix this, and frustrated as you are.
It can be quite hard to do these things through forum posts like this.
I'm almost tempted to buy one to have a play with it.
Click to expand...
I wouldn't say frustrated, i'm learning a lot and the less things work, the more i decipher from the thought-process behind the instructions received.
If you do buy one, all you have to do to brick it is try upgrading the firmware. LOL.
 
alastairstevenson said:
That's not a problem - I'm probably as curious about how to fix this, and frustrated as you are.
Click to expand...
I just tried this, where I tried to transfer the rootfs.squashfs file directly to 0x001b0000 through serial using loady
Code: 
sonix # loady 0x001b0000
loady 0x001b0000
## Ready for binary (ymodem) download to 0x001B0000 at 115200 bps...
xyzModem - CRC mode, 1(SOH)/5888(STX)/0(CAN) packets, 5 retries
## Total Size      = 0x005c0000 = 6029312 Bytes
ERROR: Invalid type parameter
but i still erred out.
 
RubberDinero said:
I just tried this, where I tried to transfer the rootfs.squashfs file directly to 0x001b0000 through serial using loady
Click to expand...
Yes, you'd need a terminal program that supports those ancient file transfer serial protocols.
But the tftp download works just fine - no problems getting files in to the camera.
It's a matter of the right file and the right command to make use of it.
Lets hope the other user has some success with the tech support dialogue.
 
You must log in or register to reply here.
Top Bottom