Date   

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


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

Wojciech Zmuda
 

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

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@huawei.com>
---
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 v3 0/5] Add 96Boards Nitrogen support

Wojciech Zmuda
 

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

Hello,

v2 -> v3:
- fix accidentally broken QEMU builds. The build failed when do_deploy looked
for .hex files that were generated for physical machines but not for QEMU
(which does not need them). Fix the issue by reverting the change of generating
.hex files. They were introduced for pyocd, but it occurs that pyocd is happy
with ELFs, so this idea of .hex files was removed altogether from this patch set.
Instead, zephyr-flash-pyocd gets ELFs and happily flashes Nitrogen.
- fix building zephyr-kernel-test-all targets for physical boards. Explained in
commit message of patch 5/5.
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

You can also build the test suite i.e. bitbake zephyr-kernel-test-all
and manually flash Nitrogen with images from the deploy directory. They are
not picked up by do_flash_usb implementation from zephyur-flash-pyocd,
as it works with single ELF file with the same name that the target has.
The same limitation is present in the current do_flash_usb implementation
from the zephyr-flash-dfu class.

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


#vmdk with #vmdk #dunfell

chruetli@...
 

Hi,

I switched from warrior to dunfell and want to build an image for Oracles VirtualBox VM.
On warrior there was 'automatically' a hddimg generated on dunfell this is no longer the case. The IMAGE_FSTYPES has to by specified, I use:
WKS_FILE = "virtualbox.wks"
IMAGE_FSTYPES += "wic.vmdk"

This requires me to write an wks file for which I use:
part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024
part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024
bootloader --ptable gpt  --timeout=5  --append="rootfstype=ext4 video=vesafb vga=current console=tty0"

With these settings I get an vmdk image but it fails to boot. I get a "VFS Unable to mount root fs on unknown block(0,0)" dump.

Any ideas?


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

pokybuild@...
 

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: #yocto #zeus -broken atomic modsset #yocto #zeus

Monsees, Steven C (US)
 

I do not see this issue under "rock", is it "zeus"/X11 specific or can it exist across the board depending on what is running in the backgroud ?

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Khem Raj
Sent: Wednesday, December 9, 2020 2:06 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus -broken atomic modsset

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 12/9/20 11:05 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:

So, this is expected ?, no current work around ?
seems that way, I guess you can fix it on X11 side of things

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Khem Raj
Sent: Wednesday, December 9, 2020 2:00 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus -broken atomic modsset

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
I'm building/running zeus 3.0.4 on intel platform...

Can someone tell me why I might be seeing the following error and how
to resolve it ?
https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.62
34-1-daniel.vetter@ffwll.ch/

might give some context


X.Org X Server 1.20.5

X Protocol Version 11, Revision 0

Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64

Current Operating System: Linux sbcb-default
4.19.135-intel-pk-standard
#1 SMP *PREE broken atomic modeset userspace detected, disabling
atomic*

MPT Mon Nov 2 15:55:20 UTC 2020 x86_64

Thanks,

Steve









Re: #yocto #zeus -broken atomic modsset #yocto #zeus

Khem Raj
 

On 12/9/20 11:05 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
So, this is expected ?, no current work around ?
seems that way, I guess you can fix it on X11 side of things
-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Khem Raj
Sent: Wednesday, December 9, 2020 2:00 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus -broken atomic modsset
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.
On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
I'm building/running zeus 3.0.4 on intel platform...

Can someone tell me why I might be seeing the following error and how
to resolve it ?
https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.6234-1-daniel.vetter@ffwll.ch/
might give some context


X.Org X Server 1.20.5

X Protocol Version 11, Revision 0

Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64

Current Operating System: Linux sbcb-default
4.19.135-intel-pk-standard
#1 SMP *PREE broken atomic modeset userspace detected, disabling
atomic*

MPT Mon Nov 2 15:55:20 UTC 2020 x86_64

Thanks,

Steve








Re: #yocto #zeus -broken atomic modsset #yocto #zeus

Monsees, Steven C (US)
 

So, this is expected ?, no current work around ?

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Khem Raj
Sent: Wednesday, December 9, 2020 2:00 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus -broken atomic modsset

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
I'm building/running zeus 3.0.4 on intel platform...

Can someone tell me why I might be seeing the following error and how
to resolve it ?
https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.6234-1-daniel.vetter@ffwll.ch/

might give some context


X.Org X Server 1.20.5

X Protocol Version 11, Revision 0

Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64

Current Operating System: Linux sbcb-default
4.19.135-intel-pk-standard
#1 SMP *PREE broken atomic modeset userspace detected, disabling
atomic*

MPT Mon Nov 2 15:55:20 UTC 2020 x86_64

Thanks,

Steve





Re: #yocto #zeus -broken atomic modsset #yocto #zeus

Khem Raj
 

On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
I’m building/running zeus 3.0.4 on intel platform…
Can someone tell me why I might be seeing the following error and how to resolve it ?
https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.6234-1-daniel.vetter@ffwll.ch/

might give some context

X.Org X Server 1.20.5
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64
Current Operating System: Linux sbcb-default 4.19.135-intel-pk-standard #1 SMP *PREE broken atomic modeset userspace detected, disabling atomic*
MPT Mon Nov 2 15:55:20 UTC 2020 x86_64
Thanks,
Steve

3101 - 3120 of 54795