Hi Manuel,

On Fri, May 28, 2021 at 11:26:26AM +0200, Manuel Wagesreither wrote:

Hello all,

to speed up builds, we would like to make the CI generated sstate-cache available via internet. Due to IP concerns, we don't want to make it publically available but for authenticated hosts only.

[1] indicates it is possible to serve the sstate-cache over http with basic authentication [2].

How does one set the username & password? By putting it into the URL like in the following example, or are other ways available?
```
SSTATE_MIRRORS ?= "\
file://.* http://username:password@someserver.tld/share/sstate/PATH"
```

There is an example in the commit you sent, so I would say:
SSTATE_MIRRORS ?= " \
file://.* http://someserver.tld/share/sstate/PATH;user=username:password;downloadfilename=PATH \n"
?

Cheers,
Quentin

Hello all,

to speed up builds, we would like to make the CI generated sstate-cache available via internet. Due to IP concerns, we don't want to make it publically available but for authenticated hosts only.

[1] indicates it is possible to serve the sstate-cache over http with basic authentication [2].

How does one set the username & password? By putting it into the URL like in the following example, or are other ways available?
```
SSTATE_MIRRORS ?= "\
file://.* http://username:password@someserver.tld/share/sstate/PATH"
```

Thank you!

[1] https://patchwork.openembedded.org/patch/130333/
[2] https://en.wikipedia.org/wiki/Basic_access_authentication

zephyr can be build for 'acrn' with following configuration:

MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/acrn.conf | 9 ---------
1 file changed, 9 deletions(-)
delete mode 100644 conf/machine/acrn.conf

diff --git a/conf/machine/acrn.conf b/conf/machine/acrn.conf
deleted file mode 100644
index c044933..0000000
--- a/conf/machine/acrn.conf
+++ /dev/null
@@ -1,9 +0,0 @@
-#@TYPE: Machine
-#@NAME: acrn
-#@DESCRIPTION: Machine for Zephyr BOARD acrn
-
-require conf/machine/include/qemu.inc
-require conf/machine/include/tune-corei7-common.inc
-ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
-
-ARCH_acrn = "x86"
--
2.17.1

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "minnowboard"

By default it set to MinnowBoard Max 'minnowboard'

Currently 32-bit supported boards:
* up_squared_32
* minnowboard

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/include/tune-core2-common.inc | 6 ++++++
conf/machine/intel-x86-32.conf | 12 ++++++++++++
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf

diff --git a/conf/machine/include/tune-core2-common.inc b/conf/machine/include/tune-core2-common.inc
new file mode 100644
index 0000000..012f078
--- /dev/null
+++ b/conf/machine/include/tune-core2-common.inc
@@ -0,0 +1,6 @@
+DEFAULTTUNE ?= "core2-32"
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDES
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-32.conf b/conf/machine/intel-x86-32.conf
new file mode 100644
index 0000000..06f6da5
--- /dev/null
+++ b/conf/machine/intel-x86-32.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-32
+#@DESCRIPTION: common MACHINE for 32-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'minnowboard' board.
+
+require conf/machine/include/tune-core2-common.inc
+
+ARCH_intel-x86-32 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "minnowboard"
+# ZEPHYR_BOARD ?= "up_squared_32"
+ZEPHYR_BOARD ?= "minnowboard"
--
2.17.1

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode).

To achieve this, an python tool[1] has been added to convert zephyr ELF file
into an EFI appliable. But currently this does not work with Yocto
cross-compilation env.
This patch fix this issue and allow to build zephyr.efi

Ref:
[1]https://github.com/zephyrproject-rtos/zephyr/commit/928d31125f0b4eb28fe1cf3f3ad02b0ae071d7fd

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
3 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

