Andrei Gherzan authored 3 years ago and Bernhard Rosenkränzer committed 3 years ago

This inc file is useful so multiple recipes can synchronise on the same
path for the main Home Assistant configuration. For example, a recipe
bringing a custom Home Assistant configuration would use this as the
source of truth for the directory where this configuration needs to
reside. Home Assistant will use the same configuration path at
runtime.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Andrei Gherzan authored 3 years ago and Bernhard Rosenkränzer committed 3 years ago

This inc file is useful so multiple recipes can synchronise on the same
user configuration. For example, a recipe bringing a custom Home
Assistant configuration would use this to set the proper user ownership
of the configuration file.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Wojciech Zmuda authored 3 years ago and Bernhard Rosenkränzer committed 3 years ago

Multiple IoT devices in the Smart Home blueprint are to be
programmed with firmware built from the same sources. That
sources specify MAC address of the BLE interface of the device.
Multiple devices cannot work at once with the same MAC, so in
that case user should have possibility to specify the address
in build time.

Variable SMART_HOME_SWITCH_MAC can be provided to Bitbake.
If detected, its value is used as MAC address for devices
using zephyr-blueprint-smarthome-led image.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Wojciech Zmuda authored 3 years ago and Bernhard Rosenkränzer committed 3 years ago

Multiple IoT devices in the Smart Home blueprint are to be
programmed with firmware built from the same sources. That
sources specify MAC address of the BLE interface of the device.
Multiple devices cannot work at once with the same MAC, so in
that case user should have possibility to specify the address
in build time.

Variable SMART_HOME_SENSORS_MAC can be provided to Bitbake.
If detected, its value is used as MAC address for devices
using zephyr-blueprint-smarthome-sensors image.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Wojciech Zmuda authored 3 years ago and Bernhard Rosenkränzer committed 3 years ago

Multiple IoT devices in the Smart Home blueprint are to be
programmed with firmware built from the same sources. That
sources specify MAC address of the BLE interface of the device.
Multiple devices cannot work at once with the same MAC, so in
that case user should have possibility to specify the address
in build time.

Look for `MAC` variable - if set, use its value as MAC address,
substituting the default value in the source code of the firmware.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Wojciech Zmuda authored 3 years ago and Bernhard Rosenkränzer committed 3 years ago

Smart Panel blueprint sensor and switch devices MAC addrsses have to be:
 - configured on devices so they communicate over BLE from known addresses
   that do not collide,
 - configured in Home Assistant so it knows where to connect to.

Addresses can be overriden in local.conf of Linux build or in command line.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

* New note added for Bitbake command disk space, fixes issue#79

Signed-off-by: Arul Kumaran <arulkumaran.devarajan@huawei.com>

* New sentence 'Once the image is built, you can run a Qemu X86-64 instance using the
  provided script wrapper as follows:' is added under Booting a Qemu
  X86-64 target with a OpenHarmony image, Fixes issue #77.

Signed-off-by: Arul Kumaran <arulkumaran.devarajan@huawei.com>

The correct from is "All Scenarios OS" as opposed to "All Scenario OS".
This change also replaces a reference to OHOS.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

This relies on the plantuml plugin/module so it also includes the
required extension and to simplify that, we switch to using a `conf.py`
file.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Acronym looks good in some places but in sentences the full name is more
readable.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

This bundles a rather large rename of all the recipes, descriptions and
comments, with the exception of repositories referenced from gitee or
other third party system (e.g. launchpad PPAs or COPR repositories).

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

External repositories for various distributions are left unchanged.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

The manifest repository now offers new hidden jobs, that make
customization and reuse easier. Those allow us to remove bulk of the
custom logic, again, reducing everything to mere configuration.

The build-docs and update-docs jobs are entirely replaced by .build-docs
and .aggregate-docs (name change without logic change).

Custom .build job is split into smaller changes to the .workspace and
.bitbake-workspace jobs. Lastly, the variable OHOS_CI_GIT_REPO_PATH
is no longer relative to sources/ but includes it explicitly.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

* 'pyOCD-flashtool -l' command syntax rectified as 'pyocd-flashtool -l',
 fixes issue#39

Signed-off-by: Arul Kumaran <arulkumaran.devarajan@huawei.com>

Due to a configuration bug in upstream, the build system outputs a
configuration warning similar to:

---------- CONFIG_SERIAL_OF_PLATFORM -----------------
Config: CONFIG_SERIAL_OF_PLATFORM
From:
[...]/kernel-source/.kernel-meta/configs/v5.10/standard/cfg/8250.cfg
Requested value:  CONFIG_SERIAL_OF_PLATFORM=y
Actual value:

Avoid this by disabling the specific config.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

When building with Python 3.9+ on the host, there are various ways the
build will fail. Fixes to address these issues are already in newer
version of the component so this only backports two related patches.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

To address the "demo" to "blueprint" rename, zephyr-demo-smarthome-base
repository was also renamed accordingly. Reflect this change in the
build recipe.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

"openharmony-linux-demo-dashboard" was deprecated in favour of
"openharmony-linux-blueprint-dashboard".

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

The mechanism and value format of OHOS_DEPRECATED_DISTROS is identical
to OHOS_DEPRECATED_COLLECTIONS.

Deprecated distro configurations can be either completely removed or
replaced by another configuration. The format of OHOS_DEPRECATED_DISTROS
is a list of <DEPRECATED_DISTRO>:<REPLACEMENT_DISTRO>. When
<REPLACEMENT_DISTRO> is not provided, the distro was removed without a
replacement.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

As the ohos-sanity bbclass is not kernel-specific, the inclusion is done
through an include file.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

This bbclass is meant to handle various build configuration checks. As
per the current implementation, it handles collections deprecation.

Deprecated collections can be either completely removed or replaced by
another layer. The format of OHOS_DEPRECATED_COLLECTIONS is a list of
<DEPRECATED_COLLECTION>:<REPLACEMENT_COLLECTION>. When
<REPLACEMENT_COLLECTION> is not provided, the layer was removed without
a replacement.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

With the 0.1.0 release done we are now back in development mode.
Indicate this by setting the version to 0.1.99. If we ned to provide
stable update releases to 0.1.0 they will come from a release branch as
0.1.1 .. 0.1.n.

Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

Show Dashboard/SmartHome demo setup on a puml diagram.

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@huawei.com>

- Add building and flashing guidelines for SmartHome demo
  endpoints

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@huawei.com>

Demo consists of two IOT endpoints: sensors board
and bulb/LED board.
Add image to specialize base settings to the LED board's
configuration. In this case settings related to LCD display
and sensors are disabled.

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@huawei.com>

Demo consists of two IOT endpoints: sensors board
and bulb/LED board.
Add image to specialize base settings to the sensors board's
configuration. In this case LED control is disabled.

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@huawei.com>

Add meta-zephyr from our local fork to the required layers.
This should be changed to upstream version when it's
aligned with our local state.

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@huawei.com>

- Allows for building SmartHome Demo Zephyr application
- Requires meta-zephyr layer
- Application is going to be built with all options enabled (default)

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@huawei.com>