Skip to content
Snippets Groups Projects

meta-openharmony

meta-openharmony is a bitbake layer, containing recipes for building OpenHarmony images and components.

Contributing

See the CONTRIBUTING.md file.

License

See the LICENSES subdirectory.

Dependencies

URI: git://git.openembedded.org/bitbake
branch: 1.46

URI: git://git.openembedded.org/openembedded-core
layers: meta
branch: dunfell

URI: git://git.openembedded.org/meta-openembedded
layers: meta-oe meta-python
branch: dunfell

URI: https://git.ostc-eu.org/distro/meta-python-mixin.git
branch: dunfell

URI: https://git.ostc-eu.org/distro/oniro.git
layers: meta-oniro-staging
branch: dunfell

URI: git://git.yoctoproject.org/meta-java
branch: dunfell

URI: https://git.ostc-eu.org/distro/meta-riscv.git
branch: OSTC/dunfell

Building

To build an OpenHarmony image with this layer, you need to use a compatible host OS. See https://docs.yoctoproject.org/3.1.8/brief-yoctoprojectqs/brief-yoctoprojectqs.html for details on this. Sections https://docs.yoctoproject.org/3.1.8/brief-yoctoprojectqs/brief-yoctoprojectqs.html#compatible-linux-distribution and https://docs.yoctoproject.org/3.1.8/brief-yoctoprojectqs/brief-yoctoprojectqs.html#build-host-packages in particular.

Additionally, some OpenHarnony v3.0 git repositories need Large File Storage (LFS) support and you need to install the git-lfs package. On Debian-based systems the command is:

sudo apt install git-lfs

To setup the build environment, you first have to clone bitbake, openembedded-core and extra layers needed. A repo manifest is included in meta-openharmony that allows to do this with two commands, which must be run in a newly created directory where you want the build environment to be placed:

mkdir ohoe && cd ohoe
repo init -u https://git.ostc-eu.org/OSTC/pre-integration/meta-openharmony.git -b dunfell
repo sync --no-clone-bundle

In case of any problems with the above in China, please try using the gitee.com mirrors:

mkdir ohoe && cd ohoe
repo init -u https://gitee.com/oniroproject/meta-openharmony.git -b dunfell -m manifests/gitee/default.xml
repo sync --no-clone-bundle

With this in place, you need to initialize the build environment (run in ohoe dir)

TEMPLATECONF=../meta-openharmony/conf source oe-core/oe-init-build-env

The current directory will change to build directory. The next commands must be run there.

To build images, you need to run bitbake with $MACHINE environment variable set to the target board and with the image type as argumment. E.g. building ipcamera image for the hispark aries board, you should use the following command:

MACHINE=hispark-aries bitbake ipcamera

By default, OpenHarmony 3.0 images are built. To build OpenHarmony 1.1.3 images instead, you should change the DISTRO variable in build/conf/local.conf to openharmony-v1.

Images for hardware boards

The following images for hardware boards can be built.

LiteOS ipcamera image for HiSpark Aries board

This image is supported with both DISTRO="openharmony-v1 and DISTRO="openharmony-v3.

To build this image, run

MACHINE=hispark-aries bitbake ipcamera

LiteOS ipcamera image for HiSpark Taurus board

This image is supported with both DISTRO="openharmony-v1 and DISTRO="openharmony-v3.

To build this image, run

MACHINE=hispark-taurus bitbake ipcamera

Linux ipcamera image for HiSpark Taurus board

This image is only supported with DISTRO="openharmony-v3.

To build this image, run

MACHINE=hispark-taurus bitbake ipcamera-linux

LiteOS WiFi IoT image for HiSpark Taurus board

This image is supported with both DISTRO="openharmony-v1 and DISTRO="openharmony-v3.

To build this image, run

MACHINE=hispark-pegasus bitbake wifiiot

Linux Standard System Demo image for HiSpark Taurus board

This image is only supported with DISTRO="openharmony-v3.

To build this image, run

MACHINE=hispark-taurus bitbake standard-system-demo

Images for QEMU

It is also possible to build images for QEMU.

LiteOS Mini System Demo image for QEMU ARM Cortex-M4

This image is only supported with DISTRO="openharmony-v3.

To build this image, run

MACHINE=qemuarmm4 bitbake mini-system-demo

LiteOS Mini System Demo image for QEMU Risc-V 32

This image is only supported with DISTRO="openharmony-v3.

To build this image, run

MACHINE=qemuriscv32nf bitbake mini-system-demo

LiteOS Small System Demo image for QEMU ARM Cortex-A7

This image is only supported with DISTRO="openharmony-v3.

To build this image, run

MACHINE=qemuarma7 bitbake small-system-demo

Using the images

The images for hardware boards can be flashed using the normal flashing procedure documented by OpenHarmony.

The image files can be found in directories such as build/tmp-glibc/deploy/images/hispark-taurus. The images for hardware boards are provided as a tar.gz file, which you need to unpack to get the files needed for the flashing procedure.

When you have built a QEMU image, you can run it using the following command.

runqemu serialstdio

Repo manifests

The meta-openharmony repository includes a number of different repo manifest files, which you can use to fetch all repositories needed for building OpenHarmony.

manifests/trunk.xml

This manifest checks out all repositories with the latest revision from their development branch, including upstream projects.

manifests/default.xml

This manifest checks out repositories not maintained by Oniro Project (bitbake, openembedded-core, meta-openembedded and so on) at known good versions, which are locked down by commit ids in the manifest file. Oniro Project maintained repositories are checked out with latest revision from development branches.

manifests/release.xml

This manifest checks out all repositories, except meta-openharmony, at known good versions. The versions are locked down by commit ids in manifest file.

manifests/ci.xml

This is for internal use in GitLab CI.

manifests/gitee/trunk.xml

This is similar to manifests/trunk.xml, but fetches all repositories from mirror on gitee.com. Use this when working from China, and have trouble fetching from one or more of the repositories.

manifests/gitee/default.xml

This is similar to manifests/default.xml, but fetches all repositories from mirror on gitee.com. Use this when working from China, and have trouble fetching from one or more of the repositories.

manifests/gitee/release.xml

This is similar to manifests/release.xml, but fetches all repositories from mirror on gitee.com. Use this when working from China, and have trouble fetching from one or more of the repositories.

manifests/gitee/ci.xml

This is similar to manifests/ci.xml, but fetches all repositories from mirror on gitee.com. Use this when working from China, and have trouble fetching from one or more of the repositories.