Date   

[meta-zephy][PATCH 11/14] zephyr-flash-pyocd.bbclass: Flash the first probe found with a timeout

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

Currently the code flashes the firmware in a blocking way. If the host
is not configured accordingly (for example in terms of permissions),
this would hang undefinitely. This can easily confuse users and in order
to avoid this, the patch changes to unblocking session creation and
opening call, wrapping the tries in some relevant logging. The timeout
can be defined with `CONNECT_TIMEOUT_SECONDS` which defaults to 30
seconds.

Also, by default, when multiple probes are attached, the session call
will return a selection choice. This would obviously break under bitbake
with an exception:
Exception: EOFError: EOF when reading a line
Avoid this by selecting the first found probe.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
classes/zephyr-flash-pyocd.bbclass | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass
index eca30c9..df3b631 100644
--- a/classes/zephyr-flash-pyocd.bbclass
+++ b/classes/zephyr-flash-pyocd.bbclass
@@ -1,11 +1,27 @@
+CONNECT_TIMEOUT_SECONDS ?= "30"
+
python do_flash_usb() {
from pyocd.core.helpers import ConnectHelper
from pyocd.flash.file_programmer import FileProgrammer

+ timeout = int(d.getVar('CONNECT_TIMEOUT_SECONDS'))
image = f"{d.getVar('DEPLOY_DIR_IMAGE')}/{d.getVar('PN')}.elf"
bb.plain(f"Attempting to flash {image} to board {d.getVar('BOARD')}")

- with ConnectHelper.session_with_chosen_probe() as session:
+ # Try to connect to a probe with a timeout
+ now = 0
+ step = 3
+ while True:
+ session = ConnectHelper.session_with_chosen_probe(blocking=False, return_first=True)
+ if session:
+ break
+ if now >= timeout:
+ bb.fatal("Timeout while trying to connect to a probe. Make sure the target device is connected and the udev is configured accordingly. See <https://github.com/mbedmicro/pyOCD/tree/master/udev> for help.")
+ bb.warn("Can't connect to the probe. Retrying in %d seconds..." % step)
+ time.sleep(step)
+ now += step
+
+ with session:
FileProgrammer(session).program(image)
session.board.target.reset()
}
--
2.30.1


[meta-zephy][PATCH 10/14] zephyr-peripheral-hr: Add recipe for BT HR sample

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
recipes-kernel/zephyr-kernel/zephyr-peripheral-hr.bb | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-peripheral-hr.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-peripheral-hr.bb b/recipes-kernel/zephyr-kernel/zephyr-peripheral-hr.bb
new file mode 100644
index 0000000..e6ef7b8
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-peripheral-hr.bb
@@ -0,0 +1,5 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/bluetooth/peripheral_hr"
+
+ZEPHYR_MODULES_append = "\;${S}/modules/crypto/tinycrypt"
--
2.30.1


[meta-zephy][PATCH 09/14] Use an include file for the common parts of the sample recipes

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
recipes-kernel/zephyr-kernel/zephyr-hci-uart.bb | 16 ++--------------
.../zephyr-kernel/zephyr-helloworld.bb | 13 +------------
.../zephyr-kernel/zephyr-kernel-test.bb | 4 ----
.../zephyr-kernel/zephyr-kernel-test.inc | 2 --
.../zephyr-kernel/zephyr-peripheral-esp.bb | 17 +++--------------
.../zephyr-kernel/zephyr-philosophers.bb | 13 +------------
recipes-kernel/zephyr-kernel/zephyr-sample.inc | 13 +++++++++++++
7 files changed, 20 insertions(+), 58 deletions(-)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-sample.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-hci-uart.bb b/recipes-kernel/zephyr-kernel/zephyr-hci-uart.bb
index ec6b13e..c66c7ec 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-hci-uart.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-hci-uart.bb
@@ -1,17 +1,5 @@
-require zephyr-kernel.inc
-require zephyr-kernel-common.inc
-inherit deploy
-
-COMPATIBLE_MACHINE = "(96b-nitrogen)"
+include zephyr-sample.inc

ZEPHYR_SRC_DIR = "${S}/samples/bluetooth/hci_uart"
-ZEPHYR_BASE = "${S}"
-
-OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

-do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
-}
-
-addtask deploy after do_compile
-do_install[noexec] = "1"
+COMPATIBLE_MACHINE = "(96b-nitrogen)"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
index 84db068..ac5ce62 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
@@ -1,14 +1,3 @@
-require zephyr-kernel.inc
-require zephyr-kernel-common.inc
-inherit deploy
+include zephyr-sample.inc

ZEPHYR_SRC_DIR = "${S}/samples/hello_world"
-ZEPHYR_BASE = "${S}"
-OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"
-
-do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
-}
-
-addtask deploy after do_compile
-do_install[noexec] = "1"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.bb
index 46d93f0..2918d2d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.bb
@@ -2,7 +2,3 @@ require zephyr-image.inc
require zephyr-kernel-test.inc

