Date   

Re: Which package provides full featured passwd, adduser, etc?

Lukasz Domowy
 

I looks like it is provided by just 'shadow' recipe:

oe-pkgdata-util list-pkg-files shadow
shadow:
        /etc/default/useradd
        /etc/limits
        /etc/login.access
        /sbin/nologin.shadow
        /sbin/vigr.shadow
        /sbin/vipw.shadow
        /usr/bin/chage
        /usr/bin/chfn.shadow
        /usr/bin/chsh.shadow
        /usr/bin/expiry
        /usr/bin/faillog
        /usr/bin/gpasswd
        /usr/bin/lastlog
        /usr/bin/newgidmap
        /usr/bin/newuidmap
        /usr/bin/passwd.shadow
        /usr/sbin/chgpasswd
        /usr/sbin/chpasswd.shadow
        /usr/sbin/groupadd
        /usr/sbin/groupdel
        /usr/sbin/groupmems
        /usr/sbin/groupmod
        /usr/sbin/grpck
        /usr/sbin/grpconv
        /usr/sbin/grpunconv
        /usr/sbin/logoutd
        /usr/sbin/newusers
        /usr/sbin/pwck
        /usr/sbin/pwconv
        /usr/sbin/pwunconv
        /usr/sbin/useradd
        /usr/sbin/userdel
        /usr/sbin/usermod

However, after adding 'shadow' package to image, nothing changed. Files enumerated above have not been added. Any ideas why?

Best regards,
Lukasz


Re: #uboot Problem compiling u-boot with bitbake #uboot

Andrew Ellis
 

Hi Randy

Thanks again for you help.

I upgraded my build system to Ubuntu 16.04, and this resolved the build errors I was having. There were historical reasons for the build drive being installed with 14.04, but that is no longer necessary. Upgrading to 16.04 cured the build problem.

Kind regards

Andrew

On 06/12/2020 16:56, Randy MacLeod wrote:
On 2020-12-05 6:20 p.m., Andrew Ellis wrote:
Hi Randy

Thank you for your reply.

Doing, "sudo apt install --reinstall coreutils" fixed the problem with test not being found. I'm not sure why it was not on the system, but that error is fixed.

Ah, good.



Unfortunately I've run into another problem when I try and run bitbake, the process fails witht he following error:

 ports/linux/pseudo_wrappers.c:68:16: error: ‘__NR_renameat2’ undeclared (first use in this function)

I'll take another look at that issue in the morning.


You'll need to upgrade to a newer yocto release or cherry-pick:

$ cd ../oe-core.git

$ git log -1 --stat 0fb257121b68f38b40c078150db8f7d0979b7ea5
commit 0fb257121b68f38b40c078150db8f7d0979b7ea5
Author: Richard Purdie <richard.purdie@...>
Date:   Wed Apr 10 19:07:02 2019

    pseudo: Update to gain key bugfixes
   
    Newer distros are using new versions of glibc and coreutils which use the new glibc
    renameat2 function. We need to intercept this for correct functioning of pseudo. This
    is essential to ensure new distros continue to work with the project.
   
    Also, this version has a fix for path/inode cross corruption problems which
    may explain our mysterious locale permissions issues.
   
    Many thanks to Otavio and Peter Seebach for the help in figuring this out and
    fixing it.
   
    Signed-off-by: Richard Purdie <richard.purdie@...>

 meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


$ git tag --contains 0fb257121b68f38b40c078150db8f7d0979b7ea5
2019-04
2019-04-warrior
2019-04.2-warrior
2019-04.3-warrior
2019-04.4-warrior
2019-10
2019-10-zeus
2019-10.1-zeus
2019-10.2-zeus
2019-10.3-zeus
2019-10.4-zeus
2020-04
2020-04-dunfell
2020-04.1-dunfell
2020-04.2-dunfell
2020-04.3-dunfell
2020-10
2020-10-gatesgarth
uninative-2.5
uninative-2.6
uninative-2.7
uninative-2.8
uninative-2.9
yocto-2.7
yocto-3.0
yocto-3.1
yocto-3.2


../Randy



Andrew


On 05/12/2020 20:27, Randy MacLeod wrote:
On 2020-12-05 2:59 p.m., Andrew Ellis wrote:
Hi Randy

Thank you for your reply.

I'm using Ubuntu 14.04 .

After reading what you said about coreutils in your last message, I tried installing coreutils and got a message saying the latest version is installed. Doing "which test" doesn't yield anything. I've looked in /usr/bin/ and there is no sign of test in there.

The version of Yocto Project I'm using is 2.5 "poky"

Andrew

Andrew,

Thanks for the info about your distro and YP version.

It's odd that 'test' isn't part of your coreutils install.
   https://launchpad.net/ubuntu/trusty/+package/coreutils

Is it possible that you have removed it somehow?
If so you could try:

$ sudo apt install --reinstall coreutils
or
$ sudo apt-get install --reinstall coreutils

../Randy




On 05/12/2020 18:54, Randy MacLeod wrote:
On 2020-12-04 7:08 p.m., ajellisuk via lists.yoctoproject.org wrote:
Hi

