On Fri, Dec 11, 2020 at 09:04 AM, Khem Raj wrote:

On 12/11/20 2:26 AM, vijayrakeshmunganda@... wrote:

Hi,

I'm trying to do HTTPS POST using curl with CA certificate, but I got an
error as "curl_easy_perform() failed: Couldn't connect to server". The
same code works on a Linux machine but not on my target board, I can't
understand what I'm missing. I have an active internet connection
without any firewall. Kindly please give any suggestions.

check what all packageconfig is being used are you using gnutls, then
you might want to try nss or openssl and see if that helps.

Thanks & Regards,
Vijay

 Hi Khem Raj,

Thanks for the reply. I had installed openssl and curl, but not gnutls because compilation was successful. I’ll definitely try ur suggestion. Thank you! 

Please correct me if I’m wrong, even if dependent packages are not installed on target system will compilation done successfully? I’m
also facing similar issue with zbar, compilation was successful and perfectly executing on Linux PC, but not my target board even after installing zbar package. 

Thanks & Regards,
Vijay Rakesh. 

On 12/11/20 2:26 AM, vijayrakeshmunganda@gmail.com wrote:

Hi,
I'm trying to do HTTPS POST using curl with CA certificate, but I got an error as "curl_easy_perform() failed: Couldn't connect to server". The same code works on a Linux machine but not on my target board, I can't understand what I'm missing. I have an active internet connection without any firewall. Kindly please give any suggestions.

check what all packageconfig is being used are you using gnutls, then you might want to try nss or openssl and see if that helps.

Thanks & Regards,
Vijay

On 12/11/20 6:41 AM, Romain Crausaz wrote:

I kept looking and I get the same error with the sdio overlay when I remove the sc16is752.

I think the content of IMAGE_BOOT_FILES would be right place to start looking into the issue.

bitbake -e <yourimage> | grep -e "^IMAGE_BOOT_FILES="

might give more insights into this variable's contents and see if the syntax is ok or not.

On Fri, Dec 11, 2020 at 10:55 AM Joshua Watt <jpewhacker@gmail.com> wrote:

On 12/11/20 9:16 AM, Bruce Ashfield wrote:

On Fri, Dec 11, 2020 at 9:48 AM Joshua Watt <JPEWhacker@gmail.com> wrote:

Fixes the serial port output stopping mid way through the boot process
by reverting the kernel commit that caused it.

If you want, I can also pick this up and merge it directly into
linux-yocto and do a SRCREV bump.

Have you tested against 5.10 ? I'm working through issues with it now,
and it would be nice to fix this before it pops up again on the next
reference kernel bump.

When I use `linux-yocto-dev` as the kernel provider, it works just fine
(in fact, I can't seem to find the commit that *fixes* the problem
there....), so I think 5.10 will be OK? Is there something else I should
try instead?

Nope, that should be enough to show that it has already been addressed
upstream. By default, you'll get a v5.10-rc with -dev in master, so
that confirms the fix.

I'm not sure if we want to backport it to linux-yocto or not... I
presume upstream backported it because it fixed something, so I'd be a
little worried about a regression somewhere else.

True that. And the time spent to prove that, or identify the fix isn't
worth it (since 5.8 is going away). If this was a longer term
version, I'd create a BSP branch and we could isolate it that way, but
again, just not worth the wrangling.

Bruce

Cheers,

Bruce

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
...-resolve-supply-after-creating-regul.patch | 53 +++++++++++++++++++
recipes-kernel/linux/linux-yocto_5.8.bbappend | 4 ++
2 files changed, 57 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
create mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
new file mode 100644
index 0000000..3dd336b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
@@ -0,0 +1,53 @@
+From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@gmail.com>
+Date: Thu, 10 Dec 2020 15:59:47 -0600
+Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
+
+This commit prevents the serial console from working on the Rock Pi 4
+for some reason. It *appears* to possibly be fixed by some other commit
+upstream, but after a lot of head scratching and bisecting, I was unable
+to find which one, so just revert it for now and we can deal with it
+later.
+
+This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
+
+---
+ drivers/regulator/core.c | 21 ++++++++-------------
+ 1 file changed, 8 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
+index 25e601bf9383..be8c709a7488 100644
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc *regulator_desc,
+ else if (regulator_desc->supply_name)
+ rdev->supply_name = regulator_desc->supply_name;
+
++ /*
++ * Attempt to resolve the regulator supply, if specified,
++ * but don't return an error if we fail because we will try
++ * to resolve it again later as more regulators are added.
++ */
++ if (regulator_resolve_supply(rdev))
++ rdev_dbg(rdev, "unable to resolve supply\n");
++
+ ret = set_machine_constraints(rdev, constraints);
+- if (ret == -EPROBE_DEFER) {
+- /* Regulator might be in bypass mode and so needs its supply
+- * to set the constraints */
+- /* FIXME: this currently triggers a chicken-and-egg problem
+- * when creating -SUPPLY symlink in sysfs to a regulator
+- * that is just being created */
+- ret = regulator_resolve_supply(rdev);
+- if (!ret)
+- ret = set_machine_constraints(rdev, constraints);
+- else
+- rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+- ERR_PTR(ret));
+- }
+ if (ret < 0)
+ goto wash;
+
+--
+2.29.2
+
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend b/recipes-kernel/linux/linux-yocto_5.8.bbappend
new file mode 100644
index 0000000..5a31842
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.8.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append_rock-pi-4 = " file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
+
--
2.29.2

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

