Arm Virtual Hardware in CI/CD workflows

This example shows how to use 3rd party hardware AVH to automatically test and deploy applications using GitHub Actions. On each commit and pull request a test job is started using a virtual STM32U5 IoT Discovery Kit, which confirms the firmware is functional. Another GHA job is available to deploy the firmware to real hardware using Amazon AWS IoT firmware update service.

GitHub Action workflows

Both flows build the application using our experimental cloud build service. It's not publicly available yet, but if you're trying to reproduce this setup you can simply use GitHub Action to build the code. Stay tuned for more information about our build service. In the meantime you can have a look at Keil Studio Cloud a modern embedded IDE in the cloud.

Test flow

Test flow runs on pull requests and direct code pushes to main branch. It builds the AWS OTA example application, creates an AWS IoT Thing and runs the application using AVH service on a virtual STM32U5 Discovery kit.

Currently we are only checking if the virtual board boots correctly and whether the firmware version matches the source code, but it would be trivial to extend the checks to confirm successful cloud connection.

Deploy flow

Deploy flow is triggered manually by the user. It builds the AWS OTA example application and starts an AWS IoT update job. It requires a pre-configured and connected IoT Thing that will be target of the update job.

Currently this flow ends when the update job is created, it doesn't wait to validate the firmware update result, but it should be relatively easy to add such a check.

Arm TrustZone for Cortex-M - Applications

Arm TrustZone for Cortex-M enables System-Wide Security for IoT Devices. The technology reduces the potential for attack by isolating the critical security firmware, assets and private information from the rest of the application.

This repository contains example applications that leverage this technology. The architecture of the application is shown in the diagram below.

Applications Parts:

• AWS Demos - For the CI/CD flow example only the OTA demo is used
• Secure second stage bootloader (BL2): Prebuilt BL2
• Trusted Firmware (TF-M): Prebuilt TF-M

Prerequisites

• Access to 3rd party hardware AVH service
• AWS account with IAM user access
• GitHub repository with Actions enabled
• Keil Studio Cloud account and a corresponding access token
• STM32U5 IoT Discovery Kit hardware

Set-up

GitHub

Enable following GitHub actions workflows in the repository: .github/workflows.

You'll need to set following repository action secrets:

Prerequisites

• KSC_ACCESS_TOKEN - Access token for Keil Studio Cloud
• GIT_ACCESS_TOKEN - Access token for GitHub with repository access rights (your GitHub account needs to have access to Arm-Debug/solar-build-and-run which currently is private)
• AVH_ACCESS_TOKEN - Access token for AVH 3rd party hardware service
• AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY - AWS IAM user credentials

Created during the setup

• AVH_MQTT_ENDPOINT - A MQTT endpoint address, you can find it in your AWS IoT Core settings
• AVH_OTA_KEY - AWS OTA Singer public key
• OTA_SIGNING_PROFILE - Signing profile name
• OTA_S3_BUCKET - AWS S3 bucket name used for firmware storage during OTA
• OTA_TARGET - AWS IoT Thing ARN of your device
• OTA_ROLE_ARN - ARN of the AWS OTA service role
• OTA_POLICY - Name of OTA policy attached to certificate

Arm Virtual Hardware

Set AVH_ACCESS_TOKEN GitHub secret to the access token for AVH 3rd party hardware service. You can request access to closed beta here

No extra setup is needed, the test flow automatically takes care of creating virtual environment, flashing the firmware, running the test and cleaning up.

AWS

For the test workflow

• Set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY GitHub secrets to your IAM user credentials. You can create and manage IAM users in IAM service in AWS Console.
• Set the AVH_MQTT_ENDPOINT GitHub Secret to your AWS IoT Core MQTT endpoint address. You can determine the endpoint for your AWS account with the aws iot describe-endpoint command (if you have the AWS client installed and configured) or you can find it on the Settings page of the AWS IoT Core console.
• Create AWS IoT code signing profile and key pair. Set the signing profile name in OTA_SIGNING_PROFILE and public key in AVH_OTA_KEY GitHub secrets. Follow the steps in here to create and setup the keys. The secret has to be set as:

-----BEGIN PUBLIC KEY-----
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
-----END PUBLIC KEY-----

• Create a OTA policy for device certificate and set OTA_POLICY GitHub secret to the policy name. You can create the policy using AWS Web console or use the following command (changing the name to a desired one). Note: This policy allows very broad access to AWS IoT MQTT APIs. Use a more restrictive policy for any production environments.

aws iot create-policy \
    --policy-name="XXXXXXXXXXX" \
    --policy-document="{ \"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": \"iot:*\", \"Resource\": \"*\"}]}"

For the deploy workflow

• Start with the test workflow setup.
• Follow these steps to create the S3 bucket and setup access to it. Set OTA_S3_BUCKET to point to your S3 bucket and OTA_ROLE_ARN to OTA service role ARN (which looks like this arn:aws:iam::your_account_id:role/your_role_name).
• Continue to the Hardware setup.

Hardware

You'll need to setup a STM32U5 Discovery kit (B-U585I-IOT02A) hardware board so that it can connect to AWS IoT service and wait for update.

Provision the STM32U5 hardware board following these instructions. Set OTA_TARGET to ARN of the AWS IoT Thing you created during the provisioning of the board. Thing ARN has the following format arn:aws:iot:<region>:<account id>:thing/<thing name>, you can copy it from your Thing page in AWS Console.