diff --git a/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
new file mode 100644
index 0000000..fd6fc6b
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
@@ -0,0 +1,80 @@
+From cfde3b1018c3151b6cc1fbe3e9e163d0aaf16954 Mon Sep 17 00:00:00 2001
+From: Naveen Saini <naveen.kumar.saini@...>
+Date: Tue, 11 May 2021 13:46:39 +0800
+Subject: [PATCH] x86: fix efi binary generation issue in cross compilation env
+
+Set root directory for headers.
+
+Upstream-Status: Inappropriate [Cross-compilation specific]
+
+Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
+---
+ arch/x86/zefi/zefi.py | 6 +++++-
+ boards/x86/ehl_crb/CMakeLists.txt | 1 +
+ boards/x86/qemu_x86/CMakeLists.txt | 1 +
+ boards/x86/up_squared/CMakeLists.txt | 1 +
+ 4 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/zefi/zefi.py b/arch/x86/zefi/zefi.py
+index d3514391a8..b9eccbfa10 100755
+--- a/arch/x86/zefi/zefi.py
++++ b/arch/x86/zefi/zefi.py
+@@ -106,7 +106,10 @@ def build_elf(elf_file):
+ # + We need pic to enforce that the linker adds no relocations
+ # + UEFI can take interrupts on our stack, so no red zone
+ # + UEFI API assumes 16-bit wchar_t
+- cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.",
++
++ # Pass --sysroot path for cross compilation
++ sysrootarg = "--sysroot=" + args.sysroot
++ cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.", sysrootarg,
+ "-fno-stack-protector", "-fpic", "-mno-red-zone", "-fshort-wchar",
+ "-Wl,-nostdlib", "-T", ldscript, "-o", "zefi.elf", cfile]
+ verbose(" ".join(cmd))
+@@ -145,6 +148,7 @@ def parse_args():
+ parser.add_argument("-o", "--objcopy", required=True, help="objcopy to be used")
+ parser.add_argument("-f", "--elf-file", required=True, help="Input file")
+ parser.add_argument("-v", "--verbose", action="store_true", help="Verbose output")
++ parser.add_argument("-s", "--sysroot", required=True, help="Cross compilation --sysroot=path")
+
+ return parser.parse_args()
+
+diff --git a/boards/x86/ehl_crb/CMakeLists.txt b/boards/x86/ehl_crb/CMakeLists.txt
+index 0d572eff30..6a228107dc 100644
+--- a/boards/x86/ehl_crb/CMakeLists.txt
++++ b/boards/x86/ehl_crb/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/qemu_x86/CMakeLists.txt b/boards/x86/qemu_x86/CMakeLists.txt
+index 1131a5c7ce..489f17192b 100644
+--- a/boards/x86/qemu_x86/CMakeLists.txt
++++ b/boards/x86/qemu_x86/CMakeLists.txt
+@@ -4,6 +4,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/up_squared/CMakeLists.txt b/boards/x86/up_squared/CMakeLists.txt
+index 0eaa9753fc..2e8ce7cfbc 100644
+--- a/boards/x86/up_squared/CMakeLists.txt
++++ b/boards/x86/up_squared/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index 6350d86..5d66f0f 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -8,3 +8,6 @@ SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

PV = "2.5.0+git${SRCPV}"
+
+SRC_URI_append = " file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..b3b9565 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -1,10 +1,6 @@
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

-# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
-include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
-
inherit cmake

# This file might be included from other places (like other layers) and not
@@ -23,3 +19,7 @@ SRC_URI = "\
file://0001-cmake-add-yocto-toolchain.patch \
"
S = "${WORKDIR}/git"
+
+# Default to a stable version
+PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
--
2.17.1

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "ehl_crb"

By default it set to Elkhart Lake CRB 'ehl_crb'

Currently 64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb
* acrn
* acrn_ehl_crb

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/include/tune-corei7-common.inc | 3 +++
conf/machine/intel-x86-64.conf | 14 ++++++++++++++
2 files changed, 17 insertions(+)
create mode 100644 conf/machine/intel-x86-64.conf

diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc
index 7ad9516..509d190 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,3 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
require conf/machine/include/tune-corei7.inc
require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDE
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-64.conf b/conf/machine/intel-x86-64.conf
new file mode 100644
index 0000000..2935cff
--- /dev/null
+++ b/conf/machine/intel-x86-64.conf
@@ -0,0 +1,14 @@
+#@TYPE: Machine
+#@NAME: intel-x86-64
+#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'ech_crb' board.
+
+require conf/machine/include/tune-corei7-common.inc
+
+ARCH_intel-x86-64 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "acrn"
+# ZEPHYR_BOARD ?= "acrn_ehl_crb"
+# ZEPHYR_BOARD ?= "up_squared"
+# ZEPHYR_BOARD ?= "ehl_crb_sbl"
+ZEPHYR_BOARD ?= "ehl_crb"
--
2.17.1

V2.6.0-rc1 patch is not merged as it is pre-release. Lets wait for stable release.
Could you please rebase these patches for v2.5.0 latest master ?

Regards,
Naveen

On 5/27/21 3:04 PM, sayinswapna@... wrote:

Hello Yocto team:
I just started with yocto and would like to know the process for switching the init manager from systemd to sysvinit.
I tried this options in config file
VIRTUAL-RUNTIME_init_manager = "busybox"
PREFERRED_PROVIDER_udev = "sysvinit"
PREFERRED_PROVIDER_udev-utils = "sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
DEFAULT_DISTRO_FEATURES += " sysvinit"
I see a warning when building my machine:
No recipe for target:
/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend

Please find out which layer is adding this bbappend you could use

bitbake-layers show-appends sysvinit

It seems recipe version is newer perhaps and the bbappend is still made for older recipe, these things happen when you mix release branches for different layers.

When I run this build on my target it still shows me systemd init manager...
Not sure if I am missing any options.
Could you please let me know if there are any pointers I can refer to?
Thanks,
Priya

On 5/27/21 3:12 PM, Robert P. J. Day wrote:

On Thu, 27 May 2021, sayinswapna@... wrote:

Hello Yocto team:

I just started with yocto and would like to know the process for switching the init
manager from systemd to sysvinit.

I tried this options in config file
VIRTUAL-RUNTIME_init_manager = "busybox"
PREFERRED_PROVIDER_udev = "sysvinit"
PREFERRED_PROVIDER_udev-utils = "sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
DEFAULT_DISTRO_FEATURES += " sysvinit"

