Bricked SV3C IP 1080P Firmware help

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
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
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I pulled the devinfo, maybe it's usefull to you
That looks like it should be useful - but will need some interpretation.

serial flash MXIC&AMIC: end address out of chip size
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.

What if were tftp the entire firmware and do the "update firmware", i would just need the correct address
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.
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
Plus, there is the assumption I've made that rootfs-r is the squashfs segment as opposed to the rootfs-rw.
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.
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.
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?
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
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
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
would this work if we modified it to
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.
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
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.
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.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
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
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
Either, one assumes a 2048 byte block size, the other a 512 byte block size.
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
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
Either, one assumes a 2048 byte block size, the other a 512 byte block size.
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.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
sonix # update rootfs-r 0x1000000 0x2E00 1 update rootfs-r 0x1000000 0x2E00 1 ## Update rootfs-r Starting ... serial flash erase offset = 0x350000 len = 0x3000
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

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.
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.
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
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.
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.
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
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.
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
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
but i don't think 1b0000 is the correct address
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.
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
This from the console log should be a valid list of how the flash is laid out :
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

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I also don't want to waste your time.
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.
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
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.
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.
 

RubberDinero

Young grasshopper
Joined
Aug 13, 2018
Messages
54
Reaction score
1
Location
phoenix, az
That's not a problem - I'm probably as curious about how to fix this, and frustrated as you are.
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.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,930
Reaction score
6,778
Location
Scotland
I just tried this, where I tried to transfer the rootfs.squashfs file directly to 0x001b0000 through serial using loady
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.
 
Top