System Backup, Restore and Update

Discussion about writing software for VS1005 and the VSOS Operating System. Also posts about VS1005-related hardware design and device drivers should be posted here.
Post Reply
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

System Backup, Restore and Update

Post by Panu »

Dear Forum Members!

Here are two command line tools SYSBKUP and SYSRESTR to save and restore SPI flash (internal/external) to a file in another device such as SD card or USB memory stick (any VSOS device you have installed).

There are a lot of goodies, checks and neat properties (more info later) in these ones, such as that they work even with SPI flashes that have only 64 kilobyte sector erase capability.

If you have SD card as device D:

- To backup your system to SD card use sysbkup -a d:backup.bin

- To restore your system from SD card use sysrestr -a d:backup.bin

- To deploy a system, which the user can update, program it with the Update kernel from the next thread, which gives the ability to reprogram the running kernel and filesystem from an SD card or USB flash.

More info coming.
-Panu
Attachments
sysbkup-2015-12-08-16-36-RC1.zip
System backup utility, first version
(15.22 KiB) Downloaded 579 times
sysrestr-2015-12-08-16-36-RC1.zip
System restore utility, first version
(15.03 KiB) Downloaded 609 times
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

VSOS Safe Firmware Update Kernel for the External SPI Flash

Post by Panu »

Dear Members,

Here is a safe update kernel that can be used together with SYSBACKUP. It is a self-contained VSOS kernel that can be used to 1) load a running kernel or 2) update the running kernel and filesystem from an SD card or USB flash memory.

This kernel contains integrated drivers for SD card and USB flash. If you keep [S2] and [S4] pressed during boot, the kernel searches for UPDATE.BIN file from the SD card and the USB flash. If such a file is found, the kernel overwrites flash locations from 65536 to the end of the flash (2 megabytes) from the update file. The safe update kernel itself (at flash location 0) is never touched or rewritten.

If the buttons are not pressed or the update is successful, the kernel the proceeds to boot the updated kernel from address 65536.

How to get the running kernel into address 65536
Short instructions:
* Take your development system where your normal kernel is prommed with VSIDE and filesystem written with PC+USB.
* Connect SD card (or USB flash) to your development system
* Give command "SYSBKUP D:UPDATE.BIN" to generate UPDATE.BIN to the SD card.
* Take your client system e.g. the product which you ship to the customer.
* Program the Update Kernel to the shippable product's SPI flash using VSIDE and UART (or an external SPI flash gang programmer)
* Perform a Software Update on the shippable product to write the running kernel and filesystem to the SPI flash. The customer will use the same procedure to install a software update from you in the future.

The file UPDATE.BIN should be generated by running SYSBKUP in a device which has a working kernel and S: flash. If SUSBKUP is run with default settings, e.g. "SYSBKUP D:UPDATE.BIN", it duplicates the first 64 kilobytes of the flash into file locations 65536-131071. That will become the running kernel after the update.

IF your device ALREADY has both the safe update kernel and the running kernel, you can do a 1:1 backup using SYSBKUP -a. With the -a parameter, e.g. "SYSBKUP -a D:UPDATE.BIN" the flash is copied verbatim into the UPDATE.BIN file.
Attachments
arch-UpdateKernel325-2016-03-01-15-27-RC3.zip
Safe update kernel, VSIDE solution
(205 KiB) Downloaded 651 times
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

Safe Update Kernel for the Internal flash

Post by Panu »

Dear Members,

Here's an update kernel for the internal flash. The update kernel needed to be modified a little because the addressing is a little different for the internal flash due to the 4K rescue image. This was not taken into account, and the update kernel got stuck in an endless loop reloading itself.

Also, since booting from the internal flash cannot be prevented by external signals, there's a useful addition that helps in case the update kernel itself becomes deadlocked due to modifications that you do when you tweak the update kernel to match your product. In the beginning, the kernel checks if a character has been received from the UART during the initial bootup messages:

- if 'a' (decimal 97) is received, the kernel goes into a loop waiting for UART VS3EMU connection so that you can reprom the update kernel with VSIDE

- if 'b' (decimal 98) is received, it forces to start an update operation from file UPDATE.BIN from SD card or a compatible USB flash.

Otherwise the operation is the same, e.g. check for [S2], [S4] if the user wants an update - modify this condition to best suit your product.

-Panu
Attachments
UpdateKernel325Int2.zip
Update Kernel 3.25 i2 for Internal flash. VSIDE Solution.
(617.01 KiB) Downloaded 604 times
jedm@vpitech.com
Senior User
Posts: 50
Joined: Wed 2016-11-02 22:50

Re: System Backup, Restore and Update

Post by jedm@vpitech.com »

We're looking for an OTA update for the kernel for our product and this sounds sort of correct. We're at VSOS 3.55 but would like to include new kernels in our update mechanism. Does 3.55 include this or how would we go about replacing our kernel with update.bin? By this time we will have no serial port.

Jed.
Post Reply