HADK FAQ

Overview

v4.5.0.19 Sailfish OS Hardware Adaptation Development Kit Documentation

This page contains the HADK faq contents derived from: https://docs.sailfishos.org/Develop/HADK/SailfishOS-HardwareAdaptationDevelopmentKit-4.5.0.19.pdf

Preparations

1.1 Goal

By following this guide you can set up a Sailfish OS (or another Sailfish Core based) Linux system that will run
on an Android device, on top of an existing Android Hardware Adaptation kernel and drivers.
This consists of:
• Sailfish Core: the GNU/Linux userspace core
• Android Hardware Adaptation (HA/HAL), consisting of:
• Device-specific Android Kernel
• Android base which can be:
• LineageOS - https://wiki.lineageos.org
• AOSP - Android Open Source Project - https://source.android.com
• CAF - Code Aurora Forum - https://www.codeaurora.org
• Sony Open Devices program - https://developer.sony.com/develop/open-devices
• Vendor-specific Android base
• Binary device drivers taken from an Android base
• Hybris patches to the Android base
• The libhybris interface built against the binary drivers
• Middleware packages depending on hardware-specific plugins
• A Qt/Wayland QPA plugin utilizing the Android hwcomposer
• Sailfish OS components

Instructions

1.2 Development

1.2.1 Requirements

