Update Procedure

Updating XM devices was covered in a separate article, but here I will share additional information that may be useful when recovering when something went wrong (turned off the light during the update process, incompatible firmware was flooded, or there was another failure).

The device can be updated in two ways: the device downloads the firmware on its own and updates itself, or the user finds the latest version, downloads it via the Web interface or CMS, and then the update proceeds according to the same scenario.
To minimize problems, the firmware contains a special InstallDesc descriptor file that contains the “Hardware” platform identifier, by which the device checks whether the downloaded firmware suits it by comparing its contents with the ProductDefinition file inside the firmware.
There is also a separate “Vendor” field, which usually contains “General”.
The “Vendor” field is introduced for hardware manufacturers who, in addition to the assembly itself, also add additional functions, special operation parameters, or simply change the factory memory allocation. Thus, the simplest copyright protection is carried out, as well as from uploading incompatible firmware.
If both of these fields match, the update procedure is started, otherwise an error message is issued.
The firmware is a renamed .zip archive that contains several .img files – dump sections with a special header of 64 bytes, as well as the already mentioned InstallDesc descriptor file. An example of a typical firmware content:
InstallDesc
u-boot.bin.img
u-boot.env.img
romfs-x.cramfs.img
user-x.cramfs.img
web-x.cramfs.img
custom-x.cramfs.img
DVRs also have a section with a logologo-x.cramfs.img
The update is carried out in sections, so if the update procedure is interrupted, only one section is damaged.
u-boot.bin is the u-boot bootloader itself, is flashed first and almost always stays intact due to its small size. In addition to the startup procedure, u-boot also contains procedures for displaying the logo on the screen (for registrars), as well as – most importantly – scripts for restoring firmware modules.
That is why we see a “mattress” or the manufacturer's logo on the screen of a failed device.
If the logo does not disappear, and the device does not enter the operating mode, then one of the firmware blocks is damaged, but the bootloader itself is intact, and the device can be restored relatively simply and inexpensively.

With a damaged bootloader, we get a complete “brick”, the method described here is no longer applicable, we will have to restore it on the programmer, we will not consider it in this article.

 

Connect UART

Communication with the bootloader is performed from the console by commands that are given through a special debugging interface – UART. It is more convenient to use Putty (Kitty) as a console (terminal), although even the hyperterminal built into windows will do.
To be able to send commands from the terminal, we need a USB-UART converter.
The most common is a converter based on the Prolific PL-2303HX chip . It will be enough to restore one device, but if you are a professional repairer, it is better to purchase a converter based on the FTDI FT232R chip, it is more reliable and not so prone to line noise.

By connecting the UART converter, we will get an additional serial COM port in the system, the number of which must be found in the device manager. We indicate this number in the terminal program, and also set other port parameters: speed 115200, no parity, stop. bit 1.

To connect, we connect the negative (“ground”) wire of the device to the common (GND) wire of the converter, connect the RX of the device to the TX of the converter, and RX, respectively, to TX.

We turn on the device and observe the following picture:

This is the download log. For a short moment, the prompt Press Ctrl + C to stop autoboot will flash on the screen. We need to catch this moment and press the key combination Ctrl + C, after which we get into the bootloader command interface.
We give the command printenv, this will display the environment variables of the bootloader and tell us additional information about the subject.

We are currently interested in two parameters:
ipaddr=192.168.1.10– The IP address of the device
serverip=192.168.1.107– The IP address of our computer,
they can be changed with a command setenvor substituted for the computer with the IP address from serverip for the recovery time.

 

TFTP server

After playing around with the commands, you'll probably want to go ahead and restore the device.
To do this, we need another program – a TFTP server, I recommend tftpd32.

Install it and configure according to the picture.

Backup is our everything

Now we connect our long-suffering camera / recorder with a network cable to the same network as the computer with the terminal program and the TFTP server, start the tftp server

Before experimenting, be sure to make a backup copy (dump). To do this, you need to find out the size of the flash memory of the device. The team will help us with this sf probe 0.

xmtech # sf probe 0
8192 KiB hi_fmc at 0:0 is now current device

This shows that the size of the flash is 8192kb, which is 0x800000h in hexadecimal. (For a 16384kb flash, this number will be 0x1000000h).

