Demonstrations for the meta-aws project
meta-aws is a Yocto Project Bitbake Metadata Layer. It accelerates building Amazon Web Services (AWS) software you can install to Embedded Linux. You can use this to build IoT solutions on AWS.
In this repository, you will find meta-aws demonstrations. These demos are based on both Poky (the Yocto Project reference implementation) and real hardware. Many times, the hardware will be representative of actual uses of hardware listed in the AWS Device Catalog.
The number of demonstrations will increase over time and your contributions are very welcome!
The DEMOs consist of a combination of a DEVICE, which represent a hardware and an IMAGE showcasing a use-case.
Select your desired target environment. These are listed below in alphabetical order for ease of selection, no preference should be inferred.
agl-renesas/ AGL + Renesasagl-rpi/ AGL + Raspberry Pi Foundationdart-mx8m/ varisciteec2-arm64/ AWS EC2ec2-x86-64/ AWS EC2imx8m/ NXPqemu-arm64qemu-x86-64rpi4-32/ Raspberry Pi Foundationrpi4-64/ Raspberry Pi Foundationrpi5/ Raspberry Pi Foundationphytec/ phytecti-am572x-idk/ Texas Instrumentsxilinx-zcu104-zynqmp/ Xilinx
Generally you can build all images for all "Devices", but some combinations do not work or do not make sense!
Important
Be careful some of the images require additional local.conf entries, those config.conf files are located in the respective image. They are automatically included if the correct environment variables (IMAGE + DEVICE) are set!
To try out this project in QEMU (default device is qemu-arm64), run the following commands:
git submodule update --init --recursive
. init-build-env
export IMAGE=aws-demo-image
bitbake $IMAGE
runqemu slirp nographicPlease also consider these build host requirements.
This repository uses submodules and a simple wrapper script to set the default
TEMPLATECONF that allows users to select the device they want to build. The
first step is to clone down the submodules:
git submodule update --init --recursiveNext, initialize the build environment, and optionally specify the build directory:
. init-build-env [BUILDDIR]Finally, the images can be built - details in linked readme for each DEMO. Default device is qemu-arm64:
export DEVICE=[DEVICE]
export IMAGE=[IMAGE]
bitbake $IMAGETo build for a different device, set the DEVICE (see here) and IMAGE environment variable,
like this:
export DEMO=ec2-arm64
export IMAGE=aws-demo-image
bitbake $IMAGEFor a list of all possible devices, see meta-aws-demos/conf/devices.
The init-build-env script adds a helper function called get_devices which
will list all devices that can be configured. This can be used to build all devices with:
for d in $(get_devices); do for i in $(get_images); do DEVICE=$d IMAGE=$i bitbake $i; done; doneNew platforms can be added by adding a new directory under
meta-aws-demos/conf/devices. This directory should contain 2 files:
layers.conf: This is the file that will be required in bblayers.conf when
the product is selected
config.conf: This is the file that will be required in local.conf when the
product is selected
TEMPLATECONF is a great mechanism for initially populating a build
configuration, but it has a few shortcomings that arise because it will only
write the files if they don't already exist. Because of this, it's not suitable
to share device configuration because users won't automatically get the new
configuration for a build when they change revisions in the repository. The
solution to this problem is quite simple though: Instead of including the build
configuration directly in the template files, the template files instead
require a file that is checked into source control. By doing this, users will
automatically get the correct build configuration when changing revisions, but
can still override anything they want in their local.conf
The following will update upstream submodule changes recursively:
git submodule update --remote --init --recursive