diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..76c5e1ddd83e18a324f5ab7012445f9395aed647
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,17 @@
+<!--
+SPDX-FileCopyrightText: Huawei Inc.
+
+SPDX-License-Identifier: CC-BY-4.0
+-->
+
+# Documentation for meta-ohos
+
+The documentation for `meta-ohos` is written as reST files and can be generated with `sphinx-build` tool:
+
+```
+sphinx-build -C -D html_theme=sphinx_rtd_theme -D project='OpenHarmony Build System and meta-ohos' -D copyright='Huawei Inc' . build
+```
+
+# License
+
+All the documentation is licensed as `CC-BY-4.0`.
diff --git a/docs/build-flavours/build-flavours.rst b/docs/build-flavours/build-flavours.rst
new file mode 100644
index 0000000000000000000000000000000000000000..bdd41bc44addbd6d362b17b976883f05e4f859e4
--- /dev/null
+++ b/docs/build-flavours/build-flavours.rst
@@ -0,0 +1,40 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Overview of Build Flavours
+##########################
+
+OpenHarmony can be hosted on top of variety of kernels. Currently supported
+kernels are Linux, Zephyr and FreeRTOS (experimental). The build system
+requires build configuration that is specific to each kernel and OpenHarmony
+provides all this configuration as build tamplates. See `Yocto documentation <https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-a-custom-template-configuration-directory>`_
+for more info about the underlying mechanism.
+
+In essence, a flavour is a build configuration that was used at build
+initialization time for a specific kernel by passing the associated
+``TEMPLATECONF`` configuration.
+
+All the available ``flavours`` are available as subdirectories of the
+``flavours`` directory in the root of the ``meta-ohos`` repository.
+
+Generically, when configuring a new build, one should pass the flavour as
+``TEMPLATECONF`` to the ``oe-init-build-env`` script:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/<FLAVOUR_NAME> . ./sources/poky/oe-init-build-env <BUILD_NAME>
+
+Notes:
+
+* The command assumes that the working directory is the root of the repo
+ workspace when issuing the above command.
+* The variables marked in ``<>`` are to be replaced accoridngly.
+* Mind the ``../`` prefix for ``TEMPLATECONF``. This is because the path
+ provided needs to be relative to the build directory.
+
+Once the build was initilized, you are dropped in a buid environment where you have access to the ``OE`` tools:
+
+.. code-block:: console
+
+ $ bitbake <TARGET/IMAGE-NAME>
diff --git a/docs/build-flavours/freertos-flavour.rst b/docs/build-flavours/freertos-flavour.rst
new file mode 100644
index 0000000000000000000000000000000000000000..add6005e03ad256da379afb7319d3de4c147fb8f
--- /dev/null
+++ b/docs/build-flavours/freertos-flavour.rst
@@ -0,0 +1,49 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+FreeRTOS Kernel Build Flavour
+#############################
+
+OpenHarmony FreeRTOS build flavour is based on *freertos* distribution (distro configuration).
+
+Supported images:
+
+* freertos-demo
+
+Supported machines (default in **bold**):
+
+* **qemuarmv5**
+
+Build steps example:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/freertos . ./sources/poky/oe-init-build-env build-ohos-freertos
+ $ bitbake freertos-demo
+
+You can test the image built for the qemuarmv5 target by issuing:
+
+.. code-block:: console
+
+ $ runqemu qemuarmv5
+
+After successful bootup, the output of the application will be similar to:
+
+.. code-block:: console
+
+ ###### - FreeRTOS sample application - ######
+
+ A text may be entered using a keyboard.
+ It will be displayed when 'Enter' is pressed.
+
+ Periodic task 10 secs
+ Waiting For Notification - Blocked...
+ Task1
+ Task1
+ You entered: "HelloFreeRTOS"
+ Unblocked
+ Notification Received
+ Waiting For Notification - Blocked...
+
+To exit qemu, use the following key combination: *Ctrl-a followed by 'x'*.
diff --git a/docs/build-flavours/index.rst b/docs/build-flavours/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..a4de7214ce5e15ffc042215d806743b46e7dfdac
--- /dev/null
+++ b/docs/build-flavours/index.rst
@@ -0,0 +1,17 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+OpenHarmony Build Flavours
+##########################
+
+OpenHarmony provides default build configuration for each supported type of
+kernels. Each set of such configuration is called a ``flavour``.
+
+.. toctree::
+ :maxdepth: 1
+
+ build-flavours
+ linux-flavour
+ zephyr-flavour
+ freertos-flavour
diff --git a/docs/build-flavours/linux-flavour.rst b/docs/build-flavours/linux-flavour.rst
new file mode 100644
index 0000000000000000000000000000000000000000..2c1d0df375fa81ab6694767527ff74aa7254974f
--- /dev/null
+++ b/docs/build-flavours/linux-flavour.rst
@@ -0,0 +1,60 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Linux Kernel Build Flavour
+##########################
+
+OpenHarmony Linux build flavour is based on *openharmony-linux* distribution (distro configuration).
+
+Supported images:
+
+* openharmony-image-base
+* openharmony-image-base-tests
+* openharmony-image-extra
+* openharmony-image-extra-tests
+
+Supported machines (default in **bold**):
+
+* **qemux86-64**
+* qemux86
+* qemuarm
+* qemuarm64
+* seco-intel-b68 (SECO SBC-B68)
+* stm32mp1-av96 (96Boards Avenger96)
+* seco-imx8mm-c61 (SECO SBC-C61)
+
+Build steps example:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+ $ bitbake openharmony-image-base
+
+You can test the image built for the qemux86-64 target by issuing:
+
+.. code-block:: console
+
+ $ runqemu qemux86-64
+
+After successful bootup, you will be dropped into a login shell:
+
+.. code-block:: console
+
+ qemux86-64 login:
+
+Default login is *root* without a password.
+
+After login you will see the shell prompt:
+
+.. code-block:: console
+
+ root@qemux86-64:~#
+
+To exit qemu, you can either shut down the system:
+
+.. code-block:: console
+
+ root@qemux86:~# poweroff -f
+
+or close qemu using a key combination: *Ctrl-a followed by 'x'*.
diff --git a/docs/build-flavours/zephyr-flavour.rst b/docs/build-flavours/zephyr-flavour.rst
new file mode 100644
index 0000000000000000000000000000000000000000..fa95b289531a846a607320104f502bef0390f602
--- /dev/null
+++ b/docs/build-flavours/zephyr-flavour.rst
@@ -0,0 +1,48 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Zephyr Kernel Build Flavour
+###########################
+
+OpenHarmony Zephyr build flavour is based on *openharmony-zephyr* distribution (distro configuration).
+
+Supported images:
+
+* Zephyr comes with multiple sample applications. Take a look into
+ ``sources/meta-zephyr/recipes-kernel/zephyr-kernel/`` to see available recipes.
+ You can extend them by adding recipes that `use sample applications provided with Zephyr <https://github.com/zephyrproject-rtos/zephyr/tree/master/samples>`_
+ or your own applications.
+
+Supported machines (default in **bold**):
+
+* **qemu-x86**
+* qemu-cortex-m3
+* 96b-nitrogen (96Boards Nitrogen)
+* 96b-avenger96 (96Boards Avenger96)
+
+Build steps example:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/zephyr . ./sources/poky/oe-init-build-env build-ohos-zephyr
+ $ bitbake zephyr-philosophers
+
+You can test the image built for the qemu-x86 target by issuing:
+
+.. code-block:: console
+
+ $ runqemu qemu-x86
+
+After successful bootup, the output of the application will be similar to:
+
+.. code-block:: console
+
+ Booting from ROM..*** Booting Zephyr OS build zephyr-v2.4.0 ***
+ Philosopher 0 [P: 3] THINKING [ 300 ms ]
+ Philosopher 1 [P: 2] EATING [ 575 ms ]
+ Philosopher 2 [P: 1] STARVING
+ Philosopher 3 [P: 0] EATING [ 525 ms ]
+ Philosopher 4 [C: -1] THINKING [ 475 ms ]
+
+To exit qemu, use the following key combination: *Ctrl-a followed by 'x'*.
diff --git a/docs/demos/index.rst b/docs/demos/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..c8edfbd636e86634e4691f9b203965b6f9f886d8
--- /dev/null
+++ b/docs/demos/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+OpenHarmony Demos
+#################
+
+This section details the available demos provided as part of the OpenHarmony
+environment.
+
+.. toctree::
+ :maxdepth: 1
+
+ smart-panel
diff --git a/docs/demos/smart-panel.rst b/docs/demos/smart-panel.rst
new file mode 100644
index 0000000000000000000000000000000000000000..3c0f6661ba1451a991ecc3ef42dafbc670d610ee
--- /dev/null
+++ b/docs/demos/smart-panel.rst
@@ -0,0 +1,30 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Smart Panel Demo
+################
+
+.. contents::
+ :depth: 3
+
+Overview
+********
+
+The Smart Panel Demo provides support for building a PoC for a home automation
+system with components showing the capabilities of the build infrastructure in
+leveraging different kernels for building an end to end solution.
+
+The setup is composed of an Avenger96 board acting as a gateway an running
+HomeAssistant. The gateway also provides UI as a browser connected to the
+localhost HomeAssistant server. The gateway is connected over Bluetooth to two
+Nitrogen boards exposing sensors and/or emulating device (eg. light bulbs).
+
+How to build
+************
+
+The Linux Gateway
+-----------------
+
+Set the ``DISTRO`` to ``openharmony-linux-demo-dashboard`` and build the
+``openharmony-linux-demo-dashboard`` image.
diff --git a/docs/hardware-support/adding-hardware-support.rst b/docs/hardware-support/adding-hardware-support.rst
new file mode 100644
index 0000000000000000000000000000000000000000..9985001f17d1217b805ec4887277e7aadb7fc8fe
--- /dev/null
+++ b/docs/hardware-support/adding-hardware-support.rst
@@ -0,0 +1,84 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Adding Hardware Support in OpenHarmony
+######################################
+
+This section details the addition of new hardware to the supported set in
+OpenHarmony. It is intended as a checklist for adding new boards to OHOS build
+system.
+
+Before starting get familiar with OpenHarmony Contribution Process.
+
+.. contents::
+ :depth: 2
+
+Select OpenHarmony Flavour
+**************************
+
+OpenHarmony uses a notion of kernel specific flavours:
+
+- Linux flavour
+- Zephyr flavour
+- FreeRTOS flavour (experimental)
+
+Flavours have predefined `IMAGES` and `MACHINES`.
+
+A single board can be included in more than one flavour only when it has **well
+maintained support** in targeted kernels.
+
+Add Required meta-layers
+************************
+
+OHOS flavours configuration templates (stored in `OHOS/meta-ohos/flavours <https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/tree/develop/flavours>`_
+directory) consist of the following files:
+
+* ``bblayers.conf.sample``
+
+ * set of meta-layers for the specific flavour (it can be unified across
+ multiple layers where there are no layers incompatibilities)
+
+* ``conf-notes.txt``
+
+ * text snippet to be used as part of build logs
+
+* ``local.conf.sample``
+
+ * default flavour build configuration
+
+OpenHarmony build system uses ***repo*** tool for cloning required meta-layers
+into appropriate build directory structure (see :ref:`Setting up a repo workspace <RepoWorkspace>`).
+To include a new layer, it has to be added in two places:
+
+- `OHOS/manifest <https://git.ostc-eu.org/OSTC/OHOS/manifest>`_
+- `OHOS/meta-ohos flavours <https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/tree/develop/flavours>`_
+ as part of the respective flavour ``bblayers.conf.sample``
+
+Test Image Backward Compatibility Of Newly Added Layers
+*******************************************************
+
+New BSP layers cannot interfere / break already supported ``IMAGES`` / ``MACHINES``.
+
+Document and Advertise the New ``MACHINE`` Support
+**************************************************
+
+Newly added ``MACHINE`` shall be documented in: :ref:`Hardware Support <RepoWorkspace>`.
+Use an existing board documentation as template and populate it accordingly for
+your newly added machine.
+
+The same machine needs to also be advertised in two places:
+
+- Flavour's ``local.conf.sample`` as a commented out ``MACHINE`` variable value
+ (tweak this step accordingly for default machine change)
+- Flavour's ``conf-notes.txt`` to surface the support in build logs
+
+Create Merge Requests
+*********************
+
+Create Merge Requests to ***develop*** branch according to the Contributing Process for repositories:
+
+- `OHOS/meta-ohos <https://git.ostc-eu.org/OSTC/OHOS/meta-ohos>`_
+- `OHOS/manifest <https://git.ostc-eu.org/OSTC/OHOS/manifest>`_
+
+After meta-ohos MR is merged, update ``meta-ohos`` revision in manifest MR.
diff --git a/docs/hardware-support/boards/96b-Avenger.rst b/docs/hardware-support/boards/96b-Avenger.rst
new file mode 100644
index 0000000000000000000000000000000000000000..103cabf4721a7dfb227fb0ce6d94230d8095cdcb
--- /dev/null
+++ b/docs/hardware-support/boards/96b-Avenger.rst
@@ -0,0 +1,414 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+.. _SupportedBoardAvenger96:
+
+96Boards Avenger96
+##################
+
+.. contents::
+ :depth: 3
+
+Overview
+********
+
+Avenger96 is a STM32MP157xx (Cortex-A7 + Cortex-M4) development board designed
+by the 96Boards initiative. Due to presence of the application processors and
+the microcontroller, Avenger96 can simultaneously run Linux and Zephyr kernels.
+The application processor is responsible for powering up and programming the
+microcontroller with the appropriate image. Linux provides interfaces to
+communicate with the program running on the microcontroller.
+
+Hardware
+********
+
+* For detailed specification, see `Avenger96 product page on the 96Boards website <https://www.96boards.org/product/avenger96/>`_.
+* For hardware user manual and schematics, see `96Boards GitHub documentation repository <https://github.com/96boards/documentation/blob/master/consumer/avenger96/hardware-docs/files/avenger96-hardware-user-manual.pdf>`_.
+
+For more details on Avenger96 board, see `Avenger96 product page <https://www.96boards.org/product/avenger96/>`_.
+
+Working with the board
+**********************
+
+Supported images
+================
+
+.. list-table:: Supported images
+ :widths: auto
+ :header-rows: 1
+
+ * - Image Name
+ - Size
+ - Description
+ * - openharmony-image-base
+ - Approximate 100-200 MB
+ - OpenHarmony image including the base OS software stack
+ * - openharmony-image-extra
+ - Approximate 100-200 MB
+ - OpenHarmony Wayland image including the base OS software stack
+
+
+Building OHOS image
+===================
+
+To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
+
+Linux image
+-----------
+
+1. Source the environment with proper template settings, flavour being *linux*
+ and target machine being *stm32mp1-av96*. Pay attention to how relative
+ paths are constructed. The value of *TEMPLATECONF* is relative to the
+ location of the build directory *./build-linux*, that is going
+ to be created after this step:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+
+2. You will find yourself in the newly created build directory. Call *bitbake*
+ to build the image. For example, if you are using *openharmony-image-base*
+ run the following command:
+
+.. code-block:: console
+
+ $ MACHINE=stm32mp1-av96 bitbake openharmony-image-base
+
+To generate images for eMMC on SD card, refer to the :ref:`Flashing OHOS image <Flashing_ohos>`.
+
+Zephyr image
+------------
+
+1. Source the environment with proper template settings, flavour being *zephyr*
+ and target machine being *96b-avenger96*:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/zephyr . ./sources/poky/oe-init-build-env build-ohos-zephyr
+
+2. You will find yourself in the newly created build directory. Call *bitbake*
+ to build the image. The image name is the name of the Zephyr application.
+
+.. code-block:: console
+
+ $ MACHINE=96b-avenger96 bitbake zephyr-philosophers
+
+3. The output file will be located in the build directory
+ *./tmp-newlib/deploy/images/96b-avenger96/*.
+
+.. _Flashing_ohos:
+
+Flashing OHOS image
+*******************
+
+For Linux, STM meta-layer provide a convenient shell script that helps you to
+create an SD card image. You can also use the `STM32 Cube Programmer <https://wiki.dh-electronics.com/index.php/Avenger96_Image_Programming>`__.
+
+For Zephyr, there is no automation as for now. To have the ELF file in the filesystem:
+
+* Copy the image manually to the filesystem using a method of your choice
+* Include it in the image before flashing the card/eMMC
+* Copy the file manually to the card or just *scp* it to the board after you set up networking.
+
+Linux image
+===========
+
+SD card
+-------
+
+The Avenger96 board supports multiple boot options which are selected by the
+DIP-switch S3. Make sure the boot switch is set to boot from the SD-Card.
+
+To set the boot option from the SD card using DIP-switch S3, set the BOOT 0
+(Switch 1) and BOOT 2 (Switch 3) to 1 and set BOOT 1 (Switch 2) to 0 on the
+circuit board.
+
+For more information on Avenger96 boot options, see `Getting Started with the Avenger96 <https://www.96boards.org/documentation/consumer/avenger96/getting-started/#starting-the-board-for-the-first-time>`__.
+
+1. After the image is built, run the following script with flash layout TSV file provided as an argument. From the build directory created
+ during the environment source. For example, if you are using
+ openharmony-image-base run the following command:
+
+.. code-block:: console
+
+ $ cd tmp/deploy/images/stm32mp1-av96
+ $ ./scripts/create_sdcard_from_flashlayout.sh ./flashlayout_openharmony-image-base/extensible/FlashLayout_sdcard_stm32mp157a-av96-extensible.tsv
+
+2. The following output is displayed. For the image to be flashed to the card,
+ copy and paste the commands to the terminal to flash the image onto the
+ card.
+
+::
+
+ [WARNING]: A previous raw image are present on this directory
+ [WARNING]: ./flashlayout_openharmony-image-base/extensible/../../FlashLayout_sdcard_stm32mp157a-av96-extensible.raw
+ [WARNING]: would you like to erase it: [Y/n]
+
+ Create Raw empty image: ./flashlayout_openharmony-image-base/extensible/../../FlashLayout_sdcard_stm32mp157a-av96-extensible.raw of 2368MB
+ Create partition table:
+ [CREATED] part 1: fsbl1 [partition size 256.0 KiB]
+ [CREATED] part 2: fsbl2 [partition size 256.0 KiB]
+ [CREATED] part 3: ssbl [partition size 2.0 MiB]
+ [CREATED] part 4: boot [partition size 64.0 MiB]
+ [CREATED] part 5: vendorfs [partition size 16.0 MiB]
+ [CREATED] part 6: rootfs [partition size 2.2 GiB]
+
+ Partition table from ./flashlayout_openharmony-image-base/extensible/../../FlashLayout_sdcard_stm32mp157a-av96-extensible.raw
+
+ Populate raw image with image content:
+ [ FILLED ] part 1: fsbl1, image: arm-trusted-firmware/tf-a-stm32mp157a-av96-trusted.stm32
+ [ FILLED ] part 2: fsbl2, image: arm-trusted-firmware/tf-a-stm32mp157a-av96-trusted.stm32
+ [ FILLED ] part 3: ssbl, image: bootloader/u-boot-stm32mp157a-av96-trusted.stm32
+ [ FILLED ] part 4: boot, image: st-image-bootfs-poky-stm32mp1-av96.ext4
+ [ FILLED ] part 5: vendorfs, image: st-image-vendorfs-poky-stm32mp1-av96.ext4
+ [ FILLED ] part 6: rootfs, image: openharmony-image-base-stm32mp1-av96.ext4
+
+ ###########################################################################
+ ###########################################################################
+
+ RAW IMAGE generated: ./flashlayout_openharmony-image-base/extensible/../../FlashLayout_sdcard_stm32mp157a-av96-extensible.raw
+
+ WARNING: before to use the command dd, please umount all the partitions
+ associated to SDCARD.
+ sudo umount `lsblk --list | grep mmcblk0 | grep part | gawk '{ print $7 }' | tr '\n' ' '`
+
+ To put this raw image on sdcard:
+ sudo dd if=./flashlayout_openharmony-image-base/extensible/../../FlashLayout_sdcard_stm32mp157a-av96-extensible.raw of=/dev/mmcblk0 bs=8M conv=fdatasync status=progress
+
+ (mmcblk0 can be replaced by:
+ sdX if it's a device dedicated to receive the raw image
+ (where X can be a, b, c, d, e)
+
+ ###########################################################################
+ ###########################################################################
+
+3. To unmount the card, call the ``umount`` command printed by the
+ ``create_sdcard_from_flashlayout.sh`` script.
+
+4. To flash the image card, call the ``dd`` command printed by the
+ ``create_sdcard_from_flashlayout.sh`` script.
+
+5. Put the card to the board and turn it on.
+
+STM32 Cube Programmer
+---------------------
+
+After you build the image, follow the instructions in `Avenger96 Image Programming <https://wiki.dh-electronics.com/index.php/Avenger96_Image_Programming>`_,
+pointing the program to the
+*./tmp/deploy/images/stm32mp1-av96/flashlayout_openharmony-image-base/trusted/FlashLayout_emmc_stm32mp157a-av96-trusted.tsv*
+flash layout file.
+
+.. _zephyr-image-1:
+
+Zephyr image
+============
+
+**Prerequisites**
+
+* Linux is running on the board.
+* Make sure that Linux is built with *remoteproc* support. To check status of remoteproc do:
+
+.. code-block:: console
+
+ root@stm32mp1-av96:~# dmesg | grep remoteproc
+ [ 2.336231] remoteproc remoteproc0: m4 is available
+
+1. Copy the Zephyr image to the board using a method of your choice.
+
+2. Check what the ``remoteproc`` framework knows about the name and location of
+ the firmware file. The default values are presented as follows. Empty path
+ defaults to ``/lib/firmware``:
+
+::
+
+ root@stm32mp1-av96:~# cat /sys/module/firmware_class/parameters/path
+ <empty>
+
+ root@stm32mp1-av96:~# cat /sys/class/remoteproc/remoteproc0/firmware
+ rproc-m4-fw
+
+3. Configure the name and the location to suit your needs. For example, the
+ firmware is located in ``/root/zephyr.elf``:
+
+::
+
+ root@stm32mp1-av96:~# echo "/root" > /sys/module/firmware_class/parameters/path
+ root@stm32mp1-av96:~# echo "zephyr.elf" > /sys/class/remoteproc/remoteproc0/firmware
+
+4. Power up the Cortex-M4 core:
+
+::
+
+ root@stm32mp1-av96:~# echo start > /sys/class/remoteproc/remoteproc0/state
+ remoteproc remoteproc0: powering up m4
+ remoteprocroc remoteproc0: Booting fw image rproc-m4-fw, size 591544
+ rproc-srm-core m4@0:m4_system_resources: bound m4@0:m4_system_resources:m4_led (ops 0xc0be1210)
+ remoteproc remoteproc0: remote processor m4 is now
+
+5. Firmware output can be inspected with:
+
+::
+
+ root@stm32mp1-av96:~# cat /sys/kernel/debug/remoteproc/remoteproc0/trace0
+ Philosopher 5 [C:-2] STARVING
+ Philosopher 3 [P: 0] DROPPED ONE FORK
+ Philosopher 3 [P: 0] THINKING [ 25 ms ]
+ Philosopher 2 [P: 1] EATING [ 425 ms ]
+ Philosopher 3 [P: 0] STARVING
+ Philosopher 4 [C:-1] STARVING
+ Philosopher 4 [C:-1] HOLDING ONE FORK
+ Philosopher 4 [C:-1] EATING [ 800 ms ]
+ Philosopher 3 [P: 0] HOLDING ONE FORK
+ Philosopher 2 [P: 1] DROPPED ONE FORK
+ Philosopher 2 [P: 1] THINKING [ 725 ms ]
+ Philosopher 1 [P: 2] EATING [ 225 ms ]
+
+There is no fully-featured console available in Linux yet, so typing commands
+to the Zephyr application is not possible.
+
+Testing the board
+*****************
+
+Serial port
+===========
+
+To connect the USB converter serial port to the low-speed connector, see `Hardware User Manual <https://github.com/96boards/documentation/blob/master/consumer/avenger96/hardware-docs/files/avenger96-hardware-user-manual.pdf>`__.
+
+.. warning::
+
+ * The low speed connector is 1.8V tolerant, therefore the converter must be 1.8V tolerant.
+ * Do not connect 5V or 3.3V tolerant devices to the connector to avoid SoC damage.
+
+Ethernet
+========
+
+Wired connection works out of the box. You can use standard tools like ``ip``,
+``ifconfig`` to configure the connection. The connection seems to have stable
+1Gb/s bandwidth.
+
+USB Host
+========
+
+Just plug something to the USB port. The board seems to work fine with an
+external 500GB USB 3.0 HDD.
+
+::
+
+ root@stm32mp1-av96:~# lsusb
+ Bus 002 Device 003: ID 0930:0b1f Toshiba Corp.
+ Bus 002 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
+ Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+ root@stm32mp1-av96:~# lsusb -t
+ /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/2p, 480M
+ |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
+ |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
+ /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
+ root@stm32mp1-av96:~# mount | grep sda
+ /dev/sda1 on /home/root/sda1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
+
+USB OTG
+=======
+
+The board supports that feature. For now it only works in DFU mode with STM32
+Cube Programmer. Using the board as USB Gadget is currently under development.
+
+eMMC
+====
+
+It can be used to store the firmware with STM32 Cube Programmer. It can also be
+mounted under Linux booted from another medium:
+
+::
+
+ root@stm32mp1-av96:~# mount /dev/mmcblk2p4 emmc/
+ [ 3006.721643] EXT4-fs (mmcblk2p4): recovery complete
+ [ 3006.726627] EXT4-fs (mmcblk2p4): mounted filesystem with ordered data mode. Opts: (null)
+ [ 3006.733931] ext4 filesystem being mounted at /home/root/emmc supports timestamps until 2038 (0x7fffffff)
+ root@stm32mp1-av96:~# ls -l emmc
+ drwxr-xr-x 2 root root 1024 Mar 9 12:34 bin
+ drwxr-xr-x 2 root root 1024 Mar 9 12:34 boot
+ drwxr-xr-x 2 root root 1024 Mar 9 12:34 dev
+ drwxr-xr-x 17 root root 1024 Mar 9 12:34 etc
+ drwxr-xr-x 3 root root 1024 Mar 9 12:34 home
+ drwxr-xr-x 3 root root 1024 Mar 9 12:34 lib
+ drwx------ 2 root root 12288 Jan 12 2021 lost+found
+ drwxr-xr-x 2 root root 1024 Mar 9 12:34 media
+ drwxr-xr-x 2 root root 1024 Mar 9 12:34 mnt
+ dr-xr-xr-x 2 root root 1024 Mar 9 12:34 proc
+ drwxr-xr-x 2 root root 1024 Jan 1 2000 run
+ drwxr-xr-x 2 root root 1024 Mar 9 12:34 sbin
+ dr-xr-xr-x 2 root root 1024 Mar 9 12:34 sys
+ lrwxrwxrwx 1 root root 8 Mar 9 12:34 tmp -> /var/tmp
+ drwxr-xr-x 10 root root 1024 Mar 9 12:34 usr
+ drwxr-xr-x 8 root root 1024 Mar 9 12:34 var
+
+Radio
+=====
+
+Radio relies on proprietary BRCM firmware. It is already included in the image.
+
+WiFi
+----
+
+WiFi can be controlled with ``wpa_supplicant``, which is a standard Linux tool.
+Please refer to the tool manual for the details.
+
+Example ``wpa_suppliant`` configs look like below. Assuming the config is saved
+in a file named ``wpa.conf`` and the interface is named ``wlan0``, WiFi can be
+brought up with ``wpa_supplicant -i wlan0 -c ./wpa.conf``:
+
+::
+
+ # Access Point mode example configuration
+ fast_reauth=1
+ update_config=1
+
+ ap_scan=2
+ network={
+ ssid="Avenger96 AP"
+ mode=2
+ frequency=2412
+ key_mgmt=WPA-PSK
+ proto=RSN
+ pairwise=CCMP
+ psk="PlaintextPasswordsAreGreat"
+ }
+
+::
+
+ # Connection to an open network with broadcasted SSID
+ network={
+ ssid="0xDEADBEEF"
+ key_mgmt=NONE
+ }
+
+Bluetooth
+---------
+
+Bluetooth be controlled with ``bluetoothctl``, which is a standard Linux tool.
+Please refer to the tool manual for the details. Devices scanning can be
+enabled as follows:
+
+::
+
+ root@stm32mp1-av96:~# bluetoothctl
+ Agent registered
+ [CHG] Controller 00:9D:6B:AA:77:68 Pairable: yes
+ [bluetooth]# power on
+ Changing power on succeeded
+ [CHG] Controller 00:9D:6B:AA:77:68 Powered: yes
+ [bluetooth]# discoverable on
+ Changing discoverable on succeeded
+ [CHG] Controller 00:9D:6B:AA:77:68 Discoverable: yes
+ [bluetooth]# scan on
+ Discovery started
+ [CHG] Controller 00:9D:6B:AA:77:68 Discovering: yes
+ [NEW] Device E2:A0:50:99:C9:61 Hue Lamp
+ [NEW] Device 57:2D:D5:48:8C:D0 57-2D-D5-48-8C-D0
+ [NEW] Device E4:04:39:65:9C:2A TomTom GPS Watch
+ [NEW] Device C0:28:8D:49:67:7E C0-28-8D-49-67-7E
+
+Pairing and establishing connection is possible with ``pair`` and ``connect``
+commands.
diff --git a/docs/hardware-support/boards/96b-nitrogen.rst b/docs/hardware-support/boards/96b-nitrogen.rst
new file mode 100644
index 0000000000000000000000000000000000000000..0c1da4e37e188f9c65eccba467c7b03342bf4eb0
--- /dev/null
+++ b/docs/hardware-support/boards/96b-nitrogen.rst
@@ -0,0 +1,107 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+.. _nitrogen:
+
+96Boards Nitrogen
+#################
+
+.. contents::
+ :depth: 3
+
+Overview
+********
+
+Nitrogen, a compliant IoT Edition board provides economical and compact BLE
+solutions for various IoT projects. This board includes the below features:
+
+* Nordic nRF52832 microcontroller
+* 64 KB of RAM
+* 512 KB on-board flash storage.
+
+Nitrogen hardware supports the Nordic Semiconductor nRF52832 ARM Cortex-M4F
+CPU.
+
+Hardware
+********
+
+* For detailed specifications, see `Nitrogen product page on the 96Boards website <https://www.96boards.org/product/nitrogen/>`_.
+* For hardware user manual, see `Seeed wiki <https://wiki.seeedstudio.com/BLE_Nitrogen/>`_.
+* For hardware schematics, see `Seeed Document <https://github.com/SeeedDocument/BLE-Nitrogen/tree/master/res>`_.
+
+For more details on 96Boards Nitrogen, see `Nitrogen product page <https://www.96boards.org/product/nitrogen/>`_.
+
+Working with the board
+**********************
+
+Supported image
+===============
+
+* zephyr-philosophers
+
+Building an application
+=======================
+
+OpenHarmony OS Zephyr flavour is based on Zephyr kernel.
+
+* Source the environment with proper template settings, flavour being zephyr and target machine being 96b-nitrogen:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/zephyr . ./sources/poky/oe-init-build-env build-ohos-zephyr
+
+* You will find yourself in the newly created build directory. Call bitbake to build the image. The supported image name is zephyr-philosophers.
+
+.. code-block:: console
+
+ $ MACHINE=96b-nitrogen bitbake zephyr-philosophers
+
+MACHINE variable can be set up in conf/local.conf file under build directory or via command line.
+
+
+Flashing an application
+=======================
+
+Installing pyOCD
+----------------
+
+pyOCD is an open source Python package for programming and debugging Arm Cortex-M microcontrollers using multiple supported types of USB debug probes. It is fully cross-platform, with support for Linux.
+
+* The latest stable version of pyOCD can be installed via `pip <https://pip.pypa.io/en/stable/>`_ as follows:
+
+.. code-block:: console
+
+ $ pip install --pre -U pyOCD
+
+* To install the latest pre-release version from the HEAD of the master branch, do the following:
+
+.. code-block:: console
+
+ $ pip install --pre -U git+https://github.com/mbedmicro/pyOCD.git
+
+* To install directly from the source by cloning the git repository, do the following:
+
+.. code-block:: console
+
+ $ python setup.py install
+
+* Verify that the board is detected by pyOCD by executing the command:
+
+.. code-block:: console
+
+ $ pyOCD-flashtool -l
+
+.. note::
+
+ When *ValueError: The device has no langid* error is displayed due to lack of permission, perform the instructions as suggested in https://github.com/pyocd/pyOCD/tree/master/udev.
+
+How to flash
+------------
+
+* To flash the image, execute the command used to build the image with -c flash_usb appended.
+ For example, to flash the already built zephyr-philosophers image, do:
+
+.. code-block:: console
+
+ $ MACHINE=96b-nitrogen bitbake zephyr-philosophers -c flash_usb
diff --git a/docs/hardware-support/boards/index.rst b/docs/hardware-support/boards/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..7ec39867decab6008de6d27bc90cc220c94fdb83
--- /dev/null
+++ b/docs/hardware-support/boards/index.rst
@@ -0,0 +1,16 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Supported Boards
+################
+
+This section details the boards supported as part of OpenHarmony.
+
+.. toctree::
+ :maxdepth: 1
+
+ 96b-Avenger
+ 96b-nitrogen
+ seco-intel-b68
+ seco-imx8mm-c61
diff --git a/docs/hardware-support/boards/seco-imx8mm-c61.rst b/docs/hardware-support/boards/seco-imx8mm-c61.rst
new file mode 100644
index 0000000000000000000000000000000000000000..a84230f7f0dfeb40476266fab6867e0d029dc827
--- /dev/null
+++ b/docs/hardware-support/boards/seco-imx8mm-c61.rst
@@ -0,0 +1,182 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+SBC-C61 SECO
+############
+
+.. contents::
+ :depth: 3
+
+Overview
+********
+
+SBC-C61 is an SBC built upon the NXP i.MX 8M mini Application Processors
+characterised by HEVC/VP9 decoding in 1080p60. As for the memory, it features a
+LPDDR4 RAM. The range of connectivity options is particularly broad, with
+optional Wi-Fi and BT LE 4.2 and optionally soldered on-board LTE Cat 4 Modem
+with microSIM slot or eSIM. Interestingly, it also features a Cortex-M4, that
+is real-time operating system capable for serving real-time applications that
+process data as it comes in without buffer delays.
+
+Hardware
+********
+
+For more detailed specifications of SBC-C61 SECO board, see `SBC-C61 Specification <https://www.seco.com/en/products/sbc-c61>`__.
+
+Working with the board
+**********************
+
+Supported image
+===============
+
+.. list-table:: Supported images
+ :widths: auto
+ :header-rows: 1
+
+ * - Image Name
+ - Size
+ - Description
+ * - openharmony-image-base
+ - Approximate 100-200 MB
+ - OpenHarmony image including the base OS software stack
+
+
+Building OHOS image
+===================
+
+To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
+
+Linux image
+-----------
+
+1. Source the environment with proper template settings, flavour being ``linux`` and target machine being ``seco-imx8mm-c61``.
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+
+2. You will find yourself in the newly created build directory. Call ``bitbake`` to build the image. The supported image is ``openharmony-image-base``.
+
+.. code-block:: console
+
+ $ MACHINE=seco-imx8mm-c61 bitbake openharmony-image-base
+
+To generate images for eMMC, refer to the following flashing procedure.
+
+Flashing OHOS image
+*******************
+
+Linux image
+===========
+
+MMC Storage
+-----------
+
+**Prerequisites**
+
+* USB To UART adapter
+* USB to OTG adapter
+* Download and install `mfgtools <https://github.com/NXPmicro/mfgtools>`__
+* Linux Host
+
+To flash OHOS using USB to OTG adapter, perform the following steps:
+
+#. Short circuit pin 1 and 2 of CN52 pin header to enter the Serial Download mode.
+#. Connect USB to OTG adapter to your host PC
+#. Navigate to the inside build output directory:
+
+ .. code-block:: console
+
+ $ cd tmp/deploy/images/seco-imx8mm-c61/
+
+#. Unzip build output using Gzip software:
+
+ .. code-block:: console
+
+ $ gzip -d openharmony-image-base-seco-imx8mm-c61.wic.gz
+
+#. To write uboot and image(p1:kernel, p2:dtb, rootfs) into c61 mmc via mfgtools:
+
+ .. code-block:: console
+
+ $ sudo uuu -b emmc_all imx-boot-seco-imx8mm-c61-emmc.bin-flash_evk openharmony-image-base-seco-imx8mm-c61.wic
+
+#. Power ON SBC-C61
+#. Remove **CN52 short circuit**
+#. Press the reset button
+
+Testing the board
+*****************
+
+Ethernet
+========
+
+You can use standard tools like ``ip``, ``ifconfig`` to configure the connection.
+
+::
+
+ root@seco-imx8mm-c61:~# ifconfig
+ eth0 Link encap:Ethernet HWaddr 1A:20:58:83:70:F0
+ UP BROADCAST MULTICAST MTU:1500 Metric:1
+ RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+ TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+ collisions:0 txqueuelen:1000
+ RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
+
+USB Host
+========
+
+::
+
+ root@seco-imx8mm-c61:~# lsusb
+ Bus 001 Device 003: ID 058f:6387 Alcor Micro Corp. Flash Drive
+ Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
+ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+
+eMMC
+====
+
+::
+
+ root@seco-imx8mm-c61:~# fdisk -l /dev/mmcblk0
+ Disk /dev/mmcblk0: 59 GB, 63585648640 bytes, 124190720 sectors
+ 1940480 cylinders, 4 heads, 16 sectors/track
+ Units: sectors of 1 * 512 = 512 bytes
+
+ Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
+ /dev/mmcblk0p1 * 64,0,1 893,3,4 8192 114403 106212 51.8M c Win95 FAT32 (LBA)
+ /dev/mmcblk0p2 896,0,1 1023,3,32 114688 558903 444216 216M 83 Linux
+
+Loaded Modules
+==============
+
+::
+
+ root@seco-imx8mm-c61:~# lsmod
+ Module Size Used by
+ nfc 90112 0
+ bluetooth 409600 8
+ ecdh_generic 16384 1 bluetooth
+ ecc 32768 1 ecdh_generic
+ rfkill 36864 3 nfc,bluetooth
+ ipv6 442368 26
+ caam_jr 196608 0
+ caamhash_desc 16384 1 caam_jr
+ caamalg_desc 36864 1 caam_jr
+ crypto_engine 16384 1 caam_jr
+ rng_core 24576 1 caam_jr
+ authenc 16384 1 caam_jr
+ libdes 24576 1 caam_jr
+ snd_soc_simple_card 20480 0
+ fsl_imx8_ddr_perf 20480 0
+ crct10dif_ce 20480 1
+ snd_soc_simple_card_utils 24576 1 snd_soc_simple_card
+ rtc_snvs 16384 1
+ snvs_pwrkey 16384 0
+ caam 40960 1 caam_jr
+ clk_bd718x7 16384 0
+ error 24576 4 caamalg_desc,caamhash_desc,caam,caam_jr
+ imx8mm_thermal 16384 0
+ snd_soc_fsl_sai 20480 0
+ imx_cpufreq_dt 16384 0
diff --git a/docs/hardware-support/boards/seco-intel-b68.rst b/docs/hardware-support/boards/seco-intel-b68.rst
new file mode 100644
index 0000000000000000000000000000000000000000..0e48e84a51f8aa6e396c51bdde7637c18ea035de
--- /dev/null
+++ b/docs/hardware-support/boards/seco-intel-b68.rst
@@ -0,0 +1,212 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+SBC-B68-eNUC SECO
+#################
+
+.. contents::
+ :depth: 3
+
+Overview
+********
+
+The SBC-B68-eNUC is a flexible and expandable full industrial x86 embedded NUC™ SBC with the Intel® Atom X Series, Intel® Celeron® J / N
+Series and Intel® Pentium® N Series (formerly code name Apollo Lake) Processors. Also available in industrial temperature version, the board
+offers wide range of connectivity options through WLAN and WWAN M.2 slots as well as wide input voltage range. Featuring Quad Channel
+soldered down LPDDR4-2400 memory, up to 8GB, thanks to its versatile expansion capabilities it is particularly suitable for embedded
+applications like HMI, multimedia devices, industrial IoT and industrial automation.
+
+Hardware
+********
+
+For more detailed specifications of SBC-B68-eNUC SECO board, see `SBC-B68-eNUC Specification <https://www.seco.com/en/products/sbc-b68-enuc>`__.
+
+
+Working with the board
+**********************
+
+Supported images
+================
+
+.. list-table:: Supported images
+ :widths: auto
+ :header-rows: 1
+
+ * - Image Name
+ - Size
+ - Description
+ * - openharmony-image-base
+ - Approximate 100-200 MB
+ - OpenHarmony image including the base OS software stack
+ * - openharmony-image-extra
+ - Approximate 100-200 MB
+ - OpenHarmony Wayland image including the base OS software stack
+
+
+Building OHOS image
+===================
+
+To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
+
+Linux image
+-----------
+
+1. Source the environment with proper template settings, flavour being *linux* and target machine being *seco-intel-b68*.
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+
+2. You will find yourself in the newly created build directory. Call *bitbake* to build the image. For example, if you are using *openharmony-image-base* run the following command:
+
+.. code-block:: console
+
+ $ MACHINE=seco-intel-b68 bitbake openharmony-image-base
+
+To generate images for SSD Disk, refer to the following flashing OHOS image section.
+
+Flashing OHOS image
+*******************
+
+.. _linux-image-2:
+
+Linux image
+===========
+
+USB Storage
+-----------
+
+**Prerequisites**
+
+* Mini DisplayPort to HDMI converter cable
+* HDMI Monitor
+* USB Storage
+* Linux Host
+
+To flash OHOS using USB storage, perform the following steps:
+
+**Prepare OHOS bootable USB**
+
+#. Connect USB storage to your host PC.
+
+#. Run the following command in your local host:
+
+.. code-block:: console
+
+ $ dd if=tmp/deploy/images/seco-intel-b68/openharmony-image-base-seco-intel-b68.wic of=/dev/sdbX
+
+**Run OHOS**
+
+#. Connect bootable USB to target
+
+#. Connect mini DP++ to HDMI adapter to HDMI monitor
+
+#. Power on B68 and press **Esc** to enter **BIOS** mode.
+
+#. Go to Save and Exit submenu
+
+#. Select the bootable USB device under **Boot Override** and press Enter.
+
+
+Testing the board
+*****************
+
+Ethernet
+========
+
+Wired connection works out of the box. You can use standard tools like ``ip``, ``ifconfig`` to configure the connection.
+
+USB Host
+========
+
+::
+
+ root@seco-intel-b68:~# lsusb
+ /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 5000M
+ /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 480M
+
+eMMC
+====
+
+::
+
+ root@seco-intel-b68:~# fdisk -l /dev/mmcblk1
+ Disk /dev/mmcblk1: 29 GB, 31268536320 bytes, 61071360 sectors
+ 954240 cylinders, 4 heads, 16 sectors/track
+ Units: sectors of 1 * 512 = 512 bytes
+
+PCI buses
+=========
+
+::
+
+ root@seco-intel-b68:~# lspci
+ 00:00.0 Host bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge (rev 0b)
+ 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 500 (rev 0b)
+ 00:0e.0 Audio device: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev 0b)
+ 00:0f.0 Communication controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Trusted Execution Engine (rev 0b)
+ 00:12.0 SATA controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SATA AHCI Controller (rev 0b)
+ 00:13.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #3 (rev fb)
+ 00:13.3 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #4 (rev fb)
+ 00:15.0 USB controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI (rev 0b)
+ 00:16.0 Signal processing controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series I2C Controller #1 (rev 0b)
+ 00:16.3 Signal processing controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series I2C Controller #4 (rev 0b)
+ 00:17.0 Signal processing controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series I2C Controller #5 (rev 0b)
+ 00:17.1 Signal processing controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series I2C Controller #6 (rev 0b)
+ 00:18.0 Signal processing controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller #1 (rev 0b)
+ 00:18.2 Signal processing controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller #3 (rev 0b)
+ 00:1b.0 SD Host controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SDXC/MMC Host Controller (rev 0b)
+ 00:1c.0 SD Host controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series eMMC Controller (rev 0b)
+ 00:1f.0 ISA bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface (rev 0b)
+ 00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller (rev 0b)
+ 01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
+ 02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
+
+Loaded Modules
+==============
+
+::
+
+ root@seco-intel-b68:~# lsmod
+ Module Size Used by
+ nfc 73728 0
+ bnep 20480 2
+ uio 20480 0
+ snd_hda_codec_hdmi 53248 1
+ iwlwifi 299008 0
+ cfg80211 688128 1 iwlwifi
+ snd_hda_codec_cirrus 20480 1
+ snd_hda_codec_generic 65536 1 snd_hda_codec_cirrus
+ ledtrig_audio 16384 1 snd_hda_codec_generic
+ intel_rapl_msr 16384 0
+ snd_soc_skl 114688 0
+ snd_soc_sst_ipc 16384 1 snd_soc_skl
+ snd_soc_sst_dsp 24576 1 snd_soc_skl
+ snd_hda_ext_core 20480 1 snd_soc_skl
+ snd_soc_acpi_intel_match 36864 1 snd_soc_skl
+ snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl
+ snd_soc_core 200704 1 snd_soc_skl
+ intel_rapl_common 20480 1 intel_rapl_msr
+ snd_compress 20480 1 snd_soc_core
+ ac97_bus 16384 1 snd_soc_core
+ intel_pmc_bxt 16384 0
+ intel_telemetry_pltdrv 20480 0
+ intel_telemetry_core 16384 1 intel_telemetry_pltdrv
+ snd_hda_intel 32768 0
+ x86_pkg_temp_thermal 16384 0
+ snd_intel_dspcfg 16384 2 snd_hda_intel,snd_soc_skl
+ snd_hda_codec 98304 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_cirrus
+ coretemp 16384 0
+ snd_hda_core 65536 7 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_cirrus,snd_soc_skl
+ snd_pcm 86016 7 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_compress,snd_soc_core,snd_soc_skl,snd_hda_core
+ snd_timer 32768 1 snd_pcm
+ i915 1888256 5
+ mei_me 32768 0
+ video 40960 1 i915
+ mei 81920 1 mei_me
+
+Video
+=====
+
+Output video tested with *DP++* to *HDMI* adapter.
diff --git a/docs/hardware-support/index.rst b/docs/hardware-support/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..7c19d138306ed5587eb3fd9ef4509b520b26c156
--- /dev/null
+++ b/docs/hardware-support/index.rst
@@ -0,0 +1,18 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+.. _HardwareSupport:
+
+Hardware support in OpenHarmony
+###############################
+
+This section details the hardware (including virtualized) supported as part of
+OpenHarmony.
+
+.. toctree::
+ :maxdepth: 2
+
+ boards/index
+ virtual-boards/index
+ adding-hardware-support
diff --git a/docs/hardware-support/virtual-boards/index.rst b/docs/hardware-support/virtual-boards/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..f1d55ccf31d13a25deaadca8b89e6f7d4c264f79
--- /dev/null
+++ b/docs/hardware-support/virtual-boards/index.rst
@@ -0,0 +1,16 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Supported Virtual Targets
+#########################
+
+This section details the support for virtual targets in OpenHarmony.
+
+.. toctree::
+ :maxdepth: 1
+
+ qemux86-64
+ qemux86
+ qemuarm
+ qemuarm64
diff --git a/docs/hardware-support/virtual-boards/qemuarm.rst b/docs/hardware-support/virtual-boards/qemuarm.rst
new file mode 100644
index 0000000000000000000000000000000000000000..ce6634cb1ced31bc9346e0138f2f24e566d5e8fb
--- /dev/null
+++ b/docs/hardware-support/virtual-boards/qemuarm.rst
@@ -0,0 +1,63 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Qemu ARM
+########
+
+.. contents::
+ :depth: 4
+
+Overview
+********
+
+OpenHarmony supports running the software stack into an virtual invironment using Qemu.
+
+Building OHOS image
+===================
+
+To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
+
+Building a Linux image
+======================
+
+Supported images
+----------------
+
+.. list-table:: Supported images
+ :widths: auto
+ :header-rows: 1
+
+ * - Image Name
+ - Description
+ * - openharmony-image-base
+ - OpenHarmony image including the base OS software stack
+ * - openharmony-image-extra
+ - OpenHarmony Wayland image including the base OS software stack
+
+Build steps
+-----------
+
+1. Source the environment with proper template settings, flavour being *linux*
+ and target machine being *qemuarm*. Pay attention to how relative paths are
+ constructed. The value of *TEMPLATECONF* is relative to the location of the
+ build directory *./build-ohos-linux*, that is going to be created after
+ this step:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+
+2. You will find yourself in the newly created build directory. Call *bitbake*
+ to build the image. For example, if you are using *openharmony-image-base*
+ run the following command:
+
+.. code-block:: console
+
+ $ MACHINE=qemuarm bitbake openharmony-image-base
+
+Once the image is done, you can run the Qemu usin the provided script wrapper:
+
+.. code-block:: console
+
+ $ MACHINE=qemuarm runqemu
diff --git a/docs/hardware-support/virtual-boards/qemuarm64.rst b/docs/hardware-support/virtual-boards/qemuarm64.rst
new file mode 100644
index 0000000000000000000000000000000000000000..48a39a340cc7a6a4d6f78485c38620052d6c623c
--- /dev/null
+++ b/docs/hardware-support/virtual-boards/qemuarm64.rst
@@ -0,0 +1,63 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Qemu ARM64
+##########
+
+.. contents::
+ :depth: 4
+
+Overview
+********
+
+OpenHarmony supports running the software stack into an virtual invironment using Qemu.
+
+Building OHOS image
+===================
+
+To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
+
+Building a Linux image
+======================
+
+Supported images
+----------------
+
+.. list-table:: Supported images
+ :widths: auto
+ :header-rows: 1
+
+ * - Image Name
+ - Description
+ * - openharmony-image-base
+ - OpenHarmony image including the base OS software stack
+ * - openharmony-image-extra
+ - OpenHarmony Wayland image including the base OS software stack
+
+Build steps
+-----------
+
+1. Source the environment with proper template settings, flavour being *linux*
+ and target machine being *qemuarm64*. Pay attention to how relative paths are
+ constructed. The value of *TEMPLATECONF* is relative to the location of the
+ build directory *./build-ohos-linux*, that is going to be created after
+ this step:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+
+2. You will find yourself in the newly created build directory. Call *bitbake*
+ to build the image. For example, if you are using *openharmony-image-base*
+ run the following command:
+
+.. code-block:: console
+
+ $ MACHINE=qemuarm64 bitbake openharmony-image-base
+
+Once the image is done, you can run the Qemu usin the provided script wrapper:
+
+.. code-block:: console
+
+ $ MACHINE=qemuarm64 runqemu
diff --git a/docs/hardware-support/virtual-boards/qemux86-64.rst b/docs/hardware-support/virtual-boards/qemux86-64.rst
new file mode 100644
index 0000000000000000000000000000000000000000..64761b5db4627664b91b6d6c80b5eb9cb1cd3441
--- /dev/null
+++ b/docs/hardware-support/virtual-boards/qemux86-64.rst
@@ -0,0 +1,63 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Qemu X86-64
+###########
+
+.. contents::
+ :depth: 4
+
+Overview
+********
+
+OpenHarmony supports running the software stack into an virtual invironment using Qemu.
+
+Building OHOS image
+===================
+
+To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
+
+Building a Linux image
+======================
+
+Supported images
+----------------
+
+.. list-table:: Supported images
+ :widths: auto
+ :header-rows: 1
+
+ * - Image Name
+ - Description
+ * - openharmony-image-base
+ - OpenHarmony image including the base OS software stack
+ * - openharmony-image-extra
+ - OpenHarmony Wayland image including the base OS software stack
+
+Build steps
+-----------
+
+1. Source the environment with proper template settings, flavour being *linux*
+ and target machine being *qemux86-64*. Pay attention to how relative paths are
+ constructed. The value of *TEMPLATECONF* is relative to the location of the
+ build directory *./build-ohos-linux*, that is going to be created after
+ this step:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+
+2. You will find yourself in the newly created build directory. Call *bitbake*
+ to build the image. For example, if you are using *openharmony-image-base*
+ run the following command:
+
+.. code-block:: console
+
+ $ MACHINE=qemux86-64 bitbake openharmony-image-base
+
+Once the image is done, you can run the Qemu usin the provided script wrapper:
+
+.. code-block:: console
+
+ $ MACHINE=qemux86-64 runqemu
diff --git a/docs/hardware-support/virtual-boards/qemux86.rst b/docs/hardware-support/virtual-boards/qemux86.rst
new file mode 100644
index 0000000000000000000000000000000000000000..29c2a29c51fb055b0e24c7a395726f6535150b74
--- /dev/null
+++ b/docs/hardware-support/virtual-boards/qemux86.rst
@@ -0,0 +1,63 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Qemu X86
+########
+
+.. contents::
+ :depth: 4
+
+Overview
+********
+
+OpenHarmony supports running the software stack into an virtual invironment using Qemu.
+
+Building OHOS image
+===================
+
+To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
+
+Building a Linux image
+======================
+
+Supported images
+----------------
+
+.. list-table:: Supported images
+ :widths: auto
+ :header-rows: 1
+
+ * - Image Name
+ - Description
+ * - openharmony-image-base
+ - OpenHarmony image including the base OS software stack
+ * - openharmony-image-extra
+ - OpenHarmony Wayland image including the base OS software stack
+
+Build steps
+-----------
+
+1. Source the environment with proper template settings, flavour being *linux*
+ and target machine being *qemux86*. Pay attention to how relative paths are
+ constructed. The value of *TEMPLATECONF* is relative to the location of the
+ build directory *./build-ohos-linux*, that is going to be created after
+ this step:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+
+2. You will find yourself in the newly created build directory. Call *bitbake*
+ to build the image. For example, if you are using *openharmony-image-base*
+ run the following command:
+
+.. code-block:: console
+
+ $ MACHINE=qemux86 bitbake openharmony-image-base
+
+Once the image is done, you can run the Qemu usin the provided script wrapper:
+
+.. code-block:: console
+
+ $ MACHINE=qemux86 runqemu
diff --git a/docs/index.rst b/docs/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..d94c01753fb0fc6f7d7ce9e0c020cb7106c6815c
--- /dev/null
+++ b/docs/index.rst
@@ -0,0 +1,17 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Build system documentation
+##########################
+
+.. toctree::
+ :maxdepth: 1
+
+ openharmony-quick-build
+ yocto-build-system/index
+ repo-workspace
+ build-flavours/index
+ ohos-build/index
+ demos/index
+ hardware-support/index
diff --git a/docs/ohos-build/index.rst b/docs/ohos-build/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..f5f07067c29f79adea32003c75f6e1b3266ccf3d
--- /dev/null
+++ b/docs/ohos-build/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Build Configuration
+###################
+
+The build system recipes provide various functionalities that expose knobs and
+primitives.
+
+.. toctree::
+ :maxdepth: 1
+
+ visual-customizations
diff --git a/docs/ohos-build/visual-customizations.rst b/docs/ohos-build/visual-customizations.rst
new file mode 100644
index 0000000000000000000000000000000000000000..b7c6955ba81e087e6a2229707633a4f7e5375623
--- /dev/null
+++ b/docs/ohos-build/visual-customizations.rst
@@ -0,0 +1,49 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Build System Visual Customizations
+##################################
+
+.. contents::
+ :depth: 2
+
+Weston dynamic configuration
+****************************
+
+The build exposes mechanism to tweak weston configuration through build
+variables. These variables can be provided as part of any configuration (eg.
+*local.conf*, *distro.conf*).
+
+The mechanism is enabled by setting ``WESTON_DYNAMIC_INI`` to ``1``. Any of the
+following variables will be ignored if this variable is not set to ``1``. The
+configuration file path can also be set via a variable: ``WESTON_INI_PATH``.
+The default value of ``WESTON_INI_PATH`` should be fine for most of the cases.
+
+Additional variable to be used in conjuction with ``WESTON_DYNAMIC_INI``:
+
+* ``WESTON_INI_NO_TOOLBAR`` - remove the shell panel when set to ``1``
+* Configuration for shell background
+ * ``WESTON_INI_BACKGROUND_IMAGE`` - sets shell.background-image accordingly
+ * ``WESTON_INI_BACKGROUND_COLOR`` - sets shell.background-color accordingly
+ * ``WESTON_INI_BACKGROUND_TYPE`` - sets shell.background-type accordingly
+
+Epiphany support for Application mode
+*************************************
+
+Epiphany is one of the browsers supported by the build meta-data. It provides a
+webkitgtk-based browser.
+
+The build exposes the ability to run the browser as a system service in
+application mode. This can be easily configurable and extended via the build
+metadata and variables.
+
+Available variables:
+
+* ``EPIPHANY_APP`` - the application name
+* ``EPIPHANY_URL`` - the URL to be used when browser starts
+* ``EPIPHANY_RDEPENDS`` - additional dependencies needed at runtime
+* ``EPIPHANY_SERVICE_ENABLED`` - when set to ``1``, build system will enable
+ the systemd service for starting at boot
+
+The build system provides support for using this mechanism with *HomeAssistant*. See this support as an example for how to implement a custom application mode for Epiphany.
diff --git a/docs/openharmony-quick-build.rst b/docs/openharmony-quick-build.rst
new file mode 100644
index 0000000000000000000000000000000000000000..b8464d9a63265a751eeefae7862ed051ce371d2c
--- /dev/null
+++ b/docs/openharmony-quick-build.rst
@@ -0,0 +1,79 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+OpenHarmony - Quick Build
+#########################
+
+This section will guide you to building your first OpenHarmony image targeting
+a supported reference hardware. It will also provide the steps for flashing and
+booting such an image.
+
+The steps below will focus on a Qemu-based target. If you want to get a feeling
+of OpenHarmony on a real hardware, checkout the :ref:`Avenger96 support page
+<SupportedBoardAvenger96>`.
+
+.. contents::
+ :depth: 2
+
+Prerequisites
+*************
+
+Have a **Ubuntu 20.04 LTS** host with all the required host packages.
+
+.. code-block:: console
+
+ $ sudo apt-get install gawk wget git diffstat unzip texinfo gcc-multilib \
+ build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
+ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
+ pylint3 xterm
+
+
+Clone build system repositories
+*******************************
+
+Install Google git repo tool:
+
+.. code-block:: console
+
+ $ sudo add-apt-repository ppa:openharmony/tools
+ $ sudo apt-get update
+ $ sudo apt-get install git-repo
+
+Initialize a repo workspace and clone all required repositories:
+
+.. code-block:: console
+
+ $ mkdir ohos; cd ohos
+ $ repo init -u https://git.ostc-eu.org/OSTC/OHOS/manifest.git -b develop
+ $ repo sync --no-clone-bundle
+
+Build the openharmony-image-base image
+**************************************
+
+The following steps will build a ``openharmony-image-base``. The process will
+build all its components, including the toolchain, from source.
+
+First of all change directory into the one where the build repositories were
+cloned using the repo tool. See above.
+
+Initialize the build directory and run a build:
+
+.. code-block:: console
+
+ $ TEMPLATECONF=../sources/meta-ohos/flavours/linux . ./sources/poky/oe-init-build-env build-ohos-linux
+ $ MACHINE=qemux86-64 bitbake openharmony-image-base
+
+Booting a Qemu X86-64 target with a OpenHarmony image
+*****************************************************
+
+Once the build is done, you can run a Qemu X86-64 instance as it follows:
+
+Once the image is done, you can run the Qemu usin the provided script wrapper:
+
+.. code-block:: console
+
+ $ MACHINE=qemux86-64 runqemu
+
+If the host has a VT-capable CPU, you can pass the ``kvm`` argument for better
+performance. Check ``runqemu``'s help message for all available arguments.
diff --git a/docs/repo-workspace.rst b/docs/repo-workspace.rst
new file mode 100644
index 0000000000000000000000000000000000000000..cfb6c4b1137d755a7d87c6e03e0931c2f451b247
--- /dev/null
+++ b/docs/repo-workspace.rst
@@ -0,0 +1,77 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+.. _RepoWorkspace:
+
+Repo Workspace
+##############
+
+OpenHarmony uses `repo <https://android.googlesource.com/tools/repo>`_ to
+provide full workspace setup that includes all the repositories needed for
+building OpenHarmony and developing on top.
+
+.. contents::
+ :depth: 2
+
+The Repo Tool
+*************
+
+OpenHarmony provides a patched version of the repo tool published as a
+`launchpad PPA <https://launchpad.net/~openharmony/+archive/ubuntu/tools>`_.
+The patches are also available in the tool's `source repository <https://git.ostc-eu.org/OSTC/packaging/git-repo>`_.
+
+Install this tool by following the next steps:
+
+.. code-block:: console
+
+ $ sudo add-apt-repository ppa:openharmony/tools
+ $ sudo apt-get update
+ $ sudo apt-get install git-repo
+
+The Manifests
+*************
+
+The `manifest repository <https://git.ostc-eu.org/OSTC/OHOS/manifest>`_
+provides the manifests available for configuring a workspace. The project provides two kinds of manifests:
+
+* develop manifests (where some projects are following a branch)
+* default manifests (where all projects are pinned to specific revisions)
+
+Setting up the Workspace
+************************
+
+Once the repo tool is installed, you can initialize and populate the workspace.
+This will bring in all the needed sources for building Openharmony:
+
+.. code-block:: console
+
+ $ mkdir ohos; cd ohos
+ $ repo init -u https://git.ostc-eu.org/OSTC/OHOS/manifest.git -b stable
+ $ repo sync --no-clone-bundle
+
+You can checkout latest development source code by using *develop* branch
+instead of *stable* as part of the above repo init command.
+
+Workspace structure
+*******************
+
+A fully set workspace, will provide a structure similar to:
+
+.. code-block:: none
+
+ ./ohos/
+ └── sources
+ ├── meta-freertos
+ ├── meta-ohos
+ ├── meta-openembedded
+ ├── meta-zephyr
+ ├── <various yocto layers>
+ └── poky
+
+The *sources* directory will include ``poky`` and all the build system layers
+that are part of the build process. Any new layers will be included under this
+directory.
+
+It is recommended to use the root of the workspace for the build directories
+using ``build`` as directory name prefix.
diff --git a/docs/yocto-build-system/assets/meta-ohos-arch.png b/docs/yocto-build-system/assets/meta-ohos-arch.png
new file mode 100644
index 0000000000000000000000000000000000000000..076fbaf855f6a45a25066b0f323f3ee8e9866a74
Binary files /dev/null and b/docs/yocto-build-system/assets/meta-ohos-arch.png differ
diff --git a/docs/yocto-build-system/assets/meta-ohos-arch.png.license b/docs/yocto-build-system/assets/meta-ohos-arch.png.license
new file mode 100644
index 0000000000000000000000000000000000000000..b23a85e2641e098a6c0cc2a16c805cd56252d547
--- /dev/null
+++ b/docs/yocto-build-system/assets/meta-ohos-arch.png.license
@@ -0,0 +1,3 @@
+SPDX-FileCopyrightText: Huawei Inc.
+
+SPDX-License-Identifier: CC-BY-4.0
\ No newline at end of file
diff --git a/docs/yocto-build-system/assets/ohos-build-arch.puml b/docs/yocto-build-system/assets/ohos-build-arch.puml
new file mode 100644
index 0000000000000000000000000000000000000000..33094667fd3f283846da2ef0210a893803ffdb8c
--- /dev/null
+++ b/docs/yocto-build-system/assets/ohos-build-arch.puml
@@ -0,0 +1,28 @@
+' SPDX-FileCopyrightText: Huawei Inc.
+'
+' SPDX-License-Identifier: CC-BY-4.0
+
+@startuml meta-ohos-arch
+!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
+
+Person(dev, "Developer", "Anyone willing to build the OHOS based image")
+System(meta_ohos, "meta-ohos", "OpenHarmony OS umbrella bitbake meta-layer")
+Boundary(poky, "poky") {
+ System_Ext(bitbake, "bitbake", "build process orchestrator")
+ System_Ext(linux_yocto, "linux-yocto", "Yocto Project LTS linux kernel")
+ System_Ext(meta_external_toolchain, "meta-external-toolchain", "Yocto Project LTS GNU GCC and LLVM toolchains")
+}
+System_Ext(meta_zephyr, "meta-zephyr", "ZephyrOS meta-layer")
+System_Ext(meta_freertos, "meta-freertos", "FreeRTOS meta-layer")
+System_Ext(meta_freertos, "meta-freertos", "FreeRTOS meta-layer")
+System_Ext(linux_yocto, "linux-yocto", "Yocto Project LTS linux kernel")
+System_Ext(meta_external_toolchain, "meta-external-toolchain", "Yocto Project LTS GNU GCC and LLVM toolchains")
+
+Rel(dev, bitbake, "selects configuration, initiates the build, deploys image to the target")
+Rel(bitbake, meta_ohos, "incorporates meta-layers relevant for selected kernel / configuration")
+Rel(bitbake, linux_yocto, "incorporates Yocto Project LTS linux kernel reference")
+Rel(bitbake, meta_external_toolchain, "incorporates Yocto Project LTS toolchains")
+Rel(bitbake, meta_zephyr, "incorporates for OHOS on Zephyr build")
+Rel(bitbake, meta_freertos, "incorporates for OHOS on FreeRTOS build")
+
+@enduml
diff --git a/docs/yocto-build-system/index.rst b/docs/yocto-build-system/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..8bea38de9334aebbba509969772f5c564927cc06
--- /dev/null
+++ b/docs/yocto-build-system/index.rst
@@ -0,0 +1,16 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+OpenHarmony, a Yocto-based Build System
+#######################################
+
+OpenHarmony build system, the foundation of the build infrastructure, is based
+on `Poky, the Yocto Project open source reference embedded distribution <https://www.yoctoproject.org/software-overview/>`_.
+This section details both generic and OpenHarmony specific aspects of the build system.
+
+.. toctree::
+ :maxdepth: 1
+
+ yocto-project
+ ohos-build-arch
diff --git a/docs/yocto-build-system/ohos-build-arch.rst b/docs/yocto-build-system/ohos-build-arch.rst
new file mode 100644
index 0000000000000000000000000000000000000000..b2fe3a3c6e11d982dd06f51ddae89f13580002e5
--- /dev/null
+++ b/docs/yocto-build-system/ohos-build-arch.rst
@@ -0,0 +1,23 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+OpenHarmony Build Architecture
+##############################
+
+``meta-ohos`` architecture is documented using `c4 model <https://c4model.com/>`_.
+
+.. contents::
+ :depth: 2
+
+Overview
+********
+
+OpenHarmony build infrastructure designed to run atop variety of OS kernels
+ranging from RTOSs to Linux.
+
+``meta-ohos`` is a *umbrella* of meta layers containing build meta-data
+required for compiling OpenHarmony images. The architecture supports plugging
+various kernels.
+
+.. image:: assets/meta-ohos-arch.png
diff --git a/docs/yocto-build-system/yocto-project.rst b/docs/yocto-build-system/yocto-project.rst
new file mode 100644
index 0000000000000000000000000000000000000000..09f3a9a872c245f1f2397d2a65c388e365f2f1ba
--- /dev/null
+++ b/docs/yocto-build-system/yocto-project.rst
@@ -0,0 +1,63 @@
+.. SPDX-FileCopyrightText: Huawei Inc.
+..
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Poky/Yocto Project
+##################
+
+OpenHarmony aims to use standard opensource tools to create a build environment
+that is both familiar to users in the domain but also flexible enough for the
+requirements of the project. With this in mind, the project build
+infrastructure is based on the OpenEmbedded build system, more specifically
+`Poky, the Yocto Project open source reference embedded distribution <https://www.yoctoproject.org/software-overview/>`_.
+
+.. contents::
+ :depth: 3
+
+Build System Concepts
+*********************
+
+The build system uses build instruction files that in the language of the
+system are called ``recipes`` and ``layers``.
+
+Layers are one of the fundamental models of the build system. It enables both
+collaboration and customization by defining scoped meta-data. These layers
+become a collection of build instruction files that have a defined scope. For
+example, there are BSP (board support package) layers that enable board support
+in the build system.
+
+See `terms for reference <https://www.yoctoproject.org/software-overview/>`_
+for more information.
+
+OpenHarmony Build Layers
+------------------------
+
+OpenHarmony bases its build setup on Poky, the Yocto Project open source
+reference embedded distribution. The main hub of layers, is `meta-ohos <https://git.ostc-eu.org/OSTC/meta-ohos/>`_,
+a collection of layers with different scopes for defining the project's
+requirements and capabilities.
+
+For example, ``meta-ohos-core`` provides build recipes for defining the core
+policies of the build infrastructure (`distribution` configuration, images,
+core packages customization, etc.).
+
+Another example is ``meta-ohos-staging``, a layer that provides temporary fixes
+and support for changes that are aimed upstream but have this place until
+upstream catches up.
+
+For more details of each provided layer of ``meta-ohos``, see the relevant
+``README.md`` file at the root of the layer,
+
+Besides the ``meta-ohos`` collection of layers, the project is also the home
+to a set of other build system layers. Explore them all in our project `GitLab <https://git.ostc-eu.org/OSTC/OHOS>`_
+instance.
+
+Aditional Documentation
+***********************
+
+`Yocto Project <https://www.yoctoproject.org>`_ provides extensive
+documentation on various aspects of the build system. For the general usage of the build system, it's components, architecture and capabilities consult the following resources:
+
+- `Yocto Project Documentation Home <https://docs.yoctoproject.org/>`_
+- `Yocto Project Quick Build <https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html>`_
+- `Yocto Project Reference Manual <https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html>`_