Hi everyone..
Some years ago, I bought an 8 channel security systems and cameras. The system model is Elec-CVD-2008H. A few months ago, we had a power outage and after that the system has never started up again normally. When it starts, it simply ends up with an image of colour bars, which by the way is pretty bad i.e. unstable and fuzzy. See photo..
After about 4-5 minutes, the system reboots by itself. I can tell my the front counter!
The front of the unit has a display which counts in hours, minutes and seconds and looks like this:
I do have the original firmware upgrade file, which I managed to get from ELEC a few years ago when I upgraded it to the current version of firmware. I have tried the following:
First I hooked up to the UART to see what was happening: The output from the UART was as follows:
U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
DRAM: 256 MiB
Check spi flash controller v300. found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128"
In: serial
Out: serial
Err: serial
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY not link!
user init finish.
Press CTRL-C to abort autoboot in 0 secondsCFG_BOOT_ADDR:0x58080000
### boot load complete: 2741872 bytes loaded to 0x82000000
### SAVE TO 80008000 !
## Booting kernel from Legacy Image at 82000000 ...
Image Name: linux
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2741808 Bytes = 2.6 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
From that I could see it was trying to boot the kernel, but then nothing. It has an EEPROM chip, MX25L128 which holds the image. I pulled it out and put it into my Minipro TL866A programmer and read out the image to save it as a xxx.bin file. I loaded the last update I had obtained i.e. a file called “General_General_MBD6504E_V4.02.R11.20130620.bin“ and burned that into the EEPROM. After returning the EEPROM to the motherboard, it simply was dead, no boot. I then pulled it off the board again, put it into the Minipro TL866A programmer, loaded the original xxx.bin file and burned that into it again. After returning it to the board, it booted as before. (I also tried another image I downloaded i.e. “General_General_MBD6504E_V4.02.R11.20141226_NT.bin” so I suspect the last updated .bin file and that other one I downloaded are just updates and don’t contain the U-boot loader. That is why I think it doesn’t work.
Then I found another image “SimpGeneral_General_NBD6808T-PL_V4.02.R11.20140723_NT.bin” which also included the “update.img” file. I put that onto a TFTP server and invoked the U-Boot command prompt when the unit booted. I then ran the “Run up” command after having pointed it to the TFTP server where it could pull the “update.img” file.. That seem to run fine..
U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
DRAM: 256 MiB
Check spi flash controller v300. found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128"
In: serial
Out: serial
Err: serial
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY not link!
user init finish.
Press CTRL-C to abort autoboot in 0 secondshisilicon # printenv
bootcmd=lload;fload;bootm 0x82000000
bootdelay=1
baudrate=115200
bootfile="uImage"
da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
dl=mw.b 0x82000000 ff 1000000;tftp 0x82000000 logo-x.cramfs.img;sf probe 0;flwrite
dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 zImage.img; bootm 0x82000000
dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
ethaddr=00:0b:3f:00:00:01
bootargs=mem=92M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:512K(boot),4M(romfs),5632K(user),1536K(web),3M(custom),256K(logo),1280K(mtd)
servip=192.168.1.103
serverip=192.168.1.103
ipaddr=192.168.1.109
netmask=255.255.255.0
gatewayip=192.168.1.1
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
Environment size: 1212/262140 bytes
hisilicon # setenv servip 192.168.1.42
hisilicon # run up
miiphy_register: non unique device name '0:02'
MAC: 00-0B-3F-00-00-01
TFTP from server 192.168.1.103; our IP address is 192.168.1.109
Download Filename 'update.img'.
Download to address: 0x82000000
Downloading: *
Abort
hisilicon # setenv serverip 192.168.1.42
hisilicon # printenv
bootcmd=lload;fload;bootm 0x82000000
bootdelay=1
baudrate=115200
bootfile="uImage"
da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
dl=mw.b 0x82000000 ff 1000000;tftp 0x82000000 logo-x.cramfs.img;sf probe 0;flwrite
dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 zImage.img; bootm 0x82000000
dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
ethaddr=00:0b:3f:00:00:01
bootargs=mem=92M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:512K(boot),4M(romfs),5632K(user),1536K(web),3M(custom),256K(logo),1280K(mtd)
ipaddr=192.168.1.109
netmask=255.255.255.0
gatewayip=192.168.1.1
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
servip=192.168.1.42
serverip=192.168.1.42
Environment size: 1210/262140 bytes
hisilicon # run up
miiphy_register: non unique device name '0:02'
MAC: 00-0B-3F-00-00-01
TFTP from server 192.168.1.42; our IP address is 192.168.1.109
Download Filename 'update.img'.
Download to address: 0x82000000
Downloading: #################################################
done
Bytes transferred = 13484416 (cdc180 hex)
16384 KiB hi_sfc at 0:0 is now current device
## Checking Image at 0x82000040 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 2998272 Bytes = 2.9 MiB
Load Address: 00b80000
Entry Point: 00e80000
Data CRC Checking ... OK
Programing start at: 0x00b80000
Programing end at: 0x00e80000
Erasing at 0xe80000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xe80000 -- 100% complete.
done.
## Checking Image at 0x822dc080 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 20480 Bytes = 20 KiB
Load Address: 00e80000
Entry Point: 00ec0000
Data CRC Checking ... OK
Programing start at: 0x00e80000
Programing end at: 0x00ec0000
Erasing at 0xec0000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xec0000 -- 100% complete.
done.
## Checking Image at 0x822e10c0 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 3854336 Bytes = 3.7 MiB
Load Address: 00080000
Entry Point: 00480000
Data CRC Checking ... OK
Programing start at: 0x00080000
Programing end at: 0x00480000
Erasing at 0x480000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0x480000 -- 100% complete.
done.
## Checking Image at 0x8268e100 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 5328896 Bytes = 5.1 MiB
Load Address: 00480000
Entry Point: 00a00000
Data CRC Checking ... OK
Programing start at: 0x00480000
Programing end at: 0x00a00000
Erasing at 0xa00000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xa00000 -- 100% complete.
done.
## Checking Image at 0x82ba3140 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 1282048 Bytes = 1.2 MiB
Load Address: 00a00000
Entry Point: 00b80000
Data CRC Checking ... OK
Programing start at: 0x00a00000
Programing end at: 0x00b80000
Erasing at 0xb80000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xb80000 -- 100% complete.
done.
hisilicon # reset
resetting ...
This did not change anything. It still boots to the fuzzy color bar screen and then reboots again after 4-5 minutes as before.
I even hooked up an oscilloscope to the composite video output to see what the signal looks like..
The blue trace shows a proper composite video from one of the cameras. The yellow trace shows the composite video from the DVR composite video out terminal. As you can see it’s pretty bad and looks like it’s somehow corrupt. (It is the same from the VGA and HDMI outputs).
I’m just wondering if something more bad has happened here to the Hi3520 chip itself, or if the U-boot loader is somehow corrupt. As I don’t have that I can’t try to replace it.
Some pictures of the board.
[url=https://obrazki.elektroda.pl/4988190200_1594718954.jpg]
Any ideas welcome..
Rgds,
Simmi
Some years ago, I bought an 8 channel security systems and cameras. The system model is Elec-CVD-2008H. A few months ago, we had a power outage and after that the system has never started up again normally. When it starts, it simply ends up with an image of colour bars, which by the way is pretty bad i.e. unstable and fuzzy. See photo..
After about 4-5 minutes, the system reboots by itself. I can tell my the front counter!
The front of the unit has a display which counts in hours, minutes and seconds and looks like this:
I do have the original firmware upgrade file, which I managed to get from ELEC a few years ago when I upgraded it to the current version of firmware. I have tried the following:
First I hooked up to the UART to see what was happening: The output from the UART was as follows:
U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
DRAM: 256 MiB
Check spi flash controller v300. found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128"
In: serial
Out: serial
Err: serial
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY not link!
user init finish.
Press CTRL-C to abort autoboot in 0 secondsCFG_BOOT_ADDR:0x58080000
### boot load complete: 2741872 bytes loaded to 0x82000000
### SAVE TO 80008000 !
## Booting kernel from Legacy Image at 82000000 ...
Image Name: linux
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2741808 Bytes = 2.6 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
From that I could see it was trying to boot the kernel, but then nothing. It has an EEPROM chip, MX25L128 which holds the image. I pulled it out and put it into my Minipro TL866A programmer and read out the image to save it as a xxx.bin file. I loaded the last update I had obtained i.e. a file called “General_General_MBD6504E_V4.02.R11.20130620.bin“ and burned that into the EEPROM. After returning the EEPROM to the motherboard, it simply was dead, no boot. I then pulled it off the board again, put it into the Minipro TL866A programmer, loaded the original xxx.bin file and burned that into it again. After returning it to the board, it booted as before. (I also tried another image I downloaded i.e. “General_General_MBD6504E_V4.02.R11.20141226_NT.bin” so I suspect the last updated .bin file and that other one I downloaded are just updates and don’t contain the U-boot loader. That is why I think it doesn’t work.
Then I found another image “SimpGeneral_General_NBD6808T-PL_V4.02.R11.20140723_NT.bin” which also included the “update.img” file. I put that onto a TFTP server and invoked the U-Boot command prompt when the unit booted. I then ran the “Run up” command after having pointed it to the TFTP server where it could pull the “update.img” file.. That seem to run fine..
U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
DRAM: 256 MiB
Check spi flash controller v300. found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128"
In: serial
Out: serial
Err: serial
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY 0x02: OUI = 0x01F0, Model = 0x0F, Rev = 0x01
PHY not link!
user init finish.
Press CTRL-C to abort autoboot in 0 secondshisilicon # printenv
bootcmd=lload;fload;bootm 0x82000000
bootdelay=1
baudrate=115200
bootfile="uImage"
da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
dl=mw.b 0x82000000 ff 1000000;tftp 0x82000000 logo-x.cramfs.img;sf probe 0;flwrite
dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 zImage.img; bootm 0x82000000
dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
ethaddr=00:0b:3f:00:00:01
bootargs=mem=92M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:512K(boot),4M(romfs),5632K(user),1536K(web),3M(custom),256K(logo),1280K(mtd)
servip=192.168.1.103
serverip=192.168.1.103
ipaddr=192.168.1.109
netmask=255.255.255.0
gatewayip=192.168.1.1
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
Environment size: 1212/262140 bytes
hisilicon # setenv servip 192.168.1.42
hisilicon # run up
miiphy_register: non unique device name '0:02'
MAC: 00-0B-3F-00-00-01
TFTP from server 192.168.1.103; our IP address is 192.168.1.109
Download Filename 'update.img'.
Download to address: 0x82000000
Downloading: *
Abort
hisilicon # setenv serverip 192.168.1.42
hisilicon # printenv
bootcmd=lload;fload;bootm 0x82000000
bootdelay=1
baudrate=115200
bootfile="uImage"
da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
dl=mw.b 0x82000000 ff 1000000;tftp 0x82000000 logo-x.cramfs.img;sf probe 0;flwrite
dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 zImage.img; bootm 0x82000000
dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
ethaddr=00:0b:3f:00:00:01
bootargs=mem=92M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:512K(boot),4M(romfs),5632K(user),1536K(web),3M(custom),256K(logo),1280K(mtd)
ipaddr=192.168.1.109
netmask=255.255.255.0
gatewayip=192.168.1.1
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jul 27 2012 - 11:19:01)
servip=192.168.1.42
serverip=192.168.1.42
Environment size: 1210/262140 bytes
hisilicon # run up
miiphy_register: non unique device name '0:02'
MAC: 00-0B-3F-00-00-01
TFTP from server 192.168.1.42; our IP address is 192.168.1.109
Download Filename 'update.img'.
Download to address: 0x82000000
Downloading: #################################################
done
Bytes transferred = 13484416 (cdc180 hex)
16384 KiB hi_sfc at 0:0 is now current device
## Checking Image at 0x82000040 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 2998272 Bytes = 2.9 MiB
Load Address: 00b80000
Entry Point: 00e80000
Data CRC Checking ... OK
Programing start at: 0x00b80000
Programing end at: 0x00e80000
Erasing at 0xe80000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xe80000 -- 100% complete.
done.
## Checking Image at 0x822dc080 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 20480 Bytes = 20 KiB
Load Address: 00e80000
Entry Point: 00ec0000
Data CRC Checking ... OK
Programing start at: 0x00e80000
Programing end at: 0x00ec0000
Erasing at 0xec0000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xec0000 -- 100% complete.
done.
## Checking Image at 0x822e10c0 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 3854336 Bytes = 3.7 MiB
Load Address: 00080000
Entry Point: 00480000
Data CRC Checking ... OK
Programing start at: 0x00080000
Programing end at: 0x00480000
Erasing at 0x480000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0x480000 -- 100% complete.
done.
## Checking Image at 0x8268e100 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 5328896 Bytes = 5.1 MiB
Load Address: 00480000
Entry Point: 00a00000
Data CRC Checking ... OK
Programing start at: 0x00480000
Programing end at: 0x00a00000
Erasing at 0xa00000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xa00000 -- 100% complete.
done.
## Checking Image at 0x82ba3140 ...
Header CRC Checking ... OK
Image Name: linux
Image Type: ARM Linux Standalone Program (gzip compressed)
Data Size: 1282048 Bytes = 1.2 MiB
Load Address: 00a00000
Entry Point: 00b80000
Data CRC Checking ... OK
Programing start at: 0x00a00000
Programing end at: 0x00b80000
Erasing at 0xb80000 -- 100% complete.
done.
Erased sectors.
Saving Image to Flash ...
Writing at 0xb80000 -- 100% complete.
done.
hisilicon # reset
resetting ...
This did not change anything. It still boots to the fuzzy color bar screen and then reboots again after 4-5 minutes as before.
I even hooked up an oscilloscope to the composite video output to see what the signal looks like..
The blue trace shows a proper composite video from one of the cameras. The yellow trace shows the composite video from the DVR composite video out terminal. As you can see it’s pretty bad and looks like it’s somehow corrupt. (It is the same from the VGA and HDMI outputs).
I’m just wondering if something more bad has happened here to the Hi3520 chip itself, or if the U-boot loader is somehow corrupt. As I don’t have that I can’t try to replace it.
Some pictures of the board.
[url=https://obrazki.elektroda.pl/4988190200_1594718954.jpg]
Any ideas welcome..
Rgds,
Simmi