The development environment uses the Platform SDK, with:
• Build Tools consisting of cross-compilers (tooling) and an emulated rootfs for your device architecture (tar-
get), containing device-specific headers and libraries – will also be referred as build environment through-
out the document
• a HA build SDK (a minimal Ubuntu chroot required to build the Android sources

During the HA development you’ll typically have one window/terminal using the HA build SDK where you build
and work on Android code and another session using the Platform SDK where you build RPMs for the hardware
adaptation.

Setting up the Platform SDK, as well as the device-specific build environment and the Ubuntu HA build chroot is
described in Setting up the SDKs.

Commands and output from the Platform SDK session are indicated using PLATFORM_SDK $ at the top of the
code block, like this:

PLATFORM_SDK $

echo "run this command in the Platform SDK terminal"

How to enter PLATFORM_SDK $ is explained in Setup the Platform SDK.
Commands and output from the HA build session are indicated using HABUILD_SDK $ at the top of the code
block, like this:

HABUILD_SDK $

echo "run this command in the Ubuntu HA build SDK terminal"

How to enter HABUILD_SDK $ is explained in Entering Ubuntu Chroot.

1.2.2 The build area root directory

In this guide, we refer to the SDK directory hosting Platform SDK, Build Tools, and Ubuntu chroot with the
environment variable $PLATFORM_SDK_ROOT. You need around 10GB of space in total.

1.2.3 Build components

There are a number of components to build; the lower level and Android related components are built in the HA
build SDK; the rest are built in the Platform SDK.
• In the HA build SDK
• a kernel
• a hacking friendly initrd which supports various boot options
• hybris-boot.img and hybris-recovery.img (for booting and debugging)
• a minimal Android /system/ tree
• modified Android parts for compatibility with libhybris and Sailfish OS (e.g. Bionic libc,
logcat, init, . . . )
• In the Platform SDK
• RPM packages containing all the built binaries and extracted configs
• Hardware-specific middleware and plugins (e.g. Qt QPA plugins, PulseAudio)
For distribution, RPM packages are uploaded to a HA-specific repository. With this repository, full system images
using the mic utility. The mic utility is usually also run inside the Platform SDK

1.3 Deployment

The hybris-boot.img (containing both the kernel and our custom initrd) is flashed to the device, while the
Sailfish OS rootfs is placed in a subdirectory of the /data/ partition alongside an existing, unmodified Android
system.

The Sailfish OS rootfs is then used as a switchroot target with /data bind-mounted inside it for shared access to
any user data.

PREREQUISITES

2.1 Mobile Device

• An Android device officially supported by LineageOS 15.1 (Android 8), 16.0 (Android 9) and 17.1 (Android
10) at the time of writing 2021-02-12. CyanogenMod versions (that are Sailfish OS-compatible) 10.1.x,
11.0, 12.1, 13.0, 14.1 will require additional effort because CM has become obsolete. For more supported
Android versions also check this link
• Throughout this guide we shall use the term Android base, which will refer to the appropriate
base that you are porting on: LineageOS, AOSP, CAF etc
• We also support Sony Open Devices program, and published guidelines how to rebuild flashable
images for:
• Xperia X (Sony AOSP 6)
• Xperia XA2 (Sony AOSP 8)
• Xperia 10 (Sony AOSP 9)
• Xperia 10 II (Sony AOSP 10)
• Xperia 10 III (Sony AOSP 11)
• Starting with Sailfish OS 3.4.0, support for 64bit ARM SFOS userspace has been added
• Sailfish OS adaptations starting with CM 13.0 (Android 6) were constructed by running a mix of
64bit Linux Kernel and Android HAL, whilst Sailfish OS userspace was being run in the 32bit
mode. Such mixed mode is still supported, but we encourage porters to switch to full 64bit ports
(using Xperia 10 II as reference)
• See https://wiki.lineageos.org/devices for a list of compatible devices
• See https://wiki.merproject.org/wiki/Adaptations/libhybris for a status list of devices already
ported using HADK
• See https://wiki.merproject.org/wiki/Adaptations/libhybris/porters for a list of ports in early
stages, and their authors to contact on the IRC
• AOSP or CAF Android base support is also possible, but we choose LineageOS for a wider
range of devices. It will be up to the porter to patch an AOSP/CAF base with hybris patches.
Remaining differences in using it are minimal (e.g. using the lunch command instead of
breakfast)
• Means to do backup and restore of the device contents (e.g. SD card or USB cable to host computer), as
well as flash recovery images to the device

2.2 Build Machine

• A 64-bit x86 machine with a 64-bit Linux kernel
• Sailfish OS Platform SDK (installation explained later)
• At least 30 GiB of free disk space (20 GiB source download + more for building) for a complete Android
6 build; a minimal download and HADK build (only hardware adaptation-related components) requires
slightly less space. Newer Android base versions yield increasingly bigger size requirements.
• At least 4 GiB of RAM (the more the better)

PREPARING YOUR DEVICE

3.1 Backup and Verify Your Device

As mentioned above, it might be helpful to backup the existing stock Android image before flashing the Android
base release for the first time, as obtaining the stock image might be hard for some vendors (e.g. some stock images
are only available as self-extracting .exe package for Windows) or impossible (some vendors do not provide stock
images for download).
Use Android Recovery (e.g. TWRP or ClockworkMod) to:
1. Backup to SD card: system, data, boot and recovery partitions
2. Test restoring the backup (important)

Warning: While backing up to internal device storage is possible for some devices, if during porting you end
up overwriting that partition, your backups will be gone. In that case (and in case of devices without SD card
slots), it’s better to also copy the backup data to your development machine (e.g. via adb pull in recovery).
Recent versions of adb support full-device backups to a host computer using the adb backup feature.
See the ClockworkMod Instructions for additional help.

3.2 Flash and Test your Android base image

Flash an image that you built or obtained of your Android base, whether it’s LineageOS, CAF, AOSP, or another.
The official LineageOS flashing instructions can be found on this LineageOS wiki page.

You may also want to verify that the Android base build for your device is fully functional, to avoid wasting time
with hardware adaptations that have known issues. Also, your device might have some hardware defects - testing
in Android verifies that all components are working correctly, so you have a functionality baseline to compare
your Sailfish OS build results with.

You should at least check the following features:

• OpenGL ES 2.0: Use e.g. Gears for Android to test (the hz you will get there will be max refresh rate).
• WLAN connectivity: Connect to an AP, ad-hoc or set up a mobile access point with your device.
• Audio: Headset detection, earpiece speaker, loudspeakers, etc.
• Bluetooth: Connect to bluetooth headsets, verify discoverability, send files.
• NFC: Check if NFC tags can be detected, read and/or written by the device.
• SD/MicroSD: Use a file manager app to see if inserted SD cards can be detected.
• USB: MTP, mass storage (if available) and adb access.
• Telephony: 2G/3G/LTE calls + data connectivity.
• GPS: Using GPS Test, check GLONASS too; typical time to fix; AGPS.
• Sensors: Using AndroSensor: Accelerometer, Proximity Sensor, Ambient Light Sensor, Gyroscope, Mag-
netometer (Compass), Hall (flip case), . . .
• LEDs: If your device has notification LEDs or keypad backlights.
• Camera (front and back): Also test functionality of zoom, flash, etc..
• Buttons: Volume up, volume down, power, camera shutter, etc..
• Video out: HDMI / MHL connectivity if you have the necessary adapters. TV out.
• Screen backlight: Suspend and backlight control, minimum and maximum brightness.
• Battery meter: Charge level, battery health, charging via USB (wall charger and host PC).
• Vibration motor: Intensity, patterns.
• HW composer version: check dumpsys SurfaceFlinger through ADB (see SF Layer Debugging).
• Fingerprint sensor
• FM Radio

We recommend that you write down the results of these tests, so you can always remember them.

SETTING UP THE SDKS

4.1 Setting up required environment variables

Throughout this guide we will be referencing the location of your SDK, device build environment and source
code. As is customary with Android hardware adaptations, the device vendor ($VENDOR) and device codename
($DEVICE) are also used, both in scripts and configuration files. Throughout this guide as example, we’ll use
Nexus 5 (lge/hammerhead for its vendor/device pair), and port it using CyanogenMod 11.0 version as the
“Android base”. Thus ensure you read the code snippets carefully and rename where appropriate for your ported
device/vendor/base.

Now run the following commands on your host operating system fitting for your device and setup:

HOST $
cat <<'EOF' > $HOME/.hadk.env
export ANDROID_ROOT="$HOME/hadk"
export VENDOR="lge"
export DEVICE="hammerhead"
# "armv7hl" is still supported, but we encourage to have full 64bit ports
export PORT_ARCH="aarch64"
# Uncomment the next line to conveniently build all RPMs in local repo:
#alias mb2='mb2 --output-dir "${ANDROID_ROOT?}/droid-local-repo/${DEVICE?}"'
EOF
cat <<'EOF' >> $HOME/.mersdkubu.profile
function hadk() { source $HOME/.hadk.env; echo "Env setup for $DEVICE"; }
export PS1="HABUILD_SDK [\${DEVICE}] $PS1"
hadk
EOF

This ensures that the environment is setup correctly when you use the ubu-chroot command to enter the
Android SDK.

It also creates a function hadk that you can use to set or reset the environment variables.

4.2 Setup the Platform SDK

Instructions are found on Sailfish OS docs (“Quick start” section is enough, do not install SDK Targets yet):
https://docs.sailfishos.org/Tools/Platform_SDK/Installation/

Afterwards, temporarily leave the PLATFORM_SDK to top up your ~/.bashrc with necessary commands:

PLATFORM_SDK $
exit

HOST $
cat <<'EOF' >> $HOME/.bashrc
if [[ $SAILFISH_SDK ]]; then
function hadk() { source $HOME/.hadk.env; echo "Env setup for $DEVICE"; }
hadk
fi
EOF
sfossdk

Warning: With Platform SDK version 4.4.0.58 and olders you need to check the MERSDK variable instead
of SAILFISH_SDK in the above code snippet.

You’ll need some tools which are not installed into the Platform SDK by default:
• android-tools-hadk contains tools and utilities needed for working with the Android SDK
• kmod is needed by mic’s qemu to build the image
• createrepo_c is needed when passing local repo to mic

PLATFORM_SDK $
sudo zypper ref
sudo zypper in android-tools-hadk kmod createrepo_c

The minimum Platform SDK SFOS version is 4.3.0.15. Use sdk-assistant command to upgrade your build
tools, or create from new (especially when updating from 2.x to 3.x). To check what release you are on:

PLATFORM_SDK $
# if no such file, you're on an old SDK version
cat /etc/os-release

More information about keeping your SDK up-to-date: https://github.com/sailfishos/sdk-setup/blob/master/
sdk-setup/README.tips.wiki#SDK_Maintenance

4.3 Setting up an Android Build Environment

4.3.1 Downloading and Unpacking Ubuntu Chroot

In order to maintain build stability, we use a Ubuntu GNU/Linux chroot environment from within the Platform
SDK to build our Android source tree. For Android device ports that require OpenJDK 1.8 or newer, the following
commands download and unpack the rootfs to the appropriate location:

PLATFORM_SDK $
TARBALL=ubuntu-focal-20210531-android-rootfs.tar.bz2
curl -O https://releases.sailfishos.org/ubu/$TARBALL
UBUNTU_CHROOT=$PLATFORM_SDK_ROOT/sdks/ubuntu
sudo mkdir -p $UBUNTU_CHROOT
sudo tar --numeric-owner -xjf $TARBALL -C $UBUNTU_CHROOT

In case you find you’re not able to gain sudo privileges inside the Ubuntu Chroot, execute the following inside
the Platform SDK:

PLATFORM_SDK $
sudo chroot $UBUNTU_CHROOT /bin/bash -c "chage -M 999999 $(id -nu 1000)"

4.3.2 Entering Ubuntu Chroot

PLATFORM_SDK $
ubu-chroot -r $PLATFORM_SDK_ROOT/sdks/ubuntu
# FIXME: Hostname resolution might fail. This error can be ignored.
# Can be fixed manually by adding the hostname to /etc/hosts
HABUILD_SDK $
# Now you are in the HABUILD_SDK environment
# To leave, just type `exit` or Ctrl+D, and you'll be back to the PLATFORM_SDK

4.3.3 If your port requires OpenJDK 1.7 or older

Our ubu-chroot environment is based on 20.04 LTS which provides OpenJDK 1.8 or newer.
If your Android base build requires an older Java Development Kit, please install the legacy ubu-chroot instead:

PLATFORM_SDK $
TARBALL=ubuntu-trusty-20180613-android-rootfs.tar.bz2
curl -O https://releases.sailfishos.org/ubu/$TARBALL
UBUNTU_CHROOT=$PLATFORM_SDK_ROOT/sdks/ubuntu
sudo mkdir -p $UBUNTU_CHROOT
sudo tar --numeric-owner -xjf $TARBALL -C $UBUNTU_CHROOT

BUILDING THE ANDROID HAL

5.1 Checking out Source of the Android base

Our build process is based around the Android source tree, but where needed we’ve modified some projects, in
order to apply patches required to make libhybris function correctly, and to minimise the built-in actions and
services in the init.*.rc files.
Ensure you have setup your name and e-mail address in your Git configuration:

HABUILD_SDK $
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
Ensure Ubuntu chroot has cpio installed:
HABUILD_SDK $
sudo apt-get install cpio

You also need to install the repo command from the AOSP source code repositories, see Installing repo.

Note: If your port requires OpenJDK 1.7 or older, use the older repo tool for legacy Python 2 systems.

After you’ve installed the repo command, a set of commands below will download the required projects for
building the modified parts of the Android base used in Sailfish OS hardware adaptations.

All available Android base variants and versions that you can port on can be seen here: https://github.com/
mer-hybris/android/branches

Choose a version which has the best hardware support for your device.

Alternatively, you can patch an Android base of your choosing (e.g. be it CAF or AOSP or another).

The result of your Sailfish OS port will be an installable ZIP file. Before deploying it onto your device, you’ll have
to flash a corresponding version of the Android base, so Sailfish OS can re-use its Android HAL shared objects.

If your primary ROM does not match your Android base or its version, and you would like to keep it on your
device, then look for MultiROM support for it. Starting with its version v28, it supports booting Sailfish OS.

This porting guide is using Nexus 5 and CyanogenMod 11.0 version as example:

HABUILD_SDK $
sudo mkdir -p $ANDROID_ROOT
sudo chown -R $USER $ANDROID_ROOT
cd $ANDROID_ROOT
repo init -u https://github.com/mer-hybris/android.git -b hybris-11.0

5.2 Device repos

The local manifest contains device-specific repositories, for Android as well as for the mer-hybris builds.

If your device has already been ported, its codes properly placed on GitHub, you should check this repository:
https://github.com/mer-hybris/local_manifests (choose the branch of hybris-* that your are porting to), and use
$DEVICE.xml file instead of creating a new one in this chapter.

Create directory at first:

HABUILD_SDK $
mkdir $ANDROID_ROOT/.repo/local_manifests

If your are working on a new port, you’ll have to create the local manifest yourself, which contains at least two
repos: one for the kernel, another for the device configuration. Find those in the LineageOS device wiki, for Nexus
5 it would be https://wiki.lineageos.org/devices/hammerhead/build#initialize-the-lineageos-source-repository Lo-
cal manifest below will also need pointing to correct branches - identify which one matches the default manifest
branch (stable/cm-11.0 in Nexus 5 case).

Add the following content to $ANDROID_ROOT/.repo/local_manifests/$DEVICE.xml:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project path="device/lge/hammerhead"
    name="CyanogenMod/android_device_lge_hammerhead"
    revision="stable/cm-11.0" />
 <project path="kernel/lge/hammerhead"
    name="CyanogenMod/android_kernel_lge_hammerhead"
    revision="stable/cm-11.0" />
</manifest>

Time to sync the whole source code, this might take a while: Do not use –fetch-submodules parameter on hybris-
18.1 or newer Android bases.

HABUILD_SDK $
repo sync --fetch-submodules

The expected disk usage for the source tree after the sync is 13 GB (as of 2015-09-09, hybris-11.0 branch).

Depending on your connection, this might take some time. In the mean time, make yourself familiar with the rest
of this guide.

5.3 Configure Mountpoint Information

Currently in Sailfish OS, udev starts after initrd, which leaves us not being able to use generic partition names
(independent of partition number).

In initrd we then have to specify hardcoded /dev/mmcblkXpY nodes for /boot and /data partitions.

After initrd, systemd needs to mount all other required partitions (such as /system, /firmware, /
persist, /config, . . . ) for the HAL layer to work. The required partitions are read from *.fstab and
init*.rc files, disabled there, and respective .mount units created – all done by $ANDROID_ROOT/rpm
(droid-hal-device).

Unfortunately, systemd cannot recognise named partition paths in .mount units, because of the same late start
of udev, even though one can see already created nodes under /dev/block/platform/*/by-name/ or
/dev/block/platform/*/*/by-name.

To work around this, we need to create a map between partition names and numbers in hybris/
hybris-boot/fixup-mountpoints for each device, for all partitions – in this way we are sure to cover
them all, because if done manually by looking through fstab/rc files, some might get unnoticed.

To get that mapping, you should flash and boot an image of your Android base and execute adb shell on
your host and something like this:

ls -l /dev/block/platform/*/by-name/

on your device. To get
the correct path you must find Android’s fstab in device repository or in device itself and get by-name path
like:

block/bootdevice/by-name/userdata,

ls -l /dev/block/platform/*/*/by-name/
``or ``block/platform/*/by-name/userdata from it.

Once you’ve patched fixup-mountpoints, take care if you ever have to run repo sync
--fetch-submodules again because it will reset your changes, unless the file .repo/
local_manifests/$DEVICE.xml is pointing hybris-boot to your fork with the needed fixup-
mountpoints changes.

Then when you get to boot to the Sailfish OS UI, please don’t forget to upstream your fixup-mountpoints
patch.

5.4 Building Relevant Bits of your Android base

In the Android build tree, run the following in a bash shell (if you are using e.g. zsh, you need to run these
commands in a bash shell, as the Android build scripts are assuming you are running bash).

You’ll probably need to iterate this a few times to spot missing repositories, tools, configuration files and others:
Before building it is recommended to read extra Android base specific hints from https://github.com/mer-hybris/
hadk-faq#android-base-specific-fixes

HABUILD_SDK $
source build/envsetup.sh
export USE_CCACHE=1
breakfast $DEVICE
make -j$(nproc --all) hybris-hal droidmedia

The relevant output bits will be in out/target/product/$DEVICE/, in particular:
• hybris-boot.img: Kernel and initrd
• hybris-recovery.img: Recovery boot image
• system/ and root/: HAL system libraries and binaries

The approximate size of the output directory out/ after make hybris-hal is 10 GB (as of 2019-03-14,
hybris-sony-aosp-8.1.0_r52-20190206 branch).

5.4.1 Kernel config

Once the kernel has built you can check the kernel config. You can use the Mer kernel config checker:

HABUILD_SDK $
cd $ANDROID_ROOT
hybris/mer-kernel-check/mer_verify_kernel_config   \
   ./out/target/product/$DEVICE/obj/KERNEL_OBJ/.config

Apply listed modifications to the defconfig file that your Android base is using. Which one? It’s different for
every device, most likely first:

• Check the value of TARGET_KERNEL_CONFIG under $ANDROID_ROOT/device/$VENDOR/*/BoardConfig*.mk
• Examine the output of make bootimage for which defconfig is taken when you’re building kernel, e.g.:
make -C kernel/lge/hammerhead ... cyanogenmod_hammerhead_defconfig
• Check your Android base kernel’s commit history for the arch/arm*/configs folder, look for def-
config

If you are in a rush, get rid only of ERROR cases first, but don’t forget to come back to the WARNING ones too.

After you’ll have applied the needed changes, re-run make hybris-boot and re-verify. Lather, rinse, repeat
:) Run also make hybris-recovery in the end when no more errors.

