Date   

[meta-zephyr][PATCH 08/13] qemu-x86.conf: drop deprecated qemu flags

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/qemu-x86.conf | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index ac6fb8f..d85c222 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -9,10 +9,8 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"

# For runqemu
QB_SYSTEM_NAME = "qemu-system-i386"
-QB_MACHINE = "-machine pc-0.14"
-#QB_OPT_APPEND = "-nographic -display none -clock dynticks -no-acpi -balloon none"
-QB_OPT_APPEND = "-nographic -display none -no-acpi"
-QB_CPU_x86 = "-cpu qemu32"
+QB_OPT_APPEND = "-nographic -no-acpi"
+QB_CPU_x86 = "-cpu qemu32,+nx,+pae"
QB_CPU_KVM_x86 = "-cpu kvm32"

ARCH_qemu-x86 = "x86"
--
2.17.1


[meta-zephyr][PATCH 07/13] zephyr-kernel: add Zephyr RTOS version 2.0.0 support

Naveen Saini
 

Release notes:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.0.0

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
classes/zephyr-kernel-src.bbclass | 14 ++--
.../0001-cmake-add-yocto-toolchain.patch | 76 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-common.inc | 2 -
.../zephyr-kernel/zephyr-kernel-src_2.0.bb | 33 ++++++++
.../zephyr-kernel/zephyr-kernel.inc | 4 -
5 files changed, 116 insertions(+), 13 deletions(-)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-cmake-add-yocto-toolchain.patch
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.0.bb

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index af53e8e..9e2558b 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -1,13 +1,13 @@
#Set relevant variables based on Zephyr kernel version

-PREFERRED_VERSION_zephyr-kernel ??= "1.6.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.0.0"

-SRCREV = "d4e799d77a36eaf6d678b357c207411ec32b2d62"
-
-SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v1.6-branch \
- file://Makefile.toolchain.yocto "
-PV = "1.6.0"
+SRCREV = "ca3eb0eb31d134be41aefc952f696f7d9c356b7a"

+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.0-branch \
+ file://0001-cmake-add-yocto-toolchain.patch \
+ "
+PV = "2.0.0"
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

@@ -15,7 +15,7 @@ ZEPHYR_TEST_SRCDIR = "tests/legacy/kernel/"