BBCLASSEXTEND = '${@" ".join(["zephyrtest:" + x for x in d.getVar("ZEPHYRTESTS", True).split()])}'
-
-
-
-
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index a1e62af..b6b4766 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -2,11 +2,9 @@ ZEPHYRTESTS_remove = "fifo fpu_sharing lifo mbox mem_heap mem_pool \
mem_protect mem_slab msgq mutex pipe profiling sched semaphore \
stack threads tickless timer workq"

-
# Exclude tests which does not build for various reasons
ZEPHYRTESTS_remove = "gen_isr_table spinlock smp mp"

-
# test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register
#ZEPHYRTESTS_remove_arm += ""

diff --git a/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb b/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
index 24f030a..8be90d1 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-peripheral-esp.bb
@@ -1,16 +1,5 @@
-require zephyr-kernel.inc
-require zephyr-kernel-common.inc
-inherit deploy
+include zephyr-sample.inc

-ZEPHYR_SAMPLE_NAME="samples/bluetooth/peripheral_esp"
-ZEPHYR_SRC_DIR = "${S}/${ZEPHYR_SAMPLE_NAME}"
-ZEPHYR_BASE = "${S}"
-OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"
-ZEPHYR_MODULES_append = "\;${S}/modules/crypto/tinycrypt"
-
-do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
-}
+ZEPHYR_SRC_DIR = "${S}/samples/bluetooth/peripheral_esp"

-addtask deploy after do_compile
-do_install[noexec] = "1"
+ZEPHYR_MODULES_append = "\;${S}/modules/crypto/tinycrypt"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
index b8262ca..a2afb57 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
@@ -1,14 +1,3 @@
-require zephyr-kernel.inc
-require zephyr-kernel-common.inc
-inherit deploy
+include zephyr-sample.inc

ZEPHYR_SRC_DIR = "${S}/samples/philosophers"
-ZEPHYR_BASE = "${S}"
-OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"
-
-do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
-}
-
-addtask deploy after do_compile
-do_install[noexec] = "1"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-sample.inc b/recipes-kernel/zephyr-kernel/zephyr-sample.inc
new file mode 100644
index 0000000..f7621d1
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-sample.inc
@@ -0,0 +1,13 @@
+require zephyr-kernel-src.inc
+require zephyr-kernel-common.inc
+inherit deploy
+
+ZEPHYR_BASE = "${S}"
+OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"
+
+do_install[noexec] = "1"
+
+do_deploy () {
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
+}
+addtask deploy after do_compile
--
2.30.1


[meta-zephy][PATCH 08/14] zephyr-kernel.inc: Remove include file

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

This file has little advantage and can be easily replaced by just
directly including the src include file.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
recipes-kernel/zephyr-kernel/zephyr-image.inc | 2 +-
recipes-kernel/zephyr-kernel/zephyr-kernel.inc | 4 ----
2 files changed, 1 insertion(+), 5 deletions(-)
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-image.inc b/recipes-kernel/zephyr-kernel/zephyr-image.inc
index e8b8871..c77692d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-image.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-image.inc
@@ -1,4 +1,4 @@
-require zephyr-kernel.inc
+require zephyr-kernel-src.inc
require zephyr-kernel-common.inc

inherit testimage
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel.inc
deleted file mode 100644
index 903973d..0000000
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel.inc
+++ /dev/null
@@ -1,4 +0,0 @@
-
-inherit zephyr-kernel-src
-
-S = "${WORKDIR}/git"
--
2.30.1


[meta-zephy][PATCH 07/14] zephyr-kernel-common.inc: Reformat EXTRA_OECMAKE

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

This will improve diffs readability in the future.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index abc55ba..330fe59 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -13,7 +13,16 @@ ZEPHYR_SYSROOT="${STAGING_DIR_TARGET}"

ZEPHYR_MAKE_OUTPUT = "zephyr.elf"

-EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto -DEXTRA_CPPFLAGS=${CPPFLAGS}"
+EXTRA_OECMAKE = "\
+ -DZEPHYR_BASE=${S} \
+ -DZEPHYR_GCC_VARIANT=yocto \
+ -DBOARD=${BOARD} \
+ -DARCH=${ARCH} \
+ -DCROSS_COMPILE=${CROSS_COMPILE} \
+ -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} \
+ -DZEPHYR_TOOLCHAIN_VARIANT=yocto \
+ -DEXTRA_CPPFLAGS=${CPPFLAGS} \
+ "

ZEPHYR_MODULES = ""
ZEPHYR_MODULES_append_arm = "\;${S}/modules/cmsis"
--
2.30.1


