R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.

@alastairstevenson ,
I took the CN version of the .dav and renamed it to digicap.dav, and used the Batch Configuration Tool to load it onto the camera. The next step in the process was step 7. which was to power down the camera and then power it back up. I did this, and now the camera powers up, but the IR LEDs stay lit, and the device doesn't have IP address 192.0.0.64, or 192.168.1.64, or a DHCP address off my network. I have wiresharked the interface of the camera on bootup, and there isn't any network traffic coming out of it. I'm thinking it is bricked for good?
 
glockgabe said:
I have wiresharked the interface of the camera on bootup, and there isn't any network traffic coming out of it. I'm thinking it is bricked for good?
Click to expand...
It's unlikely to be bricked, and odd that you are not seeing any network traffic.
The bootloader should still be probing for the tftp updater on power up.

What does SADP show, if anything?
 
@alastairstevenson
I set up another test scenario to prove what you are telling me. I have my computer connected to a dumb switch, and the dumb switch connected to the IP Cam. I am using a wall wart to power the IP Cam, so we don't have to worry with PoE negotiation. I have the Hikvision TFTP Server running, and a simple Ping going to 192.0.0.64. Within 3 seconds of IP Cam power up, I get 2 ICMP replies, the Hikvision TFTP Server shows "Device[192.0.0.64] test tftpserver, and nothing else, and I have 2 captured packets in Wireshark showing the tftp handshake between UDP ports 9978 and 9979, and then all network traffic from the IP Cam goes dead. I have attached the packet capture and TFTP server screenshot for your SA. I couldn't attach a .pcap file, so download the .txt file and change it to .pcap and open in Wireshark. What else can I try? Thanks!

P.S. SADP/Batch Config Tool don't recognize the camera in this state.
 

Attachments

glockgabe said:
I have my computer connected to a dumb switch, and the dumb switch connected to the IP Cam. I am using a wall wart to power the IP Cam
Click to expand...
That's the optimum arrangement.

glockgabe said:
Within 3 seconds of IP Cam power up, I get 2 ICMP replies
Click to expand...
glockgabe said:
the Hikvision TFTP Server shows "Device[192.0.0.64] test tftpserver
Click to expand...
Fine so far.

glockgabe said:
I get 2 ICMP replies, the Hikvision TFTP Server shows "Device[192.0.0.64] test tftpserver, and nothing else, and I have 2 captured packets in Wireshark showing the tftp handshake between UDP ports 9978 and 9979, and then all network traffic from the IP Cam goes dead
Click to expand...
Certainly, the handshake starts normally, and the PC response shows that the firewall isn't blocking the inbound traffic.
But the camera doesn't react to the PC response.
Does the switch link detect LED stay on?

If you want to further investigate, at the expense of your time spent, why the camera isn't booting or behaving properly, you'd need to connect up the serial console.
 
  • Like
Reactions: VorlonFrog
@alastairstevenson
I dusted off my trusty USB-TTL serial cable and completely disassembled the camera since the serial interface is buried in the worst location. I have attached a screenshot of the output I get when I boot the camera.
 

Attachments

  • DS-2CD2032-I_TTLOutput.png
    DS-2CD2032-I_TTLOutput.png
    53.6 KB · Views: 22
glockgabe said:
I have attached a screenshot of the output I get when I boot the camera.
Click to expand...
Good job!
(But - easier for you and for us if you use the PuTTY 'copy all to clipboard' selection in the menu top left of the window.
Then you can paste into Notepadd or similar and edit / copy / paste as needed)

Your screenshot is the brickfixV2 running environment - it looks normal.
But what we don't see is what happens when the mini-system is entered.
If it fails to run that - you should get a root shell - it means that the modded brickfixV2 min-system isn't able to run.
That would also explain why the bootloader fails to start the min-system to download the firmware following the UDP packets handshake.

Suggestion :
Show what happens, if anything, when the min-system has been requested to start, hit ENTER a few times.
If the console just freezes there, a next step could be trying to reload the mini-system.
Do this as follows :

Power off the camera.
Have the brickfixV2 digicap.dav in the tftp folder, start the tftp updater with the PC IP address 192.0.0.128
In PuTTY, keep Control-U pressed, power on the camera.
That should interrupt the bootloader.
At the bootloader prompt, try the 'update' command and see if it does anything.
As this needs the min-system, it will probably fail.