I'm trying to compile u-boot for an iMX6 board (iMX6-Q7_Plus from MSC technologies), but the compile process fails with the following output:

    ERROR: Unable to start bitbake server
    ERROR: Last 10 lines of server log for this session
(/home/user/msc-yocto-140/msc-ldk/build/1006/bitbake-cookerdaemon.log):
         self.cooker = bb.cooker.BBCooker(self.configuration,
    self.featureset)
       File
"/home/user/msc-yocto-140/msc-ldk/sources/yocto.git/bitbake/lib/bb/cooker.py",
    line 197, in __init__
         self.initConfigurationData()
       File
"/home/user/msc-yocto-140/msc-ldk/sources/yocto.git/bitbake/lib/bb/cooker.py",
    line 356, in initConfigurationData
         self.databuilder.parseBaseConfiguration()
       File
"/home/user/msc-yocto-140/msc-ldk/sources/yocto.git/bitbake/lib/bb/cookerdata.py",
    line 317, in parseBaseConfiguration
         raise bb.BBHandledException
    bb.BBHandledException
    ERROR: The following required tools (as specified by HOSTTOOLS)
    appear to be unavailable in PATH, please install them in order to
    proceed:
       test

    ERROR: bitbake u-boot-imx -c compile –f

I have had errors like this before, and have been to resolve by installing the missing tools indicated. The problem that I've got here is that I'm not sure what "test" is referring to. using, "sudo apt-get install test", doesn't work.

Can someone please give me a hint as to what the problem is here.

Hi Andrew,

It seems odd that you don't have coreutils/test already...
Test is part of coreutils on Ubuntu-20.04:

$ which test
/usr/bin/test
$ dpkg -S /usr/bin/test
coreutils: /usr/bin/test

What distro are you using for your build machine and
have you installed the suggested packages?
See the quick start guide and links therein:

https://docs.yoctoproject.org/brief-yoctoprojectqs/brief-yoctoprojectqs.html

https://docs.yoctoproject.org/ref-manual/ref-system-requirements.html#supported-linux-distributions

Also, if you could mention the layers and version of YP code
that you are using that could be helpful in general although
for this issue it shouldn't matter.


../Randy



Thanks in advance

Andrew








-- 
# Randy MacLeod
# Wind River Linux



-- 
# Randy MacLeod
# Wind River Linux





Re: QA notification for completed autobuilder build (yocto-3.2.1.rc1)

Richard Purdie
 

