Luca Seritan authored 2 years ago and Andrei Gherzan committed 2 years ago

qemu-generic-arm64 was not fully supported. Use qemuarm64-efi as
a supported 64 bit ARM alternative.

Signed-off-by: Luca Seritan <luca.seritan@huawei.com>

This makes is faster to build images, easier to handle them, e.g.
Raspberry Pi imager transparently supports .gz but not .bz2 and makes
virtually no difference to the size of the image.

Remember that the actual image is already compressed, as it is stored
inside the filesystem as a squashfs object.

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

Make sure we explicitly set up the WKS file for both C61 targets
after the target rename.

Signed-off-by: Marta Rybczynska <marta.rybczynska@huawei.com>
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Similar to how the SECO board was handled, the QEMU x86 machine can now
use EFI and GRUB correctly. This change is split over three parts,
MACHINE_FEATURES is modified to enable efi, WKS_FILE_DEPENDS to build
EFI firmware and lastly WKS_FILE to pick the new unified kick-start
file.

This was tested with:

        qemu-system-i386 -cpu IvyBridge -machine q35 -bios ovmf.qcow2 \
                oniro-image-base-qemux86.wic -m 1024 -nographic

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

Similar to how the SECO board was handled, the QEMU x86-64 machine can
now use EFI and GRUB correctly. This change is split over three parts,
MACHINE_FEATURES is modified to enable efi, WKS_FILE_DEPENDS to build
EFI firmware and lastly WKS_FILE to pick the new unified kick-start
file.

This was tested with:

        qemu-system-x86_64 -cpu IvyBridge -machine q35 -bios ovmf.qcow2 \
                oniro-image-base-qemux86-64.wic -m 1024 -nographic

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

This, coupled with the earlier EFI_PROVIDER change allows the generated
disk image to correctly boot with GRUB under QEMU/EFI. There is some
loss of functionality: the early-boot microcode patch system is gone,
for the moment, until we figure out how to bring it back with improved
and unified GRUB configuration files.

This was tested with:

        qemu-system-x86_64 -cpu IvyBridge -machine q35 -bios ovmf.qcow2 \
                oniro-image-base-seco-intel-b68.wic -m 1024 -nographic

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

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

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

This commit adds support for the qemu-generic-arm64 machine as a basic
qemu machine for arm SystemReady devices. It requires
meta-arm-dunfell-backports in order to function.

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

Many targets we support don't use IMAGE_BOOT_FILES which is specific to
the bootfiles wic plugin. Checking for this variable on targets that
don't even use that plugin, makes no sense. Let's drop it for now.

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

This change is in line with the project's rebranding.

The collection is also changed a bit to drop the "meta-" prefix. There
is no clear standardization on the collection name. Some use an ID, some
use ID-layer, some use meta-ID etc. We have decided to use the the layer
name without the "meta-" prefix  because this is an ID, not a layer per
se.

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

Rename all images to matching new project name prefix. Adjust includes
as well as image bbclass to fit.

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

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

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>