You will also need to find out the address of available RAM in order to copy the dump to memory or load blocks there. Issue the printenv command and look at the variable bootcmd=. At the very end, there is always a bootm command and a memory address. In our case bootm 0x82000000(there are also 0x42000000)

Then the backup commands will be:

setenv serverip 192.168.1.101	setting the IP address of our computer (not necessary if you have already given it an IP from serverip)
setenv ipaddr 192.168.1.10	changing the IP address of the device (not necessary if it is on the same subnet as the computer)
sf probe 0	Accessing SPI Flash
sf read 0x82000000 0x0 0x800000	Copying flash contents to RAM
tftp 0x82000000 dump.bin 0x800000	Dump transfer to tftp server

 

After that, the dump.bin file containing the full backup will appear in the tftp folder of the server.

 

Recovery

Now we need a firmware file for our device. I hope you wrote down the device number from the Info window when the device was still working? If not, you can choose the appropriate firmware by looking at the photo of the device, writing a comment on the article or writing to our channel in Telegrem.
Download the firmware, open it with an archiver and extract all the files to the server's tftp folder (I have r:\tftp).

Now there is not much left, we give the following commands in the console:
run dc
run du
run dr
run dw
Then we reboot with the command reset.

This usually allows you to restore functionality in case of damage to one of the modules. It may also be necessary to erase all settings (see next paragraph)
If files are not loaded from the tftp server (cyclic attempts in the console), then most likely the Windows firewall is interfering – disable it or add tftpd32 to the exceptions.

 

password reset

There are situations when the administrator password is lost, but you need to access the device in order to change its settings. In this situation, a USB-UART converter will also help, with the only difference being that in this case a tftp server is not required.
We repeat the same steps from the “Connecting the UART” section, including the printenv command.
We carefully study its output, paying attention to the contents of the bootargs variable.
In our example, this will be the output from the camera 00018510
bootargs=mem=39M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:320K(boot),3520K(romfs),2560K(user),1152K(web),320K(custom),320K(mtd)
320K(boot),3520K(romfs),2560K(user),1152K(web),320K(custom),320K(mtd)
We start the Windows calculator, put it in programmer mode and start counting. To do this, switch the calculator to dec mode, convert megabytes and kilobytes to bytes (we multiply kilobytes by 1024, and megabytes by 1048576), add up the resulting values ​​and switch the calculator to hex mode.
We get the following labels:

mtd partition sizes
320K(boot) 327680 50000h
3520K(romfs) 3604480 370000h
2560K(user) 2621440 280000h
1152K(web) 1179648 120000h
320K(custom) 327680 50000h
320K(mtd) 327680 50000h

Addresses mtd sections
0x000000-0x050000 : "boot"
0x050000-0x3c0000 : "romfs"
0x3c0000-0x640000 : "user"
0x640000-0x760000 : "web"
0x760000-0x7b0000 : "custom"
0x7b0000-0x800000 : "mtd"

From the table, we are interested in the last section – mtd. As you can see from the bootargs, its size is 320kb, which is 50000h in hex, and the start address is 0x7b0000.
It stores device settings, and, most importantly, user passwords. If you delete it, the system will recreate this partition again with default settings, and, accordingly, with empty passwords.

give the following commands:
sf probe 0
sf erase 0x7b0000 0x50000
reset

In the new firmware, write protection of the flash drive appeared, so immediately after sf probe 0you need to give another command sf lock 0to remove the protection.

An attentive reader may note that the mtd partition is the last one, and to calculate it, it is enough to subtract the size of mtd 0x50000 from the size of the flash drive 0x800000, we get the same 0x7b0000. It's even easier if we're only interested in one section.

I want to remind you once again that this is just an example, you will have other numbers. Using incorrect values ​​will definitely damage the device!

 

Too difficult!

Not every user will be able to install and configure a tftp server, not to mention calculating sizes and offsets to reset the settings, so we have developed a convenient program with a friendly interface that simplifies the user's actions. The program allows you to perform four basic operations:
1. Create a backup copy (dump) of the device
2. Restore the camera / recorder from the created dump
3. Restore the device using the firmware file
4. Erase settings / reset the password
These features are provided free of charge. The user has only one request – for new devices, if possible, take a photo of the device and send them along with the merged dump to one of the site's contacts. Donations to the author of the program are welcome.

The XMDeviceExplorer program can be downloaded here .