[meta-zephy][PATCH 06/14] zephyr-kernel-common.inc: Fix configuration CPPFLAGS warning

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

Configure warns when CPPFLAGS is provided as environment variable and
expects its value to be passed to cmake. This patch does that to
surpress the warning.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 5313030..abc55ba 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -13,8 +13,7 @@ ZEPHYR_SYSROOT="${STAGING_DIR_TARGET}"

ZEPHYR_MAKE_OUTPUT = "zephyr.elf"

-
-EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto"
+EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto -DEXTRA_CPPFLAGS=${CPPFLAGS}"

ZEPHYR_MODULES = ""
ZEPHYR_MODULES_append_arm = "\;${S}/modules/cmsis"
@@ -26,7 +25,6 @@ EXTRA_OECMAKE_append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"

export ZEPHYR_BASE="${S}"

-
DEPENDS += "gperf-native python3-pyelftools-native python3-pyyaml-native python3-pykwalify-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

@@ -51,3 +49,8 @@ OE_TERMINAL_EXPORTS += "ZEPHYR_SYSROOT"
OE_TERMINAL_EXPORTS += "ZEPHYR_GCC_VARIANT"

IMAGE_FSTYPES = "elf bin"
+
+do_configure_prepend() {
+ # Zephyr expects CPPFLAGS as cmake argument as and ignores env variables.
+ unset CPPFLAGS
+}
--
2.30.1


[meta-zephy][PATCH 05/14] zephyr-kernel-src-2.5.0-rc3.inc: Add support for zephyr kernel version 2.5.0-rc3

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

This version can be selected defining
PREFERRED_VERSION_zephyr-kernel ??= "2.5.0-rc3"

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
.../zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc
new file mode 100644
index 0000000..4ee9883
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc
@@ -0,0 +1,10 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "v2.5.0-rc3"
+SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
+SRCREV_nordic = "f3434da6446380fcdd426dbe2866af21d0d549b6"
+SRCREV_stm32 = "cc8731dba4fd9c57d7fe8ea6149828b89c2bd635"
+SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
+SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+
+PV = "2.5.0-rc3+git${SRCPV}"
--
2.30.1


[meta-zephy][PATCH 04/14] zephyr-kernel-src: Restructure recipe

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

* Restructure recipe to use include files as opposed to a bbclass. The
latter is unnatural when defining versions, sources etc.
* Make the zephyr-kernel-src follow the version as defined by
PREFERRED_VERSION_zephyr-kernel.
* Make the setup of the zephyr-kernel-src.inc extensible for multiple
versions.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
classes/zephyr-kernel-src.bbclass | 37 -------------------
.../zephyr-kernel/zephyr-kernel-src-2.4.0.inc | 10 +++++
...kernel-src_2.4.bb => zephyr-kernel-src.bb} | 9 +----
.../zephyr-kernel/zephyr-kernel-src.inc | 20 ++++++++++
4 files changed, 32 insertions(+), 44 deletions(-)
delete mode 100644 classes/zephyr-kernel-src.bbclass
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc
rename recipes-kernel/zephyr-kernel/{zephyr-kernel-src_2.4.bb => zephyr-kernel-src.bb} (80%)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
deleted file mode 100644
index c6c8d61..0000000
--- a/classes/zephyr-kernel-src.bbclass
+++ /dev/null
@@ -1,37 +0,0 @@
-#Set relevant variables based on Zephyr kernel version
-
-PREFERRED_VERSION_zephyr-kernel ??= "2.4.0"
-
-SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "7a3b253ced7333f5c0269387a7f3ed1dee69739d"
-SRCREV_cmsis = "542b2296e6d515b265e25c6b7208e8fea3014f90"
-SRCREV_nordic = "d8a6ea9695ddf792bb18bb6035c13b1daac5d79c"
-SRCREV_stm32 = "f0e11398128ac9abdff713da5d3035e6c96e9b86"
-SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
-SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
-SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
-
-SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.4-branch;name=default \
- git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
- git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
- git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
- git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
- git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
- git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
- file://0001-cmake-add-yocto-toolchain.patch \
- "
-
-PV = "2.4.0+git${SRCPV}"
-
-LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
-
-ZEPHYR_TEST_SRCDIR = "tests/legacy/kernel/"
-
-python () {
- src_pn = d.getVar('PREFERRED_VERSION_zephyr-kernel', True)
- if src_pn == '2.4.0':
- return
- else:
- bb.error("Unsupported Zephyr kernel version requested")
-}
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc
new file mode 100644
index 0000000..d1ef80e
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc
@@ -0,0 +1,10 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "7a3b253ced7333f5c0269387a7f3ed1dee69739d"
+SRCREV_cmsis = "542b2296e6d515b265e25c6b7208e8fea3014f90"
+SRCREV_nordic = "d8a6ea9695ddf792bb18bb6035c13b1daac5d79c"
+SRCREV_stm32 = "f0e11398128ac9abdff713da5d3035e6c96e9b86"
+SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
+SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+
+PV = "2.4.0+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.4.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.bb
similarity index 80%
rename from recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.4.bb
rename to recipes-kernel/zephyr-kernel/zephyr-kernel-src.bb
index 8e8b5b8..210cfa7 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.4.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.bb
@@ -1,16 +1,12 @@
+include zephyr-kernel-src.inc

