We could add sanity checks for all newly deprecated collections and
distros here.

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

Fixes: https://git.ostc-eu.org/OSTC/planning/maintenance/-/issues/17


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

This issue is fixed upstream and we don't need to override the class
in downstream layers
This reverts commit 34449a8c.

Related: https://git.ostc-eu.org/OSTC/OHOS/manifest/-/issues/73


Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>

FreeRTOS switched to use main branch instead of master while our code
still looks for master. Overriding of bb class is needed for the change
thus it requires change in the order of layers.

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


Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
Upstream status: Backport
Upstream commit: d4bd9d748a4223856bf92dd35ca088d1f319d189

The code detects when boot assets would overwrite something already
deployed/installed in the rootfs. This helps to avoid breaking packaging
at runtime. On the other hand, if IMAGE_BOOT_FILES has duplicates, this
check will fail when trying to install the same file multiple times. To
avoid this, treat the install_task as a set.

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

This implements logic as a rootfs postprocess command where the set of
boot artifacts are provided as part of the root filesystem. The reason
is that the system update components assume only the root filesystem as
part of the update payload while boot files are also needed depending on
the BSP. For example, RaspberryPi update process would update the kernel
and dtbs on the boot partition too.

The boot files are copied to the path defined by
ROOTFS_BOOT_ARTIFACTS_PATH, relative to the root of the root filesystem.

SOme of the logic in this mechanism are based on the current
implementation of the bootimg-partition wic plugin.

Fixes https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/104



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

When read-only rootfs is enabled - it is enabled default for the
reference images - the core bbclass rootfs-postcommands.bbclass
configures dropbear to use a volatile location (a tmpfs location) for
the hostkey because the default location, /etc/dropbear is read-only.
With the advent of writables.bbclass, the OS now provides the default
path /etc/dropbear as a writable (a persistent location bind-mounted
from the sysdata partition). This makes now /etc/dropbear both
read-write and also persistent over reboots. This change reverts the
rootfs-postcommands.bbclass dropbear configuration to use a volatile
location as opposed to the default one (/etc/dropbear).

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

This class provides support for satisfying writable locations at
runtime. It supports persistent and volatile configuration.

E.g.:

WRITABLES = "foo"
WRITABLE_PATH[foo] = "/foo/bar"

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

This can help in development to play with deltas on squashfs images.

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

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

The runqemu script doesn't know to boot compressed qemu images. Bring
them back so that we can run the script without manually uncompressing
the images.

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

Stevan Radaković authored 3 years ago and Stefan Schmidt committed 3 years ago

Unify compression for different targets.
Remove uncompressed images.

Signed-off-by: Stevan Radaković <stevan.radakovic@linaro.org>

We need compressed rootfs images for faster download from LAVA side.

Signed-off-by: Stevan Radaković <stevan.radakovic@linaro.org>

All the currently supported linux-based boards are configured to use
wic, as image type, and the provided wic configuration, for common
partition table.

qemux86
qemux86-64
stm32mp1-av96
seco-intel-b68
seco-imx8mm-c61
raspberrypi4-64

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

* dtb_boot_files - converts dtb entries from KERNEL_DEVICETREE (assumed
  in DEPLOY/kernel) into IMAGE_BOOT_FILES ones (assuming destination is
  the root of the filesystem)
* extlinux_boot_files - converts extlinux files (assumed in
  DEPLOY/bootloader/extlinux) to IMAGE_BOOT_FILES entries (assuming
  destination is relative to the deploy directory of the extlinux files)

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

Gururaj Shetty authored 3 years ago and Stefan Schmidt committed 3 years ago

Some existence of OpenHarmony changed to All Scenarios OS in Readme
and Contribution files
This fixes #55, fixes #71

Signed-off-by: shettygururaj <gururaj.shetty@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>

"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>

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>

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>