On Mon, 2020-12-07 at 16:15 +0000, Pokybuild User wrote:
A build flagged for QA (yocto-3.2.1.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2.1.rc1


Build hash information:

bitbake: fec2b85689bba1d26ad6f376bc11cc29bb27cbe5
meta-arm: 03f2d78e456160f8f6f1ffe693a7bd1ad123e5d5
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 5492270c796daf8b7a7cc9cd93880c2bb25523c0
meta-kernel: f9d30c65d08c9cef20d6487a7aff0fff40acc823
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: e525592e83062ed9a9b2d3cb37c8dbbcfe8759a9
poky: 333f24caec0bb498804dd77cbe762f2f4d9b2225
I'm building an rc2 as build-appliance was mis-configured in this
build.

Cheers,

Richard


Which package provides full featured passwd, adduser, etc?

Lukasz Domowy
 

Hi All,

I'd like to replace busybox passwd, adduser (and friends) with full featured equivalents supporting --root option. Probably I overlooked something, but I cannot find right package to include in my rootfs. At my Ubuntu host those are parts of shadow-utils. What is the right package in Yocto?
Thank you in advance.

Best regards,
Lukasz


IoT Long Term support Linux - Opening to the community of Redpesk@SEA the open source "Marine Grade Linux" by IoT.bzh.

Dominig ar Foll (Intel Open Source) <dominig.arfoll@...>
 

Hello,
As Marine requirement is very very close of any IoT (very) long term Linux requirement with high level of security and application isolation, I thought that this webinar from the Linux Fundation might be of interest to some of you...

The Marine Grade Linux project by IoT.bzh addresses smart ship provides a customized flavor of AGL that addresses marine specific requirements. For signaling, NMEA2000, CanOpen, Ethercat and Modbus were added. Cloud connectivity is designed to handle random connectivity with a balance of 4/5G and satellite data link. Some core marine services as nautical charts, safe routing, or radar are still under development and should be added in the near future. Last but not least, a 30 years old ship is pretty common and maintenance/update on 15 years is required.

This presentation exposes the outcome of the three marine projects IoT.bzh is currently developing for this industry. It starts exposing gaps in business models, then exposes some of the technical specificities (signaling, SOTA, LTS, …). Finally it introduces redpesk@sea the ready-to-use “Marine Grade Linux” version that IoT.bzh will propose as Christmas gift to the maritime open-source community.

-- 
Dominig ar Foll
Senior Software Architect


meta-kernel -> meta-linux-mainline

 

Hi all,

Just a quick announcement. The meta-kernel layer has been renamed to
meta-linux-mainline to avoid any confusion. The new URL for the layer
is https://gitlab.com/openembedded/community/meta-linux-mainline. The
old URL (https://gitlab.com/openembedded/community/meta-kernel) will
still work as a redirect.

For the dunfell and gatesgarth branches I will not be changing the
contents of layer.conf so the layer will continue to be known as
"meta-kernel" internally on those branches. This, coupled with the URL
redirect, should ensure that builds continue to work for the released
branches.

For the master branch, layer.conf has been updated and the layer is
now known as "meta-linux-mainline" internally. If you have
"meta-kernel" in LAYERDEPENDS, you'll need to update it to
"meta-linux-mainline".

Thanks,

--
Paul Barker
Konsulko Group


QA notification for completed autobuilder build (yocto-3.2.1.rc1)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-3.2.1.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2.1.rc1


Build hash information:

bitbake: fec2b85689bba1d26ad6f376bc11cc29bb27cbe5
meta-arm: 03f2d78e456160f8f6f1ffe693a7bd1ad123e5d5
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 5492270c796daf8b7a7cc9cd93880c2bb25523c0
meta-kernel: f9d30c65d08c9cef20d6487a7aff0fff40acc823
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: e525592e83062ed9a9b2d3cb37c8dbbcfe8759a9
poky: 333f24caec0bb498804dd77cbe762f2f4d9b2225



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


[meta-zephyr][PATCH v2 5/5] zephyr-flash-pyocd.bbclass: support for flashing via pyocd

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

Flash boards supported via pyocd:

MACHINE=xxx bitbake yyy -c flash_usb

The only supported board for now is 96Boards Nitrogen. Modify its
config accordingly.

Modify helloworld and philosopers samples with adidtional .hex
output file deployment, as this format is required by pyocd.

Describe the feature in README.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
README.txt | 23 +++++++++++++++++++
classes/zephyr-flash-pyocd.bbclass | 17 ++++++++++++++
conf/machine/96b-nitrogen.conf | 1 +
.../zephyr-kernel/zephyr-helloworld.bb | 1 +
.../zephyr-kernel/zephyr-philosophers.bb | 1 +
5 files changed, 43 insertions(+)
create mode 100644 classes/zephyr-flash-pyocd.bbclass

diff --git a/README.txt b/README.txt
index 6463339..bda872b 100644
--- a/README.txt
+++ b/README.txt
@@ -43,6 +43,29 @@ The same sample, for Nios2 image:
$ MACHINE=qemu-nios2 bitbake zephyr-philosophers
$ runqemu qemu-nios2

+Flashing
+=================================
+
+You can flash Zephyr samples to boards. Currently, the following MACHINEs
+are supported:
+ * DFU:
+ - arduino-101-sss
+ - arduino-101
+ - arduino-101-ble
+ * pyocd:
+ - 96b-nitrogen
+
+To flash the example you built with command e.g.
+
+ $ MACHINE=96b-nitrogen bitbake zephyr-philosophers
+
+call similar command with explicit flash_usb command:
+
+ $ MACHINE=96b-nitrogen bitbake zephyr-philosophers -c flash_usb
+
+dfu-util and/or pyocd need to be installed in your system. If you observe
+permission errors or the flashing process seem to hang, follow those instructions:
+https://github.com/pyocd/pyOCD/tree/master/udev

Building and Running Zephyr Tests
=================================
diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass
new file mode 100644
index 0000000..aafe9e7
--- /dev/null
+++ b/classes/zephyr-flash-pyocd.bbclass
@@ -0,0 +1,17 @@
+
+python do_flash_usb() {
+ from pyocd.core.helpers import ConnectHelper
+ from pyocd.flash.file_programmer import FileProgrammer
+
+ image = f"{d.getVar('DEPLOY_DIR_IMAGE')}/{d.getVar('PN')}.hex"
+ bb.plain(f"Attempting to flash {image} to board {d.getVar('BOARD')}")
+
+ with ConnectHelper.session_with_chosen_probe() as session:
+ FileProgrammer(session).program(image)
+ session.board.target.reset()
+}
+
+addtask do_flash_usb
+
+do_flash_usb[nostamp] = "1"
+do_flash_usb[vardepsexclude] = "BB_ORIGENV"
diff --git a/conf/machine/96b-nitrogen.conf b/conf/machine/96b-nitrogen.conf
index d1905f2..998db4c 100644
--- a/conf/machine/96b-nitrogen.conf
+++ b/conf/machine/96b-nitrogen.conf
@@ -4,4 +4,5 @@
#@DESCRIPTION: Machine configuration for 96Boards Nitrogen Board.

require conf/machine/include/nrf52832.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd"
ARCH_96b-nitrogen = "arm"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
index 1400e72..9b77975 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
@@ -8,6 +8,7 @@ OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.hex ${DEPLOYDIR}/${PN}.hex
}

addtask deploy after do_compile
diff --git a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
index 5f7fbcb..f720999 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
@@ -8,6 +8,7 @@ OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.hex ${DEPLOYDIR}/${PN}.hex
}

addtask deploy after do_compile
--
2.25.1


[meta-zephyr][PATCH v2 4/5] zephyr-kernel: don't limit deploy to .elf file

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

Depending on the target board and/or flashing method, it may be desirable
to have access to .bin or .hex files instead of .elf. Remove .elf extension
from ZEPHYR_MAKE_OUTPUT and let users of that variable specify the extension.

