Are you installing qemu into your image though?

Qemu did get larger as it is built with more architectures enabled,
but unless you're installing it in your image it won't make a
difference.

Ross

I have also the tarball but the build will fail later in the configure phase stating:
icedtea7 "Invalid OpenJDK source zip specified".

Is there something more I can try ?

From: Nagesh Shamnur <nagesh.shamnur@...>

Currently only dfu and pyocd flashing are supported. Some boards
such as Arduino Nano 33 BLE can be flashed via bossac which is
released by Arduino repo. Find the installed Arudino version of
bossac and flash using that tool.

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
---
classes/zephyr-flash-bossac.bbclass | 50 +++++++++++++++++++++++++++
conf/machine/arduino-nano-33-ble.conf | 1 +
2 files changed, 51 insertions(+)
create mode 100644 classes/zephyr-flash-bossac.bbclass

diff --git a/classes/zephyr-flash-bossac.bbclass b/classes/zephyr-flash-bossac.bbclass
new file mode 100644
index 0000000..50222d5
--- /dev/null
+++ b/classes/zephyr-flash-bossac.bbclass
@@ -0,0 +1,50 @@
+#@DESCRIPTION: class file to flash boards like Arduino Nano BLE which depends on bossac for flashing
+
+python do_flash_usb() {
+ import shutil
+ import subprocess
+ import serial.tools.list_ports
+
+ # Note: make sure the installed bossac is set to PATH before running flash_usb()
+ # Check if bossac is avaiable for flashing
+ origbbenv = d.getVar("BB_ORIGENV", False)
+ bossac_path = shutil.which("bossac", path=origbbenv.getVar('PATH'))
+
+ if not bossac_path:
+ bb.fatal("ERROR: bossac not found, please install first and add to PATH")
+
+ board = d.getVar('BOARD')
+
+ if board == 'arduino_nano_33_ble':
+ # find the serial port to which board is connected to
+ for port in serial.tools.list_ports.comports():
+ if 'Arduino Nano 33 BLE' in port.description:
+ serial_port = port.device
+ break
+ else:
+ bb.fatal("ERROR: board not connected for flashing. Connect via USB and enable permission to connected port")
+
+ image = "%s/%s.bin" % (d.getVar('DEPLOY_DIR_IMAGE'), d.getVar('PN'))
+
+ command = [bossac_path, '-p', serial_port , '-R', '-e', '-w', '-v', '-b', image]
+ else:
+ bb.fatal("ERROR: Unsupported board %s" % board)
+
+ bb.note("command: %s" % command)
+ bb.plain("Attempting to flash board: %s" % board)
+
+ # Random failure are a possibility here, retry till there is a success for finite times
+ for _ in range(10, 0, -1):
+ try:
+ subprocess.check_call(command)
+ bb.plain("Bossac Flashing board: %s Success " % board)
+ break
+ except subprocess.CalledProcessError as e:
+ bb.warn("Failed to flash %s (error code: %s). Retrying after 1 second..." % (board, e.returncode))
+ time.sleep(1)
+}
+
+addtask do_flash_usb after do_deploy
+
+do_flash_usb[nostamp] = "1"
+do_flash_usb[vardepsexclude] = "BB_ORIGENV"
diff --git a/conf/machine/arduino-nano-33-ble.conf b/conf/machine/arduino-nano-33-ble.conf
index e45cfc2..18ba056 100644
--- a/conf/machine/arduino-nano-33-ble.conf
+++ b/conf/machine/arduino-nano-33-ble.conf
@@ -4,5 +4,6 @@
#@DESCRIPTION: Machine configuration for Arudino nano 33 ble and Arduino nano 33 ble sense

require conf/machine/include/nrf52.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-bossac"
ARCH_arduino-nano-33-ble = "arm"

--
2.25.1

From: Nagesh Shamnur <nagesh.shamnur@...>

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
---
conf/machine/arduino-nano-33-ble.conf | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 conf/machine/arduino-nano-33-ble.conf

diff --git a/conf/machine/arduino-nano-33-ble.conf b/conf/machine/arduino-nano-33-ble.conf
new file mode 100644
index 0000000..e45cfc2
--- /dev/null
+++ b/conf/machine/arduino-nano-33-ble.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: arduino-nano-33-ble
+
+#@DESCRIPTION: Machine configuration for Arudino nano 33 ble and Arduino nano 33 ble sense
+
+require conf/machine/include/nrf52.inc
+ARCH_arduino-nano-33-ble = "arm"
+
--
2.25.1

