you don't want the leading space.

I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf

Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee

you don't want the leading space.

rday

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf

Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee

you don't want the leading space.

rday

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf

Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
_______

On Fri, May 28, 2021 at 1:47 PM Swapna Nannapaneni
<sayinswapna@...> wrote:

Thanks Robert and Raj!!

I am using Yocto 3.1 Dunfell release.

You are right about the .bbappend file. Changed the name in the overlay to new-ver.bbappend and no longer see the warning.

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf but looks like generated rootfs has init file pointing to init -> ../lib/systemd/systemd

Priya.

On Thu, May 27, 2021 at 7:28 PM Khem Raj <raj.khem@...> wrote:

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

Why do I (always) point out the obvious?

And I do need... Geniuses are not meant to fix The World to understand them!?

Geniuses should understand The World (and act properly)!

Extras to geniality, do you, YOCTO primes, think?
_______

Robert... If I am correct, i'm I?

Should you include in docs some examples??? Yes, U should!
As for an example fix:
poky/meta/conf/distro/include/init-manager-*.con, NOT
conf/distro/include/init-manager-*.conf

(full path is more explicit, isn't it?)

And some local.conf examples/snippets (since all descriptions are here
and there very dry):

## Add systemd service
INIT_MANAGER = "systemd"
## DISTRO_FEATURES_append = " systemd"
## DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
## VIRTUAL-RUNTIME_init_manager = "systemd"
## VIRTUAL-RUNTIME_dev_manager = "systemd"
## VIRTUAL-RUNTIME_initscripts = ""

Where INIT_MANAGER = "systemd" replaces all commented commands below....

My two cent advice,
Zee
_______

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