Contribute your mods back

Fork the kernel repo to your GitHub home (indicated by myname in this doc).
For Nexus 5 with CM 11.0 as base, the next action would be (rename where appropriate to match your de-
vice/branch):

HABUILD_SDK $
cd kernel/lge/hammerhead
git checkout -b hybris-11.0
DEFCONFIG=arch/arm/configs/cyanogenmod_hammerhead_defconfig
git add $DEFCONFIG
git commit -m "Hybris-friendly defconfig"
git remote add myname https://github.com/myname/android_kernel_lge_hammerhead
git push myname hybris-11.0

Create PR to the forked kernel repo under github/mer-hybris. Ask a mer-hybris admin to create one, if it isn’t
there.
Adjust your .repo/local_manifests/$DEVICE.xml by replacing the line

<project path="kernel/lge/hammerhead"
name="CyanogenMod/android_kernel_lge_hammerhead"
revision="stable/cm-11.0-XNG3C" />

with

<project path="kernel/lge/hammerhead"
name="myname/android_kernel_lge_hammerhead"
revision="hybris-11.0" />

5.5 Common Pitfalls

• If repo sync --fetch-submodules fails with a message like fatal:
duplicate path device/samsung/smdk4412-common in /home/nemo/android/.repo/manifest.xml,
remove the local manifest with rm .repo/local_manifests/roomservice.xml

