By just installing this into all of our images we open the door for
in-field debugging. It needs to be invoked manually and we do not drag
in any dbg packages so the image size stays sane.

Combined with a remote debugging setup and copy of the images files and
symbols this can allow full debugging capabilities with GDB or an IDE
later on.

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

- Use re-usable .workspace job from pipelines repository
- Less repetition with more targets supported
- Higher uniformity with the pipeline at the manifest repository.

Closes: https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/22


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

Wojciech Zmuda authored 4 years ago and Andrei Gherzan committed 4 years ago

Strong (=) assignment makes it impossible to override DISTRO
in command line when calling bitbake e.g.:

  $ DISTRO=myCoolOS bitbake myCoolImage

With strong assignment, the local.conf DISTRO setting has
precendence over command line setting. Using weak assignment
allows user to build other DISTRO without editing local.conf.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>

The browser is meant to be the only UI for the running device. So
stopping it would make little sense. epiphany, even in app mode, doesn't
hide the window controls - including the window closing button. If that
is triggered by mistake, systemd would restart it unconditionally.

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

ACTS tests a subset of ltp open_posix_testsuite.
Spread will be used to selectively execute required tests.

Related-to: https://git.ostc-eu.org/OSTC/OHOS/components/staging/xts_acts/-/issues/15


Signed-off-by: Robert Drab <robert.drab@huawei.com>

The app is directly in WORKDIR without a prefix.

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

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

Add bbappend to install main.conf file and set
AutoEnable flag to bring up BLE during boot.
Other options are commented out by default, they
may be useful for further BLE behavior tuning.

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

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

Available knobs:

WESTON_INI_BACKGROUND_IMAGE - Full runtime path of the background image.
			      The base name of this path needs to be
                              available in FILEPATH (EXTRAFILESPATH).
WESTON_INI_BACKGROUND_COLOR - Background color - default to white.
WESTON_INI_BACKGROUND_TYPE  - Background type - defaults to centered.

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

In this way, multiple recipes can take advantage of various assets (eg.
images, logos).

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

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

* disable getty on tty1
* disable weston toolbar (as we are running only one app at boot)
* define the epiphany app to use (HomeAssistant)
* run the HomeAssistant epiphany app at boot

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

This image doesn't need epiphany broweser per se, it actually needs the
epiphany browser for a specific app. Include epiphany-app and let the
epiphany dependency be pulled automatically.

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

Using systemd notify, a service dependency would be more robust. This
allows, for example, another service to depend on weston-init without
having to hack a sleep (or similar).

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

This creates a mechanism to generate a dynamic weston.ini configuration
based on build variables.

The entire mechanism is enabled using the WESTON_DYNAMIC_INI variable
(enabled when set to 1).

The default path for the weston.ini configuration is set in
WESTON_INI_PATH as "etc/xdg/weston/weston.ini".

WESTON_INI_NO_TOOLBAR, when set to 1, disables the weston toolbar.

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

This allows any image including this `.inc` file to have at its disposal
the primitives defined in that class.

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

This class allows to hook a post install function that would mask getty
services enabled by systemd as part of `systemd_preset_all`.

To take advantage of it, an image would:
1. inherit this class
2. define SYSTEMD_MASK_GETTY to point to a list of tty devices that the
   hook will mask the getty service for.

Common use-case: disable running getty on tty1 at boot.

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

This support is done configurable using the following variables:

EPIPHANY_APP             - Defines the app name (which needs to be the
			   directory name in FILESPATH/FILEEXTRAPATHS).
			   Currently defines it for HomeAssistant. If
			   this directory provides a
			   `service-override.conf`, the build system
			   will set it up as a systemd service
			   configuration for the main boot systemd
                           service.
EPIPHANY_URL             - The URL that the browser will load at
                           startup.
EPIPHANY_RDEPENDS        - Extra dependencies. If the specific
			   application needs extra dependencies at
                           runtime, they can be specifed here.