Although in some ways this is a Catch-22 situation - ie the min-system isn't working, and it normally needs the min-system to do an update - there are alternate methods of writing the needed data to the flash.
But let's cross that bridge if / when we come to it.
 
@alastairstevenson
My bad, I didn't know you wanted the console text. Here it is from trying your suggestions:

U-Boot 1.3.4-30623 (Dec 6 2012 - 11:05:48)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|BIND err|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2016-05-23 16:23:55 CST)
starting pid 375, tty '': '/etc/init.d/rcS'
Starting udev: [ OK ]
UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:0x1, sec_iUpgSuccCnt:0x1
UBI device number 3, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
diagnose_way = 15, repair_way = 1, interval = 30
route: ioctl 0x890c failed: No such process
mount: mounting none on /proc/bus/usb failed: No such file or directory
/dav
map_size = 0x300000
nr_item = 3
addr_offset = 0x0 filename = orccode.bin
addr_offset = 0x200000 filename = orcme.bin
addr_offset = 0x2a0000 filename = default_binary.bin
mmap returns 0x40379000
loading ./orccode.bin...addr = 0x40379000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x40579000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x40619000, size = 0x40000
===============================
u_code version = 2016/4/6 3.0
===============================
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot


U-Boot 1.3.4-30623 (Dec 6 2012 - 11:05:48)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 2
HKVS # ?
Unknown command:?
HKVS # help
The following commands are supported:
boot help bios diag
mtest dump erase go
exec ping r8 r16
r32 reset saveenv printenv
setenv show usbdl w8
w16 w32 tftpboot bootm
readoob killb crc nandread
nandwrite ups upm format
update upf upa upr
upk updateb ubi bapi

Use 'help' to get help on a specific command
HKVS # update


I skip the first Ctrl+U prompt and let it boot. Then the camera does a system reboot, and when it prompts for Ctrl+U this time (should be min-system) I hit Ctrl+U and break into the prompt. I gave a "help" command so you could see what is available. I also tried running the "update" command and it just freezes and does nothing. Something to note is that when I break into Ctrl+U, I am able to get ICMP responses from 192.0.0.64 on the camera. When I issued the "update" command, the ICMP responses died. I also found that if I give the command "u" that the camera asks for XMODEM. I was considering doing an XMODEM recovery on it, but wanted you opinion before I screw something up bigger.

Also, my other 2 DS-2CD2032-I were successfully upgraded using your brickfixV2 steps today. They were on v5.1.6 when I began, and are now at 5.4.41. I think I just messed the first camera up with trying to give it EN firmware when it is a CH camera, and going up and down in versions broke something prior to trying the brickfixV2.
 
glockgabe said:
Also, my other 2 DS-2CD2032-I were successfully upgraded using your brickfixV2 steps today. They were on v5.1.6 when I began, and are now at 5.4.41
Click to expand...
That's good.

glockgabe said:
I think I just messed the first camera up with trying to give it EN firmware when it is a CH camera, and going up and down in versions broke something prior to trying the brickfixV2.
Click to expand...
It's not fatal to apply EN firmware to a CN camera - nor to go up and down the versions.
I don't think that broke it.

What I think has happened is that when the brickfixV2 has executed and dropped its payload - it's a modded form of the mini-system that doesn't have the downgrade block, and has the fixup scripts etc to handle the conversion and update - something has gone wrong with writing it to the flash.
Ages ago I had a camera from someone that had suffered the same problem - and I managed to recover it by some slightly fiddly methods.
I don't recall whether it was using the bootloader 'nandwrite' command with tftp, or whether it was getting a root shell at the normal boot and writing the flash from there.
What's needed is to attempt to re-write the mini-system flash partition, assuming that flash segment is still working OK.
 
alastairstevenson said:
I need to figure out the method and the commands. And find an R0 camera.
Click to expand...
I've hit a snag with this.

I have an R0 camera to experiment with (DS-2CD2432F-IW), but it has a much newer bootloader than yours, with some of the more 'useful' commands removed.
I'd thought it may be possible to use tftpboot to download the min-system image, and nandwrite to update it to the flash.
But nandwrite is missing, and I'm not sure what the command-line parameters are.
I suspect the block numbers will be in eraseblocks - 131072 bytes (128 KiB) - but I'm not sure, unwise to guess.
And there is also the possibility that the flash segment holding the min-system has a failure, so a re-write may not even work.

