ASOS images mount the platform boot partition at /run/mount/boot.
Adjust the Raspberry Pi 4 specific configuration file to express that
location.

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

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

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

Eilís Ní Fhlannagáin authored 3 years ago and Eilís Ní Fhlannagáin committed 3 years ago

This is the first step in initiating automated package testing for
images. There will need to be some work on the CI side and some work on
the entire process but this is a first pass at getting the images to the
point where they have ptest on them.

This commit also adds an ext4 filesystem so we can test a writable
image. The wic image is still r/o but there is some benefit to having
tests run on a r/w fs.

Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@huawei.com>

Unless overridden in another layer or in local.conf, rauc will bundle
and use a know public key for verifying updates. This allows us to
to have some set of defaults that work out of the box and allow testing
the OTA stack and producing signed update bundles coming out of the CI
system.

The key is insecure and will expire in a year. This is intentional. Over
time we may switch to a reference key that is managed and secured or
re-generate another key for another year.

The insecure key has a fixed name and that name is used to trigger a
bitbake warning. OTA stack will learn to detect that key and similarly
warn users, or perform equally appropriate operations, in order to
reduce the risk of someone accidentally using this key in production.

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

The systoa package now provides standard sysotad.conf configuration
file, which is safe to install on all systems. For the MACHINE
"raspberrypi4-64" a special sysotad.conf is provided, one that
enables the pi-boot specific boot loader logic.

The entire sysota package becomes MACHINE-specific to avoid populating
the cache with the wrong config settings across builds.

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

The RAUC package contains the /etc/rauc/system.conf file, which defines
RAUC slot definitions and keyring file, which is used to verify updates.

The bbappend file makes the package machine-specific. For the MACHINE
"raspberrypi4-64" a canned system.conf is provided. For other machines
nothing, yet, happens.

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

With the introduction of $OHOS_RUNNER_TAG on the manifest repository, we
can now reliably add a custom tag to all bitbake builds that do not
customize the tag list.

Use the new tag on the two jobs which provide a custom list to be able
to redirect them to a special runner as well.

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

The repository with the layer was changed in the git-repo manifest
and the GitLab rename happened separately. There is no way to coordinate
this across repositories better AFAIK.

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

By default, with no other configuration file, SystemOTA is inert and
safe to include in any system.

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

SystemOTA or sysota is a robust, unattended update system for Linux
Gateways, suitable for home automation gateways and other devices where
reliability is paramount.

This base recipe builds fine and works in Qemu. On a Raspberry Pi system
it needs to be paired with an appropriate RAUC configuration file and a
matching SystemOTA configuration file. Those will be provided with
specialized packages as the details are closely related to WIC images.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@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>

* All project name replaced with tag
* definitions.rst reference added
* Closes: OSTC/OHOS/docs#77

Signed-off-by: Gururaj Shetty <gururaj.shetty@huawei.com>

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

The "Vending Machine" blueprint takes advantage of two Linux
applications: a UI and a Control one. These applications will exchange
messages over a defined interface using a specific protocol. This
documentation provides the specification of the communication protocol,
message format, schemas and more.

Fixes https://git.ostc-eu.org/OSTC/planning/core-os/-/issues/224

Relate-to: https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/merge_requests/282


Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
Signed-off-by: Philippe Coval <philippe.coval@huawei.com>

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

With the .build-linux-matrix job now available from the manifest
repository, we can now switch linux-seco-intel-b68,
linux-seco-imx8mm-c61 and linux-raspberrypi4-64 to build the base and
extras images separately, as distinct jobs.

In the end the exact same thing happens but we have more parallelism
since the jobs can be picked up by separate workers.

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

With the recent improvements to the CI infrastructure we are seeing
relatively fast build times for most of our jobs. The exception to this
rule are the relatively-larger blueprint build jobs.

Assign the set of tags: "bitbake-friendly", large-disk (legacy) and the
new "heavy" tag. The tag will route the job to a runner with
significantly more resources. This shoudl help even out the total build
time.

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

For now the gateway blueprint testing is limited to raspberrypi4-64. We
are not actively excluding other boards, but at least wifi and a USB
host for an OpenThread dongle is needed. Better state the tested board
only in the docs until we expand the testing.

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

Our download cache is temporarily out of order. Before it returns,
disabling it should speed up fresh builds, as the cache is gone and is
accessed repeatedly which wastes time.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@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

This build is reliably failing to fetch when invoked without download
cache constructed earlier. I've filed an issue to track this
but this blocks the auto-scaling CI system from going to production

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


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

This should help making re-run of do_configure safe.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Eilís Ní Fhlannagáin authored 3 years ago and Eilís Ní Fhlannagáin committed 3 years ago

Looking at allscenarios-image-common.inc I see some devel/dbg packages
in there. These really should be pulled into a development or debug
image as images that endusers would build off of for a production
environment should only contain the minimal packages needed to run the system.

This patch removes gdbserver and packagegroup-net-tools (iperf3) from common
and puts them along with other useful EXTRA_IMAGE_FEATURES into two new images:

allscenarios-image-base-dev
allscenarios-image-extra-dev

Due to the size of the dbg-pkgs and dev-pkgs,
allscenarios-image-extra-dev needs a bump of it's ROOT_PARTITION_SIZE
else wic creation explodes.

Closes <issues 123>

Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@huawei.com>

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

It is preferable to allow checker function to run until bbfatal is executed
for a meaningful error message to be printed for a better user experience.

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

gn docs state that the output dir should be passed as a last argument of the
gn gen command without any preceding switch

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

There's instance level bug template file which is copy of the project
level one. Directory kept for future overriding if needed

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


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

Signed-off-by: Chase Qi <chase.qi@linaro.org>

This reverts commit f7eb3cb0.

Signed-off-by: Chase Qi <chase.qi@linaro.org>

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>

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

Bernhard Rosenkränzer authored 3 years ago and Pavel Zhukov committed 3 years ago

python3-pyelftools 0.26 can't handle DWARF-5, which is generated by default
by modern toolchains (clang 12+, gcc 11+).

Update it to 0.27 with an extra patch taken from upstream git to support
DWARF-5 so we can use it (e.g. in the Zephyr kernel test suite) without
switching the toolchains back to DWARF-4.

Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

We first convert over qemuarm, qemuarm64, qemux86 and qemux86-64 to use
the common kernel.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@huawei.com>

These will be similar to linux-yocto, but customized to the ASOS kernel
policies and support our reference HW.

qemuarm and qemuarm64 builds aren't yet supported by wic, but we can
still start building the kernels from a common base.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@huawei.com>

This rename also better reflects the purpose of the file since it
reflects ASOS kernel policies.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@huawei.com>

We have merged in the inclusion of NetworkManager in the reference
images so we can disable networkd to avoid runtime conflict.

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



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

The recently introduced fixes for networkmanager introduced an implicit
dependency on meta-networking.
This change allows use of meta-ohos-staging without meta-networking layer,
without changing behaviour when used together with meta-networking.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This problem showed when building nodejs and resulted in an error of
malformed archives:

libv8_initializers.a: error adding symbols: malformed archive

There was a corner case where the fd's have not been closed on thin
archives and nodejs was heavy enough to be linked to show this problem.

Upstream report and analysis can be seen here:
https://sourceware.org/bugzilla/show_bug.cgi?id=28138



Fix is already upstream and just a backport for 2.37 added here.

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

The cache is relatively network-heavy, as it attempts to check if one of
myriad of cache files is available and is somewhat misleading, since the
cache only works for the small subset of configurations that have been
cleared for legal re-distribution and have a public cache available.

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