Updating an application
There are two ways to update an MBL application:
MBL provides a wrapper around the Device Management firmware update service and manifest tool. This means you can use the same file type (
tar, containing the
ipk) for both processes, allowing you to pick the update method independently of your packaging process. It also means that any file that MBL CLI manages to update, the manifest tool should also be able to update, so you can use MBL CLI as a proxy for testing on Device Management.
First, you need to prepare the update payload for the application.
Prepare the update payload
You need a build environment of MBL because this contains the scripts needed to create the update payload for applications. You can either reuse a full build of MBL or create a new environment just for the application update.
If you are going to create a new build environment - set up the
build-mbltools, and create an outputdir directory:
git clone email@example.com:ARMmbed/mbl-tools.git --branch mbl-os-0.9 mkdir /path/to/artifacts
Copy the application
ipkfile into the build outputdir directory:
cp /path/to/application/package.ipk /path/to/artifacts
Enter the mbl-tools interactive mode for the build. For example, for PICO-PI with IMX7D:
./mbl-tools/build-mbl/run-me.sh --builddir /path/to/build --outputdir /path/to/artifacts -- --machine imx7d-pico-mbl --branch mbl-os-0.9 interactive
Please see the other build examples.
create-update-payloadtool to create a tar file containing the application package.
These are the arguments that the tool accepts:
Name Value Information
APPLICATION_PATH Specifies the application package name and path to add to the payload.
FILE_PATH File name and path for the payload tar file to be created.
Note: The create-update-payload tool needs the bitbake environment to work. When using the interactive mode, only the builddir (
/path/to/build) or outputdir (
/path/to/artifacts) directories are available in the build environment, so you must use them as the paths for the APPLICATION_PATH and FILE_PATH arguments.
For example, to create an update payload file
user01@dev-machine:~$ create-update-payload --app /path/to/artifacts/package.ipk --output-tar-path /path/to/artifacts/payload-boot2.tar
Using MBL CLI to update
You can find installation and use instructions for MBL CLI in the application development section.
To install or update an application:
Transfer an application update tar file to the
/scratchpartition on the device:
$ mbl-cli [-a address] put <application update payload> <destination on device under the /scratch partition>
For example, if
payload.taris the payload name for an application update, and 169.254.111.222 is a link-local IPv4 address on the device:
$ mbl-cli -a 169.254.111.222 put payload.tar /scratch
You can use
mbl-cli selectto choose your device, instead of using the
Use the MBL CLI
shellcommand to get shell access on the device:
$ mbl-cli [-a address] shell
$ mbl-cli -a 169.254.111.222 shell
$ mbl-firmware-update-manager /absolute/path/to/payload.tar
The application is installed.
Note: To keep the update package after a successful update, use the optional argument
The application starts automatically, without a device reboot.
Using the manifest tool to update
Find the device ID in the
mbl-cloud-clientlog file at
/var/log/mbl-cloud-client.log, using the following command on the device's console:
root@mbed-linux-os-1234:~# grep -i 'device id' /var/log/mbl-cloud-client.log
If you only have one registered device, or if each device has been assigned a descriptive name in Portal, you can go to Device Management Portal > Device Directory to find the device ID.
Change the current working directory to the directory where the manifest tool was initialized. You initialized the manifest tool when you created the
Run the following command:
user01@dev-machine:manifests$ manifest-tool update device --device-id <device-id> --payload <payload-file> --api-key <api-key>
<device-id>is the device ID.
<payload-file>is the update payload (
<api-key>is the Pelion API key you generated as a prerequisite.
The system does not reboot after an application update.
Identifying the running applications
You can use
runc list to list all the active applications and their status.
The first steps of an application update include stopping and terminating a running instance of the application (if one exists).
If you perform
runc listwhen the application is stopped, you will see:
root@mbed-linux-os-1234:/home/app# runc list ID PID STATUS BUNDLE CREATED OWNER user-sample-app-package 0 stopped /home/app/user-sample-app-package/0 2018-12-07T08:23:36.742467741Z root
If you perform
runc listwhen the application is terminated, the application will not appear on the list.
When the application is installed or updated, it starts automatically.
If you perform
runc listfor a running application, you will see:
root@mbed-linux-os-1234:/home/app# runc list ID PID STATUS BUNDLE CREATED OWNER user-sample-app-package 3654 running /home/app/user-sample-app-package/0 2018-12-07T08:23:36.742467741Z root
Note: The Hello World application runs for about 20 seconds. When it finishes, it once again appears as stopped.
You can monitor the update payload download progress by tailing the
root@mbed-linux-os-1234:~# tail -f /var/log/mbl-cloud-client.log
You can monitor the update payload installation progress by tailing:
/var/log/arm_update_activate.log: for messages about the overall progress of the installation, and messages specific to
rootfs, kernel or boot component updates.
/var/log/mbl-app-update-manager-daemon.log: for messages about application updates.