On 12/11/20 9:16 AM, Bruce Ashfield wrote:

On Fri, Dec 11, 2020 at 9:48 AM Joshua Watt <JPEWhacker@gmail.com> wrote:

Fixes the serial port output stopping mid way through the boot process
by reverting the kernel commit that caused it.

If you want, I can also pick this up and merge it directly into
linux-yocto and do a SRCREV bump.

Have you tested against 5.10 ? I'm working through issues with it now,
and it would be nice to fix this before it pops up again on the next
reference kernel bump.

When I use `linux-yocto-dev` as the kernel provider, it works just fine (in fact, I can't seem to find the commit that *fixes* the problem there....), so I think 5.10 will be OK? Is there something else I should try instead?


I'm not sure if we want to backport it to linux-yocto or not... I presume upstream backported it because it fixed something, so I'd be a little worried about a regression somewhere else.

Cheers,

Bruce

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
...-resolve-supply-after-creating-regul.patch | 53 +++++++++++++++++++
recipes-kernel/linux/linux-yocto_5.8.bbappend | 4 ++
2 files changed, 57 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
create mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
new file mode 100644
index 0000000..3dd336b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
@@ -0,0 +1,53 @@
+From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@gmail.com>
+Date: Thu, 10 Dec 2020 15:59:47 -0600
+Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
+
+This commit prevents the serial console from working on the Rock Pi 4
+for some reason. It *appears* to possibly be fixed by some other commit
+upstream, but after a lot of head scratching and bisecting, I was unable
+to find which one, so just revert it for now and we can deal with it
+later.
+
+This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
+
+---
+ drivers/regulator/core.c | 21 ++++++++-------------
+ 1 file changed, 8 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
+index 25e601bf9383..be8c709a7488 100644
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc *regulator_desc,
+ else if (regulator_desc->supply_name)
+ rdev->supply_name = regulator_desc->supply_name;
+
++ /*
++ * Attempt to resolve the regulator supply, if specified,
++ * but don't return an error if we fail because we will try
++ * to resolve it again later as more regulators are added.
++ */
++ if (regulator_resolve_supply(rdev))
++ rdev_dbg(rdev, "unable to resolve supply\n");
++
+ ret = set_machine_constraints(rdev, constraints);
+- if (ret == -EPROBE_DEFER) {
+- /* Regulator might be in bypass mode and so needs its supply
+- * to set the constraints */
+- /* FIXME: this currently triggers a chicken-and-egg problem
+- * when creating -SUPPLY symlink in sysfs to a regulator
+- * that is just being created */
+- ret = regulator_resolve_supply(rdev);
+- if (!ret)
+- ret = set_machine_constraints(rdev, constraints);
+- else
+- rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+- ERR_PTR(ret));
+- }
+ if (ret < 0)
+ goto wash;
+
+--
+2.29.2
+
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend b/recipes-kernel/linux/linux-yocto_5.8.bbappend
new file mode 100644
index 0000000..5a31842
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.8.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append_rock-pi-4 = " file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
+
--
2.29.2

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hi Sateesh,

On Fri, Dec 11, 2020 at 07:14:17AM -0800, sateesh m wrote:

Hi Guys,

I got expansion error during parsing. I want to fix this bug. can anybody know this issue please Update me.

Traceback (most recent call last):
File "Var <PIGZ>", line 1, in <module>
bb.data_smart.ExpansionError: Failure expanding variable PIGZ, expression was -p ${@oe.utils.cpu_count(at_least=2)} which triggered exception TypeError: cpu_count() got an unexpected keyword argument 'at_least'

Are you sure all layers are checked out at the same branch? (e.g.
`dunfell` branch (or a branch with LAYERSERIESCOMPAT in conf/layer.conf
with dunfell in it))?

I suspect there was a change in oe/utils.py that now accepts the
at_least argument but didn't for some time. My guess is that you use a
layer checked out to a more recent version than the one
poky/openembedded-core is checkout out to.

If you've all layers with the same checked out branch (or compatible
branch), please give us the branch you use for each layer you add to
your build so we can check things up.

