Date   

Re: curl_easy_perform() failed: Couldn't connect to server #linux #yocto

Vijay Rakesh Munganda
 

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. 


Re: curl_easy_perform() failed: Couldn't connect to server #linux #yocto

Khem Raj
 

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


Re: [meta-raspberrypi] error with sc16is752-spi0 overlay

Khem Raj
 

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.


Re: [meta-rockchip][PATCH] Fix Rock Pi 4 serial port

Bruce Ashfield
 

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


Re: [meta-rockchip][PATCH] Fix Rock Pi 4 serial port

Joshua Watt
 

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


Re: cpu_count() got an unexpected keyword argument 'at_least'

Quentin Schulz
 

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


Re: cpu_count() got an unexpected keyword argument 'at_least'

Martin Jansa
 

You're probably mixing incompatible branches of different layers - always use the same branch in all layers.

at_least was added in oe-core/dunfell with:


On Fri, Dec 11, 2020 at 4:14 PM sateesh m <sateesh0457@...> 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'


thanking you in advance.

Regards,
Sateesh




Re: [meta-rockchip][PATCH] Fix Rock Pi 4 serial port

Bruce Ashfield
 

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


cpu_count() got an unexpected keyword argument 'at_least'

sateesh m
 

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'


thanking you in advance.

Regards,
Sateesh


[meta-rockchip][PATCH] Fix Rock Pi 4 serial port

Joshua Watt
 

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


Re: [meta-raspberrypi] error with sc16is752-spi0 overlay

Romain Crausaz <romain.crausaz@...>
 

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


[meta-raspberrypi] error with sc16is752-spi0 overlay

Romain Crausaz <romain.crausaz@...>
 

Dear all,

When I try to add the overlay for the sc16is752-spi0 to my image, it fails at the task do_image_wic with the following error:

| ERROR: Malformed boot file entry: sc16is752-spi0.dtbo;

I am using the kernel provided by meta-raspberrypi and add the following to my board configuration:

RPI_KERNEL_DEVICETREE_OVERLAYS += " \
    overlays/uart0.dtbo \
    overlays/sc16is752-spi0.dtbo \
    overlays/sdio.dtbo \
    overlays/i2c-rtc.dtbo \
    "
​I was not able to find anything on this error. 

Thank you.

Best regards
Romain

Romain Crausaz

Development

DIGI SENS Switzerland AG
Freiburgstr. 65
CH-3280 Murten

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


www.digisens.ch

 


curl_easy_perform() failed: Couldn't connect to server #linux #yocto

Vijay Rakesh Munganda
 

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


Re: QA notification for completed autobuilder build (yocto-3.3_M1.rc2)

Sangeeta Jain
 

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

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Thursday, 10 December, 2020 12:51 PM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3_M1.rc2)


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


https://autobuilder.yocto.io/pub/releases/yocto-3.3_M1.rc2


Build hash information:

bitbake: 5775d9463ecedf8681cb6c919b240b80fe70f5a3
meta-arm: 2a530c34199e9aaff2bab1ac53d81f112f34647f
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 7d79beb5093da8adf0f9b106a33d8e0904a50a48
meta-kernel: e5a0723a3f3dadd880893bccf9bff88a9b46843d
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: a55b01a3a1faf9a52d7edad074c76327f637aaa2
poky: f36484e88d21346357bd1fa1bef6fdcc42bed54a



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



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

Sangeeta Jain
 

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

-----Original Message-----
From: Pokybuild User <pokybuild@ubuntu1804-ty-2.yocto.io>
Sent: Tuesday, 8 December, 2020 7:25 AM
To: yocto@lists.yoctoproject.org
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@intel.com>;
richard.purdie@linuxfoundation.org; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>
Subject: QA notification for completed autobuilder build (yocto-3.2.1.rc2)


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


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


Build hash information:

bitbake: fec2b85689bba1d26ad6f376bc11cc29bb27cbe5
meta-arm: afa281b7a997bf265bfe221d1693a8a5bd4a243d
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 5492270c796daf8b7a7cc9cd93880c2bb25523c0
meta-kernel: f9d30c65d08c9cef20d6487a7aff0fff40acc823
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: d11ab9cb77bf91f939035417b757773a5d80242c
poky: 943ef2fad8428f002850e3655a3312e13d0dcb2c



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



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

Wojciech Zmuda
 

Hi Naveen,

I investigated the arduino-101-ble problem and for me it's non trivial to fix. It's not related to the same missing variable that I spotted in the Nitrogen case, but rather there are some inconsistencies with architecture-related variables i.e. PACKAGE_ARCHS and TUNE_xxx. I did not find any way to fix it.

For now I pushed v3 with Nitrogen support. If I find a way to straighten out the Arduino case, I'll push a separate patch set for that.

BTW, I also have 96boards Avenger96 support patch set ready. It depends on one commit from the Nitrogen patch set (Cortex-M4 tune), so I'll send it out right after Nitrogen support is merged.

Regards,
Wojciech


On Thu, 10 Dec 2020 at 08:20, Saini, Naveen Kumar <naveen.kumar.saini@...> wrote:

Hi Wojciech,

 

Yes, testcases are currently being verified only on qemu, so if we can just build testcases for now that should be sufficient. If you are able to flash and execute tests manually on HW, that would work. Please send v3.

 

Can you fix for arduino-101-ble  as well ?

 

Naveen

 

From: Wojciech Żmuda <zmuda.w@...>
Sent: Wednesday, December 9, 2020 11:07 PM
To: Saini, Naveen Kumar <naveen.kumar.saini@...>
Cc: yocto@...
Subject: Re: [yocto] [meta-zephyr][PATCH 5/5] zephyr-flash-pyocd.bbclass: support for flashing via pyocd

 

Hi Naveen,

 

I fixed the missing .hex issue and I'm ready to send v3.

 

I also experimented with your last suggestion, i.e. building test cases with MACHINE=96b-nitrogen and I observed the following:

 

It is possible to build when I provide IMGDEPLOYDIR variable somewhere, e.g. in 96b-nitrogen.conf. However, for other platforms, this variable is provided only in classes/zephyr-qemuboot.bbclass. I've also tried to build test cases for arduino-101-ble and it failed with the following reason:

 

    Error, the PACKAGE_ARCHS variable (all any noarch ${PACKAGE_EXTRA_ARCHS_tune-armv6m} cortexm0-vfp arduino_101_ble) for DEFAULTTUNE (cortexm0) does not contain TUNE_PKGARCH (cortexm0t2-vfp).

 

Additionally, when I provided IMGDEPLOYDIR in 96b-nitrogen.conf, I tried to execute test cases with -c testimage. It failed on running qemu.

 

According to my observations, my understanding is that the test cases are currently designed for being verified on qemu. Do you expect the 96b-nitrogen support to contain automatic test cases execution on the hardware, or just the possibility of building? If it just the matter of building the .elf files (you can flash them manually), then I can push v3 today.

 

Best regards,

Wojciech

 

 

On Tue, 8 Dec 2020 at 02:47, Saini, Naveen Kumar <naveen.kumar.saini@...> wrote:

You have missed few of my comments in v2 !

Regards,
Naveen

-----Original Message-----
From: Saini, Naveen Kumar
Sent: Monday, December 7, 2020 8:06 PM
To: 'Wojciech Zmuda' <zmuda.w@...>; yocto@...
Cc: davide.ricci@...; zbigniew.bodek@...; jaroslaw.marek@...; robert.drab@...; Wojciech Zmuda <wojciech.zmuda@...>
Subject: RE: [yocto] [meta-zephyr][PATCH 5/5] zephyr-flash-pyocd.bbclass: support for flashing via pyocd

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


[meta-zephyr][PATCH v3 5/5] classes: build zephyr-kernel-test-all for non-qemu boards

Wojciech Zmuda
 

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


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

Wojciech Zmuda
 

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


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

Wojciech Zmuda
 

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


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

Wojciech Zmuda
 

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

1421 - 1440 of 53123