oe-core completely dropped the associated class and support:
https://lists.openembedded.org/g/openembedded-core/message/160848



This change drops the associated references in our build sample files.

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

Upstream moved the default definition of TCLIBC as part of:

commit 57aa60ef6422568b425b6ccc4451567efc578469
Author: Martin Jansa <Martin.Jansa@gmail.com>
Date:   Wed Sep 16 15:28:52 2020 +0200
    bitbake.conf: use ${TCMODE}-${TCLIBC} directory for CACHE

This moved TCLIBC from defaultsetup.conf to bitbake.conf but the problem
is that it did it before the place were bitbake.conf includes the distro
configuration changing its behaviour. With this change, a ?= in the
distro configuration will be ignored as the first one is already
defined in bitbake.conf.

Because of the above, we ended up with defaulting to glibc. We revert
this by forcing the value of TCLIBC accordingly. This will have a side
effect that shell environment variable will be ignored. So doing that
through BB_ENV_EXTRAWHITE will be broken from now on. If we want that
ability in the future, we can try to address.

Fixes: https://booting.oniroproject.org/distro/oniro/-/issues/252



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

The oniro-grub-bootconf recipe provides the virtual-grub-bootconf
package which in turn contains a stub grub.cfg and empty grubenv file.

The change is spread around a considerable number of areas. Specifically
the kick-start file needs to explicitly reference the grub.cfg file which
must be placed in the wic/ directory. Since we need the same file in
grub/files directory, so that it can be installed into the image,
a symbolic link is employed.

The distribution configuration file, oniro-linux.conf sets
IMAGE_EFI_BOOT_FILES so that the grubenv file is installed into the boot
partition. This is required since grub cannot create the file by itself,
it can only edit the file, in-place, if it is present there already.

The actual configuration file for GRUB is a stub. Appropriate file with
some non-trivial logic will be proposed separately. The stub file boots
the first slot all the time. The kernel is loaded from the rootfs.

This test-boots fine in x86 and x86-64 qemu builds.

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

The COMPATIBLE strings are set to "QEMU x86" and "QEMU x86-64"
respectively. The values are not standardized, but since the idea is
that bundles with a matching COMPATIBLE string can be used for updates,
picking a generic value is most appropriate.

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

Chase Qi authored 3 years ago and Stevan Radaković committed 3 years ago

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

Chase Qi authored 3 years ago and Stevan Radaković committed 3 years ago

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

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

This helps to understand that the actual interpolation process cannot use
syntax like bash/sh. In addition, putting the @ sigil at both ends so that
@FOO_BAR is not incorrectly replaced as well.

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

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

Set lava-test and lava-report job as scheduled pipeline only for the
below reasons.

* lava-test requires token set using GitLab variable for job submission
* lava-report depends on all test jobs

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

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

The x-gpt-efi-disk kickstart file has a duplicate --boot argument for
the boot partition. One uses the BOOT_PARTITION_LABEL variable. The other
uses a hard-coded string "boot". Drop the hard-coded value.

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

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

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

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

After splitting, also ci need to build separate MACHINE variables.

Signed-off-by: Ettore Chimenti <ettore.chimenti@seco.com>

Signed-off-by: Ettore Chimenti <ettore.chimenti@seco.com>

Add support for 4GB boards, splitting and replacing the MACHINE variable
`seco-imx8mm-c61` with `seco-imx8mm-c61-Xgb`, where X can be 2 or 4,
depending on the installed DRAM in the target machine.

Closes https://git.ostc-eu.org/OSTC/planning/hw-enablement/-/issues/59



Signed-off-by: Ettore Chimenti <ettore.chimenti@seco.com>

Better formatting of the recipe

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

Zygmunt Krynicki authored 3 years ago and Stefan Schmidt committed 3 years ago

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

Zygmunt Krynicki authored 3 years ago and Stefan Schmidt committed 3 years ago

The update bundle is built with the new hidden job .build-rauc-bundle.
The job is documented and instantiated in the main pipeline.

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

Zygmunt Krynicki authored 3 years ago and Stefan Schmidt committed 3 years ago

In retrospective I think I've misunderstood the compatible string to
mean "what is the image we expect" vs "what is the hardware we expect".
By setting the compatible string to describe the hardware, we get the
ability to restrict images for genuinely incompatible hardware without
locking down ability to move to other software images.

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

Zygmunt Krynicki authored 3 years ago and Stefan Schmidt committed 3 years ago

The oniro-bundle-base recipe creates a RAUC update bundle corresponding
to oniro-image-base. At the moment the recipe is only compatible with
Raspberry Pi 4.

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

Francesco Pham authored 3 years ago and Stefan Schmidt committed 3 years ago

Adding ovmf to runqemu commands since we switched to GRUB+EFI as boot solution. 

Without this argument it does not boot properly and remains stuck in "Booting from Hard Disk..."

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

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

Make sure that GRUB can load squashfs, so that it can mount the system
image and load the kernel, or other modules, from there directly.

Closes: https://booting.oniroproject.org/distro/oniro/-/issues/243



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

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

Add modeprobe.bb recipe
Create oniro-kernel-mod.conf as the modprob config file
Update packagegroup-oniro-core.bb to account for the new recipe

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

Fix typo in net.ipv4.config.default.log_martians (now conf)

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

Add option to not send ICMP redirects messages.

Signed-off-by: Davide Gardenal <davide.gardenal@huawei.com>

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

The rootfs already contains kernel modules so updating the image without
updating the kernel would cause a skew that would most likely prevent
the system from working.

On some platforms the kernel must be in a special area, as the
bootloader is more limited or closed, and the update process needs to
copy it to make progress.

On other platforms, we can use a more capable bootloader to load the
kernel from the rootfs directly. For all such platforms we want to add
the kernel-image package to the base oniro dependencies.

The kernel-image package is somewhat suboptimal, as ideally we would put
the kernel image into the root directory, making the /boot directory an
empty mount point for the boot partition.

Since doing this exceeds my skills and patience, the second best thing
will do.

Closes: https://booting.oniroproject.org/distro/oniro/-/issues/240



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

Pavel Zhukov authored 3 years ago and Andrei Gherzan committed 3 years ago

/var/run is a symlink to /run nowadays.

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

Add recipe for zenohd and zenoh-c

zenohd: installs the zenohd binary which is the executable for 
the zenoh router and provides support for zenoh communication 
routing and storage capabilities. 
Tested by running: `zenohd --plugin-search-dir /usr/lib`

zenoh-c: Zenoh C client library into a Yocto recipe that can be 
invoked as needed by applications.
The library has been tested and the zenoh primitives such as: pub, 
sub, put, get, scout.. appear to be working correctly.

Closes: https://git.ostc-eu.org/OSTC/planning/core-os/-/issues/242



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

This file is now entirely replaced by x-gpt-efi-disk.wks.in

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

This file is derived from QEMU+EFI file we already have while having
wider scope of supporting both virtual and physical machines alike.

The partition table is GPT and the boot system is based on EFI. The
EFI_PROVIDER variable can be used to select either grub or systemd-boot.

Over time the qemu-specific workspace files will be deprecated and
removed. This step makes the transition easier to process.

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