-inherit zephyr-kernel-src
-inherit cmake
-
-S = "${WORKDIR}/git"
+ZEPHYR_TEST_SRCDIR = "tests/legacy/kernel/"

IMAGE_NO_MANIFEST = "1"
INHIBIT_DEFAULT_DEPS = "1"

do_configure[noexec] = "1"
do_compile[noexec] = "1"
-
-
do_install () {
kerneldir=${D}/usr/src/zephyr
install -d $kerneldir
@@ -21,4 +17,3 @@ PACKAGES = "${PN}"
FILES_${PN} = "/usr/src/zephyr"

SYSROOT_DIRS += "/usr/src/zephyr"
-
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
new file mode 100644
index 0000000..2dcde74
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -0,0 +1,20 @@
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
+
+# Default to a stable version
+PREFERRED_VERSION_zephyr-kernel ??= "2.4.0"
+include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
+
+inherit cmake
+
+SRC_URI = "\
+ git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=master;name=default \
+ git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
+ git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
+ git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
+ git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
+ git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
+ git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
+ file://0001-cmake-add-yocto-toolchain.patch \
+ "
+S = "${WORKDIR}/git"
--
2.30.1


[meta-zephy][PATCH 03/14] Cleanup superflous new lines

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
classes/zephyrtest.bbclass | 2 --
conf/distro/zephyr.conf | 1 -
conf/machine/include/tune-arc.inc | 1 -
conf/machine/include/tune-iamcu.inc | 1 -
conf/machine/include/tune-nios2.inc | 1 -
5 files changed, 6 deletions(-)

diff --git a/classes/zephyrtest.bbclass b/classes/zephyrtest.bbclass
index 3acc4c3..248fd15 100644
--- a/classes/zephyrtest.bbclass
+++ b/classes/zephyrtest.bbclass
@@ -51,5 +51,3 @@ python testdata_clean() {
}

addtask do_testdata_write before do_build after do_deploy
-
-
diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index a98da32..6ecd421 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -1,4 +1,3 @@
-
DISTRO = "zephyr"
DISTRO_NAME = "Zephyr"
DISTRO_VERSION = "1.0"
diff --git a/conf/machine/include/tune-arc.inc b/conf/machine/include/tune-arc.inc
index 4bb6f4f..ff841e7 100644
--- a/conf/machine/include/tune-arc.inc
+++ b/conf/machine/include/tune-arc.inc
@@ -18,4 +18,3 @@ AVAILTUNES += "no-sdata"
TUNEVALID[nodata] = "ARC no-delete-null-pointer-checks"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'no-delete-null-pointer-checks', ' -fno-delete-null-pointer-checks', '', d)}"
AVAILTUNES += "no-delete-null-pointer-checks"
-
diff --git a/conf/machine/include/tune-iamcu.inc b/conf/machine/include/tune-iamcu.inc
index 6935375..20a93a6 100644
--- a/conf/machine/include/tune-iamcu.inc
+++ b/conf/machine/include/tune-iamcu.inc
@@ -9,4 +9,3 @@ TUNE_ARCH = "i586"
TUNEVALID[iamcu] = "Intel MCU"

PACKAGE_EXTRA_ARCHS_tune-iamcu = "iamcu"
-
diff --git a/conf/machine/include/tune-nios2.inc b/conf/machine/include/tune-nios2.inc
index c74326d..e8662eb 100644
--- a/conf/machine/include/tune-nios2.inc
+++ b/conf/machine/include/tune-nios2.inc
@@ -1,4 +1,3 @@
-
# Nios2 Architecture Definition

DEFAULTTUNE ?= "nios2"
--
2.30.1


[meta-zephy][PATCH 02/14] zephyr-flash-pyocd.bbclass: Add missing do_flash_usb dependency on do_deploy

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
classes/zephyr-flash-pyocd.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass
index 04500af..eca30c9 100644
--- a/classes/zephyr-flash-pyocd.bbclass
+++ b/classes/zephyr-flash-pyocd.bbclass
@@ -10,7 +10,7 @@ python do_flash_usb() {
session.board.target.reset()
}

-addtask do_flash_usb
+addtask do_flash_usb after do_deploy

do_flash_usb[nostamp] = "1"
do_flash_usb[vardepsexclude] = "BB_ORIGENV"
--
2.30.1