Append .elf to all identified users, since they worked with .elf so far.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
recipes-kernel/zephyr-kernel/zephyr-helloworld.bb | 2 +-
recipes-kernel/zephyr-kernel/zephyr-image.inc | 2 +-
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 4 +++-
recipes-kernel/zephyr-kernel/zephyr-philosophers.bb | 2 +-
4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
index 84db068..1400e72 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
@@ -7,7 +7,7 @@ ZEPHYR_BASE = "${S}"
OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
}

addtask deploy after do_compile
diff --git a/recipes-kernel/zephyr-kernel/zephyr-image.inc b/recipes-kernel/zephyr-kernel/zephyr-image.inc
index e8b8871..48d3675 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-image.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-image.inc
@@ -10,7 +10,7 @@ ZEPHYR_BASE = "${S}"
OECMAKE_SOURCEPATH = "${S}/${ZEPHYR_SRC_DIR}"

do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${ZEPHYR_IMAGENAME}
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${ZEPHYR_IMAGENAME}
}

addtask deploy after do_compile
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index a1f640d..ea6cd7a 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -11,7 +11,9 @@ IMAGE_NO_MANIFEST = "1"
ZEPHYR_GCC_VARIANT="yocto"
ZEPHYR_SYSROOT="${STAGING_DIR_TARGET}"

-ZEPHYR_MAKE_OUTPUT = "zephyr.elf"
+# Output image name. There are several variants i.e. .bin, .elf, .hex.
+# Let the user append desired suffix.
+ZEPHYR_MAKE_OUTPUT = "zephyr"


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"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
index b8262ca..5f7fbcb 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
@@ -7,7 +7,7 @@ ZEPHYR_BASE = "${S}"
OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
- install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
}

addtask deploy after do_compile
--
2.25.1


[meta-zephyr][PATCH v2 3/5] conf: machine: add 96boards Nitrogen support

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

The board is based on Nordic nRF52832 Cortex-M4 chip.
The support depends on Nordic HAL. It has been verified
with zephyr-philosophers and zephyr-shell sample applications.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
conf/machine/96b-nitrogen.conf | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 conf/machine/96b-nitrogen.conf

diff --git a/conf/machine/96b-nitrogen.conf b/conf/machine/96b-nitrogen.conf
new file mode 100644
index 0000000..d1905f2
--- /dev/null
+++ b/conf/machine/96b-nitrogen.conf
@@ -0,0 +1,7 @@
+#@TYPE: Machine
+#@NAME: 96b_nitrogen
+
+#@DESCRIPTION: Machine configuration for 96Boards Nitrogen Board.
+
+require conf/machine/include/nrf52832.inc
+ARCH_96b-nitrogen = "arm"
--
2.25.1


[meta-zephyr][PATCH v2 1/5] zephyr-kernel: clone Nordic HAL

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

HAL for Nordic chipsets is one of Zephyr subprojects. It is downloaded
by default by west. Clone the HAL repository so it can be used for
building images for boards with Nordic chips.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
classes/zephyr-kernel-src.bbclass | 7 ++++---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
index d245223..ea9b30b 100644
--- a/classes/zephyr-kernel-src.bbclass
+++ b/classes/zephyr-kernel-src.bbclass
@@ -5,12 +5,13 @@ PREFERRED_VERSION_zephyr-kernel ??= "2.4.0"
SRCREV_FORMAT = "default_cmsis"
SRCREV_default = "7a3b253ced7333f5c0269387a7f3ed1dee69739d"
SRCREV_cmsis = "542b2296e6d515b265e25c6b7208e8fea3014f90"
-
+SRCREV_nordic = "d8a6ea9695ddf792bb18bb6035c13b1daac5d79c"

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 \
- file://0001-cmake-add-yocto-toolchain.patch \
- "
+ git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
+ file://0001-cmake-add-yocto-toolchain.patch \
+ "

PV = "2.4.0+git${SRCPV}"

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 3f82c20..a1f640d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -16,6 +16,7 @@ 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_append_arm = " -DZEPHYR_MODULES=${S}/modules/cmsis"
+EXTRA_OECMAKE_append_nordic = "\;${S}/modules/hal/nordic"
export ZEPHYR_BASE="${S}"


--
2.25.1


[meta-zephyr][PATCH v2 2/5] conf: machine: add support for Nordic nRF52832 Cortex-M4 chip

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

Add include for Cortex-M4 tunes and nRF52832. The nRF config
appends 'nordic' to MACHINEOVERRIDES, so the kernel recipe
can include Nordic HAL when this override is detected.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
conf/machine/include/nrf52832.inc | 10 ++++++++++
conf/machine/include/tune-cortexm4.inc | 19 +++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 conf/machine/include/nrf52832.inc
create mode 100644 conf/machine/include/tune-cortexm4.inc

