7. Software update and recovery
7.1 Restore firmware settings
CCSettingsConsole can be used to reset the firmware settings to the factory default settings, if needed. Use the following command:
$ sudo ccsettingsconsole --advanced --factory
7.2 Updating firmware components
The advanced category of CCSettingsConsole is also used for loading new SS firmware and Display MCU firmware into the device.
It is also possible to verify that a given file matches the current firmware; with “–verify” a mismatch can be detected and reported. The firmware is not written during verify.
After each program or verify action, the device must be shut down. Press the shutdown button or other alternatives to shut down the OS after a firmware update.
The preferred method to perform the update is by using the CCSettingsConsole application. It is also possible to use the API directly from your own program using the CCAux API functions.
Warning: Errors during an update can set the module in an unrecoverable state. In such case, the module must be shipped to factory for repair, or have internal parts replaced through service interfaces. Make sure that you carefully choose the correct files for updating and follow the instructions from the tools, including powering off the device when prompted.
To update the firmware, copy the firmware file to a USB stick and connect it to the device. Reboot the device to the rescue system using the following command:
$ sudo reboot-rescue.sh
Login and issue the following commands to update:
7.2.1 SS firmware
$ sudo ccsettingsconsole --advanced --update=SS --filepath=<full-path-to-file>
If only firmware verification is wanted, use the following command instead:
$ sudo ccsettingsconsole --advanced --verify=SS --filepath=<full-path-to-file>
7.2.2 Display MCU firmware
Login and issue the following command to update the Display MCU:
$ sudo ccsettingsconsole --advanced --update=Display --filepath=<full-path-to-file>
If only firmware verification is wanted, use the following command instead:
$ sudo ccsettingsconsole --advanced --verify=Display --filepath=<full-path-to-file>
VS |
VI |
X900 |
X1200 |
V700 |
V1x00 |
Vx10 |
Yukon |
|---|---|---|---|---|---|---|---|
No |
No |
No |
No |
No |
Yes |
Yes |
Yes |
7.3 Factory reset of operating system
As explained, user data is stored on the rw-partiton that is overlayed on to the ro-root filesystem. It is possible to remove all the settings and files under that location, and have the device generate the default contents back upon a restart of the device. If you have modified the ro-filesystem, the files there will not be changed back.
Note: This can potentially also remove some applications and files that are part of the factory installation by CrossControl and delivered to you as such (For example LinX and CODESYS installations). If that is the case, please avoid this method of user data and file removal unless specific knowledge about this has been gathered.
The restoration is done via the command
$ sudo reboot-rescue.sh clear
which will reboot the device twice and reformat the entire user partition, as well as restoring the default files.
7.4 Updating the operating system
The CC Linux system on the device can be updated by an administration user. The update process can also be used for resetting the device to the default state.
Warning: Errors during an update can set the module in an unrecoverable state. In such case, the module must then be shipped to our factory for repair, or have internal parts replaced through service partners.
New versions of the operating system for the device are released as a set of binary format image files as well as additional configuration files and scripts required for update.
The complete system consists of five main parts in the eMMC/CFast: main kernel, rescue system kernel, main root file system, rescue system root file system, and user defined area. Additionally, there is boot loader software in the first part of the eMMC/CFast. Normally, software updates concern only the main kernel and root file system, though they may occasionally concern the other partitions.
Note: Always update the main system first, and the rescue system second. Alternatively, in order to update both systems at once, CrossControl recommends using the uuu approach described in CC Linux – update using uuu (not available for X900).
File names will differ depending on which parts are being updated. Additionally, file names will vary depending on your device model. In the below sections, CCpilot VS 12” will be used as an example.
7.4.1 Updating main system
Warning: An update erases and replaces the old root (ro) file system completely! This should not affect contents of the rw-partition. However, creating a backup of important files is still advised.
This method requires the device to have a working rescue system.
Warning: All excess processes that might interfere or interrupt the update process should be terminated.
- Follow these steps to update the main system:
1 Copy the main system update images to /usr/local/fw_update. The folder name is important, otherwise, the update will not start. Copy method choice is free; scp, USB memory or NFS mount can all be used.
ccpilot-vs_kernel.bin
ccpilot-vs_rootfs.bin
ccpilot-vs_u-boot.bin
ccpilot-vs.md5sum
fullup.sh
2 Reboot the device to rescue system:
$ sudo reboot-rescue.sh
3 Wait for the update to automatically start and reboot to main system when complete.
Example output on the device on-screen terminal:
Please wait: booting… Recovery system vs/dev/tty1 vs login: ===== CrossControl: Device Update ===== AF System Hardware: ccpilot-vs Now running on : BACKUP system Requested action: NORMAL system update Checking MD5: ccpilot-vs_kernel.bin: ccpilot_kernel.bin= OK OK Checking MD5: ccpilot-vs_rootfs.bin: ccpilot_rootfs.bin= OK OK === Listing: Actions: === Updating: kernel Updating: root-fs ALL FILES ON ROOT-FS WILL BE LOST Files on /usr/local and /media cf unaffected Verification: Skipped, continuing.. === Now doing: Requested actions === * DO NOT BREAK PROCESS OR SHUTDOWN THE UNIT before update is complete. * Copying new kernel image.. Copying new root-fs image..
7.4.2 Updating rescue system
Note: Updating only the rescue system does not affect the main system. When the rescue system requires an update, it is updated from the main system side. If the main side is non-operational; update the main side first and continue to this step.
Warning: All excess processes that might interfere or interrupt the update process should be terminated.
- Follow these steps to update the rescue system:
1 Copy the backup system update images to /usr/local/folder (folder name has no importance when updating rescue system). Copy method choice is free; scp, USB memory or NFS mount can all be used.
ccpilot-vs_rescue_kernel.bin
ccpilot-vs_rescue_rootfs.bin
ccpilot-vs_rescue.md5sum
fullup.sh
2 Access the Linux console, either over SSH connection from another host, or using a serial console terminal access to Linux.
Warning: Avoid using the SSH method, if your Ethernet network is susceptible to connection breaks, as the image write can get interrupted.
3 Update the rescue system from within the update folder:
/usr/local/folder$ sudo ./fullup.sh -s
Note the -s flag, without it the normal side is updated!
Example output on terminal:
===== CrossControl: Device Update ===== AF
System Hardware: ccpilot-vs
Now running on : normal side
Requested action: BACKUP system update
Checking MD5: ccpilot-vs_rescue_kernel.bin: ccpilot-vs_rescue_kernel.bin: OK
OK
Checking MD5: ccpilot-vs_rescue_rootfs.bin: ccpilot-vs_rescue_rootfs.bin: OK
OK
=== Listing: Actions: ===
Updating: kernel
Updating: root-fs ALL FILES ON ROOT-FS WILL BE LOST
Files on /usr/local and /media/cf unaffected
=== Verification: ARE YOU SURE ? ===
- If yes, press Enter to continue.
- IF NOT, press CTRL+C now to cancel update.
This is your last chance to do cancel!
** IF YOU CONTINUE, DO NOT INTERRUPT THE PROCESS UNTIL READY **
The process is pausing here, waiting for ‘Enter’ or cancellation.
=== Now doing: Requested actions ===
* DO NOT BREAK PROCESS OR SHUTDOWN THE UNIT before update is complete. *
Copying new kernel image..
Copying new root-fs image..
131072+0 records in
131072+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 14.0712 s, 4.8 MB/s
Completed. Rebooting..
Broadcast message from root@vs (pts/0) (Thu Nov 9 15:02:02 2017):
The system is going down for reboot NOW!
End of all actions, H o l d o n t i g h t
7.5 Update automation
This chapter shows how to use the auto started script cc-auto.sh to automate the update. In these examples the update process is automated to start upon insertion of a USB memory stick.
These examples can be modified in order to use the cc-auto.sh script to update the system remotely over SSH.
7.5.1 Automated update of main system using USB memory
The directory name fw_update must be kept for the update to work properly.
1 Create a directory fw_update in the root directory of the USB memory and copy the update images and fullup.sh script there.
2 Add a script cc-auto.sh to the root directory of the USB memory. Note that the script name must be correct for the update to start. An example of the script contents:
echo "Starting release update"
#
# To prevent accidental updates, use this stamp file for it.
# Remove file so if user inserts USB - stick second time the
# update will be started regardless.
#
if [ -e $1/update-done ] ; then
rm $1/update-done
exit 0
fi
touch $1/update-done
cd $1 && cp -a fw_update /opt
reboot-rescue.sh
3 Insert the USB stick to the device and the update script will start automatically, without requiring any user interaction to complete.
7.5.2 Automated update of rescue system using USB memory
For the rescue system update, the directory name can be chosen freely, but must match the directory in the created script.
1 Create a directory foldername in the root directory of the USB memory and copy the update images and fullup.sh script there
2 Add a script cc-auto.sh to the root directory of the USB memory. Note that the script name must be correct in order for the update to start. An example of the script contents:
echo "Starting rescue update"
#
# To prevent accidental updates, use this stamp file for it.
# Remove file so if user inserts USB - stick second time the
# update will be started regardless.
#
if [ -e $1/update-done ] ; then
rm $1/update-done
exit 0
fi
touch $1/update-done
cd $1/foldername && ./fullup.sh -f -s
3 Insert the USB stick to the device and the update script will start automatically, without requiring any user interaction to complete.