python () {
src_pn = d.getVar('PREFERRED_VERSION_zephyr-kernel', True)
- if src_pn == '1.6.0':
+ if src_pn == '2.0.0':
return
else:
bb.error("Unsupported Zephyr kernel version requested")
diff --git a/recipes-kernel/zephyr-kernel/files/0001-cmake-add-yocto-toolchain.patch b/recipes-kernel/zephyr-kernel/files/0001-cmake-add-yocto-toolchain.patch
new file mode 100644
index 0000000..2f91c6f
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-cmake-add-yocto-toolchain.patch
@@ -0,0 +1,76 @@
+From 7dffe6c78e6799a3dfd3910876b29645305a55db Mon Sep 17 00:00:00 2001
+From: Naveen Saini <naveen.kumar.saini@intel.com>
+Date: Tue, 19 Nov 2019 14:36:19 +0800
+Subject: [PATCH] cmake: add yocto toolchain
+
+Upstream status: inappropriate [OE specific]
+
+Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
+---
+ cmake/app/boilerplate.cmake | 1 +
+ cmake/compiler/gcc/target.cmake | 7 -------
+ cmake/toolchain/yocto/generic.cmake | 13 +++++++++++++
+ cmake/toolchain/yocto/target.cmake | 1 +
+ 4 files changed, 15 insertions(+), 7 deletions(-)
+ create mode 100644 cmake/toolchain/yocto/generic.cmake
+ create mode 100644 cmake/toolchain/yocto/target.cmake
+
+diff --git a/cmake/app/boilerplate.cmake b/cmake/app/boilerplate.cmake
+index b0920b1d95..2dceead6c0 100644
+--- a/cmake/app/boilerplate.cmake
++++ b/cmake/app/boilerplate.cmake
+@@ -441,6 +441,7 @@ else()
+ set(SOC_PATH ${SOC_FAMILY}/${SOC_SERIES})
+ endif()
+
++#include(${ZEPHYR_BASE}/cmake/toolchain-yocto.cmake)
+ include(${ZEPHYR_BASE}/cmake/target_toolchain.cmake)
+
+ set(KERNEL_NAME ${CONFIG_KERNEL_BIN_NAME})
+diff --git a/cmake/compiler/gcc/target.cmake b/cmake/compiler/gcc/target.cmake
+index accd4ff19f..1d4018f5e6 100644
+--- a/cmake/compiler/gcc/target.cmake
++++ b/cmake/compiler/gcc/target.cmake
+@@ -85,13 +85,6 @@ if(NOT no_libgcc)
+ OUTPUT_STRIP_TRAILING_WHITESPACE
+ )
+
+- assert_exists(LIBGCC_FILE_NAME)
+-
+- get_filename_component(LIBGCC_DIR ${LIBGCC_FILE_NAME} DIRECTORY)
+-
+- assert_exists(LIBGCC_DIR)
+-
+- LIST(APPEND LIB_INCLUDE_DIR "-L\"${LIBGCC_DIR}\"")
+ LIST(APPEND TOOLCHAIN_LIBS gcc)
+ endif()
+
+diff --git a/cmake/toolchain/yocto/generic.cmake b/cmake/toolchain/yocto/generic.cmake
+new file mode 100644
+index 0000000000..45e5777e2a
+--- /dev/null
++++ b/cmake/toolchain/yocto/generic.cmake
+@@ -0,0 +1,13 @@
++set(COMPILER gcc)
++set(LINKER ld)
++set(BINTOOLS gnu)
++
++set(ZEPHYR_SYSROOT ${ZEPHYR_SYSROOT})
++set(SYSROOT_DIR ${ZEPHYR_SYSROOT})
++set(LIBC_LIBRARY_DIR "\"${SYSROOT_DIR}\"/")
++set(LIBC_INCLUDE_DIR ${SYSROOT_DIR}/include)
++LIST(APPEND TOOLCHAIN_LIBS gcc)
++
++LIST(APPEND LIB_INCLUDE_DIR "-L\"${STAGING_LIBDIR}\"")
++
++set(TOOLCHAIN_LIBS gcc)
+diff --git a/cmake/toolchain/yocto/target.cmake b/cmake/toolchain/yocto/target.cmake
+new file mode 100644
+index 0000000000..9881313609
+--- /dev/null
++++ b/cmake/toolchain/yocto/target.cmake
+@@ -0,0 +1 @@
++# SPDX-License-Identifier: Apache-2.0
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 2f3051d..4fab740 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -20,8 +20,6 @@ CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

DEPENDS_append_qemuall = " qemu-native qemu-helper-native"