diff --git a/conf/machine/include/nrf52832.inc b/conf/machine/include/nrf52832.inc
new file mode 100644
index 0000000..73e628a
--- /dev/null
+++ b/conf/machine/include/nrf52832.inc
@@ -0,0 +1,10 @@
+#@TYPE: Machine
+#@NAME: nrf52832
+
+#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52832 (Cortex-M4) SoC.
+
+require conf/machine/include/tune-cortexm4.inc
+
+MACHINEOVERRIDES =. "nordic:"
+
+TUNE_FEATURES = "armv7m cortexm4"
diff --git a/conf/machine/include/tune-cortexm4.inc b/conf/machine/include/tune-cortexm4.inc
new file mode 100644
index 0000000..a823b6b
--- /dev/null
+++ b/conf/machine/include/tune-cortexm4.inc
@@ -0,0 +1,19 @@
+DEFAULTTUNE ?= "cortexm4"
+
+require conf/machine/include/arm/arch-armv7a.inc
+
+TUNEVALID[cortexm4] = "Enable Cortex-M4 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexm4', ' -mcpu=cortex-m4', '', d)}"
+AVAILTUNES += "cortexm4"
+
+TUNEVALID[armv7m] = "Enable Cortex-M4 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7m', ' -march=armv7e-m', '', d)}"
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7m', 'armv7m:', '' ,d)}"
+
+TUNE_PKGARCH_tune-cortexm4 = "cortexm4"
+
+ARMPKGARCH_tune-cortexm4 = "armv7m"
+PACKAGE_EXTRA_ARCHS_tune-cortexm4 ="cortexm4"
+
+TUNE_FEATURES_tune-cortexm4 = "armv7m vfp cortexm4"
+PACKAGE_EXTRA_ARCHS_tune-cortexm4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m-vfp armv7m"
--
2.25.1


[meta-zephyr][PATCH v2 0/5] Add 96Boards Nitrogen support

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

Hello,

v1 -> v2:
- README.txt: fix bad MACHINE examples: change _ to -, i.e. 96b_nitrogen -> 96b-nitrogen

This patch set adds support for the Nitrogen board by 96Boards.
The support consists of:
- adding configs for Cortex-M4, nRF52832 SoC and Nitrogen board,
- adding bbclass with pyocd-based do_flash_usb() implementation.

Tested on Nitrogen and on QEMU so I hope I didn't accidentally
break anything.

Verification:
1. Install pyocd.
2. Connect Nitrogen and make sure you can see Bus 001 Device 004: ID 0d28:0204 NXP ARM mbed
in lsusb.
3. Build a sample app:
$ MACHINE=96b-nitrogen DISTRO=zephyr bitbake zephyr-philosophers
4. Flash app to the board:
$ MACHINE=96b-nitrogen DISTRO=zephyr bitbake zephyr-philosophers -c flash_usb

Wojciech Zmuda (5):
zephyr-kernel: clone Nordic HAL
conf: machine: add support for Nordic nRF52832 Cortex-M4 chip
conf: machine: add 96boards Nitrogen support
zephyr-kernel: don't limit deploy to .elf file
zephyr-flash-pyocd.bbclass: support for flashing via pyocd

README.txt | 23 +++++++++++++++++++
classes/zephyr-flash-pyocd.bbclass | 17 ++++++++++++++
classes/zephyr-kernel-src.bbclass | 7 +++---
conf/machine/96b-nitrogen.conf | 8 +++++++
conf/machine/include/nrf52832.inc | 10 ++++++++
conf/machine/include/tune-cortexm4.inc | 19 +++++++++++++++
.../zephyr-kernel/zephyr-helloworld.bb | 3 ++-
recipes-kernel/zephyr-kernel/zephyr-image.inc | 2 +-
.../zephyr-kernel/zephyr-kernel-common.inc | 5 +++-
.../zephyr-kernel/zephyr-philosophers.bb | 3 ++-
10 files changed, 90 insertions(+), 7 deletions(-)
create mode 100644 classes/zephyr-flash-pyocd.bbclass
create mode 100644 conf/machine/96b-nitrogen.conf
create mode 100644 conf/machine/include/nrf52832.inc
create mode 100644 conf/machine/include/tune-cortexm4.inc

--
2.25.1


Re: [meta-zephyr][PATCH 5/5] zephyr-flash-pyocd.bbclass: support for flashing via pyocd

Naveen Saini
 

Thanks for the patches. Please find my comments below.

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Wojciech Zmuda
Sent: Monday, December 7, 2020 4:15 AM
To: yocto@...
Cc: davide.ricci@...; zbigniew.bodek@...; jaroslaw.marek@...; robert.drab@...; Wojciech Zmuda <wojciech.zmuda@...>
Subject: [yocto] [meta-zephyr][PATCH 5/5] zephyr-flash-pyocd.bbclass: support for flashing via pyocd

Flash boards supported via pyocd:

MACHINE=xxx bitbake yyy -c flash_usb

The only supported board for now is 96Boards Nitrogen. Modify its config accordingly.

Modify helloworld and philosopers samples with adidtional .hex output file deployment, as this format is required by pyocd.

Describe the feature in README.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
README.txt | 23 +++++++++++++++++++
classes/zephyr-flash-pyocd.bbclass | 17 ++++++++++++++
conf/machine/96b-nitrogen.conf | 1 +
.../zephyr-kernel/zephyr-helloworld.bb | 1 +
.../zephyr-kernel/zephyr-philosophers.bb | 1 +
5 files changed, 43 insertions(+)
create mode 100644 classes/zephyr-flash-pyocd.bbclass