[meta-zephy][PATCH 01/14] zephyr-flash-dfu.bbclass: Add missing do_flash_usb dependency on do_deploy

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@...>

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
classes/zephyr-flash-dfu.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/zephyr-flash-dfu.bbclass b/classes/zephyr-flash-dfu.bbclass
index 32f589a..b4f3d49 100644
--- a/classes/zephyr-flash-dfu.bbclass
+++ b/classes/zephyr-flash-dfu.bbclass
@@ -59,7 +59,7 @@ python do_flash_usb() {
bb.utils.unlockfile(lock)
}

-addtask do_flash_usb
+addtask do_flash_usb after do_deploy

do_flash_usb[nostamp] = "1"
do_flash_usb[vardepsexclude] = "BB_ORIGENV"
--
2.30.1


Re: [meta-security-compliance][PATCH] scap-security-guide: Fix openembedded platform tests and build

Jate Sujjavanich
 

Ping

On Sun, Jan 10, 2021 at 11:21 AM Jate Sujjavanich <jatedev@...> wrote:
Add patches to fix openembedded nodistro tests and openembedded build within
ssg metadata.

Signed-Off-By: Jate Sujjavanich <jatedev@...>
---
 ...c-file-check-tests-in-installed-OS-d.patch | 46 +++++++++++++++++++
 ...g-openembedded-from-ssg-constants.py.patch | 34 ++++++++++++++
 .../scap-security-guide_git.bb                |  2 +
 3 files changed, 82 insertions(+)
 create mode 100644 meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
 create mode 100644 meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch

diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
new file mode 100644
index 0000000..60664a3
--- /dev/null
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
@@ -0,0 +1,46 @@
+From 2beb4bc83a157b21edb1a3fef295cd4cced467df Mon Sep 17 00:00:00 2001
+From: Jate Sujjavanich <jatedev@...>
+Date: Thu, 7 Jan 2021 18:10:01 -0500
+Subject: [PATCH 1/3] Fix platform spec, file check, tests in installed OS
+ detect for openembedded
+
+Change platform to multi in openembedded installed check matching others
+and allowing compile of xml into oval
+---
+ shared/checks/oval/installed_OS_is_openembedded.xml | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/shared/checks/oval/installed_OS_is_openembedded.xml b/shared/checks/oval/installed_OS_is_openembedded.xml
+index 763d17bcb..01df16b43 100644
+--- a/shared/checks/oval/installed_OS_is_openembedded.xml
++++ b/shared/checks/oval/installed_OS_is_openembedded.xml
+@@ -1,11 +1,9 @@
+-</def-group>
+-
+ <def-group>
+   <definition class="inventory" id="installed_OS_is_openembedded" version="2">
+     <metadata>
+       <title>OpenEmbedded</title>
+       <affected family="unix">
+-        <platform>OPENEMBEDDED</platform>
++        <platform>multi_platform_all</platform>
+       </affected>
+       <reference ref_id="cpe:/o:openembedded:openembedded:0"
+       source="CPE" />
+@@ -20,8 +18,11 @@
+     </criteria>
+   </definition>
+
+-  <ind:textfilecontent54_object id="test_openembedded" version="1" comment="Check OPenEmbedded version">
+-    <ind:filepath>/etc/os-release/ind:filepath>
++  <ind:textfilecontent54_test check="all" check_existence="at_least_one_exists" comment="Check OpenEmbedded version" id="test_openembedded" version="1">
++    <ind:object object_ref="obj_openembedded" />
++  </ind:textfilecontent54_test>
++  <ind:textfilecontent54_object id="obj_openembedded" version="1" comment="Check OpenEmbedded version">
++    <ind:filepath>/etc/os-release</ind:filepath>
+     <ind:pattern operation="pattern match">^VERSION_ID=\"nodistro\.[0-9].$</ind:pattern>
+     <ind:instance datatype="int">1</ind:instance>
+   </ind:textfilecontent54_object>
+--
+2.24.3 (Apple Git-128)
+
diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch
new file mode 100644
index 0000000..1e712f6
--- /dev/null
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch
@@ -0,0 +1,34 @@
+From 037a12301968a56f0c7e492ea4a05d2eecbd4cc6 Mon Sep 17 00:00:00 2001
+From: Jate Sujjavanich <jatedev@...>
+Date: Fri, 8 Jan 2021 20:18:00 -0500
+Subject: [PATCH 2/3] Fix missing openembedded from ssg/constants.py
+
+---
+ ssg/constants.py | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/ssg/constants.py b/ssg/constants.py
+index fab7cda5d..2ca289f84 100644
+--- a/ssg/constants.py
++++ b/ssg/constants.py
+@@ -234,7 +234,8 @@ PRODUCT_TO_CPE_MAPPING = {
+ }
+
+ MULTI_PLATFORM_LIST = ["rhel", "fedora", "rhosp", "rhv", "debian", "ubuntu",
+-                       "wrlinux", "opensuse", "sle", "ol", "ocp", "example"]
++                       "wrlinux", "opensuse", "sle", "ol", "ocp", "example",
++                       "openembedded"]
+
+ MULTI_PLATFORM_MAPPING = {
+     "multi_platform_debian": ["debian8"],
+@@ -249,6 +250,7 @@ MULTI_PLATFORM_MAPPING = {
+     "multi_platform_sle": ["sle11", "sle12"],
+     "multi_platform_ubuntu": ["ubuntu1404", "ubuntu1604", "ubuntu1804"],
+     "multi_platform_wrlinux": ["wrlinux"],
++    "multi_platform_openembedded": ["openembedded"],
+ }
+
+ RHEL_CENTOS_CPE_MAPPING = {
+--
+2.24.3 (Apple Git-128)
+
diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
index 6e7180f..0617c56 100644
--- a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
@@ -7,6 +7,8 @@ SRC_URI = "git://github.com/akuster/scap-security-guide.git;branch=oe-0.1.44; \
            file://0001-fix-deprecated-instance-of-element.getchildren.patch \
            file://0002-fix-deprecated-getiterator-function.patch \
            file://0003-fix-remaining-getchildren-and-getiterator-functions.patch \
+           file://0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch \
+           file://0002-Fix-missing-openembedded-from-ssg-constants.py.patch \
           "
 PV = "0.1.44+git${SRCPV}"

--
2.25.1


Re: Yocto Technical Team Minutes, Engineering Sync, for Feb 9 2021

Ross Burton <ross@...>
 

On Thu, 11 Feb 2021 at 21:14, Trevor Woerner <twoerner@...> wrote:
RP: there’s been a lot of churn in the versions (glibc, kernel, etc). if
anyone sees anything please raise a flag
Ross: yes, I’ve seen some issues, not always 100% reproducible
RP: x86 host?
Ross: not always
TimO: ubuntu host?
Ross: 20.04
RP: glibc-2.33 does have some interesting things, so i’m not surprised there
are issues
Randy: what are you seeing?
Ross: issues building the kernel (“dangerous relocations”)
RP: for dunfell we did a glibc-2.32 update but we’ll hold off on glibc-2.33
(thanks Michael!)
Ross: turning off uninative makes it go away
TimO: is that a Xen kernel?
Ross: no, just defconfig
I solved this issue: when running inside a container that uses seccomp
to filter the syscalls available, with glibc 2.33 inside (uninative,
for example), applications might end up calling faccessat2() (glibc
does this itself) which as a relatively new syscall is rejected by the
syscall filter. The rejection is EPERM but glibc only handles ENOSYS
so weird things happen.

I sent a workaround to oe-core, systemd 247 and Docker 20.10 are
fixed, but glibc appear to consider this a bug in other software and
not something it should handle.

Ross


Regarding Mender integration

U RAVI KUMAR <uppadaravi2511@...>
 

Hello folks,

I have some issues while integrating the mender on the yocto project.I have included meta-mener-core,meta-mender-raspberrypi layers.And iam getting the following error:

ERROR: u-boot-1_2020.07-r0 do_patch: Command Error: 'quilt --quiltrc /home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0  Output:
Applying patch 0001-configs-rpi-enable-mender-requirements.patch
patching file configs/rpi_0_w_defconfig
Hunk #1 FAILED at 19.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_0_w_defconfig
patching file configs/rpi_2_defconfig
Hunk #1 FAILED at 19.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_2_defconfig
patching file configs/rpi_3_32b_defconfig
Hunk #1 FAILED at 20.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_3_32b_defconfig
patching file configs/rpi_3_b_plus_defconfig
Hunk #1 FAILED at 20.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_3_b_plus_defconfig
patching file configs/rpi_3_defconfig
Hunk #1 FAILED at 20.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_3_defconfig
patching file configs/rpi_4_32b_defconfig
Hunk #1 FAILED at 16.
Hunk #2 succeeded at 45 (offset 12 lines).
1 out of 2 hunks FAILED -- rejects in file configs/rpi_4_32b_defconfig
patching file configs/rpi_4_defconfig
Hunk #1 FAILED at 16.
Hunk #2 succeeded at 45 (offset 12 lines).
1 out of 2 hunks FAILED -- rejects in file configs/rpi_4_defconfig
patching file configs/rpi_arm64_defconfig
Hunk #1 FAILED at 17.
Hunk #2 succeeded at 43 (offset 1 line).
1 out of 2 hunks FAILED -- rejects in file configs/rpi_arm64_defconfig
patching file configs/rpi_defconfig
Hunk #1 FAILED at 19.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_defconfig
patching file env/Kconfig
Hunk #1 succeeded at 55 (offset 6 lines).
patching file include/configs/rpi.h
Hunk #1 succeeded at 97 (offset 17 lines).
Patch 0001-configs-rpi-enable-mender-requirements.patch does not apply (enforce with -f)
ERROR: Logfile of failure stored in: /home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/temp/log.do_patch.5091
ERROR: Task (/home/ravi_uppada/work/vm/sato/poky/meta/recipes-bsp/u-boot/u-boot_2020.07.bb:do_patch) failed with exit code '1'



Have added in the path : /DIRECTORY_BUILD/sato/poky/layers/meta-mender/meta-mender-core/recipes-bsp/u-boot
 Have added the lines in this file : u-boot_%.bbappend.

Please help me out this.I have been trying this from very long.Please address this issue.

Thanks,
RAVI_UPPADA


Re: Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

Robert Berger
 

Hi,

My comments are in-line.


On 12/02/2021 14:30, Ross Burton wrote:
The first question is why. It sounds like you want Ubuntu but the
bootloader and kernel built by Yocto. I'm struggling to see what this
would achieve.
... a legal battle maybe?

Bring in the lawyers!

I would also ask:

"What is your use case?"
"Did you ask Canonical?"
"Does Canonical allow you to do this?"

From [1]:

"Copyright licensing[1] and trademarks[3] are two different areas of law, and we consider them separately in Ubuntu. The following policy applies only to copyright licences. We evaluate trademarks on a case-by-case basis."

From [4]:

"
You can download, install and receive updates to Ubuntu for free.

You can modify Ubuntu for personal or internal commercial use.

You can redistribute Ubuntu, but only where there has been no modification to it.

You can use our copyright, patent and design materials in accordance with this IPRights Policy.

You can be confident and can trust in the consistency of the Ubuntu experience.

You can rely on the standard expected of Ubuntu.

Ubuntu is an aggregate work; this policy does not modify or reduce rights granted under licences which apply to specific works in Ubuntu.
"

"
Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu. If you need us to approve, certify or provide modified versions for redistribution you will require a licence agreement from Canonical, for which you may be required to pay. For further information, please contact us (as set out below).
"

"
We do not recommend using modified versions of Ubuntu which are not modified in accordance with this IPRights Policy. Modified versions may be corrupted and users of such modified systems or images may find them to be inconsistent with the updates published by Canonical to its users. If they use the Trademarks, they are in contravention of this IPRights Policy. Canonical cannot guarantee the performance of such modified versions. Canonical’s updates will be consistent with every version of Ubuntu approved, certified or provided by Canonical.
"

"
You can use the Trademarks, in accordance with Canonical’s brand guidelines, with Canonical’s permission in writing. If you require a Trademark licence, please contact us (as set out below).
"

"
You can use the Trademarks in discussion, commentary, criticism or parody, provided that you do not imply endorsement by Canonical.
"

[1] https://ubuntu.com/licensing

[2] https://forum.snapcraft.io/t/commercial-usage-of-snaps-and-dealing-with-licensing/6211

[3] https://ubuntu.com/legal/trademarks

[4] https://ubuntu.com/legal/intellectual-property-policy

Regards,

Robert


Re: Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

Ross Burton <ross@...>
 

The first question is why. It sounds like you want Ubuntu but the
bootloader and kernel built by Yocto. I'm struggling to see what this
would achieve.

On Fri, 12 Feb 2021 at 11:49, <poornesh.g@...> wrote:

Greetings !

I am trying to integrate the ubuntu 20.04 Root file system with the yocto build . Ultimately my final image should consists of :

Bootloader and Kernel : From default yocto build system.

Rootfile system : Should be taken the ubuntu 20.04 RFS.

I am adding the ubuntu 20.04 rfs as a recipe in yocto, but I am failing to integrate this ubuntu RFS over the default yocto root file system.

Requesting your solutions and steps .

Thanks in advance




Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

poornesh.g@...
 

Greetings !

I am trying to integrate the ubuntu 20.04 Root file system with the yocto build . Ultimately my final image should consists of :

Bootloader and Kernel : From default yocto build system.

Rootfile system : Should be taken the ubuntu 20.04 RFS.

I am adding the ubuntu 20.04 rfs as a recipe in yocto, but I am failing to integrate this ubuntu RFS over the default yocto root file system.

Requesting your solutions and steps .

Thanks in advance


Re: How to get packages version from an image recipe #yocto #linux

Nicolas Jeker
 

Hi Zakaria

On Thu, 2021-02-11 at 03:47 -0800, zakaria.zidouh@... wrote:
Hello,
 
I want to get the version of the packages generated by a recipe from
the image recipe (or by a python script that runs outside of the
package generating recipe). (like the output of the bitbake -s
command)
 
Do you have any ideas please? 
Probably the image manifest is what you are looking for?

From
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#image-generation-dev-environment
:

The manifest file (.manifest) resides in the same directory as the root
filesystem image. This file lists out, line-by-line, the installed
packages.

The file contents look like this:

...
dropbear armv7at2hf-neon 2019.78-r0
dtc armv7at2hf-neon 1.6.0-r0
e2fsprogs armv7at2hf-neon 1.45.4-r0
...

Thank you


Re: Dunfell, nodejs and typescript - short experience report

Simon Vogl
 

Hi,


Am 12.02.21 um 11:12 schrieb Josef Holzmayr:
Howdy!

Thanks for sharing, a few comments inline.

Am Fr., 12. Feb. 2021 um 11:03 Uhr schrieb Simon Vogl <simon@...>:
I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@...>
---
 lib/bb/fetch2/npm.py | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
                 cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
                 return runfetchcmd(cmd, d, workdir=workdir)

+            cfg = open(cfgfile, "a")
             if self.configs:
                 for key, value in self.configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    #_run("npm config set %s %s" % (key, shlex.quote(value)))

             if configs:
                 for key, value in configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+            cfg.close()

             if args:
                 for key, value in args:
--
2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...
The main side effect is that you're effectively patching poky, which
is bad for maintenance.
I know, that's why I'm asking in the first place. But performance here is really really improvable.

      
Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging:

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {

     # Configure the main package
     with tempfile.TemporaryDirectory() as tmpdir:
+        # install all (native) build dependencies, overrides npm cache:
+        ret = os.system("npm i")
+        # run build step:
+        env.run("npm run build", args=[], workdir=d.getVar("S"))
+
         tarball = npm_pack(env, d.getVar("S"), tmpdir)
         npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?
Again, patching poky is a bad idea. Creating custom bbclasses is much
neater: you could create a base include, and pull that together with
npm.bbclass into two final bbclasses of yours, like npm-js-voxel and
npm-ts-voxel. The former would not have the compilation step. And,
putting the typescript/webpack invocation into configure is also not
exactly how things are meant to work. I know that the dependency
tracking of npm is not easily compatible with bitbake, but the aim
should be to
1) have a recipe that provides typescript-native
2) DEPEND on typescript-native in the recipe which you need to compile
3) add a do_compile stage that does the work.

