This recipe builds a subset of OpenHarmony 1st party components and installs
them into /usr/lib and /usr/bin.  Intended purpose is to use these OpenHarmony
components to build OpenHarmony compatibility into other projects and
products.

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

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

This machine configuration is ABI compatible with the Cortex-A7 builds made with
OpenHarmony build system.

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

Francesco Pham authored 3 years ago and Esben Haabendal committed 2 years ago

Some openharmony components (such as System Abilities) require Android
Binder ipc enabled in the kernel

Signed-off-by: Francesco Pham <francesco.pham@huawei.com>

Thierry Escande authored 3 years ago and Esben Haabendal committed 2 years ago

This patch adds the hilog and hievent kernel drivers for the OpenHarmony
v3.0 build.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

Robert Drab authored 3 years ago and Esben Haabendal committed 2 years ago

OpenHarmony requires Android Shared Memory kernel support.

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

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

Robert Drab authored 3 years ago and Esben Haabendal committed 2 years ago

OpenHarmony requires Android Shared Memory kernel support which is currently
under drivers/staging/android/ and therefore the header file is not being
installed.

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

OpenHarmony build system relies on this old version 1.x of prompt_toolkit Python
module.

A patch for adding this to meta-openembedded was submitted but rejected,
noting that we should instead try to convince any users of this old version to
upgrade to current (3.0) version. In this case, that is the OpenHarmony
build_lite.git repository.  So for now, we need to carry this recipe here.

We are using version 1.0.18, which is never than the version used currently by
OpenHarmony project, as the old version does not support Python 3.9+ which we
are using.

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

This will be used for replacing bounds_checking_function third party component
in OpenHarmony.

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

Robert Drab authored 3 years ago and Esben Haabendal committed 2 years ago

OpenHarmony build system relies on the obsolete set_sources_assignment_filter
GN function which was recently dropped.

Signed-off-by: Robert Drab <robert.drab@huawei.com>
Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

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

Thierry Escande authored 3 years ago and Esben Haabendal committed 2 years ago

This change moves the hunk for the file sys/capabilty.h into its own
patch file so it can be ignored.  We will be using the sys/capability.h
header file from libcap instead, to allow using libcap also.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>
Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

The openharmony-linux-user.patch extracted from OpenHarmony only included
modified files, not new files.

With gettid.c being included in musl 1.2.2 we should be able to drop it when
we upgrade to 1.2.2 or later.

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

With openharmony-linux-user.patch, we were modifying sys/socket.h header so
that struct sockaddr_storage was coming from linux/socket.h header instead of
being defined directly.

But upstream linux/socket.h does not do that.  It seems like some kind of
Android convention, that have been applied to kernel headers in OpenHarmony,
and as we now are using kernel headers from Oniro, we don't have that.

As part of the reason for using third party from Oniro, we really do want to
use upstream kernel headers, so we need to drop this change.

Note that this difference can be seen as an API change compared to
OpenHarmony.  Code that would be relying on linux/socket.h defining
struct sockaddr_storage will not work without changes.  But the sensible API
is to include sys/socket.h, and in that case, compatibility is preserved.

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

This reverts to upstream version 1.2.0 plus patches extracted from
//third_party/musl component in OpenHarmony-v3.0-LTS code base.

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

This is just a small subset of configuration options supported by OpenSSL code
base. Adding all of them to openssl recipe would be huge, and require continous
tracking for each new version, so is probably not diserable upstream.

These options is what we need for OpenHarmony configuration for now.

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

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

This provides recipe oniro-openharmony-toolchain and oniro-openharmony-bundle
recipes, which will build SDK images (self-extractable .sh file), which can be
installed into an OpenHarmony source repository, and provides alternative
toolchain and 3rd party components from Oniro project to the ones provided by
OpenHarmony project.

The oniro-openharmony-toolchain image provides prebuilt clang and musl libc
toolchain, and oniro-openharmony-bundle image extends that with various
prebuilt third-party components.

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

The hc-gen tool is used to convert HDF (Hardware Driver Foundation)
configuration source files (.hcs) to HDF configuration binary files (.hcb).

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

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

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

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