diff --git a/README.txt b/README.txt
index 6463339..4366764 100644
--- a/README.txt
+++ b/README.txt
@@ -43,6 +43,29 @@ The same sample, for Nios2 image:
$ MACHINE=qemu-nios2 bitbake zephyr-philosophers
$ runqemu qemu-nios2

+Flashing
+=================================
+
+You can flash Zephyr samples to boards. Currently, the following
+MACHINEs are supported:
+ * DFU:
+ - arduino_101_sss
+ - arduino_101
+ - arduino_101_ble
+ * pyocd:
+ - 96b_nitrogen
+
+To flash the example you built with command e.g.
+
+ $ MACHINE=96b_nitrogen bitbake zephyr-philosophers
[Naveen Saini] Typo here, MACHINE=96b-nitrogen
+
+call similar command with explicit flash_usb command:
+
+ $ MACHINE=96b_nitrogen bitbake zephyr-philosophers -c flash_usb
[Naveen Saini] Same as above

+
+dfu-util and/or pyocd need to be installed in your system. If you
+observe permission errors or the flashing process seem to hang, follow those instructions:
+https://github.com/pyocd/pyOCD/tree/master/udev

Building and Running Zephyr Tests
=================================
diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass
new file mode 100644
index 0000000..aafe9e7
--- /dev/null
+++ b/classes/zephyr-flash-pyocd.bbclass
@@ -0,0 +1,17 @@
+
+python do_flash_usb() {
+ from pyocd.core.helpers import ConnectHelper
+ from pyocd.flash.file_programmer import FileProgrammer
+
+ image = f"{d.getVar('DEPLOY_DIR_IMAGE')}/{d.getVar('PN')}.hex"
+ bb.plain(f"Attempting to flash {image} to board
+ {d.getVar('BOARD')}")
+
+ with ConnectHelper.session_with_chosen_probe() as session:
+ FileProgrammer(session).program(image)
+ session.board.target.reset()
+}
+
+addtask do_flash_usb
+
+do_flash_usb[nostamp] = "1"
+do_flash_usb[vardepsexclude] = "BB_ORIGENV"
diff --git a/conf/machine/96b-nitrogen.conf b/conf/machine/96b-nitrogen.conf index d1905f2..998db4c 100644
--- a/conf/machine/96b-nitrogen.conf
+++ b/conf/machine/96b-nitrogen.conf
@@ -4,4 +4,5 @@
#@DESCRIPTION: Machine configuration for 96Boards Nitrogen Board.

require conf/machine/include/nrf52832.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd"
ARCH_96b-nitrogen = "arm"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
index 1400e72..9b77975 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
@@ -8,6 +8,7 @@ OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.hex
+ ${DEPLOYDIR}/${PN}.hex
}
[Naveen Saini] No *.hex file while building for MACHINE=qemu-x86
Error log: ...build/zephyr/zephyr.hex': No such file or directory


addtask deploy after do_compile
diff --git a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
index 5f7fbcb..f720999 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
@@ -8,6 +8,7 @@ OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.hex
+ ${DEPLOYDIR}/${PN}.hex
}

[Naveen Saini] No *.hex file while building for MACHINE=qemu-x86
Error log: ...build/zephyr/zephyr.hex': No such file or directory

Could you also try to build testcases !!
$ MACHINE=96b-nitrogen bitbake zephyr-kernel-test-all

Build breaks with error: ......build/zephyr/zephyr.elf.elf': No such file or directory

addtask deploy after do_compile
--
2.25.1


"cleanest" way to resolve python2/python3 recipe file install conflicts?

Robert P. J. Day
 

was recently presented with the following issue involving a
zeus-based (actually, wind river LTS19-based -- effectively much the
same) issue.

group wants to move many python2 recipes to python3, but there is
apparently a need to keep python2, including quite a number of the
same recipes that will also be installed as python3 versions, which is
causing the following problem.

as a single example, in trying to install both versions of
"python{2,3}-chardet", it's entirely unsurprising for there to be a
file install conflict as both recipes want to install the same file
"/usr/bin/chardetect":

Error: Transaction check error:

  file /usr/bin/chardetect conflicts between attempted installs of
python-chardet-3.0.4-r0.core2_64and python3-chardet-3.0.4-r0.core2_64

until now, there were very few examples of that, and it was
"resolved" by do_install_append()ing one of the recipes to simply
delete its copy of that executable, leaving the other one. yuck.

given the many more examples of that now showing up, i don't want to
have to start doing that for every recipe conflict. my initial
reaction was to grumble, "are you really, really sure you need both
versions of the same recipe? really? seriously?"

am i overlooking something here? it seems that there are going to be
many dozen examples of that shortly, and i don't want to have to
bbappend every one of them in such a hacky way.

thoughts?

rday


qemu-5.1.0-r0 do_package_write_deb

Dingo <dingo@...>
 