Agreed, and I have a patched configure in my own subclass without changing the official codebase -- I just wanted to point where the modification needs to take place.

I actually tried the approach that you propose by playing around with configure_append / compile_prepend tasks, but these build steps are called after the package has already been packed --> the compiled data is not being  installed, I'd have to re-pack things.

Agreed, a typescript-native package would be nice, on the other hand this is where the npm-version-chaos comes in again: Many packages use different tsc versions,...

Simon


Greetz



-- 
VoXel Interaction Design  |  www.voxel.at
DI Dr.techn. Simon Vogl   |  simon@...
Tomaschekweg 46           |  +43 650 2323 555
A-4040 Linz - Austria     |
Office address: Industriezeile 35, 4020 Linz (2nd floor)


Re: Dunfell, nodejs and typescript - short experience report

Josef Holzmayr
 

Howdy!

Thanks for sharing, a few comments inline.

Am Fr., 12. Feb. 2021 um 11:03 Uhr schrieb Simon Vogl <simon@...>:

I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@...>
---
lib/bb/fetch2/npm.py | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
return runfetchcmd(cmd, d, workdir=workdir)

+ cfg = open(cfgfile, "a")
if self.configs:
for key, value in self.configs:
- _run("npm config set %s %s" % (key, shlex.quote(value)))
+ cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+ #_run("npm config set %s %s" % (key, shlex.quote(value)))

if configs:
for key, value in configs:
- _run("npm config set %s %s" % (key, shlex.quote(value)))
+ cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+ # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+ cfg.close()

if args:
for key, value in args:
--
2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...
The main side effect is that you're effectively patching poky, which
is bad for maintenance.

Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging:

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {

# Configure the main package
with tempfile.TemporaryDirectory() as tmpdir:
+ # install all (native) build dependencies, overrides npm cache:
+ ret = os.system("npm i")
+ # run build step:
+ env.run("npm run build", args=[], workdir=d.getVar("S"))
+
tarball = npm_pack(env, d.getVar("S"), tmpdir)
npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?
Again, patching poky is a bad idea. Creating custom bbclasses is much
neater: you could create a base include, and pull that together with
npm.bbclass into two final bbclasses of yours, like npm-js-voxel and
npm-ts-voxel. The former would not have the compilation step. And,
putting the typescript/webpack invocation into configure is also not
exactly how things are meant to work. I know that the dependency
tracking of npm is not easily compatible with bitbake, but the aim
should be to
1) have a recipe that provides typescript-native
2) DEPEND on typescript-native in the recipe which you need to compile
3) add a do_compile stage that does the work.

Greetz