• If repo sync --fetch-submodules fails with some other error message try running repo sync
to see if it helps. This is usually needed for hybris-18.1 or newer Android bases.

• If you notice git clone commands starting to write out “Forbidden . . . ” on github repos, you might
have hit API rate limit. To solve this, put your github credentials into ~/.netrc. More info can be found
following this link: Perm.auth. with Git repositories

• error: Cannot fetch . . . (GitError: –force-sync not enabled; cannot overwrite a local work tree., usually
happens if repo sync --fetch-submodules gets interrupted. It is a bug of the repo tool. Ensure
all your changes have been safely stowed (check with repo status), and then workaround by:

HABUILD_SDK $
repo sync --force-sync
repo sync --fetch-submodules

• In some cases (with parallel builds), the build can fail, in this case, use make -j1 ... to retry with a
non-parallel build and see the error message without output from parallel jobs. The build usually ends with
the following output:

HABUILD_SDK $
...
Install: .../out/target/product/$DEVICE/hybris-recovery.img
...
Install: .../out/target/product/$DEVICE/hybris-boot.img

INSTALLING BUILD TOOLS FOR YOUR DEVICE

It is necessary to emulate your target device architecture and file system to build hardware adaptation packages in
the next section. Download and install your build tools following instructions below.

Important: Minimum version for SFOS target is 4.3.0.15 (same requirement as for the Platform SDK Chroot
earlier)

Warning: To ensure consistency with HADK build scripts, name your tooling SailfishOS-4.5.0 (or
whichever release you are building for) instead of suggested SailfishOS-latest, and your target as
$VENDOR-$DEVICE-$PORT_ARCH (instead of SailfishOS-latest-aarch64). Ignore the i486 tar-
get.

For ARM devices, choose aarch64 build target, unless you are building for the armv7hl Sailfish OS userspace.
https://docs.sailfishos.org/Tools/Platform_SDK/Target_Installation/

To verify the correct installation of the build tools, cross-compile a simple “Hello, World!” C application with
mb2 build-shell:

PLATFORM_SDK $

cd $HOME

mkdir hadk-test-tmp

cd hadk-test-tmp



cat > main.c << EOF

#include <stdlib.h>

#include <stdio.h>

int main(void) {

    printf("Hello, world!\n");

    return EXIT_SUCCESS;

}

EOF

mb2 -t $VENDOR-$DEVICE-$PORT_ARCH build-init

mb2 -t $VENDOR-$DEVICE-$PORT_ARCH build-shell gcc main.c -o test

If the compilation was successful you can test the executable by running the following command (this will run the
executable using qemu as emulation layer, which is part of the mb2 setup):

mb2 -t $VENDOR-$DEVICE-$PORT_ARCH build-shell ./test

The above command should output “Hello, world!” on the console, this proves that the build tools can compile
binaries and execute them for your architecture.