EPIPHANY_SERVICE_ENABLED - By default disabled (0). When enabled (1), it
			   will enable loading the epiphany app at boot.

The configuration defaults to setting up Epiphany browser in application
mode for a local instance of Home Assistant.

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

We can reference it when pointing to license in recipes that don't have
any package license files.

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

ActsJFFS2Test it is requires mtd_block device to mount jffs2 fs image.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

jffs2.img will be used to mount /storage directory required by ActsJFFS2Test
test suite using loopback device.

Related-To: https://git.ostc-eu.org/OSTC/OHOS/components/staging/xts_acts/-/issues/5


Signed-off-by: Robert Drab <robert.drab@huawei.com>

ActsJFFS2Test test suite requires /storage directory to be mounted on jffs2.
To achieve that jffs2 image is mounted on loopdevice using block2mtd module,
therefore mtd, jffs2 and block2mtd modules have to be configured.

Related-To: https://git.ostc-eu.org/OSTC/OHOS/components/staging/xts_acts/-/issues/5


Signed-off-by: Robert Drab <robert.drab@huawei.com>

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

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

Epiphany needs gcr while gcr needs x11 backend in gtk3+. That leads us
to the need of bringing x11 DISTRO_FEATURE back.

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

This is not ideal but will unblock using the browser while we
investigate the matter.

See: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14281



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

This image is part of the dashboard gateway demo and is meant to run on
the linux based target running HomeAssistant.

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

This configuration inherits the ohos distro configuration but makes
configurations specific to the dashboard demo use-cases. For now we only
handle the HomeAssistant version requirements and set a custom hostname.

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

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

Our bblayers file diverged between the different flavours and e.g. the
meta-ohos-foundation was still present for zephyr and freertos.

We enable all layers on all flavours. The only overhead should be in
parsing the recipes. If something else breaks we consider this a bug
worth fixing.

The usage of symlinks should be safe here. Yocto buildhost will almost
always be Linux based, but it this should even work on Windows by now.
If we run into trouble with this we can always got back to three files.

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

Since https://git.ostc-eu.org/OSTC/OHOS/meta-av96/-/merge_requests/4


it is no longer needed.

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

Dongni He authored 4 years ago and Stefan Schmidt committed 4 years ago

Signed-off-by: Dongni He <dongni.he@huawei.com>

Zygmunt Krynicki authored 4 years ago and Andrei Gherzan committed 4 years ago

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

The BSP layer is now a subdirectory - meta-av96-core.

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

The layer was restructured and all the BSP support is now provided
through the machine configuration.

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

When we started to use the networkd unit for wired in qemu we also broke
the static IP configuration the runqemu script uses. The IP address, etc
are given as kernel commandline options for the static setup.

If we see this happening we can simply skip the networkd unit file for
DHCP setup as we know a static IP config was provided.

The key part of the imported unit file here is the KernelCommandLine=!ip
line in the match section to skip the unit if IP is present in the
commandline.

Closes: https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/29



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

Add meta-qt5, new dependency layer of meta-av96.

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

In order to control what we ship and being responsible for, as well as
reducing the image size, we start with disabling DISTRO_FEATURES we
inherited from Poky. These are simply default values Poky uses to show
what Yocto/OE can do. They have currently no use for us and we can still
bring them back when the use cases arises.

Before:
build tasks: 5795 (26m)
du -cs tmp/deploy/images/stm32mp1-av96/openharmony-image-extra-stm32mp1-av96-20210301211000.rootfs.tar.xz
46624

After:
build tasks: 5159 (24m)
du -cs tmp/deploy/images/stm32mp1-av96/openharmony-image-extra-stm32mp1-av96-20210301215709.rootfs.tar.xz
43420

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

As part of our investigation and support, musl integration in the
project is fully supported (subject to the project's scope and QA
processes).

Upstream also carried out the relevant analysis and nothing 'known' is
broken: https://www.openwall.com/lists/musl/2019/11/08/6



That being said, we clean up the build logs of the respective warning.

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