Guides

It is often advantageous to be able to test software builds on a target system by booting them over a network, typically booting from artifacts shared via TFTP or NFS. It may not always be viable or sensible to arrange for such resources to be exposed on a shared network. The Apertis SDK can be utilised to provide such services and be configured to share them with a target board with minimal extra infrastructure required. [Read More]

The Apertis distribution provides a number of routes for managing updates to deployed devices. This document discusses utilising hawkBit, a domain independent back-end framework for rolling out software updates. Design The hawkBit data model defines a hierarchy of software that starts with a distribution, which can have (sub-)modules and these may have multiple artifacts. The hawkBit Data Model concept can be found here. For Apertis, we want the device agent to be as simple as possible. [Read More]

This document describes how to execute automated LAVA tests controlling resources external to the DUT across a network implementing a LAVA parallel pipeline job. Test Cases The approach proposed in this document will help to address test cases like: Executing a test in the DUT where certain power states are simulated (for example a power loss) during specific test actions using a programmable PSU external to the DUT. [Read More]

The Apertis Toolchain provides a build environment to build Apertis for a foreign architecture from an operating system that is not Apertis. The toolchain is intended for cross-compilation, targeting architectures that don’t match the CPU architecture of the build host (for instance, building ARM64 binaries from a Intel-based host). Currently Apertis provides toolchain for two architectures : 32 bits ARM (armhf) 64 bits ARM (AArch64) It is meant to be used by teams that want to keep their development tools such as their preferred editor. [Read More]

The guide will explain the process of modifying and packaging a custom kernel to be used within Apertis. Apertis is provided with a number of pre-built kernels, however it is likely that these may not suit your purpose: The kernels don’t have the support for your SoC enabled You wish to enable some specific drivers that aren’t enabled in the standard build You have out-of-tree board support or drivers that you need to add You wish to incorporate more drivers directly into the kernel rather than loading them as modules In order to meet your project goals, it may be necessary to create a project specific kernel package for use in your project. [Read More]

With the 18.03 release of Apertis, a new set of images have appeared. Apertis is now delivered in two variants: apt images and OSTree images. OSTree provides Apertis with an atomic update solution, which is able to work in containers and flash-specific file systems like UBIFS. OSTree uses an efficient mechanism to package updates, thus resulting in small downloads. The standard images are a debian derivative. The OSTree images are prefixed apertis_ostree. [Read More]

Apertis provides tools to aid with the development of applications using the Canterbury application framework, which help with the building of applications targeting a hardware platform; the installation of development versions of the application to the target device and debugging of the application. These tools are pre-installed in the Apertis SDK. The SDK images shipped by Apertis are meant to be run in VirtualBox. They provide a common, reproducible environment to build both platform packages and application-bundles for Apertis. [Read More]

This document aims to explain how to develop on devices running the reference Apertis images. Which image to choose The APT-based images like apertis_18.09-minimal-amd64-uefi_18.09.0.img.gz and apertis_18.09-target-amd64-uefi_18.09.0.img.gz are the ones providing all the flexibility needed for development, letting developers install and remove packages, and otherwise customize the rootfs. The OSTree-based images are tailored as a reference for product deployments: their constraints make installing and removing packages impossible, and the more care must be taken to get write access to the rootfs managed by OSTree. [Read More]

Apertis is moving to a WebView widget and browser based on WebKit2GTK+. The purpose of this migration is to take advantage of the new WebKit2 multi-process architecture, adopt a port that is upstream and that is based on a more future-proof toolkit. Packages for testing and using the API The engine is available in Apertis on the webkit2gtk source package. To test it on a development or SDK image, install the webkit2gtk-testing package and run /usr/bin/GtkClutterLauncher. [Read More]

Git is used for version control for all Apertis projects. This page assumes good working knowledge of git; some introductory material is available here, and a git cheatsheet is here. Summary Make atomic, revertable commits. (Guidelines for making commits) Include full reasoning in commit messages, plus links to relevant bug reports or specifications. (Guidelines for making commits) Keep large changes, such as renames, in separate commits. (Guidelines for making commits) Merge changes from feature branches by rebasing. [Read More]