Build Configuration:
BB_VERSION           = "1.49.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "fedora-33"
TARGET_SYS           = "x86_64-overc-linux"
MACHINE              = "intel-corei7-64"
DISTRO               = "overc"
DISTRO_VERSION       = "1.0"
TUNE_FEATURES        = "m64 corei7"
TARGET_FPU           = ""
meta
meta-poky
meta-yocto-bsp       = "HEAD:64a18762f05dcaf525a2c945908b2747897a79df"
meta-oe
meta-python
meta-networking
meta-filesystems
meta-initramfs
meta-multimedia
meta-perl            = "HEAD:a6d9a4adb86bac52ef02731fd9c8c941a6fbf955"
meta-overc
meta-cube            = "HEAD:470c1d77d5d65b10ea6713404042d6a97df022bc"
meta-virtualization  = "HEAD:6049f9abf8cebe6d827b51b63f3b6bcfd462ab99"
meta-security        = "HEAD:d2ceb5e438b3b9c91696c83bf32f2df415a761ab"
meta-selinux         = "HEAD:5a58e87aa998c53527f92b32c3e6bc516a03d9a3"
meta-gnome
meta-xfce            = "HEAD:a6d9a4adb86bac52ef02731fd9c8c941a6fbf955"
meta-intel           = "HEAD:7d79beb5093da8adf0f9b106a33d8e0904a50a48"
meta-cloud-services  = "HEAD:ad57527aff18c3977a4187e001bf89b008d65c92"
meta-awnix           = "<unknown>:<unknown>"
meta-browser         = "master:1aef1b7857bc065c0e350c5732c3f0d69572e9ec"
meta-clang           = "master:1dfc3a905ad0fed7a3b300aa51153365f9950fe7"
meta-rust            = "master:f56fd4ec6835d68c4e9f8a9630963acd34d172e5"
meta-python2         = "<unknown>:<unknown>"

ERROR: qemu-5.1.0-r0 do_package_write_deb: Fatal errors occurred in subprocesses:
Command 'PATH="/var/home/dingo/overc/poky/scripts:/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/recipe-sysroot-native/usr/bin/x86_64-overc-linux:/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/recipe-sysroot/usr/bin/crossscripts:/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/recipe-sysroot-native/usr/sbin:/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/recipe-sysroot-native/usr/bin:/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/recipe-sysroot-native/sbin:/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/recipe-sysroot-native/bin:/var/home/dingo/overc/poky/bitbake/bin:/var/home/dingo/overc/build/tmp/hosttools" dpkg-deb -b /var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/packages-split/qemu-x86_64 /var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/deploy-debs/corei7-64' returned non-zero exit status 2.
Subprocess output:dpkg-deb: error: package name has characters that aren't lowercase alphanums or '-+.'

ERROR: Logfile of failure stored in: /var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/qemu/5.1.0-r0/temp/log.do_package_write_deb.3730245
ERROR: Task (/var/home/dingo/overc/poky/meta/recipes-devtools/qemu/qemu_5.1.0.bb:do_package_write_deb) failed with exit code '1'


npm node-gyp python3 compatibility issue

Marek Belisko
 

Hi,

I'm adding custom npm app using devtool (using poky dunfel) and
hittin build issue like:
TypeError: write() argument must be str, not bytes while trying to
load binding.gyp

To me it seems it's this exact problem described
here:https://github.com/nodejs/node-gyp/issues/2051 as release of
nodejs fits. Do we have fix for that or it's only possible to get it
by bumping node package? Thanks.

BR,

marek


Qftp absent of qt5 and yocto "zeus" #zeus #qt5 #ftp

anthony.marchand@...
 

Hello everyone,

I'm working with Qt5 and I would like to use Qftp QT module on my embedded system, but Yocto project "zeus" seems to don't have the recipe Qftp. Do you know if it exists an alternative or if Qt5 is not compatible with Qftp?

Thanks for all and best reguards.


Re: perl5 do_install() fails (libperl.so: No such file or directory) #dunfell

Nathan Rossi
 

On Fri, 4 Dec 2020 at 23:08, <frank.wolff@...> wrote:

Hi,

I've got a weird problem when trying to build perl5 (from perl_5.30.1.bb, "dunfell" branch): the do_install() fails :

rm: cannot remove '/home/frwol/Sources/yocto/build/tmp/work/core2-64-poky-linux/perl/5.30.1-r0/image//usr/lib/perl5/5.30.1/*/CORE/libperl.so': No such file or directory'

The thing is, there IS a 'libperl.so', which is a symlink, in a "x86_64-linux" subfolder :

$ ls -la /home/frwol/Sources/yocto/build/tmp/work/core2-64-poky-linux/perl/5.30.1-r0/image//usr/lib/perl5/5.30.1/*/CORE/libperl.so

lrwxrwxrwx 1 frank frank 26 2020-12-04 12:23 /home/frwol/Sources/yocto/build/tmp/work/core2-64-poky-linux/perl/5.30.1-r0/image//usr/lib/perl5/5.30.1/x86_64-linux/CORE/libperl.so -> /usr/lib/libperl.so.5.30.0

And if I try to manually delete it using the same command it works :