as i recall, all of the above can be replaced by a single assignment
to the INIT_MANAGER variable.

it will depend on release, if you are on 3.0+ then yes single setting will work, older releases would mean above is needed. see

https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

rday

On Thu, 27 May 2021, sayinswapna@... wrote:

Hello Yocto team:

I just started with yocto and would like to know the process for switching the init
manager from systemd to sysvinit.

I tried this options in config file
VIRTUAL-RUNTIME_init_manager = "busybox"
PREFERRED_PROVIDER_udev = "sysvinit"
PREFERRED_PROVIDER_udev-utils = "sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
DEFAULT_DISTRO_FEATURES += " sysvinit"

as i recall, all of the above can be replaced by a single assignment
to the INIT_MANAGER variable.

rday

Hello Yocto team:

I just started with yocto and would like to know the process for switching the init manager from systemd to sysvinit.

I tried this options in config file

Hello Folks,

In order to continue to develop my:
https://github.com/ZoranStojsavljevic/bbb-yocto

And advance to yocto hardknott, I did the temporary moves:

Cloned both jumpnow repos to my github space:
https://github.com/ZoranStojsavljevic/meta-bbb
https://github.com/ZoranStojsavljevic/meta-jumpnow

So far, I did only the framework job creating hardknott branches, to
be able to commence.

I'll try to advance meta-bbb with some recent kernels (5.12) in the near Future.

I hope Scott Ellis will return to continue to maintain his repos, but
in the meantime...

Zee
_______

maybe take a look at some of the work toradex has done,

maybe in their torizon tree you can find some creative ways

https://developer.toradex.com/knowledge-base/how-to-autorun-application-at-the-start-up-in-linux

https://developer.toradex.com/knowledge-base/run-manage-docker-container-torizon

Has anyone seen suck an animal before, and if not, how hard would it be to launch a container, then get the output to install like a normal recipe does?

It might be easier to manually enable the service with a symbolic link instead of using systemd.bbclass with something like:

do_install() {

  install -Dm 755 ${D}${systemd_unitdir}/system/multi-user.target.wants/

  ln -s ${systemd_unitdir}/system/openvpn@.service ${D}${systemd_unitdir}/system/multi-user.target.wants/openvpn@...

}

NOTE: I didn't explicitly test this

Hi François,

On Thu, May 27, 2021 at 02:17:03PM +0000, François GOUDAL wrote:

Hello,

I am struggling with something I couldn’t find any solution for so far.

I am trying to make a very simple recipe that does this:
- Drop an openvpn configuration file in /etc/openvpn/test.conf
- Make the systemd service openvpn@... enabled by default

The recipe itself depends on openvpn, and so, it doesn’t, by itself, provide the openvpn@.service , which comes with openvpn.

Dropping the openvpn configuration file in the rootfs is easy, but I can’t manage to make the recipe to enable the service.
I’ve tried adding this to my recipe:

inherit systemd
SYSTEMD_AUTO_ENABLE = "enable"
SYSTEMD_SERVICE_${PN} = "openvpn@..."

But bitbake fails on this recipe with the message below:

ERROR: test-openvpn-config-1.0-r0 do_package: SYSTEMD_SERVICE_test-openvpn-config value openvpn@... does not exist

I believe this is caused by the fact that the service file is not part of the files installed by the recipe itself, but it is not meant to be anyway.

Yes that seems like the origin of the error.

Recipe data is local to the recipe. You therefore also cannot modify the
openvpn recipe from another recipe (this includes enabling a service for
example).

The proper way to do it is to create a bbappend for the openvpn recipe
and enable the service from there. SYSTEMD_AUTO_ENABLE = "enable" should
be enough, though it'll start the loopback client and server unit too.

It is not possible to have different image recipes enable or not the
service, if this is something you want, you need to modify
SYSTEMD_AUTO_ENABLE of the openvpn recipe in a configuration file (and
the proper way is in a distro configuration file).

Cheers,
Quentin

Hello,

I am struggling with something I couldn’t find any solution for so far.

I am trying to make a very simple recipe that does this:
- Drop an openvpn configuration file in /etc/openvpn/test.conf
- Make the systemd service openvpn@... enabled by default

The recipe itself depends on openvpn, and so, it doesn’t, by itself, provide the openvpn@.service , which comes with openvpn.

Dropping the openvpn configuration file in the rootfs is easy, but I can’t manage to make the recipe to enable the service.
I’ve tried adding this to my recipe:

inherit systemd
SYSTEMD_AUTO_ENABLE = "enable"
SYSTEMD_SERVICE_${PN} = "openvpn@..."

But bitbake fails on this recipe with the message below:

ERROR: test-openvpn-config-1.0-r0 do_package: SYSTEMD_SERVICE_test-openvpn-config value openvpn@... does not exist

I believe this is caused by the fact that the service file is not part of the files installed by the recipe itself, but it is not meant to be anyway.

Is there a (clean) way to achieve this ?

Thanks in advance