Elektroda.com
Elektroda.com
X

DVR boots into fuzzy color bars and then stops

240 3
  • Level 3  
    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..


    DVR boots into fuzzy color bars and then stops




    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:


    DVR boots into fuzzy color bars and then stops


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

    DVR boots into fuzzy color bars and then stops

    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.

    DVR boots into fuzzy color bars and then stops


    DVR boots into fuzzy color bars and then stops [url=https://obrazki.elektroda.pl/4988190200_1594718954.jpg]

    Any ideas welcome..
    Rgds,
    Simmi
  • Level 39  
    Provide markings or photos of the PCB in full resolution.
    In addition, accurate information from the barcode label, etc.
    Provide the exact firmware version.
  • Level 3  
    Hi, following are the photos of the main board..
    First the top side of the board:
    DVR boots into fuzzy color bars and then stops

    The bottom side of the board:
    DVR boots into fuzzy color bars and then stops

    The firmware file that is in the device is called: "General_General_MBD6504E_V4.02.R11.20130620.bin" I received that from ELEC the last time I requested an update for the firmware. The InstallDesc of the firmware file contains the following:
    {
    "UpgradeCommand" : [
    {
    "Command" : "Burn",
    "FileName" : "custom-x.cramfs.img"
    },
    {
    "Command" : "Burn",
    "FileName" : "romfs-x.cramfs.img"
    },
    {
    "Command" : "Burn",
    "FileName" : "user-x.cramfs.img"
    },
    {
    "Command" : "Burn",
    "FileName" : "web-x.cramfs.img"
    }
    ],
    "Hardware" : "MBD6504E",
    "Vendor" : "General"
    }

    I've use the U-boot loader to reload these images again, without any changes.
    Rgds,
    Simmi
  • Level 39  
    simmiv wrote:
    General_General_MBD6504E_V4.02.R11.20130620.bin

    Share this file as an attachment.

    There is an information sticker underneath the recorder housing? Or somewhere on the case?

    Added after 9 [minutes]:

    simmiv wrote:
    I took it out and put it in my Minipro TL866A programmer and read the image to save it as a xxx.bin file.

    Share this memory batch.

    Added after 7 [minutes]:

    simmiv wrote:
    A file called "General_General_MBD6504E_V4.02.R11.20130620.bin" and I recorded it to the EEPROM. After returning the EEPROM to the motherboard it was just dead


    But this is not a memory batch file but an UPDATE file. You install it from the recorder menu level or through the browser. Do not upload this through the Minipro TL866A programmer.