Cheers,
Quentin

On Fri, Dec 11, 2020 at 9:48 AM Joshua Watt <JPEWhacker@gmail.com> wrote:

Fixes the serial port output stopping mid way through the boot process
by reverting the kernel commit that caused it.

If you want, I can also pick this up and merge it directly into
linux-yocto and do a SRCREV bump.

Have you tested against 5.10 ? I'm working through issues with it now,
and it would be nice to fix this before it pops up again on the next
reference kernel bump.

Cheers,

Bruce

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
...-resolve-supply-after-creating-regul.patch | 53 +++++++++++++++++++
recipes-kernel/linux/linux-yocto_5.8.bbappend | 4 ++
2 files changed, 57 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
create mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
new file mode 100644
index 0000000..3dd336b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
@@ -0,0 +1,53 @@
+From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@gmail.com>
+Date: Thu, 10 Dec 2020 15:59:47 -0600
+Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
+
+This commit prevents the serial console from working on the Rock Pi 4
+for some reason. It *appears* to possibly be fixed by some other commit
+upstream, but after a lot of head scratching and bisecting, I was unable
+to find which one, so just revert it for now and we can deal with it
+later.
+
+This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
+
+---
+ drivers/regulator/core.c | 21 ++++++++-------------
+ 1 file changed, 8 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
+index 25e601bf9383..be8c709a7488 100644
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc *regulator_desc,
+ else if (regulator_desc->supply_name)
+ rdev->supply_name = regulator_desc->supply_name;
+
++ /*
++ * Attempt to resolve the regulator supply, if specified,
++ * but don't return an error if we fail because we will try
++ * to resolve it again later as more regulators are added.
++ */
++ if (regulator_resolve_supply(rdev))
++ rdev_dbg(rdev, "unable to resolve supply\n");
++
+ ret = set_machine_constraints(rdev, constraints);
+- if (ret == -EPROBE_DEFER) {
+- /* Regulator might be in bypass mode and so needs its supply
+- * to set the constraints */
+- /* FIXME: this currently triggers a chicken-and-egg problem
+- * when creating -SUPPLY symlink in sysfs to a regulator
+- * that is just being created */
+- ret = regulator_resolve_supply(rdev);
+- if (!ret)
+- ret = set_machine_constraints(rdev, constraints);
+- else
+- rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+- ERR_PTR(ret));
+- }
+ if (ret < 0)
+ goto wash;
+
+--
+2.29.2
+
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend b/recipes-kernel/linux/linux-yocto_5.8.bbappend
new file mode 100644
index 0000000..5a31842
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.8.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append_rock-pi-4 = " file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
+
--
2.29.2

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hi Guys,


              I got expansion error during parsing. I want to fix this bug. can anybody know this issue please Update me.

Fixes the serial port output stopping mid way through the boot process
by reverting the kernel commit that caused it.

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
...-resolve-supply-after-creating-regul.patch | 53 +++++++++++++++++++
recipes-kernel/linux/linux-yocto_5.8.bbappend | 4 ++
2 files changed, 57 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
create mode 100644 recipes-kernel/linux/linux-yocto_5.8.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
new file mode 100644
index 0000000..3dd336b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-Revert-regulator-resolve-supply-after-creating-regul.patch
@@ -0,0 +1,53 @@
+From a414d39b848002e15531f2538d2b6427ce51d07d Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@gmail.com>
+Date: Thu, 10 Dec 2020 15:59:47 -0600
+Subject: [PATCH] Revert "regulator: resolve supply after creating regulator"
+
+This commit prevents the serial console from working on the Rock Pi 4
+for some reason. It *appears* to possibly be fixed by some other commit
+upstream, but after a lot of head scratching and bisecting, I was unable
+to find which one, so just revert it for now and we can deal with it
+later.
+
+This reverts commit 96c6b5d5775637b3095ef934f871044811fd4db7.
+
+---
+ drivers/regulator/core.c | 21 ++++++++-------------
+ 1 file changed, 8 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
+index 25e601bf9383..be8c709a7488 100644
+--- a/drivers/regulator/core.c
++++ b/drivers/regulator/core.c
+@@ -5187,20 +5187,15 @@ regulator_register(const struct regulator_desc *regulator_desc,
+ else if (regulator_desc->supply_name)
+ rdev->supply_name = regulator_desc->supply_name;
+
++ /*
++ * Attempt to resolve the regulator supply, if specified,
++ * but don't return an error if we fail because we will try
++ * to resolve it again later as more regulators are added.
++ */
++ if (regulator_resolve_supply(rdev))
++ rdev_dbg(rdev, "unable to resolve supply\n");
++
+ ret = set_machine_constraints(rdev, constraints);
+- if (ret == -EPROBE_DEFER) {
+- /* Regulator might be in bypass mode and so needs its supply
+- * to set the constraints */
+- /* FIXME: this currently triggers a chicken-and-egg problem
+- * when creating -SUPPLY symlink in sysfs to a regulator
+- * that is just being created */
+- ret = regulator_resolve_supply(rdev);
+- if (!ret)
+- ret = set_machine_constraints(rdev, constraints);
+- else
+- rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+- ERR_PTR(ret));
+- }
+ if (ret < 0)
+ goto wash;
+
+--
+2.29.2
+
diff --git a/recipes-kernel/linux/linux-yocto_5.8.bbappend b/recipes-kernel/linux/linux-yocto_5.8.bbappend
new file mode 100644
index 0000000..5a31842
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.8.bbappend
@@ -0,0 +1,4 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append_rock-pi-4 = " file://0001-Revert-regulator-resolve-supply-after-creating-regul.patch"
+
--
2.29.2