-do_configure[noexec] = "1"
-
# The makefiles are explicit about the flags they want, so don't unset
# them so zephyr flags actually get used.
# This is done here rather than in the task so that things still work
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.0.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.0.bb
new file mode 100644
index 0000000..cb457f5
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.0.bb
@@ -0,0 +1,33 @@
+
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
+
+# tag v2.0
+SRCREV="ca3eb0eb31d134be41aefc952f696f7d9c356b7a"
+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.0-branch \
+ file://0001-cmake-add-yocto-toolchain.patch \
+ "
+inherit cmake
+PV = "2.0.0"
+S = "${WORKDIR}/git"
+
+IMAGE_NO_MANIFEST = "1"
+INHIBIT_DEFAULT_DEPS = "1"
+
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_compile () {
+}
+
+do_install () {
+ kerneldir=${D}/usr/src/zephyr
+ install -d $kerneldir
+ cp -r ${S}/* $kerneldir
+}
+
+PACKAGES = "${PN}"
+FILES_${PN} = "/usr/src/zephyr"
+
+SYSROOT_DIRS += "/usr/src/zephyr"
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel.inc
index ec7b5ae..903973d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel.inc
@@ -2,7 +2,3 @@
inherit zephyr-kernel-src

S = "${WORKDIR}/git"
-
-do_compile_prepend() {
- cp ${WORKDIR}/Makefile.toolchain.yocto ${S}/scripts
-}
--
2.17.1


[meta-zephyr][PATCH 06/13] zephyr-kernel: drop v1.7

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
classes/zephyr-kernel-src.bbclass | 10 -----
.../zephyr-kernel/zephyr-kernel-src_1.7.bb | 40 -------------------
2 files changed, 50 deletions(-)
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.7.bb

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index 4a0d554..af53e8e 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -8,12 +8,6 @@ SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=
file://Makefile.toolchain.yocto "
PV = "1.6.0"

-# FIXME: This points to 1.7.rc4
-SRCREV_1.7 = "3d2893cf85d51ceca04aa3bec2dd5fc77625ff81"
-SRC_URI_1.7 = "git://gerrit.zephyrproject.org/r/zephyr.git;protocol=https;branch=v1.7-branch\
- file://Makefile.toolchain.yocto "
-PV_1.7 = "1.7.0"
-
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

@@ -23,10 +17,6 @@ python () {
src_pn = d.getVar('PREFERRED_VERSION_zephyr-kernel', True)
if src_pn == '1.6.0':
return
- elif src_pn == '1.7.0':
- d.setVar('SRC_URI',d.getVar('SRC_URI_1.7', True))
- d.setVar('SRCREV',d.getVar('SRCREV_1.7', True))
- d.setVar('PV',d.getVar('PV_1.7', True))
else:
bb.error("Unsupported Zephyr kernel version requested")
}
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.7.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.7.bb
deleted file mode 100644
index 63610f3..0000000
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.7.bb
+++ /dev/null
@@ -1,40 +0,0 @@
-
-LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
-
-SRCREV = "3d2893cf85d51ceca04aa3bec2dd5fc77625ff81"
-SRC_URI = "git://gerrit.zephyrproject.org/r/zephyr.git;protocol=https;branch=v1.7-branch"
-SRC_URI += "file://Makefile.toolchain.yocto"
-
-PV = "1.7.0"
-
-S = "${WORKDIR}/git"
-
-IMAGE_NO_MANIFEST = "1"
-INHIBIT_DEFAULT_DEPS = "1"
-
-do_compile[noexec] = "1"
-
-do_configure() {
- cp ${WORKDIR}/Makefile.toolchain.yocto ${S}/scripts
-}
-
-do_compile () {
-}
-
-
-do_install () {
- kerneldir=${D}/usr/src/zephyr
- install -d $kerneldir
- cp -r ${S}/* $kerneldir
-}
-
-PACKAGES = "${PN}"
-FILES_${PN} = "/usr/src/zephyr"
-
-SYSROOT_DIRS += "/usr/src/zephyr"
-
-#WARNING: zephyr-kernel-src-1.7.0-r0 do_package_qa: QA Issue:
-# /usr/src/zephyr/scripts/checkpatch.pl contained in package zephyr-kernel-src
-# requires /usr/bin/perl, but no providers found in RDEPENDS_zephyr-kernel-src?
-INSANE_SKIP_${PN} = "file-rdeps"
--
2.17.1


[meta-zephyr][PATCH 05/13] qemu-x86.conf: remove invalid options

Naveen Saini
 

Throw below error:

runqemu - ERROR - Failed to run qemu: qemu-system-i386: -clock: invalid option

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/qemu-x86.conf | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index 8bf1e35..ac6fb8f 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -10,7 +10,8 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
# For runqemu
QB_SYSTEM_NAME = "qemu-system-i386"
QB_MACHINE = "-machine pc-0.14"
-QB_OPT_APPEND = "-nographic -display none -clock dynticks -no-acpi -balloon none"
+#QB_OPT_APPEND = "-nographic -display none -clock dynticks -no-acpi -balloon none"
+QB_OPT_APPEND = "-nographic -display none -no-acpi"
QB_CPU_x86 = "-cpu qemu32"
QB_CPU_KVM_x86 = "-cpu kvm32"

--
2.17.1


[meta-zephyr][PATCH 04/13] zephyr-helloworld: add

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
.../zephyr-kernel/zephyr-helloworld.bb | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-helloworld.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
new file mode 100644
index 0000000..8900bfd
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
@@ -0,0 +1,18 @@
+require zephyr-kernel.inc
+require zephyr-kernel-common.inc
+inherit deploy
+
+ZEPHYR_SRC_DIR = "${S}/samples/hello_world"
+ZEPHYR_BASE = "${S}"
+
+do_compile () {
+ cd ${ZEPHYR_SRC_DIR}
+ oe_runmake ${ZEPHYR_MAKE_ARGS}
+}
+
+do_deploy () {
+ install -D samples/hello_world/outdir/${BOARD}/zephyr.elf ${DEPLOYDIR}/${PN}.elf
+ install -D samples/hello_world/outdir/${BOARD}/zephyr.bin ${DEPLOYDIR}/${PN}.bin
+}
+
+addtask deploy after do_compile
--
2.17.1


[meta-zephyr][PATCH 03/13] zephyr-kernel-src: updated SRC_URI to point to github

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
classes/zephyr-kernel-src.bbclass | 3 ++-
recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index d7aa81b..4a0d554 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -3,7 +3,8 @@
PREFERRED_VERSION_zephyr-kernel ??= "1.6.0"

SRCREV = "d4e799d77a36eaf6d678b357c207411ec32b2d62"
-SRC_URI = "git://gerrit.zephyrproject.org/r/zephyr.git;protocol=https;branch=v1.6.0-branch \
+
+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v1.6-branch \
file://Makefile.toolchain.yocto "
PV = "1.6.0"

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb
index df373e8..b47e8ac 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src_1.6.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

# tag v1.6.0
SRCREV="d4e799d77a36eaf6d678b357c207411ec32b2d62"
-SRC_URI = "git://gerrit.zephyrproject.org/r/zephyr.git;protocol=https;branch=v1.6.0-branch"
+SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v1.6-branch"
SRC_URI += "file://Makefile.toolchain.yocto"

PV = "1.6.0"
--
2.17.1


[meta-zephyr][PATCH 02/13] qemu: updated version to bbappend latest bb

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
.../qemu/{qemu_2.8.%.bbappend => qemu_4.1.%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-devtools/qemu/{qemu_2.8.%.bbappend => qemu_4.1.%.bbappend} (100%)

diff --git a/recipes-devtools/qemu/qemu_2.8.%.bbappend b/recipes-devtools/qemu/qemu_4.1.%.bbappend
similarity index 100%
rename from recipes-devtools/qemu/qemu_2.8.%.bbappend
rename to recipes-devtools/qemu/qemu_4.1.%.bbappend
--
2.17.1


[meta-zephyr][PATCH 01/13] layer.conf: add LAYERSERIES_COMPAT to warrior & zeus

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/layer.conf | 2 ++
1 file changed, 2 insertions(+)

diff --git a/conf/layer.conf b/conf/layer.conf
index f7cd15d..cb0064f 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,3 +14,5 @@ BBFILE_PRIORITY_zephyr = "6"
LAYERVERSION_zephyr = "1"

LAYERDEPENDS_zephyr = "core"
+
+LAYERSERIES_COMPAT_zephyr = "warrior zeus"
--
2.17.1


Re: linux-libc-headers - how to handle for older kernels?

Mikko Rapeli
 

Hi,

On Mon, Dec 02, 2019 at 09:28:03AM +0000, Mike Looijmans wrote:
One solution I can think of is to put the header into it's own
recipe/repository and then refer to it like any other library would. Refer to
that recipe from the module (or kernel) recipe that needs it. This way you
have your header in a single maintainable location and dependencies properly
taken care of.

If that's not something you could live with, share your recipes, since vague
problem descriptions will only get you vague solutions...
This is the problem I see with multiple BSPs. In the end for every one of them
the best solution is to fork linux-libc-headers.

Adding custom recipes to export headers for every BSP kernel is not scaling so well.

Sharing the BSPs and hacks around them would be nice but they are not public sadly :(

Cheers,

-Mikko


Re: linux-libc-headers - how to handle for older kernels?

Mike Looijmans
 

On 02-12-19 10:19, Mikko.Rapeli@bmw.de wrote:
Hi,

On Mon, Dec 02, 2019 at 09:13:47AM +0000, Mike Looijmans wrote:
On 01-12-19 22:57, Peter Bergin via Lists.Yoctoproject.Org wrote:
Hi,

I'm currently working in a project using Yocto 2.6 (thud) release. It has
default kernel v4.18 and also linux-libc-headers from kernel v4.18. In my
project we will use kernel v4.1. I would like advice how to handle the
linux-libc-headers package for my project, should I use the v4.18 headers or
should I use the v4.1 header files which matches the running kernel?

From https://www.kernel.org/doc/html/latest/kbuild/headers_install.html:
"Kernel headers are backwards compatible, but not forwards compatible. This
means that a program built against a C library using older kernel headers
should run on a newer kernel (although it may not have access to new
features), but a program built against newer kernel headers may not work on an
older kernel."

With the information from the quote above I would directly use v4.1 headers as
my linux-libc-headers. But then reading the information in the file
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc makes me think
another round. It states:

"
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
...
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
"

The first part states that I should not change linux-libc-headers. But when I
read the last part I'm not sure about the interpretation and it could be for
my case. Just a matter of definition if v4.1 is extremely old compared to v4.18.

Then another thing comes in to the equation; the LIBC ABI. When I look into
the configuration of the glibc package it uses the configure switch
"--enable-kernel=3.2" which means it shall be compatible with all kernel newer
than v3.2. Then probably glibc is fine if it is compiled with v4.18 and run on
v4.1?

If building all applications against v4.18 headers but run on v4.1 kernel. I
have a feeling that there potentially can be problems here.

Please help me with some information about this and share your opinions? Are
there any risks at all to use v4.1 as linux-libc-headers in my Yocto build?
The only drawback I see is that it will be a new configuration not well tested
by the community. Are there other risks or drawbacks using your own version of
linux-libc-headers?

It is not broken, so please don't fix it.

OpenPLi has been using kernels way older than 4.1 with the kernel-headers
generated by OE/yocto and did not experience any problems with that. There's
about 50+ machines in there that have pre-built binary drivers that only work
with a particular kernel config and hence the old stuff.

There are some corner-cases with exotic kernels and exotic exports and exotic
boot executables that use the kernel compiler, but I doubt that you're in there...

If you have a kernel that exports something that's not in the regular headers,
it's way better to solve that using a syscall than trying to poke in low level
libc stuff.

So again, if you don't experience problems, please don't try to fix it...
How to find a Linux kernel uapi header file with custom ioctl() etc definitions which
are missing form the default linux-libc-headers?

Other recipes and SDK builds need these.

Copying the needed header files into the recipes who needs them is not ok.
One solution I can think of is to put the header into it's own
recipe/repository and then refer to it like any other library would. Refer to
that recipe from the module (or kernel) recipe that needs it. This way you
have your header in a single maintainable location and dependencies properly
taken care of.

If that's not something you could live with, share your recipes, since vague
problem descriptions will only get you vague solutions...


Re: linux-libc-headers - how to handle for older kernels?

Mikko Rapeli
 

Hi,

On Mon, Dec 02, 2019 at 09:13:47AM +0000, Mike Looijmans wrote:
On 01-12-19 22:57, Peter Bergin via Lists.Yoctoproject.Org wrote:
Hi,

I'm currently working in a project using Yocto 2.6 (thud) release. It has
default kernel v4.18 and also linux-libc-headers from kernel v4.18. In my
project we will use kernel v4.1. I would like advice how to handle the
linux-libc-headers package for my project, should I use the v4.18 headers or
should I use the v4.1 header files which matches the running kernel?

From https://www.kernel.org/doc/html/latest/kbuild/headers_install.html:
"Kernel headers are backwards compatible, but not forwards compatible. This
means that a program built against a C library using older kernel headers
should run on a newer kernel (although it may not have access to new
features), but a program built against newer kernel headers may not work on an
older kernel."

With the information from the quote above I would directly use v4.1 headers as
my linux-libc-headers. But then reading the information in the file
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc makes me think
another round. It states:

"
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
...
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
"

The first part states that I should not change linux-libc-headers. But when I
read the last part I'm not sure about the interpretation and it could be for
my case. Just a matter of definition if v4.1 is extremely old compared to v4.18.

Then another thing comes in to the equation; the LIBC ABI. When I look into
the configuration of the glibc package it uses the configure switch
"--enable-kernel=3.2" which means it shall be compatible with all kernel newer
than v3.2. Then probably glibc is fine if it is compiled with v4.18 and run on
v4.1?

If building all applications against v4.18 headers but run on v4.1 kernel. I
have a feeling that there potentially can be problems here.

Please help me with some information about this and share your opinions? Are
there any risks at all to use v4.1 as linux-libc-headers in my Yocto build?
The only drawback I see is that it will be a new configuration not well tested
by the community. Are there other risks or drawbacks using your own version of
linux-libc-headers?

It is not broken, so please don't fix it.

OpenPLi has been using kernels way older than 4.1 with the kernel-headers
generated by OE/yocto and did not experience any problems with that. There's
about 50+ machines in there that have pre-built binary drivers that only work
with a particular kernel config and hence the old stuff.

There are some corner-cases with exotic kernels and exotic exports and exotic
boot executables that use the kernel compiler, but I doubt that you're in there...

If you have a kernel that exports something that's not in the regular headers,
it's way better to solve that using a syscall than trying to poke in low level
libc stuff.

So again, if you don't experience problems, please don't try to fix it...
How to find a Linux kernel uapi header file with custom ioctl() etc definitions which
are missing form the default linux-libc-headers?

Other recipes and SDK builds need these.

Copying the needed header files into the recipes who needs them is not ok.

Cheers,

-Mikko


Re: linux-libc-headers - how to handle for older kernels?

Mike Looijmans
 

On 01-12-19 22:57, Peter Bergin via Lists.Yoctoproject.Org wrote:
Hi,

I'm currently working in a project using Yocto 2.6 (thud) release. It has
default kernel v4.18 and also linux-libc-headers from kernel v4.18. In my
project we will use kernel v4.1. I would like advice how to handle the
linux-libc-headers package for my project, should I use the v4.18 headers or
should I use the v4.1 header files which matches the running kernel?

From https://www.kernel.org/doc/html/latest/kbuild/headers_install.html:
"Kernel headers are backwards compatible, but not forwards compatible. This
means that a program built against a C library using older kernel headers
should run on a newer kernel (although it may not have access to new
features), but a program built against newer kernel headers may not work on an
older kernel."

With the information from the quote above I would directly use v4.1 headers as
my linux-libc-headers. But then reading the information in the file
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc makes me think
another round. It states:

"
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
...
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
"

The first part states that I should not change linux-libc-headers. But when I
read the last part I'm not sure about the interpretation and it could be for
my case. Just a matter of definition if v4.1 is extremely old compared to v4.18.

Then another thing comes in to the equation; the LIBC ABI. When I look into
the configuration of the glibc package it uses the configure switch
"--enable-kernel=3.2" which means it shall be compatible with all kernel newer
than v3.2. Then probably glibc is fine if it is compiled with v4.18 and run on
v4.1?

If building all applications against v4.18 headers but run on v4.1 kernel. I
have a feeling that there potentially can be problems here.

Please help me with some information about this and share your opinions? Are
there any risks at all to use v4.1 as linux-libc-headers in my Yocto build?
The only drawback I see is that it will be a new configuration not well tested
by the community. Are there other risks or drawbacks using your own version of
linux-libc-headers?

It is not broken, so please don't fix it.

OpenPLi has been using kernels way older than 4.1 with the kernel-headers
generated by OE/yocto and did not experience any problems with that. There's
about 50+ machines in there that have pre-built binary drivers that only work
with a particular kernel config and hence the old stuff.

There are some corner-cases with exotic kernels and exotic exports and exotic
boot executables that use the kernel compiler, but I doubt that you're in there...

If you have a kernel that exports something that's not in the regular headers,
it's way better to solve that using a syscall than trying to poke in low level
libc stuff.

So again, if you don't experience problems, please don't try to fix it...


Re: linux-libc-headers - how to handle for older kernels?

Mikko Rapeli
 

Hi,

On Sun, Dec 01, 2019 at 10:57:15PM +0100, Peter Bergin wrote:
Hi,

I'm currently working in a project using Yocto 2.6 (thud) release. It has
default kernel v4.18 and also linux-libc-headers from kernel v4.18. In my
project we will use kernel v4.1. I would like advice how to handle the
linux-libc-headers package for my project, should I use the v4.18 headers or
should I use the v4.1 header files which matches the running kernel?

From https://www.kernel.org/doc/html/latest/kbuild/headers_install.html:
"Kernel headers are backwards compatible, but not forwards compatible. This
means that a program built against a C library using older kernel headers
should run on a newer kernel (although it may not have access to new
features), but a program built against newer kernel headers may not work on
an older kernel."

With the information from the quote above I would directly use v4.1 headers
as my linux-libc-headers. But then reading the information in the file
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc makes me think
another round. It states:

"
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
...
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
"

The first part states that I should not change linux-libc-headers. But when
I read the last part I'm not sure about the interpretation and it could be
for my case. Just a matter of definition if v4.1 is extremely old compared
to v4.18.

Then another thing comes in to the equation; the LIBC ABI. When I look into
the configuration of the glibc package it uses the configure switch
"--enable-kernel=3.2" which means it shall be compatible with all kernel
newer than v3.2. Then probably glibc is fine if it is compiled with v4.18
and run on v4.1?

If building all applications against v4.18 headers but run on v4.1 kernel. I
have a feeling that there potentially can be problems here.

Please help me with some information about this and share your opinions? Are
there any risks at all to use v4.1 as linux-libc-headers in my Yocto build?
The only drawback I see is that it will be a new configuration not well
tested by the community. Are there other risks or drawbacks using your own
version of linux-libc-headers?
I would fork linux-libc-headers to the kernel you are actually using despite the
comment in the file.

That's the only way to export headers from the correct kernel to everyone
who needs them.

There is no other documented way of exporting the actual kernel headers to users
in bitbake builds and SDK.

One optimization I would do is to fork the uapi headers from the actual kernel
recipe so that full system does not need to be recompiled when kernel changes.

One needs to manually track for kernel uapi header changes then.

Cheers,

-Mikko


trying to use ext4 rootfs image in a wic image (dependency issues)

Theodore A. Roth
 

Hello,

I'm trying to create a wic image that contains an ext4 partition image
file in the /boot partition . I've set the following:

IMAGE_FSTYPES = "tar.xz ext4 wic wic.bmap"
IMAGE_BOOT_FILES += "${IMAGE_BASENAME}-${MACHINE}.ext4;rootfs.ext4"

I'm using "beaglebone-yocto" for MACHINE and the above overrides what
is set in the "beaglebone-yocto.conf" machine configuration.

When I run "bitbake myimage", the do_image_wic task fails to find the
""${IMAGE_BASENAME}-${MACHINE}.ext4" because the do_image_wic task is
run before the do_image_complete task copies the files from DEPLOYDIR
into DEPLOY_DIR_IMAGE. Since the do_image_wic task is looking in
DEPLOY_DIR_IMAGE and is run before the do_image_complete task due to
dependencies, the creation of the wic image fails.

I tried to work around this with the following:

do_image_wic[recrdeptask] += "do_image_ext4"

but I quickly discovered that does not work due do_image_complete
copying of files (as discussed above).

If I remove "wic*" from IMAGE_FSTYPES, build myimage and then run wic
manually, all is good, but I lose the automating of wic image creation
when building the image recipe and also lose the ability to have other
image recipes inherit (via "include") and extend the base image (thus
inheriting the wic creation rules).

The end goal is to have an initramfs which loopback mounts the ext4
rootfs partition readonly from the /boot partition.

Any suggestions on how to get do_image_ext4 generated files available
to do_image_wic?

Ted Roth


linux-libc-headers - how to handle for older kernels?

Peter Bergin
 

Hi,

I'm currently working in a project using Yocto 2.6 (thud) release. It has default kernel v4.18 and also linux-libc-headers from kernel v4.18. In my project we will use kernel v4.1. I would like advice how to handle the linux-libc-headers package for my project, should I use the v4.18 headers or should I use the v4.1 header files which matches the running kernel?

From https://www.kernel.org/doc/html/latest/kbuild/headers_install.html:
"Kernel headers are backwards compatible, but not forwards compatible. This means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel."

With the information from the quote above I would directly use v4.1 headers as my linux-libc-headers. But then reading the information in the file meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc makes me think another round. It states:

"
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
...
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
"

The first part states that I should not change linux-libc-headers. But when I read the last part I'm not sure about the interpretation and it could be for my case. Just a matter of definition if v4.1 is extremely old compared to v4.18.

Then another thing comes in to the equation; the LIBC ABI. When I look into the configuration of the glibc package it uses the configure switch "--enable-kernel=3.2" which means it shall be compatible with all kernel newer than v3.2. Then probably glibc is fine if it is compiled with v4.18 and run on v4.1?

If building all applications against v4.18 headers but run on v4.1 kernel. I have a feeling that there potentially can be problems here.

Please help me with some information about this and share your opinions? Are there any risks at all to use v4.1 as linux-libc-headers in my Yocto build? The only drawback I see is that it will be a new configuration not well tested by the community. Are there other risks or drawbacks using your own version of linux-libc-headers?

Best regards,
/Peter


Re: Mising init and systemd binary files

JH
 

Thanks Paul, indeed, what was I missing.

Kind regards,

- jh

On 11/30/19, Paul Barker <paul@betafive.co.uk> wrote:
On Sat, 30 Nov 2019, at 11:28, JH wrote:
Hi,

I built a Yocto image, but could not find /init, usually it should be
a symbolic link in /init->/sbin/init->/lib/systemd/systemd, In
/lib/systemd directory, it only contains a subdirectory system, all
other systemd binaries are missing, many system commands in /sbin are
also missing. What could I get wrong here to miss out all systemd
files?
Are you using an existing image recipe or writing your own? If it's your
own, do you have packagegroup-core-boot included?

Thanks,

--
Paul Barker


Re: Mising init and systemd binary files

 

On Sat, 30 Nov 2019, at 11:28, JH wrote:
Hi,

I built a Yocto image, but could not find /init, usually it should be
a symbolic link in /init->/sbin/init->/lib/systemd/systemd, In
/lib/systemd directory, it only contains a subdirectory system, all
other systemd binaries are missing, many system commands in /sbin are
also missing. What could I get wrong here to miss out all systemd
files?
Are you using an existing image recipe or writing your own? If it's your own, do you have packagegroup-core-boot included?

Thanks,

--
Paul Barker


Mising init and systemd binary files

JH
 

Hi,

I built a Yocto image, but could not find /init, usually it should be
a symbolic link in /init->/sbin/init->/lib/systemd/systemd, In
/lib/systemd directory, it only contains a subdirectory system, all
other systemd binaries are missing, many system commands in /sbin are
also missing. What could I get wrong here to miss out all systemd
files?

Thank you.

Kind regards,

- jh


Re: How does metadata include in an image recipe work?

Morne
 

but when I run bitbake ex-image2, it only built ex-image2 image, it did not built images defined in ex-image1.bb.
See this previous answer on the mailing list to a similar question:

https://www.yoctoproject.org/pipermail/yocto/2018-August/042220.html

- Morné


Add package to rootfs

JH
 

Hi,

I built a Yocto image in a file app-image.rootfs.tar.gz, I also built
a kernel initramfs to bundle the rootfs, but that kernel rootfs is
different to my app-image.rootfs.tar.gz, how to define IMAGE_ROOTFS to
have my kernel rootfs point to the same rootfs packaged to
app-image.rootfs.tar.gz?

Thank you.

Kind regards,

- jh

6321 - 6340 of 53814