From: Nagesh Shamnur <nagesh.shamnur@...>

Some boards (e.g. Arduino Nano 33 BLE) require image in bin format
for flashing with `-c flash_usb`. Provide that image along with ELF
image on do_deploy step.

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
Signed-off-by: Stefan Schmidt <stefan.schmidt@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-sample.inc | 4 ++++
2 files changed, 5 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 330fe59..46f19e2 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -12,6 +12,7 @@ ZEPHYR_GCC_VARIANT="yocto"
ZEPHYR_SYSROOT="${STAGING_DIR_TARGET}"

ZEPHYR_MAKE_OUTPUT = "zephyr.elf"
+ZEPHYR_MAKE_BIN_OUTPUT = "zephyr.bin"

EXTRA_OECMAKE = "\
-DZEPHYR_BASE=${S} \
diff --git a/recipes-kernel/zephyr-kernel/zephyr-sample.inc b/recipes-kernel/zephyr-kernel/zephyr-sample.inc
index f7621d1..7b49611 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-sample.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-sample.inc
@@ -9,5 +9,9 @@ do_install[noexec] = "1"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
+ if [ -f ${B}/zephyr/${ZEPHYR_MAKE_BIN_OUTPUT} ]
+ then
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_BIN_OUTPUT} ${DEPLOYDIR}/${PN}.bin
+ fi
}
addtask deploy after do_compile
--
2.25.1

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

This patch set adds support for nRF52-based Arduino boards - Nano 33 BLE and BLE Sense - to
both build and flash Zephyr applications.

The board support itself is a trivial MACHINE config. Flashing is done with a new bbclass, that
is a wrapper around `bossac` flashing tool. One general kernel recipe fix was necessary to produce
and copy over the .bin file, as the flasher requires input in that format. This does not affect
scenarios where .elf file is required.

Tested on an actual Arduino Nano 33 BLE dev board.

Nagesh Shamnur (3):
zephyr-kernel: install .bin image if available
arduino-nano-33-ble.conf: Add Arduino Nano 33 BLE and BLE Sense
support
zephyr-flash-bossac.bbclass: Enable board flashing via bossac

classes/zephyr-flash-bossac.bbclass | 50 +++++++++++++++++++
conf/machine/arduino-nano-33-ble.conf | 9 ++++
.../zephyr-kernel/zephyr-kernel-common.inc | 1 +
.../zephyr-kernel/zephyr-sample.inc | 4 ++
4 files changed, 64 insertions(+)
create mode 100644 classes/zephyr-flash-bossac.bbclass
create mode 100644 conf/machine/arduino-nano-33-ble.conf

--
2.25.1

From: Nagesh shamnur <nagesh.shamnur@...>

Edit the test recipe removing obj_tracing tests that have
been removed from Zephyr 2.6.0 release.

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index b6b4766..78747f9 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -36,7 +36,6 @@ ZEPHYRTESTS = " \
mp \
msgq \
mutex \
- obj_tracing \
pending \
pipe \
poll \
--
2.25.1

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

Transition to Zephyr 2.6.0 broke meta-zephyr test suite. This patch fixes
QEMU Cortex-M3 test suite (MACHINE=qemu-cortex-m3 bitbake zephyr-kernel-test-all -c testimage).

The reason of failure is that the `obj_tracing` test suite has been removed from
Zephyr sources, but it still is referenced in zephyr-kernel-test.inc.

Unfortunately, there are other problems in this area not solved in this path. We'd
like to take the opportunity to report it anyway. The QEMU x86 test suite build
fails because of unimplemented instructions:

| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c: In function 'direct_isr1':
| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c:47:1: sorry, unimplemented: 80387 instructions aren't allowed in an interrupt service routine
| 47 | ISR_DIRECT_DECLARE(direct_isr1)
| | ^~~~~~~~~~~~~~~~~~
| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c: In function 'direct_isr2':
| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c:54:1: sorry, unimplemented: 80387 instructions aren't allowed in an interrupt service routine
| 54 | ISR_DIRECT_DECLARE(direct_isr2)
| | ^~~~~~~~~~~~~~~~~~

The problem above does not occur in case of Cortex-M3 QEMU tests - `interrupt` builds and passes
just fine. We have not investigated this one further.

Nagesh shamnur (1):
zephyr-kernel-test: fix Cortex-M tests failure with 2.6.0 kernel

recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 1 -
1 file changed, 1 deletion(-)