I kept looking and I get the same error with the sdio overlay when I remove the sc16is752.

---

Romain Crausaz

Development

DIGI SENS Switzerland AG
Freiburgstr. 65
CH-3280 Murten

Telefon: +41 26 672 9876
Email:     romain.crausaz@...

www.digisens.ch

 

Hi, 

I'm trying to do HTTPS POST using curl with CA certificate, but I got an error as "curl_easy_perform() failed: Couldn't connect to server". The same code works on a Linux machine but not on my target board, I can't understand what I'm missing. I have an active internet connection without any firewall. Kindly please give any suggestions.

Thanks & Regards,
Vijay

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.3_M1.rc2. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Friday, December 11.

Thanks,
Sangeeta

Hello All,

This is the full report for yocto-3.2.1.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issues found


Existing bugs observed in this release:

BUG id:14051 - [QA 3.2 M3 RC1] failure in ptest : valgrind.drd and valgrind.helgrind

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14051


Thanks,
Sangeeta

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

Machines not inheriting zephyr-qemuboot did not have
IMGDEPLOYDIR variable set, which is required for building
zephyr-kernel-test-all. The build was fine for qemu-xxx machines,
but for physical boards it failed somewhere inside python code
when .join() got an empty argument incoming from IMGDEPLOYDIR.
Move IMGDEPLOYDIR to zephyr class, so it's defined for
qemu and non-qemu machines.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
---
classes/zephyr-qemuboot.bbclass | 3 ---
classes/zephyr.bbclass | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass
index 39de3f0..5ac1c86 100644
--- a/classes/zephyr-qemuboot.bbclass
+++ b/classes/zephyr-qemuboot.bbclass
@@ -11,9 +11,6 @@ IMAGE_LINK_NAME = "${PN}-image-${MACHINE}"
# Create a link with "-image-" in the name just to keep runqemu happy
QEMU_IMAGE_LINK = "${DEPLOY_DIR_IMAGE}/${PN}-image-${MACHINE}.elf"

-# qemuboot writes into IMGDEPLOYDIR, force to write to DEPLOY_DIR_IMAGE
-IMGDEPLOYDIR = "${DEPLOY_DIR_IMAGE}"
-
CLEANFUNCS += "bootconf_clean"

python bootconf_clean() {
diff --git a/classes/zephyr.bbclass b/classes/zephyr.bbclass
index ead762a..6fceb04 100644
--- a/classes/zephyr.bbclass
+++ b/classes/zephyr.bbclass
@@ -10,6 +10,9 @@ TERMINFO = "${STAGING_DATADIR_NATIVE}/terminfo"
KCONFIG_CONFIG_COMMAND ??= "menuconfig"
ZEPHYR_BOARD ?= "${MACHINE}"

+# qemuboot writes into IMGDEPLOYDIR, force to write to DEPLOY_DIR_IMAGE
+IMGDEPLOYDIR = "${DEPLOY_DIR_IMAGE}"
+
python () {
# Translate MACHINE into Zephyr BOARD
# Zephyr BOARD is basically our MACHINE, except we must use "-" instead of "_"
--
2.25.1

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

Implement do_flash_usb for boards supported by pyocd:

MACHINE=xxx bitbake yyy -c flash_usb

Pyocd support abundance of boards, however for now this
meta-layer supports only one board that can be flashed
using pyocd, that is 96Boards Nitrogen.

Describe the feature in README.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@huawei.com>
---
README.txt | 23 +++++++++++++++++++++++
classes/zephyr-flash-pyocd.bbclass | 16 ++++++++++++++++
conf/machine/96b-nitrogen.conf | 1 +
3 files changed, 40 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..04500af
--- /dev/null
+++ b/classes/zephyr-flash-pyocd.bbclass
@@ -0,0 +1,16 @@
+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')}.elf"
+ 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"
--
2.25.1

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

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@huawei.com>
---
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

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

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@huawei.com>
---
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