& rm /home/frwol/Sources/yocto/build/tmp/work/core2-64-poky-linux/perl/5.30.1-r0/image//usr/lib/perl5/5.30.1/*/CORE/libperl.so
& ls -la /home/frwol/Sources/yocto/build/tmp/work/core2-64-poky-linux/perl/5.30.1-r0/image//usr/lib/perl5/5.30.1/*/CORE/libperl.so

zsh: no matches found: /home/frwol/Sources/yocto/build/tmp/work/core2-64-poky-linux/perl/5.30.1-r0/image//usr/lib/perl5/5.30.1/*/CORE/libperl.so

So... I'm kind of confused to tell the truth. My guess is it's related to my setup (or PEBCAK) or else everybody would have encountered this.

$ uname -a
Linux laptop-frwol 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64 GNU/Linux

I've made absolutely no modification whatsoever. I've just cloned the "dunfell" branch from poky and launched a "bitbake perl".
Thanks in advance for your help.
I hit this recently too, on master though. Same distro Debian, likely
similar package versions (testing/unstable).

Just with some preliminary testing this looks like an issue caused by
pseudo, maybe something to do with path length? as I only see the
failure when building nativesdk-perl but not target/native.

Regards,
Nathan


Regards,

Frank.



[meta-zephyr][PATCH 5/5] zephyr-flash-pyocd.bbclass: support for flashing via pyocd

Wojciech Zmuda
 

Flash boards supported via pyocd:

MACHINE=xxx bitbake yyy -c flash_usb

The only supported board for now is 96Boards Nitrogen. Modify its
config accordingly.

Modify helloworld and philosopers samples with adidtional .hex
output file deployment, as this format is required by pyocd.

Describe the feature in README.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
README.txt | 23 +++++++++++++++++++
classes/zephyr-flash-pyocd.bbclass | 17 ++++++++++++++
conf/machine/96b-nitrogen.conf | 1 +
.../zephyr-kernel/zephyr-helloworld.bb | 1 +
.../zephyr-kernel/zephyr-philosophers.bb | 1 +
5 files changed, 43 insertions(+)
create mode 100644 classes/zephyr-flash-pyocd.bbclass

diff --git a/README.txt b/README.txt
index 6463339..4366764 100644
--- a/README.txt
+++ b/README.txt
@@ -43,6 +43,29 @@ The same sample, for Nios2 image:
$ MACHINE=qemu-nios2 bitbake zephyr-philosophers
$ runqemu qemu-nios2

+Flashing
+=================================
+
+You can flash Zephyr samples to boards. Currently, the following MACHINEs
+are supported:
+ * DFU:
+ - arduino_101_sss
+ - arduino_101
+ - arduino_101_ble
+ * pyocd:
+ - 96b_nitrogen
+
+To flash the example you built with command e.g.
+
+ $ MACHINE=96b_nitrogen bitbake zephyr-philosophers
+
+call similar command with explicit flash_usb command:
+
+ $ MACHINE=96b_nitrogen bitbake zephyr-philosophers -c flash_usb
+
+dfu-util and/or pyocd need to be installed in your system. If you observe
+permission errors or the flashing process seem to hang, follow those instructions:
+https://github.com/pyocd/pyOCD/tree/master/udev

Building and Running Zephyr Tests
=================================
diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass
new file mode 100644
index 0000000..aafe9e7
--- /dev/null
+++ b/classes/zephyr-flash-pyocd.bbclass
@@ -0,0 +1,17 @@
+
+python do_flash_usb() {
+ from pyocd.core.helpers import ConnectHelper
+ from pyocd.flash.file_programmer import FileProgrammer
+
+ image = f"{d.getVar('DEPLOY_DIR_IMAGE')}/{d.getVar('PN')}.hex"
+ bb.plain(f"Attempting to flash {image} to board {d.getVar('BOARD')}")
+
+ with ConnectHelper.session_with_chosen_probe() as session:
+ FileProgrammer(session).program(image)
+ session.board.target.reset()
+}
+
+addtask do_flash_usb
+
+do_flash_usb[nostamp] = "1"
+do_flash_usb[vardepsexclude] = "BB_ORIGENV"
diff --git a/conf/machine/96b-nitrogen.conf b/conf/machine/96b-nitrogen.conf
index d1905f2..998db4c 100644
--- a/conf/machine/96b-nitrogen.conf
+++ b/conf/machine/96b-nitrogen.conf
@@ -4,4 +4,5 @@
#@DESCRIPTION: Machine configuration for 96Boards Nitrogen Board.

require conf/machine/include/nrf52832.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd"
ARCH_96b-nitrogen = "arm"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
index 1400e72..9b77975 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb
@@ -8,6 +8,7 @@ OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.hex ${DEPLOYDIR}/${PN}.hex
}

addtask deploy after do_compile
diff --git a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
index 5f7fbcb..f720999 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb
@@ -8,6 +8,7 @@ OECMAKE_SOURCEPATH = "${ZEPHYR_SRC_DIR}"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.elf ${DEPLOYDIR}/${PN}.elf
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT}.hex ${DEPLOYDIR}/${PN}.hex
}

addtask deploy after do_compile
--
2.25.1

5741 - 5760 of 57398