My next thought was to enable the web GUI on the currently running brickfixV2 firmware, so 'hacked to English' firmware could be loaded, by enabling a root shell and issuing the needed commands manually.
I tested this, and realised that in the brickfixV2 firmware I'd stripped out davinci (the main app) to give needed space for the payload, so that route isn't available.

And there isn't a tftp to give a mechanism for bringing in external files.
By any chance do you have a NAS on your LAN? With NFS shares?
 
alastairstevenson said:
I've hit a snag with this.
Click to expand...
Well crud. I appreciate you looking into this though.

I do have a NAS and it is sharing NFS right now. I also wanted to remind you that I found an XMODEM recovery prompt on the serial interface. Not sure if sending the brickfixV2 this way is an option?

Let me know what else you need. I can also send you the output of commands for everything if that helps you get an idea of what I might need to do for recovery. I realize this would be time consuming, but that doesn't bother me.

Thanks!
 
alastairstevenson said:
I'll work up some commands.
Click to expand...
OK, here we go, fingers crossed :

Here are the steps needed to use the brickfixV2 firmware environment with an NFS mount to refresh the min-system recovery flash partition when it is not available.

It's best to copy / paste the commands into PuTTY, from Notepad for example, one line at a time as opposed to a single multiple line block.

On the NAS NFS share, create a folder and drop the attached mtd8.zip into it, and unzip it.
In this example, the created folder is named DS-2CD2432F-IW
The NFS share name, and the IP addresses shown in the commands below should be altered as required for your LAN environment.

First of all, power on the camera, interrupt the bootloader with Control-U
It would be prudent to use the 'printenv' and 'help' commands to provide an 'as-is' record of initial status, and save the PuTTY scrollback.

These commands should boot the device into a root shell :
Code: 
setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0 init=/bin/sh
saveenv
reset

Wait about 10 seconds for the boot process to reach the shell, with a '#' prompt.

Then, at the root shell, bring the environment to a usable state, mount the NFS share, and write the min-system image to flash.

Code: 
/etc/init.d/rcS
ifconfig eth0 192.168.1.64 up
mount -t nfs -o nolock 192.168.1.201:/cctv1 /mnt/nfs00
cd /mnt/nfs00/DS-2CD2432F-IW
cat mtd8 > /dev/mtdblock8

Hopefully that will not result in an error message.
If it does - the flash memory has a failure.

Power cycle the camera, interrupt the bootloader with Control-U and put the bootargs variable back to the original value, and initiate a reboot.
With some luck - the refreshed min-system should be entered.
If so - this will be at the stage where brickfixV2 has been applied, and telnet access should be possible at 192.0.0.64

Code: 
setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
saveenv
reset

Good luck!
 

Attachments

@alastairstevenson great instructions! I followed them exactly as you wrote them wrt my own network environment. I didn't receive any error messages, but after I put the bootargs variable back and do the final reboot, the camera does not enter the min-system. I poked around on it and found that eth0 doesn't have 192.0.0.64 set as its IP, so I manually set that. I also found that /dav/fixup.sh exists, but TFTP doesn't exist on the camera, so the script fails to run. This is quite a headscratcher. I have attached the putty output from all the work I did on the camera. There is a point where the camera just reboots on its own, and then appears to boot into "mini system" but it just hangs at that point. The serial interface freezes, and there isn't any network traffic. I had to zip the .txt. file. For some reason the forum wasn't allowing me to attach it.
 

Attachments

glockgabe said:
I didn't receive any error messages, but after I put the bootargs variable back and do the final reboot, the camera does not enter the min-system.
Click to expand...
That's disappointing.
Despite refreshing it several times, the min-system doesn't activate.
I'm speculating that the flash segment isn't reading correctly.
One possible way to confirm that is to grab a copy and inspect it against the data that had been written.
At the point where the NFS share has been mounted, and the current directory has been changed to the one that had mtd8 in it - try the command :

cat /dev/mtd8ro > mtd8ro_extract

The resultant file will be larger than mtd8 as it was trimmed it back to save space, the first 4.9MB could be compared.
HxD works well for that.
 
glockgabe said:
it looks like the extracted file is missing information from 003A0000 thru 003C0000.
Click to expand...
Yes, there is a big chunk just filled with nulls.
That's probably why the min-system is freezing.

If you want to spend (even) more time on this - we could look at manually grafting the needed files in, as you've still got good access at the shell level.
 
You must log in or register to reply here.
Top Bottom