--
2.25.1

From: Davide Ricci <davide.ricci@...>

Blinky is the most referenced sample in Zephyr's documentation and
recall Arduino's first sketch example. This .bb file allows to build
such example.

Signed-off-by: Davide Ricci <davide.ricci@...>
---
recipes-kernel/zephyr-kernel/zephyr-blinky.bb | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-blinky.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-blinky.bb b/recipes-kernel/zephyr-kernel/zephyr-blinky.bb
new file mode 100644
index 0000000..bd5ce4f
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-blinky.bb
@@ -0,0 +1,3 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/basic/blinky"
--
2.25.1

It is still a problem and I have tried everything you suggested.  I am building with Ubuntu 20.4 and that seems to be the issue.

Lots of people use 20.04 so it seems odd that you'd have a problem specific to that host.

 

I have moved on from this, so will no longer require any information.  The problem has been turned over to someone new.

Okay, please encourage them to reply on this thread.

We may not always respond right away but there is usually
someone reading things and in my case, I'll respond eventually.

Thanks,

../Randy

 

From: Randy MacLeod <randy.macleod@...>
Sent: Tuesday, June 8, 2021 8:27 PM
To: Cris Scott <cscott@...>; yocto@...
Subject: Re: [External] [yocto] Bitbake failure

 

On 2021-05-31 6:12 p.m., Cris Scott wrote:

Not sure who to ask about this.

Using https://push.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/lighttpd/lighttpd_1.4.59.bb to build lighttpd, bitbake fails, and I receive tons of messages that look like:

 

ERROR: lighttpd-1.4.59-r0 do_package_qa: QA Issue: /usr/lib/mod_staticfile.so contained in package lighttpd-module-staticfile requires libc.so.6(GLIBC_2.4), but no providers found in RDEPENDS_lighttpd-module-staticfile? [file-rdeps]

 

 

Can someone point me in the right direction to resolve this?

Hi Cris,

It's been a while is this still a problem for you?
If not, how did you fix it?

 

Can you reproduce the error with poky? git://git.yoctoproject.org/poky

What release/commit are you using?

Does it happen when you just run: bitbake lighttpd ?

Does it happen if you mv your sstate-cache (tmp*) directories aside
and do a rebuild?

What's in your local.conf?

For completeness, what is your build host distro (I doubt it matters here.).

 

I built poky from:
7f3c996d30 (HEAD -> master, origin/master, origin/HEAD) lttng-tools: upgrade 2.12.3 -> 2.12.4

on an Ubu-18.04.3 builder, and both:
$ bitbake lighttpd and
$ bitbake core-image-minimal

worked fine with:

grep -v "^$" conf/local.conf  | grep -v "^#"
MACHINE ??= "qemux86-64"
DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
CONF_VERSION = "1"
IMAGE_INSTALL_append = "lighttpd"

../Randy

 

-Bill

 

 

-- 

# Randy MacLeod

# Wind River Linux

 

---

This email has been scanned for spam and viruses by Proofpoint Essentials. Click here to report this email as spam.

-- 
# Randy MacLeod
# Wind River Linux

Hi,

Op 10-06-2021 om 21:06 schreef Trevor Gamblin:

On 2021-06-10 5:22 a.m., Ferry Toth wrote:

**[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Trevor,

Gmane is really messing things up here, sorry about that. I need to create a new thread I'm afraid.

I'd like to your reworked patch.

But note, I reworked it too (but maybe wrongly). I builds like 90% of my image, but fails building cmake-native. Or more accurately it fails do_configure while trying to build a small test program.

Hi,

I've pushed the patch onto my fork of the poky repo at https://github.com/threexc/poky

Let me know how your testing turns out - I am still running tests as well, but it would be good to know how others' attempts turn out, and more changes could still end up being necessary.

Your patch didn't apply clean on Gatesgarth, but fix seemd trivial. With this it builds cmake-native fine, thanks!

You can find it here: https://github.com/htot/meta-intel-edison/commit/8abce2f6f752407c7b2831dabf37cc358ce55bc7

I will check if any other build errors occurs, and if not will try to time image build with and without the patch to compare performance and see if it worth the effort.

- Trevor

Ferry

[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Trevor,

Gmane is really messing things up here, sorry about that. I need to create a new thread I'm afraid.

I'd like to your reworked patch.

But note, I reworked it too (but maybe wrongly). I builds like 90% of my image, but fails building cmake-native. Or more accurately it fails do_configure while trying to build a small test program.

Hi,

I've pushed the patch onto my fork of the poky repo at https://github.com/threexc/poky

Let me know how your testing turns out - I am still running tests as well, but it would be good to know how others' attempts turn out, and more changes could still end up being necessary.

- Trevor

Ferry

I think this will be hard to support unless your applications are self contained and will bring its own runtime as well in that case you can build a SDK from newer releases which matches compiler you need and let them use it, if you want to mix and match then it will require a bit of extra work e.g. check if runtime from newer compiler will still work with older libs/binaries or find a way to package two versions seprately and ensure that existing packages on image can keep using older libs

So our application might be able to be self contained and bring in all of it's own libs and runtime that it needs.  If that case I wouldn't have to supply the sysroot that comes as part of the SDK; I'd just provide the compiled toolchain/compiler with the updated gcc 8.2, right?

On 6/10/21 7:57 AM, greghwang@... wrote:

The backstory is I'm supporting a legacy system built with the Jethro branch and gcc 5.x.  I'm wondering instead of upgrading the underlying yocto layers to a more recent branch like Thud which supports gcc 8.2, is there a way to leave the image built with gcc 5, but build a new cross compiler toolchain use gcc 8.2.  The application team I'm supporting really wants to use C++17 features, and is unable to with gcc 5.x as their crosscompiler.  I would try to put the 2.28 glibc and 8.2 gcc-runtime libraries on the image and rely on forward compatibility of the libs to ensure compatibility with gcc 5.  Otherwise, the image would still be using gcc-5 as the compiler for all the recipes.
I did some experiments on Thud poky and was able to get a different version of gcc in the toolchain by modifying PREFERRED_VERSION_gcc_corss-canadian-${TRANSLATED_TARGET_ARCH}, however I quickly ran into problem trying compile hello-world with g++.  It looked like the compiler was trying to find its header files in
sysroots/aarch64-oe-linux/usr/include/c++/<gcc version>
but now I have a mismatched gcc version from what is on the sysroot and the cross compiler can't find it's headers.
I'm wondering if forcing a different version of gcc in the SDK is even feasible, or maybe I should be looking at external toolchains or some other solution to support my application team's need for an upgraded version of gcc.

I think this will be hard to support unless your applications are self contained and will bring its own runtime as well in that case you can build a SDK from newer releases which matches compiler you need and let them use it, if you want to mix and match then it will require a bit of extra work e.g. check if runtime from newer compiler will still work with older libs/binaries or find a way to package two versions seprately and ensure that existing packages on image can keep using older libs

So usually upgrading to relevant yocto release would be cleanest way to move forward and would be most reliable of all options but if thats not an option then
Perhaps upgrading compiler across the board might be better approach

The backstory is I'm supporting a legacy system built with the Jethro branch and gcc 5.x.  I'm wondering instead of upgrading the underlying yocto layers to a more recent branch like Thud which supports gcc 8.2, is there a way to leave the image built with gcc 5, but build a new cross compiler toolchain use gcc 8.2.  The application team I'm supporting really wants to use C++17 features, and is unable to with gcc 5.x as their crosscompiler.  I would try to put the 2.28 glibc and 8.2 gcc-runtime libraries on the image and rely on forward compatibility of the libs to ensure compatibility with gcc 5.  Otherwise, the image would still be using gcc-5 as the compiler for all the recipes.

I did some experiments on Thud poky and was able to get a different version of gcc in the toolchain by modifying PREFERRED_VERSION_gcc_corss-canadian-${TRANSLATED_TARGET_ARCH}, however I quickly ran into problem trying compile hello-world with g++.  It looked like the compiler was trying to find its header files in

sysroots/aarch64-oe-linux/usr/include/c++/<gcc version>

but now I have a mismatched gcc version from what is on the sysroot and the cross compiler can't find it's headers.

I'm wondering if forcing a different version of gcc in the SDK is even feasible, or maybe I should be looking at external toolchains or some other solution to support my application team's need for an upgraded version of gcc.

Hi All,

When I run : (bitbake -e | grep ^WKS_FILE=) I get: 

WKS_FILE="imx-imx-boot-bootpart.wks.in"

Here is the content:

part u-boot --source rawcopy --sourceparams="file=imx-boot" --ondisk mmcblk --no-table --align ${IMX_BOOT_SEEK}

part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label boot --active --align 8192 --size 64

part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 8192

 

bootloader --ptable msdos

What to add here in order to create a swap partition with size 2G.

Thanks for the help.
Talel